AS/400 Guru: I need to load our invoicing data on my AS/400. How can we exchange it?

UNIX Guru: AS/400? What’s that? AS/400 Guru: What type of system are you running? UNIX Guru: An HP.

AS/400 Guru: Cool. Can you copy my file to a 1/4” cartridge? UNIX Guru: A what?

AS/400 Guru: What kind of tape drives do you have? UNIX Guru: 8mm.

AS/400 Guru: Can you dump the file to 8mm? The tape needs to have standard labels and fixed record and block length, and it needs to be formatted to 2 GB. UNIX Guru: Huh?

AS/400 Guru: How do you usually exchange this data? UNIX Guru: I have a cool utility that downloads the data into a spreadsheet. AS/400 Guru: Great.

UNIX Guru: You know, I think we got one of those old 1/2” reel tape jobbies in the back. We sometimes use those to talk to old mainframes like yours.

The frustration involved in trying to exchange information between disparate platforms often seems not worth the effort. If only there were a way that data could be easily exchanged and read in a native high-level language (HLL) program, things would be greatly simplified. This simplicity is now reality, thanks to the introduction of the AS/400 Integrated File System (AS/400 IFS) and the addition of a CD-ROM drive as standard AS/400 equipment. This drive is capable of reading all standard CD-ROMs and is accessible as part of the AS/400 IFS. With the help of a few APIs and some wrapper coding, you can quickly write programs to process files directly from CD-ROM.

CD-ROM and Data on the AS/400

To allow the AS/400 to work as a server and fit into an integrated network, the AS/400 file system has been expanded to include non-DB2 file systems. All data storage on the AS/400, whether DB2 or not, is known as the AS/400 IFS. The AS/400 IFS can be used to store UNIX files, PC files, and AS/400 folders and documents as well as AS/400

objects. The storage of non-AS/400 objects allows for integration of things such as graphics, images, and sound into native applications. Non-AS/400 objects on the AS/400 IFS can be manipulated using AS/400 commands such as Copy from Stream File (CPYFRMSTMF), Copy to Stream File (CPYTOSTMF), and Work with Object Links (WRKLNK). They can also be manipulated using APIs within HLL programs.

The AS/400’s CD-ROM drive is accessible as an optical drive and usually has the device name OPT01. Optical devices, whether standard drives or optical libraries, are all part of the AS/400 IFS. This means that objects from these optical devices can be manipulated in the same manner as any other AS/400 IFS objects (with the obvious exception of not being able to write to a read-only drive). This capability makes CD-ROM technology on the AS/400 a viable alternative for exchanging data.

Most systems on the market today have access to writable CD-ROM drives, and those that don’t can interface with PCs that have CD-ROM burners installed. An added benefit of using a CD-ROM drive is that the format used to write to the medium is standard. For example, this means that a CD-ROM burned on a PC running Windows 95 can be read on an AS/400 model 720 running V4R4. There are some limitations based on disk capacity, and some of the media that support variable-speed drives may be questionable, but, on a whole, there is a consistent standard. Compared with tape drives—with their myriad of sizes, capacities, and formats—CD-ROM is, far and away, easier and more reliable to use.

Processing a CD-ROM

There are two basic ways to process a CD-ROM. The first is to manipulate the CD-ROM object as a stream file object. A stream file is a file treated as a continuous stream of bytes. It is read a byte at a time, and special characters (typically carriage return and line feed) mark record boundaries. You copy a stream file from the optical drive by using the CPYFRMSTMF command, which translates the file from ASCII to EBCDIC and parses it into records. These records are then written to a physical file in DB2 where they can be processed like any other database file. This method works but may take a considerable amount of time and disk space to copy the file from the CD-ROM.

The second method for processing a CD-ROM is to read the file directly from the CD-ROM with the aid of AS/400 IFS APIs. This is the method that I will look at for the rest of this article. By taking AS/400 IFS APIs and adding RPG IV wrappers around them, you can write programs where you use standard file processing logic. On the MC Web site at www.midrangecomputing.com/mc is a program that reads a file from CD-ROM and prints it on an AS/400 printer. The key point to look at is not the functionality of the example but the logic and API wrappers it uses.

The AS/400 IFS APIs

To process the CD-ROM, you use these five APIs:

• Open Stream File (QHFOPNSF)—The QHFOPNSF API receives the path name of the file to be opened and returns a handle after that file has been opened. The handle is used to reference the stream file for any further operations. To process from the CD-ROM, the path always begins with QOPT.

• Get Stream File Size (QHFGETSZ)—The QHFGETSZ API receives the file handle for an opened file and returns the size of the file in bytes. This process is important because many files have no end-of-file indicator. The only way to determine whether or not you have read the end of the file is to track the number of bytes read and compare that with the total number of bytes in the file.

• Close Stream File (QHFCLOSF)—A call to the QHFCLOSF API with the file handle closes the file and prevents any further access to it.

• Read Stream File (QHFRDSF)—The QHFRDSF API reads the data in a stream file. It is passed the file handle and number of bytes in the file to be read and returns both the data read and the number of bytes actually read. Normally, the number of bytes read will equal the number of bytes requested unless the physical end of the file is reached. By varying the number of bytes requested, the file can be processed one byte at a time or by blocks. You will process the file by blocks but select only one record at a time.

• Change Stream File Pointer (QHFCHGFP)—The QHFCHGFP API is similar to a SETLL operation. By passing the file handle and the file offset, the file pointer is positioned for the next read.

The Wrappers

You can also get the RPG IV source code for this article by visiting the MC Web site at www.midrangecomputing.com/mc. The following paragraphs explain how my RPG programs read from CD-ROM.

Service program UTRSVC02 wraps RPG IV logic around these APIs to make it easier to use them in an HLL program. UTRSVC02 consists of seven procedures:

• Open Stream File Input (OpenSTMFI)—The OpenSTMFI procedure opens the stream file for input and sets up the OpenInfo data structure with requirements for an input-only file. The path is passed in through a parameter, and, once the file is opened, the file handle is returned to the calling procedure.

• Get Stream File Size (GetSizeSTMF), Read Stream File (ReadSTMF), Position Stream File (PositionSTMF), and Close Stream File (Close- STMF)—These simple wrappers go around the QHFGETSZ, QHFRDSF, QHFCHGFP, and QHFCLOSF APIs respectively and allow these APIs to be easily bound into an ILE program.

• Read Stream File as ASCII (ReadSTMFAsc)—The ReadSTMFAsc procedure reads data from the stream file and converts it from ASCII to EBCDIC. The translation is done using the QDCXLATE API and QEBCDIC translation table.

• Read Stream File Record as ASCII (ReadSTMFRecAsc)—This procedure pulls together many of the procedures you have already seen so that, when called, it returns only the data that belongs in a particular record. That data is then translated to EBCDIC. First, the stream file is read and converted to ASCII. (The number of bytes to be read is the maximum size of the particular record in the file, including any end-of-record markers.) The returned data is scanned to see whether or not there are any end-of-record markers, and the record is stripped down to include only data prior to these markers. Finally, the file pointer is positioned to the byte following the markers in case data for more than one record was read.

Putting It Together

Program SVRCDD01 is an example of how you put all this together to accomplish something useful. The program reads the CD-ROM and prints the records to a report. There are a few things to note first.

In the D-specs, I define two fields named EORChar and EORLength. These fields are given an initial value but are set to the value passed into the program. This is more for

documentation than anything else. I was never able to remember what the hex values for Carriage Return (CR) and Line Feed (LF) were, so I coded them in the program.

This brings me to a discussion of what End of Record (EOR) characters are and how to find what they are for a specific file. EOR characters are special hex values that are used to signal the end of a record of data to the program. Traditionally, EOR characters include CR, LF, or any combination of these. In order for my program to function properly, I must know what these are. The easiest way to find these is to ask the person putting the data to CD-ROM what that person’s system uses. If you have to guess, try CR/LF (X’0D25’). The more complicated but most effective solution would be to dump a portion of the CD-ROM to a physical file and view the hex characters in the file. This could be accomplished by the CPYFRMSTMF command.

Take a look at the parameters that are passed to the program:

• PMVolume—This is the name of the CD-ROM volume that is going to be read.

• PMFileNameI—This is the name of the file on the CD-ROM.

These two values, concatenated with the file system identifier /QOPT/, create the path of the file to be read. You can find these values for your CD-ROM by using the following command:

DSPOPT VOL(*MOUNTED) +

DEV(OPT01) +

DATA(*FILATR) +

PATH(*ALL)

• PMRecordLen—This is the maximum record length, including EOR characters contained within the file. This is used to optimize the way the program processes the data. It is possible to specify a very large record that the program will process properly, but by specifying the maximum record length, the amount of data read multiple times is reduced.

• PMEORChar—This parameter contains the characters that identify the end of the record for the file. Typically, this will be a combination of CR and LF.

• PMEORLength—This is the length of the end-of-record characters. A system may use any number of characters to indicate the end of a record, but typically, this will be either 1 or 2.

• PMPageControl—Because this program was designed to print a report that is delivered on CD-ROM, it is necessary to tell it how the generating system indicates the end of a page. This end of form (EOF) character is 1 byte.

The specifications up to the DO loop initialize the program. Processing parameters are set up, the file is opened, and the file size is retrieved. The file size and number of records read need to be tracked so you know when you have reached the end of the file.

The code within the DO loop is the main processing routine. Using the ILE wrapper, a single record is read from the file. A check for a new page flag is done, and the record is printed. This second block continues to be processed until the calculated starting position of the next record to be read is determined to be outside the size of the file.

When the loop is completed, the file is closed and the program is terminated.

Creating the Program

A few things need to be mentioned in creating the service program as well as the print program.

First, you must create the service program UTRSVC02. To do so, use the following command:

CRTRPGMOD MODULE(objlib/UTRSVC02) +

SRCFILE(srclib/srcfile) +

SRCMBR(UTRSVC02) +

TEXT(‘Print data from CD’)

In this command, objlib is the library for the module to be created in, srclib is the library containing the source file, and srcfile is the source file that contains the UTRSVC02 member. This command will create an ILE module in the object library.

You must then convert the module into a service program. This is done with the following command:

CRTSRVPGM SRVPGM(objlib/UTRSVC02) +

MODULE(*SRVPGM) +

EXPORT(*ALL) +

BNDDIR(*LIBL/*N) +

ACTGRP(*CALLER) +

TEXT(‘Print data from CD’)

In this command, objlib is the library where the service program will be placed. You will notice that the H-spec in the main program contains the BNDDIR(‘SVRCDD01’) keyword. This tells the ILE compiler to use the binding directory SVRCDD01 when compiling this program. A binding directory is a list of objects to be pulled together to create the program. To create the binding directory, use the following commands:

CRTBNDDIR BNDDIR(objlib/SVRCDD01) +

TEXT(‘Print data from CD’)
ADDBNDDIRE BNDDIR(SVRCDD01) +

OBJ((SVRCDD01 *MODULE))
ADDBNDDIRE BNDDIR(SVRCDD01) +

OBJ((UTRSVC02 *SRVPGM))

Finally, you are ready to compile the program. This can be done with option 14 from PDM or by using this command:

CRTBNDRPG PGM(objlib/SVRCDD01) +

SRCFILE(srclib/srcfile) +

SRCMBR(SVRCDD01)

You may notice that I did not specify what activation group to use for this program. This is because the activation group is set in the H-spec of the program with the DFTACTGRP and ACTGRP keywords. This allows me to have the program compiled consistently, regardless of who (or what) is compiling it.

Processing data directly from CD-ROM is easy and quick. And by the way, you may find these APIs will work with other file systems. I know they will work with the folder file system, QDLS, although I have not used them to access QDLS in production work.

By using wrappers to simplify interface to APIs, program development is made more efficient. Using CD-ROM as a common medium for exchanging large volumes of data results in very reliable and consistent exchange between systems.

So What?

UNIX Guru: That’s pretty cool, dude. What language is that written in? AS/400 Guru: RPG.

UNIX Guru: R what? AS/400 Guru: Oh, brother!

References and Related Materials

• Integrated File System Introduction (SC41-5711-03, CD-ROM QB3AUH03)
• OS/400 Hierarchical File System APIs V4R4 (SC41-5859-03, CD-ROM QB3AMK03)
• OS/400 Optical Support V4R1 (SC41-5310-00, CD-ROM QB3AL800)