Sometimes, the simplest problems end up taking the most time to overcome. If you are like me, you have probably spent a lot of time writing code that supports printer output. I finally replaced all of those routines with a set of standard printer output procedures that encapsulate several useful prompt and print functions in an easy-to-use toolkit of RPG IV procedures. These standard procedures allow users to redirect their printer output, and because printer attributes are stored in a file, these procedures make it easy to change the way reports are printed.
Some of the attributes supported by the print toolkit are lines per page, columns per page, overflow line, page rotation, and print drawer. Changing these attributes allows you to target reports for different printers and to take full advantage of the laser and ink-jet printers attached to your iSeries or AS/400. You can also change the output format for individual users. For example, by manipulating these attributes to print a report on large paper, using a larger font, you can help a user that has trouble reading small print.
Rather than relying on device settings or a programming change, the print toolkit allows your users to store their own defaults for a report. During prompting, users press a function key to save the output options they have entered. Later, when a user reruns that particular report, the saved options are retrieved and used when the report prompt is initially displayed. By having users maintain their own defaults, you save programming time and users gain control.
Gaining Control
Two files support the printer toolkit; they are a report control file and a report run file. The report control file contains information that describes print attributes. Only the report name, which is usually the procedure or program that produces the report, and the print file are required. If you do not specify an attribute, the attribute from the print file is used. Other values contained in this file include lines per page, columns per page, characters per inch, overflow line, page rotation, duplex, and print drawer. These attributes allow you to print reports on a variety of printers and give you the ability to change fonts, orientation (portrait or landscape), as well as other common attributes, such as save and hold.
The report run file stores information gathered by the prompt procedure. When a report is printed, an override procedure uses this information to apply a print file override.
The key to this file is a unique 15-digit sequence number retrieved from a data area and assigned by the prompt procedure. The information in this file is never purged, so if you do not see any reason to keep this information, you can delete it in the report completion procedure or create a periodic cleanup program.
Prompting for Overrides
The report prompt displays a window that allows users to change the output queue and number of copies, as wells as the save and hold options. I have found that these are the most frequently used printer options and are universally understood by the user community. It is not difficult to change the display procedure of the print toolkit if these options do not meet your needs. For example, you might want to allow users to change attributes like duplex, paper size, and print drawer.
To change the values that the report prompt supports, you will need to modify the Report Prompt (RptPrm) procedure and the Print Toolkit display file (PrtTktZ). Start by modifying the display file to support your prompt fields. Next, modify the parameters passed to the RptPrm procedure. Finally, add edits that ensure the values entered are correct.
To incorporate the report prompt into your programs, add a procedure call to the RptPrm procedure using the EVAL op code. You must pass the first parameter, which is Report ID; the other parameters are optional. The first optional parameter is Print file name. If you do not pass this, an override is generated for all print files defined for the report in the report control file. Passing 0 for the second optional parameter allows you to bypass the prompt and create override records based on the values specified in the control file. The other optional parameters allow the calling program to specify the initial values shown on the report prompt.
When the print prompt is called, the report control record for the report being prompted is retrieved. The attributes specified on that record are used to set the initial values shown on the prompt screen. The program then uses the Retrieve Mode (QsnRtvMod) Dynamic Screen Manager API to get the current display mode (27 x 132 or 24 x 80), and the prompt window is displayed in the appropriate mode. When a user presses F9, the values on the display are written to the control file with the current user’s profile. If the same user reruns the report, the saved values are shown. When the user presses Enter, the next report run sequence is retrieved from a data area and a report run record is written with the prompt values.
Applying an Override
To use the override information collected by the override prompt, you will need the unique run ID assigned by and returned from the report prompt procedure. Pass the run ID to the Report Override (RptOvr) procedure. The RptOvr procedure calls the Command Execution (QCMDEXC) API to apply the override, and error messages are sent back to the calling procedure.
If an override issued by RptOvr does not work, the probable cause is that the override scope is not set properly. Setting the scope to *JOB in the report control file is sure to fix the problem, but may cause a problem if the printer file is used again in the same job by another procedure that is not supported by the print toolkit.
The only thing left to do after producing a report is to call the Report Completion (RptCmp) procedure. This procedure sets the completion time and status on the report run record. This information can be used to identify reports that are failing or that have been running longer than expected.
You will have to experiment to find out what print attribute values will work with your printers. With the printers at my company (including several types of Hewlett-Packard LaserJets), I have found that for landscape orientation, a page rotation value of *AUTO, a characters-per-inch value of 18, and a print width of 238 will fit the most information on
8.5 x 14 inch paper. On 8.5 x 11 inch paper, specifying a characters-per-inch value of 15 with a print width of 198 works well. Setting the page rotation to 0 will cause reports to print in portrait orientation.
Another attribute you may want to change is the print drawer; at my company there is 8.5 x 11 inch paper in drawer 1, 8.5 x 14 inch paper in drawer 2, and special forms in drawer 3.
I have not provided a file maintenance program for the report control file, but any file update utility, such as DFU or DBU, will work.
Checking It Out
To use the print toolkit, you need to create several service programs, files, and a data area. Start by downloading the source code associated with this article, at www.midrangecomputing.com/mc. Follow the instructions found in the readme.txt document that describe how to unzip and save the source code to your AS/400; compile; and install the utility.
Now you are ready to try out the print toolkit. Start by calling Test Print Toolkit (TstPrtTkt) from a command line; there are no parameters. Enter an option to select one of the reports. A report prompt window like the one shown in Figure 1 pops up, displaying several output options. The prompted values will be blank the first time you select one of the test reports, because there is no definition for these reports in the report control file. When the report prompt does not find a report control record, one is added with minimal information. A report run record is written out when you press Enter on the report prompt.
After displaying the report prompt, the test program uses the returned report run sequence to call the override procedure. The override procedure retrieves the report run record and applies an override that reflects the values specified on the prompt. With the override in effect, the test program uses the QCMDEXC API to call the print program.
Now that you have seen how the print toolkit handles a report with no definition, try changing some of the print attributes in the report control file using a utility like DBU or DFU. Once you have changed the attributes, call the test prompt and print the report again.
Overriding Thoughts
There is nothing fancy about the printer toolkit procedures—they simplify and formalize the interface for some routines that you have likely written many times. Instead of creating new print support for every report on your system, the print toolkit procedures save time because standard print functionality is not duplicated in every print program. In addition to timesaving, these procedures provide a central point of control that allows you to focus your efforts and provide better print support for your users.
If you are moving your applications to ILE, the procedures contained in the print toolkit provide examples that show how to encapsulate your commonly used prompts into a toolkit. If you are already using ILE, it will be easy for you to use the print toolkit procedures to enhance your report prompts.
Figure 1: This plug-in report prompt enhances any application that prints a report.
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