ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

*DATE not updated during job

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • *DATE not updated during job

    Hi all from the Cleanaway iSeries developer team

    We had a job run for 2+ days which caused a problem with our date-stamps. Our routine uses *date, and we find in the V5R3 manual a new section added: "For an interactive or batch program, the user date special words are set to the value of the job date when the program starts running on the system. The value of the user date special words are not updated during the program execution even if the program runs over midnight or if the job is changed. Use the TIME operation code to obtain the time and date while the program is running"

    Our question is, has this changed since V4Rx or have the values never been updated during execution, and the manual has had a better explanation added?



    Thanks

  • #2
    Re: *DATE not updated during job

    found this in V5R2




    Code:
    Remember the following rules when using the user date: 
    
    •	UDATE, when specified in positions 30 through 43 of the output 
             specifications, prints a 6-character numeric date field. *DATE, 
             when similarly specified, prints an 8-character (4-digit year portion) 
             numeric date field. These special words can be used in three different 
             date formats: 
    
    Month/day/year 
    Year/month/day 
    Day/month/year 
    
    Use the DATEDIT keyword on the control specification to specify the date formats 
    of UDATE and *DATE: 
    
    DATEDIT 	UDATE format 	*DATE format 
    *MDY 	*MDY 	*USA (mmddyyyy) 
    *DMY 	*DMY 	*EUR (ddmmyyyy) 
    *YMD 	*YMD 	*ISO (yyyymmdd) 
    
    Note that the DATEDIT keyword also controls the format of the Y edit code.
    If this keyword is not specified, the default is *MDY. 
    
    •	For an interactive job or batch program, the user date special words are 
             set to the value of the job date when the program starts running in the 
             system. The value of the user date special words are not updated during 
             program processing, even if the program runs past midnight or if the job 
             date is changed. Use the TIME operation code to obtain the time and 
             date while the program is running. 
    
    •	UMONTH, *MONTH, UDAY, *DAY, and UYEAR when specified in positions 
            30 through 43 of the output specifications, print a 2-position numeric date 
            field. *YEAR can be used to print a 4-position numeric date field. Use UMONTH 
            or *MONTH to print the month only, UDAY or *DAY to print the day only, and 
            UYEAR or *YEAR to print the year only. 
    
    •	UDATE and *DATE can be edited when they are written if the Y edit code is 
             specified in position 44 of the output specifications. The 
             DATEDIT(fmt{separator}) keyword on the control specification determines 
            the format and the separator character to be inserted; for example, 
            12/31/88, 31.12.88., 12/31/1988. 
    
    •	UMONTH, *MONTH, UDAY, *DAY, UYEAR and *YEAR cannot be edited by the Y 
             edit code in position 44 of the output specifications. 
    
    •	The user date fields cannot be modified. 
             This means they cannot be used: 
    
    o	In the result field of calculations 
    o	As factor 1 of PARM operations 
    o	As the factor 2 index of LOOKUP operations 
    o	With blank after in output specifications 
    o	As input fields 
    
    •	The user date special words can be used in factor 1 or 
             factor 2 of the calculation specifications for operation codes 
             that use numeric fields. 
    
    •	User date fields are not date data type fields but are numeric fields.
    Ill keep looking for V4R5 info...


    If its just the date I would use

    eval Isodate = %date()

    or eval timestamp = %timestamp()

    by leaving blanks () the system supplies the current values.

    Jamie
    All my answers were extracted from the "Big Dummy's Guide to the As400"
    and I take no responsibility for any of them.

    www.code400.com

    Comment


    • #3
      Re: *DATE not updated during job

      This matches with the V5R3 information. Interesting, we use
      move *date fieldx
      ... are you saying if we use eval fieldx = %date() the date IS updated during execution?

      Comment


      • #4
        Re: *DATE not updated during job

        I use it here all the time. It just looks way cooler than move *date fieldx

        check out this page




        jamie
        All my answers were extracted from the "Big Dummy's Guide to the As400"
        and I take no responsibility for any of them.

        www.code400.com

        Comment


        • #5
          Re: *DATE not updated during job

          It does look cooler. That is a great page. But does it work the same or does using the eval method update the date during the job. I guess it does not, I found a good way to extract date and time from timestamp on your page which I think we will look at using a version of. Thanks Jamie you da man.

          *================================================= ======================
          * INPUT PARAMETERS
          * Description Type Size How Used
          * ----------- ---- ---- --------
          *
          d TimeStamp s z
          d TheDate s d
          d TheTime s t
          *
          * Main Line
          *
          c eval TimeStamp = %timeStamp()
          c eval Thedate = %date(TimeStamp)
          c eval Thetime = %time(TimeStamp)
          c
          *
          c eval *INLR = *on
          Last edited by cleanteam; January 9, 2006, 03:52 AM.

          Comment


          • #6
            Re: *DATE not updated during job

            Correct. *DATE is set to the system date AT THE TIME THE PROGRAM STARTS.

            Eval date = *date will alwys get the date the pgm started

            Eval date = date() gets the actual date at the time the calc line is executed.

            If you want "true" timestamp, use date() time() or timestamp() functions and NOT *Date (or Udate)

            Comment


            • #7
              Re: *DATE not updated during job

              Very clear now thanks all

              Comment


              • #8
                Re: *DATE not updated during job

                *DATE (UDATE) has worked this way at least since the S/36. We always had to use the TIME op code back then in the same circumstances, and it apparently hasn't changed.

                Comment


                • #9
                  Re: *DATE not updated during job

                  That *Date picks the date the batch job was submitted has been useful in our application. That way, even when the job crosses midnight, the customer's invoice shows the date the job was submitted and not the date that particular customer was billed. Uniformity is the word.
                  â??No bird soars too high if he soars with his own wingsâ?? â?? William Blake

                  Comment


                  • #10
                    Re: *DATE not updated during job

                    Originally posted by kc5f
                    *DATE (UDATE) has worked this way at least since the S/36. We always had to use the TIME op code back then in the same circumstances, and it apparently hasn't changed.
                    There are _two_ dates in effect for any program on the system. The system date (Current dater) and the job date (the date the job started).

                    UDATE and *DATE are representations of the Job date and therefore never changes during a job.

                    %Date() is the System date and will therefore always be current.

                    The preponderance of UDATE/*DATE is probably a legacy issue stemming from the days when many (most) users shut their machines down at night and therefore midnight "rollover" wasn't an isse.

                    The big thing to remember is _never_ to use *DATE/UDATE in a CGI or other never ending job!

                    Comment

                    Working...
                    X