This topic has been locked.
5 replies Latest Post - 2011-12-20T14:08:27Z by dbzThedinosaur
Pinned topic Processing time overage
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
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 110000D4XK403 PostsACCEPTED ANSWER
Re: Processing time overage2011-12-19T18:38:13Z in response to CLK1I 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.
Re: Processing time overage2011-12-19T21:19:22Z in response to SystemAdminThanks 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.
Re: Processing time overage2011-12-19T21:43:39Z in response to SystemAdminThanks 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 110000D4XK403 PostsACCEPTED ANSWER
Re: Processing time overage2011-12-20T03:33:12Z in response to CLK1One 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:
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 120000FXCN57 PostsACCEPTED ANSWER
Re: Processing time overage2011-12-20T14:08:27Z in response to CLK1you 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.