CA IDMS IUA EIUA

Expand all | Collapse all

zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

  • 1.  zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    Posted 11-29-2006 10:29 PM
    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


  • 2.  Re:zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    Posted 11-29-2006 10:29 PM
    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
    "I think it is because you have different data types.

    With a character (pic x) field you get the token error.
    With a numeric (pic(9) field you get a syntax error.
    The result of DateOff is something else.

    You may need the following format:
    AND [date-field] > EXTRACT(DATEOFFX(TODAYX(G),'-7'))
    AND [date-field] < EXTRACT(DATEOFFX(TODAYX(G),'-1'))


    Tommy Petersen
    110 Cokesbury Rd
    Room 542H
    Lebanon, NJ 08833

    Phone:
    Internal 200 - 3699
    External (908) 236-3699
    Fax: (908) 236-3692




    Mike Champagne
    <mchampagne@MILNO
    R.COM> To
    Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
    Public Discussion cc
    Forum
    <IDMS-L@LISTSERV. Subject
    IUASSN.COM> Re: OLQ question


    11/30/2006 12:44
    PM


    Please respond to
    IDMS Public
    Discussion Forum
    <IDMS-L@LISTSERV.
    IUASSN.COM>






    Well, who would think to look in the ADS manual for OLQ syntax . . .
    Nevertheless, this did not change the outcome at all. However, since
    that example specifically notes a six-byte date field, I decided to try
    TODAY instead of TODAYX . . . No change as well.

    Replaced the TODAY('G') call nested in both DATEOFF calls with 061130,
    and the error message is the same but now points to token #99 instead of
    #102 as previously.

    This is looking more and more like a parser issue.


  • 3.  Re:zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    Posted 11-29-2006 10:29 PM
    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
    "I think a minus offset (-1) needs to be in quotes.





  • 4.  Re:zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    Posted 11-29-2006 10:29 PM
    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: zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .
    "You may want to consult with your systems programmer on this issue.
    There may be a clock synchronization issue or perhaps an operator issue.
    I vaguely remember having a similar problem a long time ago but can't
    remember the exact details on how operations and/or the systems
    programmer managed to mess things up. BTW, while doing a little
    research for you on IBM's website I did notice the following that may be
    of interest to the entire list:

    http://www.ibm.com/support/alerts/us/

    This is about the change to Daylight Savings Time that is effective next
    year.

    Dan Miley
    Lockheed Martin


  • 5.  Re: zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    Posted 11-30-2006 07:17 AM
    It was obviously late for you too . . . the difference between the times
    is consistently 24'ish seconds -look at the times again; the times in
    BCF are earlier than those from SYSLOG.

    Nevertheless, OK, so the difference is consistent. But WHY is there a
    difference in the first place? That's what is agonizing me . . . And
    this came about because I was doing a ROLL FORWARD of a copy of this
    database to the start of this job, so I grabbed the time from SYSLOG as
    the ""STOP"" time for the EXTRACT JOURNAL - is this a bad idea? Of
    course, in this case, it was . . . but what does everyone else do?

    Nevertheless, thanks for taking the time to respond.

    ------------------------------

    Date: Thu, 30 Nov 2006 15:57:05 +1030
    From: ""Cherlet, Gary (JTS)"" <Cherlet.Gary@SAUGOV.SA.GOV.AU>
    Subject: Re: zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    It was obviously late at night when you looked at this - you may have
    mixed the minutes and seconds up in the IDMS date/time stamp - looks to
    me like the difference between the times is consistently 36'ish seconds.
    I may be wrong - it's been known ;-) HTH

    Cheers - Gary

    step S010 ran (roughly) from 23.33.08 to 23.33.09,

    NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 16 UPD
    00 BGIN 2006-11-25-23.32.44.905409 <<<<<< Only 1 minute out
    23.32.44.905409 = 23.38.08 + 36 seconds >>>>>
    NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 15 UPD
    00 ENDJ 2006-11-25-23.32.44.959296

    step S015 ran (roughly) from 23.33.10 to 23.33.10, and

    NODE SYST0001 RU_ID 0210037297 PGM_ID STEPS015 QUIESCE LEVELS 16 UPD
    00 BGIN 2006-11-25-23.32.46.179976 <<<<<< Only 1 minute out
    23.32.46.179976 = 23.33.10 + 36 seconds >>>>

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

    step S020 ran (roughly) from 23.33.11 to 01.24.50 the next day

    NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16 UPD
    00 BGIN 2006-11-25-23.32.48.611905 <<<<< Only 1 minute out
    23.32.48.611905 = 23.33.11 + 36.4'ish seconds >>>


  • 6.  Re: zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    Posted 11-30-2006 10:47 PM
    It was obviously late for you too . . . the difference between the times
    is consistently 24'ish seconds -look at the times again; the times in
    BCF are earlier than those from SYSLOG.

    Nevertheless, OK, so the difference is consistent. But WHY is there a
    difference in the first place? That's what is agonizing me . . . And
    this came about because I was doing a ROLL FORWARD of a copy of this
    database to the start of this job, so I grabbed the time from SYSLOG as
    the ""STOP"" time for the EXTRACT JOURNAL - is this a bad idea? Of
    course, in this case, it was . . . but what does everyone else do?

    Nevertheless, thanks for taking the time to respond.

    ------------------------------

    Date: Thu, 30 Nov 2006 15:57:05 +1030
    From: ""Cherlet, Gary (JTS)"" <Cherlet.Gary@SAUGOV.SA.GOV.AU>
    Subject: Re: zOS SYSLOG time versus timestamps in IDMS JOURNALs . . .

    It was obviously late at night when you looked at this - you may have
    mixed the minutes and seconds up in the IDMS date/time stamp - looks to
    me like the difference between the times is consistently 36'ish seconds.
    I may be wrong - it's been known ;-) HTH

    Cheers - Gary

    step S010 ran (roughly) from 23.33.08 to 23.33.09,

    NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 16 UPD
    00 BGIN 2006-11-25-23.32.44.905409 <<<<<< Only 1 minute out
    23.32.44.905409 = 23.38.08 + 36 seconds >>>>>
    NODE SYST0001 RU_ID 0210037295 PGM_ID STEPS010 QUIESCE LEVELS 15 UPD
    00 ENDJ 2006-11-25-23.32.44.959296

    step S015 ran (roughly) from 23.33.10 to 23.33.10, and

    NODE SYST0001 RU_ID 0210037297 PGM_ID STEPS015 QUIESCE LEVELS 16 UPD
    00 BGIN 2006-11-25-23.32.46.179976 <<<<<< Only 1 minute out
    23.32.46.179976 = 23.33.10 + 36 seconds >>>>

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

    step S020 ran (roughly) from 23.33.11 to 01.24.50 the next day

    NODE SYST0001 RU_ID 0210037298 PGM_ID STEPS020 QUIESCE LEVELS 16 UPD
    00 BGIN 2006-11-25-23.32.48.611905 <<<<< Only 1 minute out
    23.32.48.611905 = 23.33.11 + 36.4'ish seconds >>>