ca.portal.admin

zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

Discussion created by ca.portal.admin on Nov 30, 2006
Latest reply on Dec 1, 2006 by ca.portal.admin
Hello again fellow listees . . .

IDMS R15.0 SP2, running under zOS R1.4.

Here's something strange (at least to me):

Given a batch job executing DML-CoBOL steps, based on the display upon
the JES log of SYSIDMS parameters for each step, and the standard JES
'end-of-step' messages:

23.33.00 JOB03518 ---- SATURDAY, 25 NOV 2006 ---- 23.33.00 JOB03518
IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.
23.33.06 JOB03518 ICH70001I IBMUSER LAST ACCESS AT 22:00:06 ON
SATURDAY, NOVEMBER 25, 2006
23.33.06 JOB03518 $HASP373 TESTJOB1 STARTED - INIT F - CLASS C -
SYS SYS1
23.33.06 JOB03518 IEF403I TESTJOB1 - STARTED - TIME=23.33.06
23.33.08 JOB03518 +SYSIDMS parms --> ECHO=ON
23.33.08 JOB03518 +SYSIDMS parms --> DBNAME=PDATA
23.33.08 JOB03518 +SYSIDMS parms --> DICTNAME=PDICT
23.33.08 JOB03518 +SYSIDMS parms --> DMCL=PDMCL
23.33.09 JOB03518 -
TIMINGS (MINS.) ----PAGING COUNTS---
23.33.09 JOB03518 -JOBNAME STEPNAME PROCSTEP RC EXCP CONN
TCB SRB CLOCK SERV PG PAGE SWAP VIO SWAPS
23.33.09 JOB03518 -TESTJOB1 S010 00 370 864
.00 .00 .0 441 0 0 0 0 0
23.33.10 JOB03518 +SYSIDMS parms --> ECHO=ON  23.33.10 JOB03518
SYSIDMS parms --> DBNAME=PDATA  23.33.10 JOB03518  SYSIDMS parms -->
DICTNAME=PDICT 23.33.10 JOB03518 +SYSIDMS parms --> DMCL=PDMCL
23.33.10 JOB03518 -TESTJOB1 S015 00 366 859
.00 .00 .0 434 0 0 0 0 0
23.33.11 JOB03518 +SYSIDMS parms --> ECHO=ON
23.33.11 JOB03518 +SYSIDMS parms --> DBNAME=PDATA
23.33.11 JOB03518 +SYSIDMS parms --> DICTNAME=PDICT
23.33.11 JOB03518 +SYSIDMS parms --> DMCL=PDMCL
00.00.00 JOB03518 ---- SUNDAY, 26 NOV 2006 ----
01.24.50 JOB03518 -TESTJOB1 S020 00 6327 6303
11.95 1.10 111.6 3297K 0 0 0 0 0

one would logically surmise that:

step S010 ran (roughly) from 23.33.08 to 23.33.09, step S015 ran
(roughly) from 23.33.10 to 23.33.10, and step S020 ran (roughly) from
23.33.11 to 01.24.50 the next day

however, output from an IDMSBCF ""EXTRACT JOURNAL"" seems to indicate
otherwise:

NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 16
UPD 00 BGIN 2006-11-25-23.32.44.905409
NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 15
UPD 00 ENDJ 2006-11-25-23.32.44.959296

NODE SYST0001 RU_ID 0210037297 PGM_ID STEPS015 QUIESCE LEVELS 16
UPD 00 BGIN 2006-11-25-23.32.46.179976
NODE SYST0001 RU_ID 0210037297 PGM_ID STEPS015 QUIESCE LEVELS 15
UPD 00 ENDJ 2006-11-25-23.32.46.288765


NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 BGIN 2006-11-25-23.32.48.611905
NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 COMT 2006-11-25-23.32.48.755072
NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 COMT 2006-11-25-23.33.06.971661
NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 COMT 2006-11-25-23.33.17.106128

I can see being ""off"" by a second maybe (i.e. due to I/O delays, etc.),
but over twenty?

Only one of the programs (STEPS020) does a DISPLAY of the current system
TIME on SYSLST when it starts and it is, in fact, 23.32.48, which is
earlier than the time on SYSLOG that the job was SUBMITED, much less
STARTED . . .

Can anyone shed any light on this? Or am I making a mountain out of a
molehill? Is the SYSLOG time possibly ""from somewhere else"" and there's
something ever so slightly amiss in zOS? (not my yob anymore...)

TIA for all thought and replies.

Mike

PELLERIN MILNOR CORPORATION
Michel J Champagne
Systems Analyst / DBA

Voice: 504-712-7589
FAX: 504-712-3589

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized 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.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .
"Hello again fellow listees . . .

IDMS R15.0 SP2, running under zOS R1.4.

Here's something strange (at least to me):

Given a batch job executing DML-CoBOL steps, based on the display upon
the JES log of SYSIDMS parameters for each step, and the standard JES
'end-of-step' messages:

23.33.00 JOB03518 ---- SATURDAY, 25 NOV 2006 ----
23.33.00 JOB03518 IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.
23.33.06 JOB03518 ICH70001I IBMUSER LAST ACCESS AT 22:00:06 ON
SATURDAY, NOVEMBER 25, 2006
23.33.06 JOB03518 $HASP373 TESTJOB1 STARTED - INIT F - CLASS C -
SYS SYS1
23.33.06 JOB03518 IEF403I TESTJOB1 - STARTED - TIME=23.33.06
23.33.08 JOB03518 +SYSIDMS parms --> ECHO=ON
23.33.08 JOB03518 +SYSIDMS parms --> DBNAME=PDATA
23.33.08 JOB03518 +SYSIDMS parms --> DICTNAME=PDICT
23.33.08 JOB03518 +SYSIDMS parms --> DMCL=PDMCL
23.33.09 JOB03518 -
TIMINGS (MINS.) ----PAGING COUNTS---
23.33.09 JOB03518 -JOBNAME STEPNAME PROCSTEP RC EXCP CONN
TCB SRB CLOCK SERV PG PAGE SWAP VIO SWAPS
23.33.09 JOB03518 -TESTJOB1 S010 00 370 864
.00 .00 .0 441 0 0 0 0 0
23.33.10 JOB03518 +SYSIDMS parms --> ECHO=ON
23.33.10 JOB03518 +SYSIDMS parms --> DBNAME=PDATA
23.33.10 JOB03518 +SYSIDMS parms --> DICTNAME=PDICT
23.33.10 JOB03518 +SYSIDMS parms --> DMCL=PDMCL
23.33.10 JOB03518 -TESTJOB1 S015 00 366 859
.00 .00 .0 434 0 0 0 0 0
23.33.11 JOB03518 +SYSIDMS parms --> ECHO=ON
23.33.11 JOB03518 +SYSIDMS parms --> DBNAME=PDATA
23.33.11 JOB03518 +SYSIDMS parms --> DICTNAME=PDICT
23.33.11 JOB03518 +SYSIDMS parms --> DMCL=PDMCL
00.00.00 JOB03518 ---- SUNDAY, 26 NOV 2006 ----
01.24.50 JOB03518 -TESTJOB1 S020 00 6327 6303
11.95 1.10 111.6 3297K 0 0 0 0 0

one would logically surmise that:

step S010 ran (roughly) from 23.33.08 to 23.33.09,
step S015 ran (roughly) from 23.33.10 to 23.33.10, and
step S020 ran (roughly) from 23.33.11 to 01.24.50 the next day

however, output from an IDMSBCF ""EXTRACT JOURNAL"" seems to indicate
otherwise:

NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 16
UPD 00 BGIN 2006-11-25-23.32.44.905409
NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 15
UPD 00 ENDJ 2006-11-25-23.32.44.959296

NODE SYST0001 RU_ID 0210037297 PGM_ID STEPS015 QUIESCE LEVELS 16
UPD 00 BGIN 2006-11-25-23.32.46.179976
NODE SYST0001 RU_ID 0210037297 PGM_ID STEPS015 QUIESCE LEVELS 15
UPD 00 ENDJ 2006-11-25-23.32.46.288765


NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 BGIN 2006-11-25-23.32.48.611905
NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 COMT 2006-11-25-23.32.48.755072
NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 COMT 2006-11-25-23.33.06.971661
NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16
UPD 00 COMT 2006-11-25-23.33.17.106128

I can see being ""off"" by a second maybe (i.e. due to I/O delays, etc.),
but over twenty?

Only one of the programs (STEPS020) does a DISPLAY of the current system
TIME on SYSLST when it starts and it is, in fact, 23.32.48, which is
earlier than the time on SYSLOG that the job was SUBMITED, much less
STARTED . . .

Can anyone shed any light on this? Or am I making a mountain out of a
molehill? Is the SYSLOG time possibly ""from somewhere else"" and there's
something ever so slightly amiss in zOS? (not my yob anymore...)

TIA for all thought and replies.

Mike

PELLERIN MILNOR CORPORATION
Michel J Champagne
Systems Analyst / DBA

Voice: 504-712-7589
FAX: 504-712-3589

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized 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.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: OLQ question
"This is a wild guess since I am not at a shop with IDMS right now, so I don;t have my quick references or access to test it. . .

But if you are checking for 8 digit dates,
Shouldnt the functions be DATEOFFX (I thought the functions without the X at the end were for the two digit years).
(I don't recall about TODAY - whether there is a TODAYX.)

HTH
Cindy Kline

Outcomes