Brief: Using the utility presented here, you can take the worry out of changing your system time twice a year. This utility will schedule a job to do the work for you.
Changing your AS/400's system clock twice a year doesn't sound like much to worry about, yet it's probably something that rarely gets done when it's supposed to. Most areas of the country switch from standard time to daylight saving time at 2 a.m. on the first Sunday in April, and back to standard time on the last Sunday in October. But who can remember when it's to be done? And worse, who is willing to make the change at 2 a.m.?
Keeping your system time adjusted properly is critical to most applications. For example, if you have a batch update scheduled to begin at 6 p.m. daily, your users will not be pleased if the job begins at 5 p.m. If you IPL at 7 a.m. each day, an 8 a.m. IPL for even a single day could interfere with users starting their morning tasks. If your system is on a network, the proper order for mail messages may be determined by a date/time stamp.
An additional consideration for mail applications is the setting of the system value QUTCOFFSET. It determines how many hours your system is behind (or ahead of) coordi-nated universal time (UTC). This value is used to synchronize mail with other systems, so that no matter what your local time, the mail you send and receive is posted in the proper chronological order. If you do change the local time on your system in the fall and spring, but you do change the QUTCOFFSET system value, you could end up with user mail problems. (OS/400 does not change QUTCOFFSET when it changes the time.)
It's easy to forget when (or how) to make the changes. Chances are you won't have a system operator standing by at 2 a.m., chomping at the bit to make the changes for you. So, I wrote the Maintain Daylight Saving Time (MTNDST) command (1) to make the changes automatically, each time they are required. The command changes your system time and adjusts the QUTCOFFSET value for you. This helps eliminate problems in your time-sensitive applications. Network mail dates and times will be correct, even if you communicate with systems in other time zones.
It's easy to forget when (or how) to make the changes. Chances are you won't have a system operator standing by at 2 a.m., chomping at the bit to make the changes for you. So, I wrote the Maintain Daylight Saving Time (MTNDST) command (Figure 1) to make the changes automatically, each time they are required. The command changes your system time and adjusts the QUTCOFFSET value for you. This helps eliminate problems in your time-sensitive applications. Network mail dates and times will be correct, even if you communicate with systems in other time zones.
Before You Start
The MTNDST command uses the current value of QUTCOFFSET to determine what season it is. This is much simpler than calculating whether daylight savings time is in effect from the current system date. Before you can schedule the command for the first time, you need to do some preliminary groundwork.
o Before you create the DST001CL program (2), change the initial value of &STDOFFSET to match your time zone. See the comments following the definition of &STDOFFSET for additional information.
o Before you create the DST001CL program (Figure 2), change the initial value of &STDOFFSET to match your time zone. See the comments following the definition of &STDOFFSET for additional information.
o Use the Change System Value (CHGSYSVAL) command to manually change the UTC offset (value QUTCOFFSET) to whatever is correct for your time zone and current season. (This is one hour less than &STDOFFSET if you are currently on daylight saving time, and the same value as &STDOFFSET if you're currently on standard time.)
o Make sure that system value QHOUR is correct on your system.
When you run the command, two conditions must be met. First, MTNDST must be run by a user who has author-ity to the CHGSYSVAL command. Second, the utility must be run at least one week prior to a scheduled time change.
How It Works
The Submit Job (SBMJOB) CL command allows us to schedule jobs in the future and provides the added flexibility of specifying that the job will run on a specific day of the week, or a specific date. We will use this to our advantage in the three programs that automatically adjust the system's time and offset from UTC.
Another approach to designing this utility would be to use the job scheduler. I chose not to use this solution because the job scheduler does not directly support annually scheduled jobs. You would have to schedule a job to run once a month and then have your program decide if it's the month to make the time change.
DST001CL (2), the CPP for the MTNDST command, runs once and determines whether to submit a fall or a spring time change. It retrieves the system values QDATE and QUTCOFFSET using the Retrieve System Value (RTVSYSVAL) command and extracts the current month and day into one field (&TODAY_MD) and the year into another (&TODAY_YR). (If your system has a different date format than *MDY, you will have to modify the code to accommodate your date format.)
DST001CL (Figure 2), the CPP for the MTNDST command, runs once and determines whether to submit a fall or a spring time change. It retrieves the system values QDATE and QUTCOFFSET using the Retrieve System Value (RTVSYSVAL) command and extracts the current month and day into one field (&TODAY_MD) and the year into another (&TODAY_YR). (If your system has a different date format than *MDY, you will have to modify the code to accommodate your date format.)
If the value of QUTCOFFSET (&OFFSET) is the same as the value declared for &STDOFFSET, then we can assume that standard time is in effect. Therefore, the next time change moves us to daylight saving time and the program jumps to label SPRING. Otherwise, the program assumes daylight saving time is in effect and jumps to label FALL.
In either case, the next task is to determine the correct date for the next scheduled job-either April 1 or October 25. The code at label SPRING determines whether to advance the year or not. The value of &YEARNUM is increased by 1 if the month and day are greater than or equal to April 1. Otherwise, the year remains the same as the current date.
The offset value (&OFNUM) is used to change the QUTCOFFSET system value. QUTCOFFSET represents the difference between UTC and your local time. The program adds 100 (one hour) to it in the spring and subtracts 100 from it in the fall. This value is passed as a parameter to the program that actually changes the QUTCOFFSET system value.
Next, the program concatenates the character values for the date statement to get the first possible date of change. The program submits a scheduled job to run at midnight on that date (using the SCDDATE and SCDTIME parameters of the SBMJOB command). The submitted job does nothing but call the second CL program, DST002CL (3).
Next, the program concatenates the character values for the date statement to get the first possible date of change. The program submits a scheduled job to run at midnight on that date (using the SCDDATE and SCDTIME parameters of the SBMJOB command). The submitted job does nothing but call the second CL program, DST002CL (Figure 3).
When DST002CL is called (at midnight on the first possible day of change), it submits another job to run on the first occurrence of Sunday [SCDDATE(*SUN)] at 2 a.m. [SCDTIME(020000)]. This job runs DST003CL (4) which performs the actual changes to the system values. It is not necessary to alter the system value QTIME; all we have to do is add or subtract one hour from QHOUR and add or subtract 100 from system value QUTCOFFSET, depending on the season.
When DST002CL is called (at midnight on the first possible day of change), it submits another job to run on the first occurrence of Sunday [SCDDATE(*SUN)] at 2 a.m. [SCDTIME(020000)]. This job runs DST003CL (Figure 4) which performs the actual changes to the system values. It is not necessary to alter the system value QTIME; all we have to do is add or subtract one hour from QHOUR and add or subtract 100 from system value QUTCOFFSET, depending on the season.
When DST003CL finishes altering the QUTCOFFSET and QHOUR values, it calls DST001CL, which will submit a job for the next change (approximately six months later). In this respect, the utility is an "endless loop." Once the initial program, DST001CL, is run, the series will run indefinitely. The only way to stop it is to end the job DSTCHANGE from the job queue. If you want to prevent it from running the next time, you have up to six months to make up your mind.
Your System Won't Forget
The many parameters of the SBMJOB command can be used to your advantage to make your programming easier. In this case, I didn't even have to write a single line of RPG code! All the work is done for me by facilities already built in to IBM's CL language. So, the next time you try to remember when the time change occurs and to change it on your system, stay where you are and relax! Your system will remember and set its clock for you.
Francis Lapeyre is a programmer/analyst at a commercial collections firm in Louisiana.
Automate Daylight Saving Time Changes
Figure 1 MTNDST Command
/*===============================================================*/ /* To compile: */ /* */ /* CRTCMD CMD(XXX/MTNDST) PGM(XXX/DST001CL) + */ /* SRCFILE(XXX/QCMDSRC) */ /* */ /*===============================================================*/ CMD PROMPT('Maintain Daylight Savings Time')
Automate Daylight Saving Time Changes
Figure 2 CL Program DST001CL
/*===============================================================*/ /* To compile: */ /* */ /* CRTCLPGM PGM(XXX/DST001CL) SRCFILE(XXX/QCLSRC) */ /* */ /*===============================================================*/ DST001CL: + PGM DCL VAR(&NXTJOBDTE) TYPE(*CHAR) LEN(6) DCL VAR(&OFFSET) TYPE(*CHAR) LEN(5) DCL VAR(&OFNUM) TYPE(*DEC) LEN(5 0) DCL VAR(&SEASON) TYPE(*CHAR) LEN(1) DCL VAR(&STDOFNUM) TYPE(*DEC) LEN(5 0) DCL VAR(&STDOFFSET) TYPE(*CHAR) LEN(5) VALUE('-0800') /* + Change this value to what your system's value should be for + Standard Time: -0800 for PST; -0700 for MST; -0600 for CST; + and -0500 for EST. See the Work Management Guide for further + details. */ /* Earliest possible dates for DST changes in spring and fall */ DCL VAR(&SPRG1STDTE) TYPE(*CHAR) LEN(4) VALUE('0401') DCL VAR(&FALL1STDTE) TYPE(*CHAR) LEN(4) VALUE('1025') DCL VAR(&TODAY) TYPE(*CHAR) LEN(6) DCL VAR(&TODAY_MD) TYPE(*CHAR) LEN(4) DCL VAR(&TODAY_YR) TYPE(*CHAR) LEN(2) DCL VAR(&YEAR) TYPE(*CHAR) LEN(2) DCL VAR(&YEARNUM) TYPE(*DEC) LEN(2 0) GETFROMSYS: + RTVSYSVAL SYSVAL(QDATE) RTNVAR(&TODAY) RTVSYSVAL SYSVAL(QUTCOFFSET) RTNVAR(&OFFSET) EXTRACT: + CHGVAR VAR(&TODAY_MD) VALUE(%SST(&TODAY 1 4)) CHGVAR VAR(&TODAY_YR) VALUE(%SST(&TODAY 5 2)) /* CONVERT TO NUMERIC */ CVTNUM: + CHGVAR VAR(&YEAR) VALUE(&TODAY_YR) CHGVAR VAR(&YEARNUM) VALUE(&TODAY_YR) CHGVAR VAR(&OFNUM) VALUE(&OFFSET) CHGVAR VAR(&STDOFNUM) VALUE(&STDOFFSET) SELECT: + IF COND(&OFFSET *EQ &STDOFFSET) THEN(GOTO CMDLBL(SPRING)) ELSE CMD(GOTO CMDLBL(FALL)) /* We don't want to increment the year if we're already into + next year */ SPRING: + IF COND(&TODAY_MD *LT &SPRG1STDTE) THEN(CHGVAR VAR(&YEAR) + VALUE(&YEARNUM)) ELSE CMD(CHGVAR VAR(&YEARNUM) VALUE(&YEARNUM + 1)) CHGVAR VAR(&YEAR) VALUE(&YEARNUM) CHGVAR VAR(&NXTJOBDTE) VALUE(&SPRG1STDTE *CAT &YEAR) CHGVAR VAR(&OFNUM) VALUE(&OFNUM + 100) CHGVAR VAR(&OFFSET) VALUE(&OFNUM) CHGVAR VAR(&SEASON) VALUE('S') GOTO CMDLBL(CALL002) FALL: + CHGVAR VAR(&YEAR) VALUE(&YEARNUM) CHGVAR VAR(&NXTJOBDTE) VALUE(&FALL1STDTE *CAT &YEAR) CHGVAR VAR(&OFNUM) VALUE(&OFNUM - 100) CHGVAR VAR(&OFFSET) VALUE(&OFNUM) CHGVAR VAR(&SEASON) VALUE('F') CALL002: + SBMJOB CMD(CALL PGM(DST002CL) PARM(&OFFSET &SEASON)) + JOB(DSTCHANGE) JOBD(QGPL/QBATCH) JOBQ(QBATCH) + SCDDATE(&NXTJOBDTE) SCDTIME(000000) END: + ENDPGM
Automate Daylight Saving Time Changes
Figure 3 CL Program DST002CL
/*===============================================================*/ /* To compile: */ /* */ /* CRTCLPGM PGM(XXX/DST002CL) SRCFILE(XXX/QCLSRC) */ /* */ /*===============================================================*/ DST002CL: + PGM PARM(&OFFSET &SEASON) DCL VAR(&SEASON) TYPE(*CHAR) LEN(1) DCL VAR(&OFFSET) TYPE(*CHAR) LEN(5) CALL003: + SBMJOB CMD(CALL PGM(DST003CL) PARM(&OFFSET &SEASON)) + SCDDATE(*SUN) SCDTIME(020000) END: + ENDPGM
Automate Daylight Saving Time Changes
Figure 4 CL Program DST003CL
/*===============================================================*/ /* To compile: */ /* */ /* CRTCLPGM PGM(XXX/DST003CL) SRCFILE(XXX/QCLSRC) */ /* */ /*===============================================================*/ DST003CL: + PGM PARM(&OFFSET &SEASON) DCL VAR(&HOUR) TYPE(*CHAR) LEN(2) DCL VAR(&HOURNUM) TYPE(*DEC) LEN(2 0) DCL VAR(&OFFSET) TYPE(*CHAR) LEN(5) DCL VAR(&SEASON) TYPE(*CHAR) LEN(1) RTVSYSVAL SYSVAL(QHOUR) RTNVAR(&HOUR) CHGVAR VAR(&HOURNUM) VALUE(&HOUR) IF COND(&SEASON *EQ 'F') THEN(CHGVAR VAR(&HOURNUM) + VALUE(&HOURNUM - 1)) IF COND(&SEASON *EQ 'S') THEN(CHGVAR VAR(&HOURNUM) + VALUE(&HOURNUM + 1)) CHGVAR VAR(&HOUR) VALUE(&HOURNUM) CHANGE: + CHGSYSVAL SYSVAL(QUTCOFFSET) VALUE(&OFFSET) CHGSYSVAL SYSVAL(QHOUR) VALUE(&HOUR) CALL001: + CALL PGM(DST001CL) END: + ENDPGM
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