You are currently on IBM Systems Media’s archival website. Click here to view our new website.

IBM i > DEVELOPER > RPG

Making RPG Even More “Special”

Simpler steps with INFDS and a look at Open Access


 

This is the promised follow-on to the March EXTRA article on SPECIAL files, “Get More from RPG.” Before we do anything else, we want to mention two things. First, several people have told us they have problems getting their heads around how SPECIAL files work. As with many new concepts, it’s often easier to understand when you see it running in debug mode. So to try to make things clearer, we’ve posted a video (link not active) of a debug session using this month's programs.

Second, we must apologize for some misinformation in that first article. We stated there that one of the disadvantages of SPECIAL files was that they had to be program described. Turns out we were wrong about that. SPECIAL files can indeed be externally described, as IBM’s Barbara Morris and Dan Cruikshank both pointed out to us. More on Dan’s comments in a moment.

Quite how we’ve remained under this misapprehension for all these years is beyond us. We’ve written multiple articles on the subject and given many presentations, and during all that time nobody has ever pointed it out. Sorry, but at least it’s nice to know that these old dogs can still learn new tricks!

The fact that we could use externally described files led us to consider that perhaps we could also make use of the INFDS to provide a simpler method of identifying the actions to be taken by the SPECIAL file handler. That turned out to be in the category of “useful but ...” as we’ll demonstrate. Once we’ve shared the differences in these new versions of the programs, we’ll take a quick look at how RPG’s new Open Access facility compares with the SPECIAL file.

Why Use the INFDS?

Many of our earlier explorations with SPECIAL files revolved around converting printer files to browser output. We’d always set up and passed an additional parameter to let the SPECIAL file determine the type of record being written. It occurred to us recently that if we specified an INFDS structure for the file, we’d then be able to simply pass that instead and utilize the file and/or record name within the structure to determine the action to be taken. This would make it far easier to write truly generic SPECIAL files that could adapt their behavior to the file and record in use.

Unfortunately, only part of the INFDS is available to be passed to our SPECIAL file program—specifically only those first 80 characters directly controlled by RPG. Additionally, for legacy reasons, the file and record names within that section are only eight characters long, not 10! This doesn’t nullify its use, but it does mean that it’s only really useful if the names you wish to use can be differentiated in the first eight characters. Needless to say, we’ll make sure our example fits that mold. You may be thinking that you can get the full 10-character names from the INFDS, but unfortunately, the longer names are only in the part of the INFDS not specifically controlled by RPG and therefore unavailable. (If you want details on this, see Chapter 5 of the RPG Reference Manual.) So, we’re stuck with the short versions of the fields.

Modifying the USESPECIAL Program

We’re implementing two primary features into our SPECIAL file example. First, we’ll use an externally described file (now that we know we can!), which simplifies the original set of programs because we don’t need the /Copy member to bring in the format of the data. Second, we’ll use the INFDS to illustrate the potential of adding some flexibility to the SPECIAL file program that wasn’t in the original version. In this example, the flexibility added was to allow the handling of two levels of detail about the IFS files and folders in the directory, based on the record format name specified. As we did in March, we’ll highlight sections of the code in this article, but if you would prefer to see the full source code you can download it from our website.

That said, let’s look at the changes we made to the program USESPECIAL from the March EXTRA. The first change was to modify the F-spec to use an external file description and to add the INFDS keyword. We also added a /COPY to bring in the INFDS definition. Our standard INFDS definition (ShortINFDS) only includes the fields, not the actual DS entry. This allows us the flexibility to add keywords to the DS we may need, such as QUALIFIED or BASED as we’ll do in this new example.

FLongDirE  IF   E             SPECIAL PgmName('DIRREADER2')
F                                     PList(DirReaderParm)
F                                     UsrOpn
F                                     INFDS(INFDS)
     
D INFDS           DS                  QUALIFIED
 /Copy ExtraSrc,ShortINFDS

The next change was to modify the READ operation to use the record format name (the previous version used the file name) so that the record name field in the INFDS would be populated by RPG and we could therefore reference it in the SPECIAL file.

   Read(E) LongRec;

Additionally, we extended the additional parameter list to pass the INFDS as the sixth parameter. (Remember from the earlier article that the PLIST only specifies the additional parameters beyond the four standard SPECIAL file parameters that are always passed.) The SPECIAL file program uses this additional information as we’ll show. The PLIST DirReaderParm now looks like this:

C     DirReaderParm PList                         
C                   Parm            directoryName 
C                   Parm            INFDS    

That’s it for the changes to this program. Now let’s look at the modifications to the SPECIAL file program itself.

 

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters