HOME PUBLICATIONS NEWS EVENTS BUYER'S GUIDE FORUMS VIDEOS POPULAR ARCHIVE STORE Remember me Forgot Password?

| Register

Analysis App Software Career Database Internet Networking OP Systems Printing Programming Security System Admin TechTips WebSphere Analysis of News Events Commentary Business Intelligence Business Management Collaboration Content Management Customer Relationship ERP/Financial General High Availability IBM Managed Services Microsoft General Data Warehousing DB2 JDBC Microsoft Access Microsoft ODBC MySQL Oracle SQL General Portals

Protocols Telephony Web Conferencing Emulation General Wireless/WiFi i5/OS Linux/Open Source Microsoft UNIX/AIX General APIs Change Management CL General Java RPG Scripting SQL Visual Basic Web Languages Compliance/Privacy General i5/OS Microsoft General Performance Monitoring & Tuning APIs Career CL Collaboration Database HA/DR i5/OS Internet Java Linux MS Networking Printing Programming RPG Scripting Security SQL Sys Admin Web Languages WebSphere General Systems Management

Use CD-ROM to Port Source Code and Data Written by John Panzenhagen Friday, 31 March 2000 Use RPG and CD-ROM to move data to many platforms. 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 label s 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 uti lity 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 pla tforms often seems not worth the effort. If only there were a way that data coul d be easily exchanged and read in a native high-level language (HLL) program, th ings 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 proces s 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 s torage 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 de vice 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 devic es can be manipulated in the same manner as any other AS/400 IFS objects (with t he obvious exception of not being able to write to a read-only drive). This capa bility 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 thos e that don t can interface with PCs that have CD-ROM burners installed. An added b enefit 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 b ased 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 w ith tape drives with their myriad of sizes, capacities, and formats CD-ROM is, far a nd 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 CDROM object as a stream file object. A stream file is a file treated as a continu ous stream of bytes. It is read a byte at a time, and special characters (typica lly carriage return and line feed) mark record boundaries. You copy a stream fil e from the optical drive by using the CPYFRMSTMF command, which translates the f ile from ASCII to EBCDIC and parses it into records. These records are then writ ten to a physical file in DB2 where they can be processed like any other databas e file. This method works but may take a considerable amount of time and disk sp ace 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 f or the rest of this article. By taking AS/400 IFS APIs and adding RPG IV wrapper s around them, you can write programs where you use standard file processing log ic. 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 i s 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 u sed 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 o pened 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 whet her or not you have read the end of the file is to track the number of bytes rea d 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 close s 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 bo th 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 t he file is reached. By varying the number of bytes requested, the file can be pr ocessed 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 opera tion. By passing the file handle and the file offset, the file pointer is positi oned 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 RP G 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 f or input and sets up the OpenInfo data structure with requirements for an inputonly file. The path is passed in through a parameter, and, once the file is open ed, 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 allo w 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 us ing the QDCXLATE API and QEBCDIC translation table. Read Stream File Record as ASCII (ReadSTMFRecAsc) This procedure pulls together ma ny 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 E BCDIC. First, the stream file is read and converted to ASCII. (The number of byt es to be read is the maximum size of the particular record in the file, includin g 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 th e 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 so mething 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 ar e 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 valu es for Carriage Return (CR) and Line Feed (LF) were, so I coded them in the prog ram. This brings me to a discussion of what End of Record (EOR) characters are and ho w to find what they are for a specific file. EOR characters are special hex valu es that are used to signal the end of a record of data to the program. Tradition ally, EOR characters include CR, LF, or any combination of these. In order for m y program to function properly, I must know what these are. The easiest way to f ind these is to ask the person putting the data to CD-ROM what that person s syste m uses. If you have to guess, try CR/LF (X 0D25 ). The more complicated but most eff ective 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 CPYFRMSTM F 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 th e path of the file to be read. You can find these values for your CD-ROM by usin g 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 pr operly, but by specifying the maximum record length, the amount of data read mul tiple times is reduced. PMEORChar This parameter contains the characters that identify the end of the reco rd 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 a ny number of characters to indicate the end of a record, but typically, this wil l be either 1 or 2. PMPageControl Because this program was designed to print a report that is delivere d 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 paramete rs 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 wrappe r, a single record is read from the file. A check for a new page flag is done, a nd 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 o utside 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 i s the library containing the source file, and srcfile is the source file that co ntains 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 f ollowing 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 You will notice that the H-spec in the main keyword. This tells the ILE compiler to use compiling this program. A binding directory ogether to create the program. To create the g commands: CRTBNDDIR BNDDIR(objlib/SVRCDD01) + the service program will be placed. program contains the BNDDIR( SVRCDD01 ) the binding directory SVRCDD01 when is a list of objects to be pulled t binding directory, use the followin

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 f rom 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 prog ram. This is because the activation group is set in the H-spec of the program wi th the DFTACTGRP and ACTGRP keywords. This allows me to have the program compile d 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 th e folder file system, QDLS, although I have not used them to access QDLS in prod uction work. By using wrappers to simplify interface to APIs, program development is made mor e efficient. Using CD-ROM as a common medium for exchanging large volumes of dat a 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)

Last Updated ( Friday, 31 March 2000 ) No Comments Have Been Posted. User Rating: / 0 PoorBest Related Articles Is There a Rich Client in Your Future? (08/27/2008) Picking the Right Partner for RPG (08/20/2008) The API Corner: Finding All *SRVPGMs on the System (08/20/2008) Book Review: JavaScript for the Business Developer (08/15/2008) The System Integration Challenge: Eliminating Project Breakdowns (08/11/2008) < Prev Next > [ Back ] MOST POPULAR ARTICLES BOOKS FORUMS SEARCHES Picking the Right Partner for RPG Is There a Rich Client in Your Future? TechTip: Simplify Report Development with DB2 Web Query Business Views Book Review: JavaScript for the Business Developer The API Corner: Finding All *SRVPGMs on the System As IBM Reaches Out to Business Partners, Will They Reach Back to IBM? Best Practices for Selecting Application Development Tools Laptop Technology Comes of Age Will Google's Android Cure iPhone-Envy? Boost Efficiency in the Real World with Electronic Forms and Documents Top 10 Best-Selling Titles for August 2008 System i Disaster Recovery Planning HTML for the Business Developer The Modern RPG IV Language, Fourth Edition Free-Format RPG IV IBM System i APIs at Work, Second Edition SQL for eServer i5 and iSeries Subfiles in RPG IV JavaScript for the Business Developer Qshell for iSeries DB2 9 for Linux, UNIX, and Windows Database Administration Certification Study G uide How to display many subfile columns (461 views) Picking the Right Partner for RPG (302 views) Printing Bar Codes in an internal output spec's (167 views) DB2 Web query vs SEQUEL (69 views) ANSI to UTF-8 on IFS (63 views) Schedule Announced for Conference & Workshops on SOA, SaaS, Virtualisation & ECM (49 views) Schedule Announced for Conference & Workshops on SOA, SaaS, Virtualisation & ECM (31 views) 1. DB2 web query

2. display PDF 3. seiden 4. pdf 5. web services 6. Subfiles 7. subfile 8. spooled files and pdf 9. Chris Smith 10. green

MC-STORE.COM Home | Publications | News | Events | Buyer's Guide | | Popular | Archive | Store Forums | Videos

Copyright 2008 MC Press Online, LP | Privacy Policy | Search | RSS | FAQ | Contact Us | Write For Us | Advertise | Site Map