Creating an Auto-refresh Screen in CL
I wanted to monitor my network information and display it on a screen which would update itself automatically without any user intervention. I was able to accomplish this by employing the following technique.
1. Use the Override Display File (OVRDSPF) command to assign a maximum Wait Record (WAITRCD) time. Normally, this value is *NOMAX, which makes the file wait until a user presses Enter.
2. Write and read the display file record with the Send Receive File (SNDRCVF) command and specify WAIT(*NO). This causes the system to not wait for input from the user. Instead, the program continues to process the commands that follow the SNDRCVF command.
3. Code a WAIT command to cause the program to wait the number of seconds specified by the WAITRCD keyword of the OVRDSPF command executed previously. The WAIT command issues message CPF0889 when the WAITRCD time of the display file expires. Monitor for this message and when it is detected, redisplay the record. The following partial CL code illustrates this technique
. . . OVRDSPF FILE(SCREENFM) WAITRCD(30) . . . LOOP: SNDRCVF RCDFMT(DELAY) WAIT(*NO) IF COND(&IN12) THEN(GOTO + CMDLBL(ENDPGM)) WAIT MONMSG MSGID(CPF0889) EXEC(GOTO + CMDLBL(LOOP)) . . . ENDPGM: ENDPGM
Self-submitting CL Programs
If you have ever been frustrated with the need to write two programs in order to submit a job to a job queue (one program to submit the job and another to perform the task), take heart.
You can write one program that can submit itself to batch by retrieving the type of job environment in which the job is running. This is accomplished by using the Retrieve Job Attribute (RTVJOBA) command to obtain the job type. A CL variable receives a one-character value representing the environment of the job. A character value of 0 indicates that the job is running as a batch job, and a 1 indicates an interactive job. The variable must be a character variable with a minimum length of 1 character.
To illustrate, look at the program below. It submits itself to the job queue or runs interactively, depending on the response by the operator. When the job is called initially, it is running interactively. If the operator types a Y option to the question, then the program submits itself to the job queue and returns. Now the job is running in batch and the job's TYPE attribute is 0. This time, the program does not present the prompt screen to the operator. Instead, it branches over this and goes to label EXEC where the processing occurs.
PGM1: PGM PARM(&PARM1 &PARM2 &PARM3) DCL VAR(&JOBTYPE) TYPE(*CHAR) LEN(1) DCLF FILE(OPTIONS) RTVJOBA TYPE(&JOBTYPE) IF COND(&JOBTYPE *EQ '0') THEN(GOTO + CMDLBL(EXEC)) /* Present options display */ SNDRCVF SBMJOB CMD(CALL PGM(PGM1) PARM(&PARM1 + &PARM2 &PARM3)) + JOB(REPORT) JOBQ(QBATCH) RETURN /* Generate report */ EXEC: (etc.) ENDPGM
Display Status Messages in Reverse Image
To display status messages in reverse image, define two single-character fields to hold the hex code for display attributes: one to contain the reverse-image attribute byte and one to contain the normal attribute byte. Then, concatenate these fields with your message field, as the following partial program illustrates.
DCL VAR(&REVERSE) TYPE(*CHAR) LEN(1) VALUE(X'21') DCL VAR(&NORMAL) TYPE(*CHAR) LEN(1) VALUE(X'20') SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) + MSGDTA(&REVERSE *CAT &MSG *CAT &NORMAL) + TOPGMQ(*EXT) MSGTYPE(*STATUS)
Copying Multiple-format Files to Tape
The Copy to Tape (CPYTOTAP) command does not allow you to copy all record formats in a multiple-record logical file. To get around this limitation, use Copy File (CPYF) with an Override Tape File (OVRTAPF) command. For example, two physical files (a transaction header and detail) described by a logical file called HDRDTL could be copied to tape with the following commands.
OVRTAPF FILE(QTAPE) DEV(TAP01) VOL(*NONE) BLKLEN(80) + ENDOPT(*UNLOAD) CPYF FROMFILE(HDRDTL) TOFILE(QTAPE) MBROPT(*REPLACE) + RCDFMT(*ALL)
Flexible Library References
Some commands such as Create Duplicate Object (CRTDUPOBJ) require a library name, but hard-coding a library name in a CL program is something you should try to avoid. A better method is to use the RTNLIB parameter of the Retrieve Object Description (RTVOBJD) command to retrieve the library name. For example, to retrieve the library where WKFILE resides, use the RTVOBJD command as follows:
RTVOBJD OBJ(WKFILE) OBJTYPE(*FILE) RTNLIB(&LIB)
The value in the RTNLIB parameter could then be used in any command including those that require a library name to specify the library. The WKFILE file could be moved to any library in your library list and any program that uses the above command would still work-no program changes would be required. The library where the file exists could even be renamed without affecting the programs.
Beware of Changed Commands-Part I
This tip is for consultants and software developers who have to write CL programs that must run on someone else's (your customer's) machine.
An interesting feature of S/38 and AS/400 CL procedures is that, even though they are compiled, each command is interpreted when run, and the current default values for that command are substituted into the command. This can lead to unexpected errors if someone changes any of the defaults for any of the IBM- supplied commands using the Change Command Default (CHGCMDDFT) command.
To avoid this pitfall when creating CL procedures that must run at other sites, prompt each command in SEU by pressing F4=Prompt with the cursor on that line; then, press F10=Additional Parameters. Type over the first character of each default value with the same character. This will cause the "modified data tag" for that field to be turned on so that when you press Enter, that "key- word(value)" will be included in the statement.
What this technique does, in effect, is allow you to supply all of the "defaults" with the default values you expect. Hence, at run-time, the values are already supplied at the user's site, so there are no defaults to be plugged in-no more nasty surprises!
Date Validation in CL
The easiest way to validate dates in CL is to use the Convert Date (CVTDAT) command. If the command fails, it's because the date is invalid. For example:
. . . CVTDAT DATE(&DATE) TOVAR(&DATE) FROMFMT(*MDY) + TOFMT(*MDY) TOSEP(*NONE) MONMSG MSGID(CPF0000) EXEC(DO) CHGVAR VAR(&IN70) VALUE('1') /* Error indicator */ GOTO CMDLBL(ERROR) /* Redisplay */ ENDDO . . .
In this case, the from-format and to-format are the same, so no conversion takes place. However, an exception message will be sent if the variable &DATE does not contain a valid date.
Decompile CL Programs
If you inadvertently delete the source code of a compiled CL program, you can retrieve the source (minus comments) with the Retrieve CL Source (RTVCLSRC) command. (Of course, if you had a good backup of the source, you would most likely want to restore the source from the backup copy.) The command's format is:
RTVCLSRC PGM(library/compiled_program_name) + SRCFILE(library/QCLSRC) SRCMBR(source_program_name)
This process will only work if the Allowed Retrieve Source parameter of the original CL program has a value of '*YES' which is the default value for the Create CL Program (CRTCLPGM) command.