But all of the calls to COBOL programs occur at the aspx program level. No COBOL program calls any other COBOL program. The aspx programs are replacing native COBOL console .exe programs which themselves replaced JCL streams in the original mainframe batch environment. Here's a pseudo code example of what we have so far: task.aspx - open output logfile {write initial log stuff} close logfile try call cblprgm1.dll catch open logfile {write error message} close logfile exit run end-try [ try call cblprgm2.dll catch open logfile {write error message} close logfile exit run end-try . . . ] open extend logfile {write final log stuff} close logfile exit run cblprgm1 - open extend logfile * added because no redirect {process} write log entry * converted from DISPLAY UPON CONSOLE {process} write log entry * converted from DISPLAY UPON CONSOLE . . . close logfile * added because no redirect exit program cblprgm2 - open extend logfile * added because no redirect {process} write log entry * converted from DISPLAY UPON CONSOLE {process} write log entry * converted from DISPLAY UPON CONSOLE . . . close logfile * added because no redirect exit program Each of our 60+ aspx tasks makes from 1-85 calls to COBOL programs. Each COBOL program performs its function and returns to the calling aspx program. In this situation, would we start a run unit for each call and terminate it after each return? Would the dd_ environment variables set by the aspx program be accessible to the MF file handler inside the run unit?
↧
