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.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin > Sent: Tuesday, March 13, 2012 7:42 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Server time Protocol and CICS > > On Tue, 13 Mar 2012 11:46:39 +0000, Jousma, David wrote: > > >I just read about that. Not sure it is too helpful, unless > I am mis-understanding it? Time changes at 02:00 local > time, based on what I read, the CICS clock would be off for > the next 22 hours until the next local midnight?: > > > >AUTORESETTIME > >The AUTORESETTIME parameter specifies the action CICS should > take if, at the next local midnight, the CICS time-of-day > differs from the system time-of-day by more than 30 minutes; > for example, setting clocks forward or back to adjust for > summer and winter time. > > > >AUTORESETTIME={NO|YES} > >Valid values are as follows: > >NO > >CICS issues message DFHAP1500 to indicate that a CEMT > PERFORM RESET command is required to synchronize the CICS > time-of-day with the system time-of-day. > >YES > >CICS issues a PERFORM RESET command to synchronize the CICS > time-of-day with the system time-of-day > >Note: Setting clocks back might cause end-of-day statistics > to be written twice. > > > Sigh. Sounds like a powerful argument for performing the RESET > instantaneously instead of at midnight. Or the customer's using > auto ops to issue the RESET command every day at 01:01 and 02:01. > > Why does CICS even have its own time-of-day when there's a perfectly > good system time-of-day it could use? Simpler is better. And why a > 30 minute fuzz? One second should be enough to trigger a RESET. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
