|The CL Corner: What's New with Files?|
|Programming - CL|
|Written by Bruce Vining|
|Friday, 04 December 2009 00:00|
Are you up on IBM file-related enhancements?
In the course of recent user group presentations and discussions, I have been surprised by the number of CL developers who are unaware of IBM-provided CL file-related enhancements that have become available in the past few releases. In hindsight, it is possible that you may not have the time to review all new commands, new parameters on existing commands, and relaxed limitations for existing commands. The focus of this article will be getting you up to date on file-related CL enhancements that IBM made in V5R3, V5R4, and V6R1.
Starting with the most current release, V6R1, IBM introduced two new CL commands that can really streamline CL application development as it is related to file processing.
Have you ever read a file using the CL Receive File (RCVF) command, encountered an end-of-file condition, and then wanted to continue reading records in the file? In the past, you had to jump through a few hoops if this situation occurred. Common approaches for this in the past have included (1) writing two programs, where the first program called the second program multiple times in order to reread the records of a file, (2) having a program retrieve the number of records in the file prior to using the RCVF command and under program control, avoiding ever reading past the last record, (3) declaring the file multiple times within the program and processing the file as two or more separate entities, etc. With V6R1, IBM provides the new command Close Database File (CLOSE) which, as you might guess, allows you to explicitly close a file (as opposed to implicitly closing the file when the CL program ends). The real benefit of CLOSE, however, is that once a file has been closed, the next RCVF command for the file will cause the file to be implicitly reopened, just like RCVF does when a CL program is initially called. You no longer need to jump through those hoops in order to process a file multiple times. A real simplifier to your life as a CL developer!
The CLOSE command has one optional parameter: Open file identifier (OPNID), which allows you to specify the file that is to be closed. We will look more at this OPNID keyword later in this article. It's one of the V5R3 CL enhancements to the Declare File (DCLF) command, along with several other file-related commands, such as Receive File (RCVF) and Send File (SNDF).
The second file-related command new with V6R1 is the Include CL Source (INCLUDE) command. INCLUDE, as aptly named as the CLOSE command (though I do miss the verb/noun combination used for most CL commands), allows you to include CL source in the source program being compiled. The source included can be declare commands (like DCL or DCLF), control flow commands (like SELECT or DOWHILE), or regular commands (like CHGVAR or SNDPGMMSG). In other words, you now have the equivalent of RPG /COPY directives, COBOL COPY directives, and C #include directives when developing CL applications!
There are some limitations on what can be included. For instance, the source included cannot contain commands such as PGM, ENDPGM, or another INCLUDE (though rumor on the street is that the limitation concerning included INCLUDE commands may be removed in a future release). You are also responsible to ensure that the included commands conform to the required structure of a CL program, which is no different from the include support found in other high-level languages. That is, you cannot INCLUDE a source member that contains declare commands after any non-declare commands have been encountered in the CL program being compiled. Likewise, included subroutines (subroutines being a V5R4 enhancement to CL) need to physically follow the main routine of a CL program. But being able to include common declares and processing logic at compile time certainly beats having to manually copy shared source into various source members and then having to manually maintain each copy whenever a change is made! Now, changes to common code can be picked up by simply recompiling the CL programs utilizing the shared code by way of the INCLUDE command.
The INCLUDE command has one required parameter (the source member to be included) and one optional parameter (the source file to locate the source member in). The source file parameter defaults to the include file specified with the new Include file (INCFILE) parameter of the CL Create command compiling the source. The INCFILE parameter in turn defaults to the source file specified with the source file (SRCFILE) keyword of the Create command. In other words, the source file default is the file containing the primary CL source member being compiled.
With V5R4, IBM slipped in an enhancement to the Declare File (DCLF) command. Though not as significant (to me, anyway; you may feel differently) as the CLOSE and INCLUDE commands of V6R1, the DCLF command was enhanced with the Declare binary fields (DCLBINFLD) parameter. In the past, binary (or integer) fields defined within a file were always declared as packed-decimal variables within a CL program. Declaring binary fields as TYPE(*DEC) continues to be the default with the DCLF command for compatibility reasons, but you can now specify DCLBINFLD(*INT) on the DCLF. This will cause binary fields defined within the file with a precision of 0 and a length of 9 or less digits to be declared as TYPE(*INT). TYPE(*INT), for signed integers, and TYPE(*UINT), for unsigned integers, are, incidentally, new data types that were introduced on the DCL command in V5R3. Using the integer data type can provide a small performance advantage over mapping file data to packed decimal.
Prior to the V5R4 DCLF support for integer data types, the DCLF command was also significantly enhanced in V5R3 with support for multiple files within the same CL program. Prior to V5R3, CL programs were limited to allowing only one file to be declared. With V5R3, you can declare up to five files within a single CL program. One of the files declared can be declared in the same manner as you have done since Release 1 of the system, as in DCLF FILE(MYFILE). The remaining files, or all five if you wish, must use the new V5R3 Open file identifier parameter (OPNID) mentioned earlier in this article. The OPNID parameter allows you to associate an identifier, or name, with the file specified on the FILE parameter of the DCLF command, as in DCLF FILE(SECONDFILE) OPNID(FILE2). The open identifier FILE2 would then be used with other file-related commands, such as RCVF and SNDRCVF, to identify the file that is being referenced.
There is one side effect of the DCLF OPNID parameter that is worth pointing out. When the OPNID parameter is not specified, CL variable names for each field of the file are simply the name of the field as provided in DDS or SQL. For example, the database field CUSTNAME of file CUSTMAST is declared within the CL program as variable &CUSTNAME when using the command DCLF FILE(CUSTMAST). If the file, however, is declared with an OPNID, then the OPNID value is used as a prefix for the CL variable name. For example, DCLF FILE(CUSTMAST) OPNID(CUSTOMERS) will cause the database field CUSTNAME to be declared with the CL variable name &CUSTOMERS_CUSTNAME. This use of the OPNID value within the CL variable name can be an advantage if you have two files, both with a CUSTNAME field, and you want to keep the value read from each file as two unique instances. It can, however, be a disadvantage if you simply want a shared view of the most recently read CUSTNAME field as you need to use CHGVAR to keep the two instances of CUSTNAME in sync. But in any case, you can now have two (or more) files declared within the same CL program and access data from each file. It is also interesting that DCLF support can now generate 21-character CL variable names (up to 10 characters for the OPNID value, the underscore, and again up to 10 characters for the database field name), but the DCL command continues to be limited to 10-character variable names (not counting the leading ampersand). It is certainly on my wish list for this support of longer named fields to be extended to user DCLed CL variable names, though I anticipate it might be a while (if ever) before we see this.
As you can see, IBM has made some very significant improvements to file processing within CL application programs. In future articles, we will look at other enhancements, not file-related, that can have a positive impact on your CL application development activities.
More CL Questions?
Wondering how to accomplish a function in CL? Send your CL-related questions to me at firstname.lastname@example.org. I'll try to answer your burning questions in future columns.
|Last Updated on Friday, 04 December 2009 00:00|