|
There's probably several ways to do things, but for me, I can go to the spool file list of reports & designate some report to start printing immediately, without waiting on the program to finish creating it. Problem is that this now ties up the printer with that report until it is done. We have scores of jobs going to same printer.. Of course if that printer is only needed for that program, then no problem for you. You might take a look in OVRPRTF in the CL. I am sure it is in there, I just not remember the parameter.
If in fact you have large numbers of reports, you might consider how long you want the iSeries to hang onto the disk space that a report ate, before recovering it, after the report gets deleted. The trade off is that it is faster to put new reports back into our holes from prior reports. We have ours set at recover the disk space 3 days after the hole was created by deleting a report. I not remember where we set that ... WRKSYSVAL or GO CLEANUP.
Another wrinkle you might look at is the size of the printer file. You can make it *NOMAX and hope you never have a runaway job, or you can periodically deal with hassle when something gets up to XX,XXX pages. When that happens, the operator has to respond to an error message to close one chunk, and start another chunk. I suppose someone could put in auto response messages to respond on behalf of the operator, and in advance set size of printer file so that it will fill up more rapidly than usual.
I know that anything that can be done in COBOL or in RPG can be done in the other language, I just not know the process. I write in RPG. With RPG the way I would do this is designate one program to do the segments, and another to be the main program to process all the neccessary data. The segment printing program would be called by the main program, which would pass it the relevant info, it would do its thing & return control to the main program. Customarily performance demands that the called printing program would remain in a "wait state" until called again by the main program. When the main program ends, both programs would end. However, by ending the called program for each segment to be printed, that releases the report to the printer.
I think this is a very inefficient way to use the iSeries. Print immediately, without waiting for the program to finish running, is so much more efficient way of solving this. One program should be having page top bottom controls that distinguish the individual letters, and print immediately can be from CL that manages the one program.
List, I have another mainframe-to-iSeries question for you. On our VSE system, every night, we print tens of thousands of 1-page letters on our Xerox laser. The program on the VSE system creates 1 large "report" to the spooler containing all of the letters in a certain order. The program "segments" the output on a logical boundary, usually a combination of number of letters and form code/type. The reason this is done is so that printing of letters can be started (i.e. sent to the Xerox) BEFORE the program has completed processing of all the letters for the run. This saves time, allowing the operator to get a "jump" on the printing by not having to wait until the program has finished to be able to release the print. My questions: Is there a way to duplicate this process on the iSeries? Can a COBOL program interface with the system so that it can "segment" the print file output? Would it be as simple as closing and re-opening the print output file? What is the best way to handle this? As always, TIA! -- Regards, Michael Rosinger Systems Programmer / DBA Computer Credit, Inc. 640 West Fourth Street Winston-Salem, NC 27101 336-761-1524 m rosinger at cciws dot com -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
