
This almost slipped past me, the information in the IBM i 7.6 documentation that says that the Convert Date command, CVTDAT can use the '1970 rule'.
Whether CVTDAT uses the '1940 rule' or the '1970 rule' depends upon the presence of the QIBM_QBASEYEAR Environment variable. If its value is '1970' that rule is used, if it is not present then the '1940 rule' is used.
How can I tell if I have that Environment variable? There are two ways. I can use the Work with Environment Variables command, WRKENVVAR:
01 WRKENVVAR |
This returns a screen displaying all the Environment variables for the system and the job.
I prefer to use SQL as I can just display the Environment variable I desire:
01 SELECT ENVIRONMENT_VARIABLE_TYPE AS "Level", 02 ENVIRONMENT_VARIABLE_NAME AS "Name", 03 ENVIRONMENT_VARIABLE_VALUE AS "Value" 04 FROM QSYS2.ENVIRONMENT_VARIABLE_INFO 05 WHERE ENVIRONMENT_VARIABLE_NAME = 'QIBM_QBASEYEAR' |
Lines 1 – 3: I only want to return three columns in my results:
- ENVIRONMENT_VARIABLE_TYPE: Whether is Environment variable is at the system or the job level
- ENVIRONMENT_VARIABLE_NAME: Its name
- ENVIRONMENT_VARIABLE_VALUE: Its value
There is no result as this Environmental variable has not been added to this partition and job.
Level Name Value ------ ----------------- ---------------------- |
I add the QIBM_QBASEYEAR Environment variable with the following Add Environment Variable command, ADDENVVAR:
01 ADDENVVAR ENVVAR(QIBM_QBASEYEAR) VALUE(1970) LEVEL(*JOB) |
Line 1: I am setting this at the job, not the system, level as this is not my partition to make such a significant change to.
When I execute the SQL statement I showed before, I get a result:
Level Name Value ------ ----------------- ---------------------- JOB QIBM_QBASEYEAR 1970 |
As I have added this at the job level this can be removed when the job ends, I signoff, or I can use the Remove Environment variable command, RMVENVVAR:
01 RMVENVVAR ENVVAR(QIBM_QBASEYEAR) LEVEL(*JOB) |
To show how the CVTDAT can use the '1970' rule I created this CL program:
01 DCL VAR(&IN_DATE) TYPE(*CHAR) LEN(6) 02 DCL VAR(&OUT_DATE) TYPE(*CHAR) LEN(10) 03 CHGVAR VAR(&IN_DATE) VALUE(010260) 04 CVTDAT DATE(&IN_DATE) + 05 TOVAR(&OUT_DATE) + 06 FROMFMT(*MDY) + 07 TOFMT(*ISO) + 08 TOSEP('-') 09 DMPCLPGM 10 ADDENVVAR ENVVAR(QIBM_QBASEYEAR) VALUE(1970) + 11 LEVEL(*JOB) REPLACE(*YES) 12 CHGJOB JOB(*) DATFMT(*MDY) 13 CVTDAT DATE(&IN_DATE) + 14 TOVAR(&OUT_DATE) + 15 FROMFMT(*MDY) + 16 TOFMT(*ISO) + 17 TOSEP('-') 18 DMPCLPGM |
Line 1: A character variable that will contain a six long "date".
Line 2: A character variable that will contain the result of the CVTDAT, as a ISO "date".
Line 3: Change the six long date to contain '010260', for the date January 2 60. I chose 60 as with the '1940 rule' this would be 1960, to the '1970' it would be 2060.
Lines 4 – 8: This is where I convert the six long, 'MMDDYY', character "date" to a ten long character ISO "date", 'YYYY-MM-DD'.
Line 9: I use the Dump CL program command, DMPCLPGM, to perform a program dump to get a snap shot of the values in the variables.
Lines 10 and 11: I use the ADDENVVAR to add the QIBM_QBASEYEAR Environment variable at the job level, with the value of "1970".
Line 12: I have to use the Change Job command, CHGJOB, to "apply" the change to my job. Notice that I use the DATFMT(*MDY) as that is the default date format for this job.
Lines 13 – 17: I convert the date using the same values for the CVTDAT as I did before.
Line 18: I produce a second program dump.
After compiling this program, I call it.
When it is finished I browse the first QPPGMDMP spool file, and at the bottom I find:
Variable Type Length Value *...+....1... &IN_DATE *CHAR 6 '010260' &OUT_DATE *CHAR 10 '1960-01-02' |
At the time this dump was performed there was no QIBM_QBASEYEAR in place, therefore, the "date" is converted using the '1940 rule' to '1960-01-02'.
Looking in the second I find:
Variable Type Length Value *...+....1... &OUT_DATE *CHAR 10 '2060-01-02' |
As QIBM_QBASEYEAR was in place with the value of '1970', the six long date was converted to '2060-01-02'.
It is good to see this progress in CL. Remember in RPG we have to make the changes ourselves, to help identify what changes need to be made use the DATEYY.
This article was written for IBM i 7.6.
Will it work only in IBMi 7.6 because I tried in IBMi 7.5 and it is not working.
ReplyDeleteNot 7.5, just 7.6
Delete