CL

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, instead of restoring the member from a backup. Remember, there may be no backup if this program was new. The command's format is:

RTVCLSRC PGM(library/compiled program name) + SRCFILE(library/QCLSRC) + SRCMBR(source program name)

The ALWRTVSRC parameter of the CL program must have a value of '*YES'. This is the default value for the CRTCLPGM command.

- Richard A. Phifer

OPNQRYF and MDY Dates

You can use date selection in reports even when the dates are in *MDY format in the database by using mapped fields on an OPNQRYF command. For example, the following command selects only records whose LRDAT field (which is a packed date in *MDY format) falls within 1992:

OPNQRYF FILE(LRDS) + QRYSLT('yymmdd = %RANGE(''920101'' ''921231'')') + MAPFLD((DATE1 LRDAT *ZONED 6 0) (DATE2 DATE1 *CHAR 6) + (YYMMDD '(%SST(DATE2 5 2) *CAT %SST(DATE2 1 4))' + *CHAR 6))

Note that if the date is already in zoned or character format, the first or first and second mapped field specifications can be eliminated respectively. This still allows updates and deletes of the data.

You can sort by date this way by adding a mapped field specification to map the new date back to another field in the file that you specify on the KEYFLD parameter. The field must be one that you don't need for that application. Data will not be affected; however, you cannot update the file when this map is added.

- Bryan Leaman

Re-use File After OPNQRYF

Here's a way that I re-cycle the OPNQRYF command in the same CL program:

OVRDBF FILE(FILENAME) SHARE(*YES).... OPNQRYF ... OPNID(FILE1) CALL PGM(PGMA) POSDBF OPNID(FILE1) POSITION(*START) CALL PGM(PGMB) CLOF OPNID(FILE1) DLTOVR FILE(FILENAME)

I also use this technique frequently when I want to view the records/sequence that my OPNQRYF is producing. I issue the OPNQRYF command, then do a CPYFRMQRYF to a test file, then issue the POSDBF command and then call my program. It's a nice feature.

- Cynthy Johnson

CL Gotcha

In CL, the CLOF command will not close a file declared in the CLP. The only way to close the file is to end the program, transfer control to another program, or reach the end of file. If the end of file is reached, the file is closed and CPF0864 is issued. The file cannot be opened again in the same execution of the program.

If end of file is not reached, the CL program cannot close the file and hence cannot perform certain operations like CLRPFM or DLTF.

- Douglas Handy

Date Validation in CL

The easiest way to validate dates in CL is to use the CVTDAT command. You do not actually need to convert the date to another format. 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(SCREEN) /* Redisplay */ ENDDO

In this case the from-format and to-format are the same, so no conversion actually takes place. However, an exception message will be sent if the variable &DATE does not contain a valid date.

- Bryan Leaman

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 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. Then, type over the first character of each default value with the same character. This causes the "modified data tag" for that field to be turned on, and so 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 used at your site. 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!

- Mark Waterbury

Beware of Changed Commands-Part II

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.

If you distribute compiled CL procedures to other AS/400 sites, either utilities or tools, or as part of a software product, consider the following:

If a customer wants to, he can change the default values or even replace certain IBM commands in QSYS directly. This is, of course, not recommended and ill-advised.

However, when you ship your program, you probably want to use the "real" IBM supplied versions of IBM commands. The following technique will ensure that when the CL procedure runs at the customer's site, it will use the same defaults and the same version of the command definition object used at your site when you compiled the procedure. This can be very useful for critical procedures that must not fail.

1. Copy each of the *CMD command definition objects from QSYS into your product library, using CRTDUPOBJ. (NOTE: if you need to support a user running a previous release of OS/400, duplicate the commands from QSYSPRV rather than QSYS, and be sure to specify TGTRLS(*PRV) on the CRTCLPGM command.)

2. Qualify all of the commands in your CL program to use the copies in the product library. For example:

MYLIB/DSPFFD FILE(&LIB/&FILE) OUTPUT(*OUTFILE) + OUTFILE(QTEMP/DSPFFD)

3. Save the entire library MYLIB on your distribution tape. This saves everything in your product library, including the duplicated command definition objects (*CMD) needed to run the CL procedures correctly. (NOTE: specify TGTRLS(*PRV) on the SAVLIB command to support users running the previous release of OS/400.)

4. The first step of your printed installation documentation should instruct the user to restore the product library (e.g. MYLIB). For example:

RSTLIB SAVLIB(MYLIB) DEV(TAP01)

- Mark Waterbury

A Permanent Solution to Temporary Work Files

There are times when you need to create work files for jobs-normally batch type. Occasionally, the jobs that use these work files either get canceled or end abnormally and you end up with a file needlessly taking up space on your system. Not only is this wasting space, but there is the chance that one of your programs may end up referencing the wrong version of the file.

A good solution to this problem is to create the work file(s) in the appropriate production library and leave them there empty, permanently.

Whenever you need to use the work file, use the RTVOBJD command to retrieve the name of the library where the work file resides. Then, use the Create Duplicate Object (CRTDUPOBJ) command to create a duplicate of the work file from the production library to library QTEMP. (If the job is interactive and the file already exists in QTEMP, clear it [CLRPFM] instead of creating the duplicate object.) Override the file (OVRDBF) to the copy in QTEMP before using it.

If the job gets canceled or terminates abnormally and it's a batch job, the work file goes away since it is in QTEMP. If the job is interactive, the work file will go away at sign-off or it will be cleared if used again before sign- off.

- Robin Klima