IBM Support

Semantics of UDATE and *DATE in IBM RPG/400 and ILE RPG

Troubleshooting


Problem

This document clarifies some potential misunderstandings about the semantics of UDATE (6-digit date) and *DATE (8-digit date).

Resolving The Problem

This document clarifies some potential misunderstandings about the semantics of UDATE (6-digit date) and *DATE (8-digit date). Both reserved words retrieve the job date rather than the system date. This has several ramifications, some of which can be easily overlooked:

oThe date retrieved by UDATE/*DATE can be modified using the CL command CHGJOB to change the job date.
oFor interactive jobs, UDATE/*DATE retrieves the date when the interactive session started. Scenario: A user signs on a machine at a date X and stays logged on past midnight (and possibly over several days). The user then runs an interactive RPG program containing UDATE/*DATE. Either of these reserved words will return date X regardless of what the current date is. To reset what the reserved words return, the user must sign off and back on and, therefore, retain a fresh interactive session.
oFor prestart jobs (PJ) and batch immediate jobs (BCI), the date that is returned for a prestart job (PJ) is the date when the job gets started. It is not the time the connection was made.

Note: Prestart jobs are recycled according to the prestart job entry settings (WRKSBS, Option 5, Option 10). The date the daemon job started is returned for BCI jobs rather than the time the BCI job started.
oFor batch jobs, UDATE/*DATE retrieves the date when the job was submitted to run. Scenario: A user submits on date X a batch job consisting of a CL program which calls an IBM® RPG/400® program with UDATE/*DATE in it. In addition, suppose the CL program includes a DLYJOB command which delays the call to the RPG program until past midnight. When the RPG program finally runs, the UDATE/*DATE in it returns date X (the start date of the batch job) rather than X+1 (the date when the RPG program actually starts running). The same behavior continues on should the CL program recursively call itself over multiple days; UDATE/*DATE continues returning date X for the duration of the job. This can be observed in practice by submitting the following CL program to batch. In addition, UDATE and *DATE have the following behavior for prestart jobs (PJ) and batch immediate jobs (BCI). The date of the time the prestart job started (versus the time the connection was made) is returned for type PJ. Prestart jobs are recycled according to the prestart job entry settings (WRKSBS, Option 5, Option 10). The date the daemon job started is returned for BCI jobs rather than the time the BCI job started.
PGM          /* This CL program has the name "RECURSIVE" */
            DLYJOB     RSMTIME('00:00:01')  /* resume 1 sec after midnight */
            CALL       PGM(RPGDATE)         /* call RPG to retrieve *DATE  */
            CALL       PGM(RECURSIVE)       /* recursive call to this CL   */
ENDPGM  


The RPG program is defined as follows:

Note: This program is written in ILE RPG; however, RPG/400 shows the same behavior with respect to UDATE/*DATE.

F* Each time it is invoked, this RPG program writes *DATE followed by the
F* current timestamp in a new record of file DATEFILE.                  
FDATEFILE  O    E             DISK                                      
C                   EVAL      STARDATE = *DATE                          
C                   TIME                    TIMESTAMP                    
C                   WRITE     DATEREC                                    
C                   EVAL      *INLR = *ON  



The DDS source for file DATEFILE is defined as follows:


     A          R DATEREC            
    A            STARDATE       8S 0
    A            TIMESTAMP       Z  



During each run, the RPG program adds a record in DATEFILE with *DATE and the current timestamp. Following are some sample records from a batch job submitted 09/13/1999, displayed using the CL command RUNQRY () DATEFILE:


                              Display Report
                                                           Report width . . . . . :      39
Position to line  . . . . .                                Shift to column  . . . . . .
Line   ....+....1....+....2....+....3....+....
         STARDATE   TIMESTAMP                
000001  9,131,999   1999-09-14-00.00.01.531000
000002  9,131,999   1999-09-15-00.00.01.968000
000003  9,131,999   1999-09-16-00.00.01.867000

 ****** ********  End of report  ********

In conclusion when getting dates and not using the reserved words UDATE and *DATE then system dates will be in effect.

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.1.0"}]

Historical Number

16783421

Document Information

Modified date:
18 December 2019

UID

nas8N1017986