On Tue, 13 Mar 2012 07:54:06 -0500, McKown, John wrote: >Going back into the dark days of history, CICS has often done things which the >OS can also do. One thing I remember was it implemented its own version of >program fetch. It would read the directory entry for a program, allocate the >correct amount of storage in the CICS managed DSA (Dynamic Storage Area), then >do BSAM READs to bring in the program as well as perform address relocation. >Why? Because using a OS/360 LOAD macro would cause the entire region to "wait" >while the program was loaded. By doing the function itself, it could do >asynchronous reads and dispatch other transactions while the waiting for the >READ to complete. Remember, this was in the days of very slow SLEDs such as >3330 disk drives and slow machines. > Sigh. Conway's Law. YA case of IBM's implementing valuable function in the wrong layer, thus depriving other components of its use. The proper approach would have been to provide a NOWAIT option to LOAD, with an ECB to be POSTed when the operation completed. Or, simply, for CICS to ATTACH programs and go about its business. (But when does ATTACH return to its caller? Immediately, or after performing a LOAD?)
What does CICS do nowadays about Program Objects: o Use the Program Management API to fetch them? o Use non-GUPIs to fetch them? o Hardware and software (particularly with deferred fetch) are so much faster nowadays that it doesn't matter? o Prohibit use of Program Objects and require Load Modules? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
