Brief: Piping is a common operation used in many operating systems to redirect the output from one program function to another. In OS/400, piping is accomplished with overrides. This article gives you an example using the standard Override with Printer File (OVRPRTF) CL command.
Every now and then, a consultant is asked to explain the advantages or disadvantages of using one programming technique over another. This task can be rather difficult when the consultant works in a shop that has established standards, preferences, or prejudices. Even large shops get caught in inertia, continuing to program in ways which no longer make sense. For instance, as odd as it may seem, some shops continue to create program-described printer output.
"What's the advantage of an externally described printer file?" one manager asked me. "We don't do that here! It's just one more program object we have to track, one more thing to get broken." Why should you program with externally described printer files? The answer can be summed up by referring to one CL command: OVRPRTF.
OVRPRTF Defined
The Override Printer File command (OVRPRTF) allows you to divert the printer datastream from one report to another without delving into the intricacies of program logic. It's like the pipe commands used in other operating systems, which redirect the flow of information away from one destination, towards another. Piping is not something that you build. It is a function built into the operating system-a kind of pre-built tool that allows you to control where and how different program objects relate to each other. OVRPRTF is one of those pipes. To see exactly how this might work, consider the following example.
OVRPRTF Piping Example
The CNTMST file is a database containing the names, addresses, and phone numbers of important people frequently contacted by members of your organization. The database is used by many different employees, and it is usually printed as a simple report called CNT01R. It uses the externally described printer file called CNT01P (See 1).
The CNTMST file is a database containing the names, addresses, and phone numbers of important people frequently contacted by members of your organization. The database is used by many different employees, and it is usually printed as a simple report called CNT01R. It uses the externally described printer file called CNT01P (See Figure 1).
Christmas time is fast approaching, and someone in the marketing department has a great idea. "Let's send holiday cards to everyone in our contact database! We'll put a POSTNET bar code on the labels, and it won't cost us much! It'll be a good way to keep our names in front of our contacts."
The simplest means of accomplishing this is to create a second externally described printer file called XMASP, (see 2). Then, using the OVRPRTF command, we will redirect (or pipe) the report output to the XMASP printer file instead of to the normal CNT01P printer file.
The simplest means of accomplishing this is to create a second externally described printer file called XMASP, (see Figure 2). Then, using the OVRPRTF command, we will redirect (or pipe) the report output to the XMASP printer file instead of to the normal CNT01P printer file.
Compare XMASP to the original CNT01P printer file. XMASP uses some (but not all) of the fields described in the CNT01P printer file. The significant difference is in the way the printer file is described. For instance, instead of printing out a heading line under the format called HEADR (containing the name of the report and the date) XMASP's HEADR format prints nothing; it only skips to line one. Secondly, the zip code format for the RPZIP field is printed as a POSTNET bar code.
This example assumes that we're using an Intelligent Printer Data Stream (IPDS) printer capable of producing a POSTNET bar code. See "Implementing POSTNET," MC, April 1994 for more information on using POSTNET in your organization. Or, see "Barcoding with DDS," MC, February 1994 for a detailed look at using IPDS printers.
XMASP is compiled using the Create Printer File (CRTPRTF) command, making certain that the LVLCHK parameter is set to *NO. This prevents the CNT01R program from halting with a level check when we pipe the report output to the XMASP printer file. Other parameters of the compile specify the size of the form being used, the number of lines, and other pertinent information about the report output.
Now it's about time to test XMASP. We could write a CL program to run this new program combinination, but since this will probably be a one-time program, we'll run the job interactively.
The first the first thing we'll need to do is to redirect the printer file to XMASP. To accomplish this, we key in OVRPRTF and press the F4 prompt key. The screen in 3 is displayed. In the FROMFILE parameter, we specify the original CNT01P printer file. In the TOFILE parameter, we specify the new XMASP file. This is all that's needed to set the pipe although there are lots of other parameters we could manipulate. For instance, if the original CNT01P printer file specified a printer device type that is not defined as an IPDS printer, we could use the OVRPRTF to instruct OS/400 to transform the datastream to IPDS. An entire list of options available for the OVRPRTF command can be found in the CL Reference manual.
The first the first thing we'll need to do is to redirect the printer file to XMASP. To accomplish this, we key in OVRPRTF and press the F4 prompt key. The screen in Figure 3 is displayed. In the FROMFILE parameter, we specify the original CNT01P printer file. In the TOFILE parameter, we specify the new XMASP file. This is all that's needed to set the pipe although there are lots of other parameters we could manipulate. For instance, if the original CNT01P printer file specified a printer device type that is not defined as an IPDS printer, we could use the OVRPRTF to instruct OS/400 to transform the datastream to IPDS. An entire list of options available for the OVRPRTF command can be found in the CL Reference manual.
After pressing the Enter key on the screen, we can call the CNT01R program interactively. As the output is created, OS/400 redirects the datastream, away from the CNT01P printer file and into the XMASP printer file. The resulting output has transformed the original report from one printed format to another without any modification of the original code. The printer override stays in effect only as long as the session remains active, or until a Delete Override (DLTOVR) command is issued.
Conclusion
This is just one example of how the redirection ability of OVRPRTF can reduce programming efforts. Instead of having to create another program (or modify the existing program) to process the slightly different printer file, we simply redirect the existing printer file to the file we want to use. It's a good demonstration of the power which externally defined printer files provide to a programming staff. Using these architectural utensils, which come as part of the standard OS/400, we can minimize the requirements of programming by increasing our efficiency. All it takes is a little planning and understanding of OS/400.
Thomas M. Stockwell is a senior technical editor for Midrange Computing.
REFERENCE CL Reference (SC41-0030, CD-ROM QBKA8202).
A Simple Pipe Called OVRPRTF
Figure 1 CNT01P Printer File
*. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A REF(REF) * A A R HEADR SKIPB(1) A 1'CNT01R' A 11TIME EDTWRD(' : : 0') A 54'CONTACT MASTER LISTING' A 113DATE EDTCDE(Y) A 124'Page' A 129PAGNBR EDTCDE(Z) A SPACEA(2) * A 1'Number' A 7'Last Name' A 23'First Name' A 34'Address ' A 53'City ' A 64'State' A 70'Zip Code' A SPACEA(2) * A R DETAIL A RP#ID R 2REFFLD(RF#ID) A RPLNAM R 7REFFLD(RFLNAM) A RPFNAM R 23REFFLD(RFFNAM) A RPADR1 R 34REFFLD(RFADR1) A RPCTY R 53REFFLD(RFCTY) A RPST R 64REFFLD(RFST) A RPZIP R 70REFFLD(RFZIP) A SPACEA(1) *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
A Simple Pipe Called OVRPRTF
Figure 2 XMASP Printer File
*. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A REF(REF) * A R HEADR SKIPB(1) * A R DETAIL A RPFNAM R 1REFFLD(RFFNAM) A RPLNAM R 16REFFLD(RFLNAM) A SPACEA(1) A RPADR1 R 1REFFLD(RFADR1) A SPACEA(1) A RPCTY R 1REFFLD(RFCTY) A RPST R 12REFFLD(RFST) A SPACEA(1) A RPZIP R 1REFFLD(RFZIP) A BARCODE(POSTNET) A SPACEA(1) *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
A Simple Pipe Called OVRPRTF
Figure 3 Override with Printer file (OVRPRTF) Command Promp
UNABLE TO REPRODUCE GRAPHICS
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