While skimming the updated RPG manual I found something that I had not seen before, I can initialize variables with special values. What do I mean by special values? Basically system type values that start with an asterisk. When I went back and looked at older documentation I found that this has been available since IBM i 6.1.
I no longer have to go to the Program Status Data Structure, PSDS, to get the user id of the person running the program, or to initialize a date field with the system date.
In this post I am going to give examples of how to use this in both fixed and all free format RPGLE.
The special values that can be used are:
- *EXTDFT - initialize an externally described data structure to the default values defined in its DDS.
- *NULL - Null.
- *USER - Current user profile.
- *JOB - Job date.
- *SYS - System date, time or timestamp.
The Job date is the date when the job started. If the job was started before midnight it will contain yesterday’s date. The system date is the current date as defined on your IBM i.
Let me start with the fixed format code:
01 D FixedUser S 10 inz(*user) 02 D FixedJobDate S D inz(*job) 03 D FixedSysDate S D inz(*sys) datfmt(*ymd-) 04 D FixedTimeStamp S Z inz(*sys) 05 D FixedTime S T inz(*sys) 06 D FixedTimeUsa S T inz(*sys) timfmt(*usa) |
Line 1 uses the INZ(*USER) to initialize the field with the user id of the person.
Line 2 by using INZ(*JOB) the variable is initialized with the job date, like using UDATE or *DATE.
Lines 3 – 6 are all initialized using INZ(*SYS) which is the system date (line 3), time (lines 5 and 6), and time stamp (line 4). On lines 3 and 6 I show how use the DATFMT and TIMFMT to change the format, the way the date or time is presented.
Below are the values each variable contained when I ran my test:
Variable | Value |
FIXEDUSER | 'SIMONH ' |
FIXEDJOBDATE | '2014-04-02' |
FIXEDSYSDATE | '14-04-02' |
FIXEDTIMESTAMP | '2014-04-02-13.51.42.479000' |
FIXEDTIME | '13.51.42' |
FIXEDTIMEUSA | '01:51 PM' |
And now for the free format code:
01 dcl-s FreeUser char(10) inz(*user) ; 02 dcl-s FreeJobDate date inz(*job) ; 03 dcl-s FreeSystemDate date(*usa) inz(*sys) ; 04 dcl-s FreeTimeStamp timestamp inz(*sys) ; 05 dcl-s FreeTime time inz(*sys) ; 06 dcl-s FreeTimeUsa time(*usa) inz(*sys) ; |
The variables are defined to be the same as the fixed format ones.
I did learn that the DATFMT and TIMFMT are not used in free format definitions. When you define a variable as a date or time you follow the variable type word, DATE or TIME with the format you want, see lines 3 and 6.
The table below shows the values of the variables from my testing:
Variable | Value |
FREEUSER | 'SIMONH ' |
FREEJOBDATE | '2014-02-04' |
FREESYSTEMDATE | '04/02/2014' |
FREETIMESTAMP | '2014-04-02-13.51.42.479000' |
FREETIME | '13.51.42' |
FREETIMEUSA | '01:51 PM' |
 
For more information on this you can consult the IBM documentation here.
I love a system shortcut
ReplyDeleteLIKE!
ReplyDeleteThat is neat and saves a lot of angst.
ReplyDeleteSome notes:
ReplyDeleteUser id at position 254 to 263 in PSDS is equivalent to RTVJOBA USER(&USER), it may contain values like "QUSER" when running remote program/job.
inz(*user) is equivalent to RTVJOBA CURUSER(&CURUSER) and will give you the real user id.
Hi Simon,
ReplyDeleteActually all that stuff exists since V5.R4.M0.
Thanks for sharing this useful info.
ReplyDeleteVery useful info. Thanks.
ReplyDeleteVery useful info. Thanks.
ReplyDeleteThanks you Simon,today I learned something new
ReplyDeletethanks simon
ReplyDeleteSimons articles are simple, clean and easily understandable to iseries developers. Such articles are not found elsewhere - J
ReplyDeleteHow can we assign data to a variable longer than one line in rpg free?
ReplyDeleteI know the formatting in this comment is not going to look nice, but here goes:
ReplyDeletea_variable_name_that_is_just_...
way_too_long_to_be_sensible...
_in_a_normal_program = 'Y' ;
I've previously used `EXEC SQL SET :fixeduser = CURRENT_USER;` instead of using the PSDS, but I think I prefer your method of defining and setting the variable in one
ReplyDelete*USER is only set when the program starts, which is usually ok. But if it's a server job which can swap the current user profile, for example for ODBC or JDBC, you need to retrieve *USER in a simple sub-proc.
ReplyDeleteRinger
very helpful
ReplyDeleteI didn't know this, but will start using it right away. Thanks.
ReplyDeleteThanks for sharing. It's usefull info.
ReplyDelete