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:
The "RPGDATE" 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.
The DDS source for file "DATEFILE" is defined as follows:
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 11/26/2024 to CL program "RECURSIVE" and two additonal records created by running the RPG program directly. The below is displayed using the CL command DSPPFM DATEFILE:
In conclusion when getting dates and not using the reserved words UDATE and *DATE then system dates will be in effect.
o | The date retrieved by UDATE/*DATE can be modified using the CL command CHGJOB to change the job date. |
o | For 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. |
o | For 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. |
o | For 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 "RPGDATE" 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.
**FREE
// Each time it is invoked, this RPG program writes *DATE followed by the
// current timestamp in a new record of file DATEFILE.
Dcl-F DATEFILE Usage(*Output);
STARDATE = *DATE;
TIMESTAMP = %TimeStamp;
Write DATEREC;
*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 11/26/2024 to CL program "RECURSIVE" and two additonal records created by running the RPG program directly. The below is displayed using the CL command DSPPFM DATEFILE:
*...+....1....+....2....+....3....
112620242024-11-27-00.00.02.198000
112620242024-11-28-00.00.01.916000
112620242024-11-29-00.00.01.839000
112620242024-11-30-00.00.01.948000
112620242024-12-01-00.00.02.099000
112620242024-12-02-00.00.02.008000
120220242024-12-02-11.36.10.803000
120220242024-12-02-11.37.08.403000
****** END OF DATA ******
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":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CHtAAM","label":"Programming ILE Languages"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
16783421
Was this topic helpful?
Document Information
More support for:
IBM i
Component:
Programming ILE Languages
Software version:
All Versions
Operating system(s):
IBM i
Document number:
642099
Modified date:
02 December 2024
UID
nas8N1017986
Manage My Notification Subscriptions