Re: Server time Protocol and CICS
On 13 March 2012 11:08, Paul Gilmartin paulgboul...@aim.com wrote: 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. IBM's multi-user subsystems have a long history of implementing their own services, either on top of or bypassing the OS provided ones. HASP (later JES2) provides a good example, not least because it documented the reasons. It provided its own interval timer services because for the first couple of decades of its existence there was no STIMERM, so each task could have only one outstanding STIMER request. It provided its own DASD space management services because DADSM was such an incredibly poor performer, and the VTOC scheme had limited function. It did its own console commands and messages to avoid waits, and so on and so on. I don't know CICS, but it's of a similar age to HASP, and it seems reasonable that it may have implemented its own services of necessity. Now that many of them are provided by z/OS in a usable form, there's probably a slow change in progress, as there has been with JES2. To be sure, there are cases of subsystems gratuitously implementing their own services that are worse in various senses than the OS ones. Look at the original VSAM catalogues, or VSAM as a whole, for that matter. 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?) It notionally returns immediately, and the LOAD is done under the new subtask, which is the Right Way to do it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
Tony's response deserves high praise, not least because it reflects some historical understanding of how systems evolve. The original design of CICS envisaged making elegant use of the announced facilities of OS/MVT. When the time came to implement CICS 1) some of these facilities were not yet available and 2) some of them did not yet work reliably. The implementers of CICS were thus forced to take a RYO approach. They in effect gutted an MFT partition and installed their own functionally MVT-like facilities in it, calling their storage-management interfacing macros GETMAIN and FREEMAIN, etc., etc. The result was an in many ways a superb table-driven system, one that improved significantly over the succeeding years. Its chief 'defect' was the implementation of its user interfaces as a set of assembly-language macros, which meant that applications run under it had to be written in assembly language. This was 'remedied' in various ways, some elegant and some not, and finally by introducing a 'command'---as opposed to the old 'macro'---level CICS; ultimately it became possible to write CICS APs even in RPG, although these could not be even quasi-reentrant. The major marketing obstacles to its use by other than assembly-language programmers were thus gradually removed. In my own doubtless élitist view CICS never fully recovered from these initiatives. They did enable ribbon clerks to write CICS APs, and opinions about whether that was beneficial differ widely. What is not in my view open to argument is that criticism of the present state of CICS and other such subsystems that is not diachronic is all but certain to be irrelevant. We are all, ineluctably, creatures of our experience. If you don't know the history of CICS, IMS, DB2, whatever, mug it up if you wish to discuss that subsystem; and stai zitt' until you have mastered it. (Controversy will not thus be eliminated or perhaps even much reduced; equally informed views can, do differ sharply; quaint irrelevance will be reduced). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
johnwgilmore0...@gmail.com (John Gilmore) writes: The original design of CICS envisaged making elegant use of the announced facilities of OS/MVT. When the time came to implement CICS 1) some of these facilities were not yet available and 2) some of them did not yet work reliably. The implementers of CICS were thus forced to take a RYO approach. They in effect gutted an MFT partition and installed their own functionally MVT-like facilities in it, calling their storage-management interfacing macros GETMAIN and FREEMAIN, etc., etc. The result was an in many ways a superb table-driven system, one that improved significantly over the succeeding years. Its chief 'defect' was the implementation of its user interfaces as a set of assembly-language macros, which meant that applications run under it had to be written in assembly language. This was 'remedied' in various ways, some elegant and some not, and finally by introducing a 'command'---as opposed to the old 'macro'---level CICS; ultimately it became possible to write CICS APs even in RPG, although these could not be even quasi-reentrant. The major marketing obstacles to its use by other than assembly-language programmers were thus gradually removed. In my own doubtless élitist view CICS never fully recovered from these initiatives. They did enable ribbon clerks to write CICS APs, and opinions about whether that was beneficial differ widely. What is not in my view open to argument is that criticism of the present state of CICS and other such subsystems that is not diachronic is all but certain to be irrelevant. We are all, ineluctably, creatures of our experience. If you don't know the history of CICS, IMS, DB2, whatever, mug it up if you wish to discuss that subsystem; and stai zitt' until you have mastered it. (Controversy will not thus be eliminated or perhaps even much reduced; equally informed views can, do differ sharply; quaint irrelevance will be reduced). I've more characterized that pathlengths for os/360 was so enormous that there was no way to do light-weight operations. CICS effectively batched a large percentage of os/360 operations at startup ... and then used its own lightweight versions for actual operation. Disclaimer: Univ library got ONR grant to do online catalog and used part of the funds to get 2321 datacell. It was also selected for one of the beta test sites for CICS program product (1969) ... and I got tasked for supporting debugging the deployment. Part of the CICS birthing experience was shooting some number of bugs related to the library choosing different BDAM options than the site where CICS was originally developed. misc. past posts mentioning CICS /or BDAM http://www.garlic.com/~lynn/submain.html#cics other cics history (gone 404 but lives on at the wayback machine): http://web.archive.org/web/20080123061613/http://www.yelavich.com/history/toc.htm The Evolution of CICS: CICS Services for Performance (1968) http://web.archive.org/web/20060325095459/http://www.yelavich.com/history/ev196805.htm from above: In the very beginning, CICS attempted to use services provided by the operating system(s) (PCP, MFT and MVT), however it quickly proved to be unacceptable because of the relatively high overhead of those services (CPU cycles and storage consumed with regard to the particular service). ... snip ... I've made similar claims (about large part of design involved countermeasures for heavyweight os/360 services) ... old email Jim Gray wanting me to be take responsibility for consulting with the IMS group when he was leaving for Tandem: http://www.garlic.com/~lynn/2007.html#email8011016 IMS wiki http://en.wikipedia.org/wiki/IBM_Information_Management_System as to DB2 ... original relational/sql was done at sjr on vm370 some number of past posts http://www.garlic.com/~lynn/submain.html#systemr the standard folklore was that we were able to do tech. transfer from sjr to endicott for sql/ds under the radar when the corporation was distracted with the official DBMS product, EAGLE. Then when EAGLE imploded, there was a request about how fast could there be a port to MVS ... eventually turning into DB2. for random other DB2 lore ... one of the people mentioned in this Jan92 meeting in Ellison's conference room claims to have done the SQL/DS transfer from Endicott back to STL http://www.garlic.com/~lynn/95.html#13 ... separate from the SJR work. Additional relational/SQL lore: http://www.mcjones.org/System_R/SQL_Reunion_95/index.html -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
Just curious: what about DB2, MQ, maybe DFSMS, DFSMShsm? What else need to be reset to get DST ? Any clue? -- Radoslaw Skorupka Lodz, Poland W dniu 2012-03-12 23:49, John Norgauer pisze: This weekend we had our mainframe time automatically adjusted to Day Light Time using S.T.P.. However, CICS did not get the time changed automatically. Is CICS still unable to do this(have the time changed automatically)? John Norgauer Senior Systems Programmer -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
it is we have v3.2 and in our sit I use AUTORESETTIME=YES cheers -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, March 12, 2012 8:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Server time Protocol and CICS On Mon, 12 Mar 2012 16:58:44 -0600, Jerry Whitteridge wrote: CICS needs a nudge to pick up the timechange - we issue a F CICSNAME,CEMT-PERFORM RESET Why? Couldn't this be automated with a PARM? To each region following the automatic change (We are on Sysplex Timers) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail is strictly confidential and for the intended use of the addressee only; it may also be legally privileged and/or price sensitive. Notice is hereby given that any disclosure, use or copying of the information by anyone other than the intended recipient is prohibited and may be illegal. If you have received this message in error, please notify the sender immediately by return e-mail. Every reasonable precaution has been taken to ensure that any attachment to this e-mail has been swept for viruses. We accept no liability for any damage sustained as a result of software viruses and advise you carry out your own virus checks before opening any attachment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
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.
_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Paul Jodlowski
Sent: Tuesday, March 13, 2012 6:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Server time Protocol and CICS
it is we have v3.2 and in our sit I use AUTORESETTIME=YES
cheers
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Paul Gilmartin
Sent: Monday, March 12, 2012 8:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Server time Protocol and CICS
On Mon, 12 Mar 2012 16:58:44 -0600, Jerry Whitteridge wrote:
CICS needs a nudge to pick up the timechange - we issue a
F CICSNAME,CEMT-PERFORM RESET
Why? Couldn't this be automated with a PARM?
To each region following the automatic change (We are on Sysplex
Timers)
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@bama.ua.edu with the message: INFO IBM-MAIN
The information contained in this e-mail is strictly confidential and for the
intended use of the addressee only; it may also be legally privileged and/or
price sensitive. Notice is hereby given that any disclosure, use or copying of
the information by anyone other than the intended recipient is prohibited and
may be illegal. If you have received this message in error, please notify the
sender immediately by return e-mail. Every reasonable precaution has been taken
to ensure that any attachment to this e-mail has been swept for viruses. We
accept no liability for any damage sustained as a result of software viruses
and advise you carry out your own virus checks before opening any attachment.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@bama.ua.edu with the message: INFO IBM-MAIN
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
On Tue, 13 Mar 2012 11:46:39 +, 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
Re: Server time Protocol and CICS
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 +, 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
Re: Server time Protocol and CICS
How about a parameter that specifies when to perform the check, say
CHECKTIME=020001 (unless your time zone changes at a different time)?
On Tue, Mar 13, 2012 at 7:42 AM, Paul Gilmartin paulgboul...@aim.com wrote:
On Tue, 13 Mar 2012 11:46:39 +, 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
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
On Tue, 13 Mar 2012 08:50:41 +0100, R.S. r.skoru...@bremultibank.com.pl wrote: Just curious: what about DB2, MQ, maybe DFSMS, DFSMShsm? What else need to be reset to get DST ? Any clue? From some notes I have: The only other IBM thing used to be RMF III, but that was changed (fixed) quite a while ago at the z/OS 1.3 level. Also IMS prior to V6 would need to recycled (and down for an hour in the fall) due to using local time. I hope no one is running an OS level that old that can still support IMS V6. Records in LOGREC are recorded with a time stamp of local time. As a result, records might be produced with duplicate timestamps in the fall, but would not cause any logic problems downstream. Records in SYSLOG are recorded with local timestamps, but, like LOGREC, are cosmetic in nature. I'm sure this is also in the archives, but the use of CA Datacom as part of these CA products changes things a little: JOBTRAC - JOBTRAC and ISERVE should be brought down prior to the time change, then restarted after the clock is reset. For the backward time change in the fall, JOBTRAC needs to be down for an hour because of the checkpoint file. ** What's new with Datacom in the picture here is that prior to restart this command should be issued to the MUF: MODIFY muf_name,TIME_SYNC DISPATCH - Bring down prior to the time change and then restart after the clock is reset. You don't need to wait an hour for the backward time change in the fall. I also had a note for Omegamon II regarding the history task and some reset commands to issue to other tasks, but again, this is very old and I know we haven't done anything with Omegamons going back as far as I can remember now. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
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
Re: Server time Protocol and CICS
Another item worth mentioning, when z/OS changes the time based on an STP change, the message IEA392I is issued. If you have an automation package, you could rite automation that would catch this message and reset the time in CICS. IEA392I description: One or more of the time offset values has changed. These include leap seconds, local time, and daylight savings time offsets. Along these lines, I heard that some Omegamon tasks wanted a time reset command also. The tasks appear to be mostly Omegamon II. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Norgauer Sent: Monday, March 12, 2012 6:50 PM To: IBM-MAIN@bama.ua.edu Subject: Server time Protocol and CICS This weekend we had our mainframe time automatically adjusted to Day Light Time using S.T.P.. However, CICS did not get the time changed automatically. Is CICS still unable to do this(have the time changed automatically)? John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- 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
Re: Server time Protocol and CICS
On Tue, 13 Mar 2012 08:50:41 +0100, R.S. wrote: Just curious: what about DB2, MQ, maybe DFSMS, DFSMShsm? What else need to be reset to get DST ? Any clue? -- http://www-01.ibm.com/support/docview.wss?uid=swg21184270 http://www-01.ibm.com/support/docview.wss?uid=swg21569725 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
F cicsjobn,CEMT PERFORM RESET Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Norgauer Sent: Monday, March 12, 2012 3:50 PM To: IBM-MAIN@bama.ua.edu Subject: Server time Protocol and CICS This weekend we had our mainframe time automatically adjusted to Day Light Time using S.T.P.. However, CICS did not get the time changed automatically. Is CICS still unable to do this(have the time changed automatically)? John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- 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
Re: Server time Protocol and CICS
CICS needs a nudge to pick up the timechange - we issue a F CICSNAME,CEMT-PERFORM RESET To each region following the automatic change (We are on Sysplex Timers) Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Norgauer Sent: Monday, March 12, 2012 3:50 PM To: IBM-MAIN@bama.ua.edu Subject: Server time Protocol and CICS This weekend we had our mainframe time automatically adjusted to Day Light Time using S.T.P.. However, CICS did not get the time changed automatically. Is CICS still unable to do this(have the time changed automatically)? John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
On Mon, 12 Mar 2012 16:58:44 -0600, Jerry Whitteridge wrote: CICS needs a nudge to pick up the timechange - we issue a F CICSNAME,CEMT-PERFORM RESET Why? Couldn't this be automated with a PARM? To each region following the automatic change (We are on Sysplex Timers) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
