|
Michael, The average COBOL program does not need to worry with the printer control character on the iSeries. If you are writing to a print file it will handle the printer control in the print file. WRITE....ADVANCING will work and give the correct spacing on the report. When migrating from the mainframe you have to deal with the 1 byte control character basically one of two ways. You can remove the one byte in front of the print record in the COBOL program and the print file will handle all of the spacing for WRITE.....ADVANCING n lines. The other option is to use the TBLREFCHR(*YES) option on the print file override statement. This will only work with DEVTYPE(*LINE/*AFPDSLINE) OVRPRTF FILE(TESTPRT) DEVTYPE(*LINE) TBLREFCHR(*YES) Hope this helps Jerry Thomas -----Original Message----- From: cobol400-l-bounces@xxxxxxxxxxxx [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Rosinger Sent: Thursday, November 02, 2006 6:38 AM To: cobol400-l@xxxxxxxxxxxx Subject: [COBOL400-L] printer control character in print file records This is related to my other post concerning print lines greater than 132... In the mainframe world, there is a COBOL compiler option (ADV/NOADV) which deals with the placement of printer control characters for print lines. If ADV is specified, the compiler adds one byte to the record length to account for the printer control character. ADV is only meaningful if you use WRITE...ADVANCING in the source code. If NOADV is in effect, the assumption is that the print line has already reserved a byte for the printer control character. I've searched through what I can find are the available compiler options for COBOL/ILE and I don't see anything comparable to ADV/NOADV. How is the printer control character handled on the iSeries? Is this something the average iSeries COBOL program needs to be concerned with?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.