Topic
5 replies Latest Post - ‏2011-12-20T14:08:27Z by dbzThedinosaur
CLK1
CLK1
3 Posts
ACCEPTED ANSWER

Pinned topic Processing time overage

‏2011-12-19T17:48:34Z |
I have an issue with a program that runs forever. It does have like 70 million input recs and writes 1 to many output recs for each one, so I know that it's going to take some time, but I know there has to be something in my coding or something I don't know about that can make this run faster. Generally each record is read, compared against the 1st internal (8,000 recs) table using search, then if found then we do a perform until, and the 1st thing there is another table (42,000 recs) search and if found there we go into the main process to search another table (9,000 recs) and get certian info, then we have to take that and run it against the same table (200 recs) twice, the first time to create a total sum from those multiple records then we use that and run each record again through the table search to create a value for each entry, so no, it can't be done in just one search. Then this record is written to the output file, and we start all over with a new extract record. The multiple table searches, even though the largest table is only 42,000 records, are part of what I have been trying to reduce, but to no avail. Each time I think I can remove one I find a reason why it can't be removed and several programmers have looked at this and don't see a way around the necessary internal tables. I already have the BLKSIZE0 in the JCL and Block contains 0 records in the program which helped some but this still runs over 24 hours! I just need to know if there are any best practices that anyone knows that I might try to speed this Hog up? Any suggestions appreciated, thanks.
Updated on 2011-12-20T14:08:27Z at 2011-12-20T14:08:27Z by dbzThedinosaur
  • SystemAdmin
    SystemAdmin
    403 Posts
    ACCEPTED ANSWER

    Re: Processing time overage

    ‏2011-12-19T18:38:13Z  in response to CLK1
    I can only assume that, because you reference JCL and BLKSIZE, that you are talking about a z/OS environment. But, it would be very helpful to someone trying to respond if they knew the compiler - Version and Release - that you are using.

    I would also suggest, if you have not done so already, that you check out the: "Enterprise COBOL Version 4 Release 2 Performance Tuning" document that IBM published last year. It may give you some hints/tips that will help you improve your performance. The document is available from the IBM Support Portal.
    http://www-01.ibm.com/support/docview.wss?rs=203&q=7018287&uid=swg27018287
    • CLK1
      CLK1
      3 Posts
      ACCEPTED ANSWER

      Re: Processing time overage

      ‏2011-12-19T21:19:22Z  in response to SystemAdmin
      Thanks Carl, yes your wright about the z/OS environment. We use a panel driven tool for the compiler so we don't see the options, version or anything, just the listing once it compiles correctly. I am using the performance and tuning guide from IBM, didn't know they published one, and am trying to update using that. Hopefully I can find something there as they really want this program but not at this cost, too much CPU and Runtime (about the same each), and all the Performance and tunning done so far have not reduced too much. I am trying some program updates to help, but am more hopeful from the IBM P&T guide you reference. Thanks for your help.
    • CLK1
      CLK1
      3 Posts
      ACCEPTED ANSWER

      Re: Processing time overage

      ‏2011-12-19T21:43:39Z  in response to SystemAdmin
      Thanks Carl, yes your wright about the z/OS environment. We use a panel driven tool for the compiler so we don't see the options, version or anything, just the listing once it compiles correctly. I am using the performance and tuning guide from IBM, didn't know they published one, and am trying to update using that. Hopefully I can find something there as they really want this program but not at this cost, too much CPU and Runtime (about the same each), and all the Performance and tunning done so far have not reduced too much. I am trying some program updates to help, but am more hopeful from the IBM P&T guide you reference. Thanks for your help.
      • SystemAdmin
        SystemAdmin
        403 Posts
        ACCEPTED ANSWER

        Re: Processing time overage

        ‏2011-12-20T03:33:12Z  in response to CLK1
        One other area that should be carefully evaluated is the LE Run-Time options. In particular, the storage usage. Evaluating the storage usage is really quite easy and requires no changes to the code.

        The LE run-time option, RPTSTG. To turn on storage reporting, simply add:
        PARM='RPTSTG(ON)/'
        to the EXEC JCL statement for the application. Then, look at the report generated to the output file defined by 'MSGFILE' - default: SYSOUT.

        If you are not familiar with the RPTSTG output, more information can be found in the LE Programming Reference, Programming Guide and the LE Debugging Guide. RPTOPTS may also be helpful
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts
    ACCEPTED ANSWER

    Re: Processing time overage

    ‏2011-12-20T14:08:27Z  in response to CLK1
    you mention search but I don't know if that is SEARCH or SEARCH ALL.
    need more info about the COBOL Internal Tables and their relationships,
    try to have the table values sorted, then even if you are using SEARCH and not SEARCH ALL,
    you can get out of the search loop at LESS-THAN.

    I would have a save area for each table's last found key and occurs number,
    and before 'searching' would check the save area.

    since you are file based, your should try to become i/o bound
    and not compute bound.

    try to make large block sizes, and increase the BUFFNO DCB parm according to recommendations in the manualS

    you mention SUMming, so i assume you are doing arithmetics,
    so use packed fields and not display numerics.