Normally it runs later in the morning but due to some file transfers and resultant processing coming from external sites we moved it forward. It produces some kind of report (it's not my program, I just got lumped with investigating the issue for the apps support people). The report header has the date in it, which is used by the recipients.
For example, D T currently shows: RESPONSE=SYSA IEE136I LOCAL: TIME=20.58.51 DATE=2007.235 GMT: RESPONSE=TIME=19.58.51 DATE=2007.235 If it were after midnight, the GMT date stays on 235 for an hour, whilst the local time will have moved on to 236. Our clock always runs on GMT, we SET CLOCK= to put the local time an hour ahead during summer time, then just SET RESET when the clocks go back again. We don't use the offsets in PARMLIB(CLOCKxx) - could that be the reason? As OPC is scheduling on local time we'd like the batch cobol programs to do the same so we don't have to avoid this post-midnight hour during the summer.. I'm sure I can't be the first person ever to hit this problem..? This e-mail message is for the sole use of the intended recipient (s) and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Tranaction Network Services Limited Register No : 2952557 Registered Office: Sheffield Business Park Europa Link Sheffield S9 1XU Directors: R. Low, M Collins, H. Graham (USA), M. Keegan (USA) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
