Changing your applications to correctly process dates of the Year 2000 and beyond is not complete until the changes are tested. As part of testing your applications for Year 2000 readiness, you may be considering changing the system date of your production AS/400 to some point in the future, putting applications through their paces, and then changing the system date back to the present. But be warned! Doing so can bring on disaster.

Here are some things to consider:

o You cannot predict what will happen when your machine accesses something that appears to have been created in the future. That "something" could be a lot of things-an object, a file member, a spooled file, a journal entry, or even a single record in a source member.

o Failure to disable time-dependent and logging software-such as journaling, the OS/400 job scheduler, Operational Assistant, and Performance Monitor-before changing to a future date could cause the software to work incorrectly when the machine date returns to the present.

o When you advance the system date, passwords and software licenses may expire.

Testing on a separate machine is the best way to go. If you don't have a separate machine, consider getting one, if only for a brief period. IBM makes AS/400s available for short-term lease or at a reduced price for this sort of testing. Check out the Year 2000 rebate for the AS/400e series on IBM's Year 2000 home page (http://www.softmall. ibm.com/as400/year2000.html).

If you cannot test on a separate machine but must test on a production system, consider these points:

o Programs that only print or display the system date should not be affected by the arrival of
2000. Programs that log the system date to a file (e.g., as a date stamp) should not be affected. However, any programs that read the logged date should be examined for Y2K impact. Programs

that compare to the system date, or calculate based on the system date, need to be tested for Y2K readiness.

o Using the job date (the UDATE and *DATE variables in RPG programs) is often just as good as using the system date, and it avoids much of the issue. You can sign on to the system and issue a Change Job (CHGJOB) command to set the job date into the future. The interactive programs that access the job date should behave as they will when that date becomes reality.

o Batch jobs are another issue. The default for the Submit Job (SBMJOB) command is DATE(*JOBD), which says the job date of the submitted job comes from the job description. The default value for the Create Job Description (CRTJOBD) command is DATE(*SYSVAL), which says use the system date. In other words, the default job date of submitted jobs is the system date, not the job date of the submitting job.

If you want a program that runs in batch mode to use the job date of the job that submitted it, use code like that in Figure 1.

Note that this may be unacceptable in some cases. For example, a user might submit a job to a held job queue that won't be released until after midnight. When it finally runs, the submitted job would use the previous day's date as the job date; that may or may not be appropriate.

Ideally, you should not change the system date of your production machine to test applications. If you must do so, consider the following:

o Do a complete save of user libraries before moving the system date into the future. Do a complete restore immediately upon restoring the system date to the present. The best way to save is probably to use the Save Storage (SAVSTG) command.

o Use test libraries, not production libraries.

o Disable any time-dependent software, such as job scheduling software, during the period of testing.

o Disable any system monitoring software during the period of testing.

o Disable communications with other systems during the period of testing.

o Retest your applications after resetting the system date to the present.

One last word of warning: This is not an exhaustive list of potential problems or recommendations. For an expanded version of this discussion, see IBM's Year 2000 home page at the URL given above.

Ted Holt is a technical editor for Midrange Computing. He can be reached by email at holt@ midrangecomputing.com.

Figure 1: The submitted job uses the job date of the submitting job

DCL VAR(&JOBDATE) TYPE(*CHAR) LEN(6)
RTVJOBA DATE(&JOBDATE)

SBMJOB CMD(CALL PGM(PGMA)) JOB(XYZ)

DATE(&JOBDATE)

Ted Holt is IT manager of Manufacturing Systems Development for Day-Brite Capri Omega, a manufacturer of lighting fixtures in Tupelo, Mississippi. He has worked in the information processing industry since 1981 and is the author or co-author of seven books. 

---

MC Press books written by Ted Holt available now on the MC Press Bookstore.

		Complete CL: Fifth Edition Become a CL guru and fully leverage the abilities of your system. List Price $79.95 Now On Sale
		Complete CL: Sixth Edition Now fully updated! Get the master guide to Control Language programming. List Price $79.95 Now On Sale
		IBM i5/iSeries Primer Check out the ultimate resource and “must-have” guide for every professional working with the i5/iSeries. List Price $99.95 Now On Sale
		Qshell for iSeries Check out this Unix-style shell and utilities command interface for OS/400. List Price $79.95 Now On Sale