This document clarifies some potential misunderstandings about the semantics of as400 rpg 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:
o
The date retrieved by UDATE/*DATE can be modified using the as400 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 aDLYJOB 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; as400 rpg UDATE/*DATE continues returning date X for the duration of the job.
Posts
