We had a job that would display five lines to the console if an error condition were hit. Because of a programming error, the error condition happened many times and the job took nearly 25 minutes to run. We corrected the programming error and since it was not outputting the console messages, the job ran in 9 minutes. Besides encountering the error condition, the batch job was outputting the error message to the console and SYSOUT. Why did outputting a few lines cause the run time to almost triple?
Running a test here using a plain Cobol batch job also exhibited the same behavior. Our job ran for about 13 minutes sending output to the JES Spool and to the Console Log. The supplied sample happened to send out messages 666 times, so we matched that number. Our job took 13 minutes 31 seconds to run. We found the overhead is a result of DISPLAY UPON CONSOLE statements. Our test program was then modified to use a small set of DISPLAY UPON CONSOLE statements (6) and a large number of plain DISPLAY statements (660) but they were redirected via the OUTDD directive and a new DD card was added in the JCL. So OUTDD(ErrDisp) was passed as a compiler directive and the JCL was modified to use: //ERRDISP DD DSN=ERRDISP,DISP=SHR which was catalogued as DSORG=PS,RECFM=F,LRECL=121,BLKSIZE=0 with a character set of ASCII. Our test job ran in 8 seconds instead of 13 minutes 31 seconds. So we suggest, if you can, to try to limit the 'UPON CONSOLE' phrase. Use it for identification and logging purposes, but use a plain DISPLAY for application message details and send it to a dataset for future reference. The cost of an I/O operation is very expensive just like the mainframe. And DISPLAYs with an UPON CONSOLE phrase get routed to both the JES Spool file and the console log so we have doubled the I/O. Since the messages are not being sent to a file, we cannot buffer them, so each one is moved from storage to disk one at a time.
#MFDS
#EnterpriseDeveloper
