Edit Spooled Files with SEU
November 9, 2005 Hey, Ted
If the name Don Rima sounds familiar to you, it should. Don is well known for his product reviews in the iSeries edition of eServer Magazine and as the president of the Washington Area Midrange iSeries user group. Here is Don’s technique for editing a spooled file with SEU (or any other source-code editor).
1. Create a program-described non-source physical file member (unless you already have a suitable one.) The record length should be one byte longer than the report. That is, for a 132-column report, create a physical file with 133-byte records.
CRTPF QTEMP/TEMP RCDLEN(133)
2. Use the Copy Spooled File (CPYSPLF) command to place the report in the physical file member you just created. Specify that you want to use first-character forms control in order to prefix each record with skipping and spacing information. I explained the forms-control codes in Extract Reports from Disk Files.
CPYSPLF FILE(QPRTLIBL) TOFILE(QTEMP/TEMP) + JOB(*) CTLCHAR(*FCFC)
3. Unless you already have one, create a source physical file in which to edit the report. The record length should be 12 bytes more than the physical file you created in step 1.
CRTSRCPF FILE(QTEMP/TEMPSRC) RCDLEN(146) MBR(TEMPSRC)
4. Copy the non-source physical file member to the source physical file member, specifying FMTOPT(*CVTSRC).
CPYF FROMFILE(QTEMP/TEMP) TOFILE(QTEMP/TEMPSRC) + MBROPT(*REPLACE) FMTOPT(*CVTSRC)
5. Use SEU to edit the report. Remember that the first column is reserved for the forms control characters.
STRSEU SRCFILE(QTEMP/TEMPSRC) SRCMBR(TEMPSRC)
6. Now reverse the process. First copy the source member to the non-source member.
CPYF FROMFILE(QTEMP/TEMPSRC) TOFILE(QTEMP/TEMP) + MBROPT(*REPLACE) FMTOPT(*CVTSRC)
7. Build a new report by copying the non-source member to a program-described printer file, such as QSYSPRT. You’ll need an override to make CPYF interpret the forms control characters.
OVRPRTF FILE(QSYSPRT) CTLCHAR(*FCFC) CPYF FROMFILE(QTEMP/TEMP) TOFILE(QSYSPRT)
“Now,” says Rima, “you’re in business.”
Don mentions further that there are some size constraints, but this technique works great in many cases.
Now that the technique has been presented, let’s talk briefly about appropriate usage. The Sarbanes-Oxley law is all the rage, to the point that many of us are almost afraid to do our jobs. A technique like this one might be misused to falsify reports, so should we avoid it?
I don’t think so. Just because some people abuse something doesn’t mean that others shouldn’t be allowed to use that something in a legitimate fashion.
One example Don gives is the user who types in the wrong year on a prompt screen before a program runs. Some of the packaged software I have used is inflexible and mistakes are not easily corrected. If someone enters the wrong year before running a month-end close, correcting the database might be a simple matter of one SQL UPDATE command, but fixing the report that is generated during the close might not be such a simple matter. Editing the report might be the easiest way to fix the problem, especially if the “correct” way involves reloading the database from the last backup and redoing all the work that was done up until the close.
During testing, a developer might find it advantageous to make manual changes to an existing report in order to get the user’s approval of the new report layout before writing the code that generates the new report format.
Any programming technique, or at least many techniques, can be used for good or for bad. After all, people who write viruses use the same languages and programming techniques that everyone else uses. It could also be argued that a person who is doing something nefarious at work will be caught eventually, no matter what techniques he uses.