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
Bruce Vining is president and co-founder of Bruce Vining Services, LLC, a firm providing contract programming and consulting services to the System i community. He began his career in 1979 as an IBM Systems Engineer in St. Louis, Missouri, and then transferred to Rochester, Minnesota, in 1985, where he continues to reside. From 1992 until leaving IBM in 2007, Bruce was a member of the System Design Control Group responsible for OS/400 and i5/OS areas such as System APIs, Globalization, and Software Serviceability. He is also the designer of Control Language for Files (CLF).A frequent speaker and writer, Bruce can be reached at
MC Press books written by Bruce Vining available now on the MC Press Bookstore.
 |
||
 |
|
IBM System i APIs at Work Leverage the power of APIs with this definitive resource. List Price $89.95 Now On Sale
|
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