On Thu, 7 Apr 2011 06:53:12 -0400 Angel Luis DomÃnguez <[email protected]> wrote:
:>On Wed, 6 Apr 2011 04:14:54 -0400, Gordon G. Hodson :><[email protected]> wrote: :>>Original posting refers to CSF calls for encryption (processing); such :>>calls generally involve the use of a separate encryption hardware :>>engine/feature which generally has multiple parallel processing :>>capabilities that maybe the COBOL code is taking advantage of. Another :>>possibility is the ASM version is requesting the key more than necessary :>>(resides within a system file accessed by ICSF) â try nullifying the CSF :>>calls and then see which uses the least CPU. :>Thanks a lot Gordon for this valuable notes. I had never thought that the :>CSF may be the cause of CPU consumption because both assm and cobol do the :>same call to the same function. :>I have made a test with and without dynamic calling CSF from assm and cobol :>and the results are surprising, in the expected line. I have used ECO :>function for this test because it doesn't need access to CSF system files. :>For the same number of iterations calling the subprogram, here are the :>results in seconds of CPU: :>ASSM without CSF: 0,503661 :>COBOL without CSF: 6,881114 :>ASSM with CSF: 27,642152 :>COBOL with CSF: 15,630138 :>So it appears, as Gordon points that there are process involved in CSF :>calling that are different from COBOL than from assembler. I can't :>understand this because there is the same dynamic call to CSF module :>residing in LINKLIST. :>I will continue researching this line. LE will LOAD the module on the first call and then BALR the later calls. Change your ASM module to LOAD it and BALR as well. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
