02
Sat, Nov
2 New Articles

Use CD-ROM to Port Source Code and Data

APIs
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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)


BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: