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)
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online