Frank I wonder what it was you found "interesting" since you appear to be replying to yourself!
I strongly suspect that this is neither "perplexing" nor "strange" - when you understand the basics of IBM printer control, specifically the fundamental difference between ASA/ANSI (A) and "machine" (M). This topic has arisen twice in living memory[1] - but I guess most subscribers pay attention only to their immediate problems - probably described as "issues"! You'll have to excuse me if I try exclusively to use the Queen's English - and avoid split infinitives! Thanks to a regular contributor - strictly a pair of regular contributors if the e- mail identification is to be one's guide, we have an online copy of a "green card" which includes the codes both for "A" and "M" control codes with the crucial comment of when they take effect in "moving/advancing" the carriage, physical or logical, of the printer.[2] "Normalising" and generally "cleaning up" the two tables as laid out in the green card text, we have the following:[3] - For "ANSI (ASA) printer control characters" (RECFM=...A) Code Action before printing = COBOL "AFTER ADVANCING" + No space blank Space 1 line 0 Space 2 lines - Space 3 lines 1 Skip to channel 1 (line 1 on new page) 2 Skip to channel 2 3 Skip to channel 3 4 Skip to channel 4 5 Skip to channel 5 6 Skip to channel 6 7 Skip to channel 7 8 Skip to channel 8 9 Skip to channel 9 A Skip to channel 10 B Skip to channel 11 C Skip to channel 12 - For "Machine-defined printer control characters" (RECFM=...M) Code Action after printing = COBOL "BEFORE ADVANCING" 01 00000001 No space 09 00001001 Space 1 line 11 00010001 Space 2 lines 19 00011001 Space 3 lines 89 10001001 Skip to channel 1 (line 1 on new page) 91 10010001 Skip to channel 2 99 10011001 Skip to channel 3 A1 10100001 Skip to channel 4 A9 10101001 Skip to channel 5 B1 10110001 Skip to channel 6 B9 10111001 Skip to channel 7 C1 11000001 Skip to channel 8 C9 11001001 Skip to channel 9 D1 11010001 Skip to channel 10 D9 11011001 Skip to channel 11 E1 11100001 Skip to channel 12 - Note how the "M" code is constructed: bit 0 0=space, 1=channel bits 1-4 space count or channel number bit 5 always 0 bit 6 0=print, 1=no printing (not shown above) bit 7 always 1 - The "M" code becomes the operation byte of the channel command word (CCW) which explains why it is called the "machine-defined printer control character". There are other codes such as the diagnostic codes but including such exotic functions as raising the printer cover (X'6B') - just try that on the operators in the middle of the third shift! The key difference between the two sets is as follows: - with the "A" code, the printer carriage moves *before* the line is printed - or - the line is printed *after* the printer carriage is moved - with the "M" code, the printer carriage moves *after* the line is printed - or - the line is printed *before* the printer carriage is moved - I haven't checked your little program snippet in detail but I can see that the logic is establishing some sort of equivalence between two sets of codes as follows: - space - 1 - zero - 2 - "-" - 3 Given that I see the program is using "AFTER ADVANCING", I now begin to wonder where "machine control" comes into the picture. What this code snippet seems to be doing is simply reinterpret the "A" control characters to more "A" control characters. The program "sees" an "A" control code and, in effect, replaces it with the same "A" control code using the "AFTER ADVANCING" qualification of the WRITE statement. What the output you see is telling us is that, although IBM COBOL has been obliged to follow the "AFTER ADVANCING" instruction in creating a file suitable for a printer, it is nevertheless setting up "M" codes and so is obliged to set up two outputs, one to perform the "advancing", that is, carriage movement *without* printing and then one to perform the printing *without* carriage movement. As explained above, there is no code it could specify which would cause "advancing" and then printing - using "M" codes. Now, I don't know COBOL that well so I can only suggest some avenues to explore by either yourself or list subscribers still trying to follow all this who do know a thing or two about IBM COBOL. It is possible to specify the appropriate RECFM code, "A" or "M", in the JCL which causes the file to be created. The IBM COBOL program may pay attention to this or, given that the file is being created from within the program, the program as created by the COBOL compiler may feel entitled to override whatever RECFM code has been specified with its own idea of what the code should be. If it takes the RECFM code specified as "A" or it is induced somehow to consider that the code should be "A", then you should get "A" control codes, the "AFTER ADVANCING" codes will be the efficient option and the "BEFORE ADVANCING" codes will be the inefficient option. If it takes the RECFM code specified as "M" or it is induced somehow to consider that the code should be "M", then you should get "M" control codes, the "BEFORE ADVANCING" codes will be the efficient option and the "AFTER ADVANCING" codes will be the inefficient option. I believe you have managed to set up the latter case. How does the RECFM code, "A" or "M", in the DCB get set? That I can't answer but perhaps there is a COBOL programmer's guide manual which covers precisely that point. If someone can provide an URL for the appropriate manual I'll be happy to try to find the answer - or - that person might be able to find the answer - and post it for us all. Now I look at the reference John McKown provided again, I think I see what it is struggling to tell us. It would appear that the COBOL compiler imposes the "M" code in the DCB and ensures that the "M" code is used if any of the WRITE statements happens to use - or imply? - "BEFORE ADVANCING". Conversely that would mean that if every last WRITE statement specified "AFTER ADVANCING", you could either specify the "A" code through JCL or the COBOL compiler would manage to work out that "A" was the appropriate code to insert "A" into the DCB - and store "A" codes in the file. Chris Mason [1] In November 2009, someone was mystified by printer control codes and was hoping to "port" them to Linux: "FTP PUT RECFM=FBM files". The task then was simply to get rid of the codes. In October 2008 one John McKown asked a question about converting a file using "M" codes to one using "A" codes and so similar information to the above was elicited. [2] http://www.garlic.com/~lynn/gcard.html [3] There is actually a mistake on the supposedly "green card" text in that the machine "Immediate" "space 0 lines" should be X'03', that is, a "no-operation" - because - think about it - nothing happens! On Fri, 15 Jan 2010 18:33:49 -0700, Frank Swarbrick <[email protected]> wrote: >Interesting. The one very odd thing this system does is that it declares it's output files as EXTERNAL. A main program will open the file and write the first line and then call a subprogram. The subprogram also has the file as EXTERNAL. > >I was able to recreate it with the following program and subprogram: > >Main program: > >process noadv >identification division. >program-id. noadv. >environment division. >input-output section. >file-control. > select report-1 assign to report1. > >data division. >file section. >fd report-1 external > recording mode f. >01 report-1-record. > 05 report-1-cc pic x. > 05 report-1-data pic x(132). >procedure division. > open output report-1 > move all '-' to report-1-data > write report-1-record after advancing page > call 'noadvsub' > close report-1 > goback. >end program noadv. > >Sub program: >process noadv >identification division. >program-id. noadvsub. >environment division. >input-output section. >file-control. > select report-1 assign to report1. > >data division. >file section. >fd report-1 external > recording mode f. >01 report-1-record. > 05 report-1-cc pic x. > 05 report-1-data pic x(132). >procedure division. > move all '1' to report-1-data > write report-1-record after advancing 1 > move all '2' to report-1-data > write report-1-record after advancing 2 > move all '3' to report-1-data > write report-1-record after advancing 1 > move all '4' to report-1-data > write report-1-record after advancing 0 > move all '5' to report-1-data > write report-1-record > goback. >end program noadvsub. > >Still very strange, though. Any thoughts as to why this is? > >Thanks, >Frank >-- > >Frank Swarbrick >Applications Architect - Mainframe Applications Development >FirstBank Data Corporation - Lakewood, CO USA >P: 303-235-1403 > > >On 1/15/2010 at 6:19 PM, in message <[email protected]>, >Frank Swarbrick <[email protected]> wrote: >> Is there any reason that an Enterprise Cobol 4.2 program running under z/OS >> 1.10 might use 'machine control' characters instead of ANSI characters? >> >> We have a vendor program that uses a rather complex shared I/O module, and >> it appears to be the only one that's doing it. The writes themselves are >> pretty basic: >> >> X-000-RSP-PRINT. >> MOVE ZERO TO PDA-RWA-REQ. >> * >> IF RSP-PRINT-CC IS EQUAL TO '1' >> GO TO X-000-RSP-LINE1. >> IF RSP-PRINT-CC IS EQUAL TO SPACE >> MOVE 1 TO MSC-CC. >> IF RSP-PRINT-CC IS EQUAL TO ZERO >> MOVE 2 TO MSC-CC. >> IF RSP-PRINT-CC IS EQUAL TO '-' >> MOVE 3 TO MSC-CC. >> WRITE RSP-PRINT AFTER ADVANCING MSC-CC. >> GO TO X-000-EXIT. >> X-000-RSP-LINE1. >> WRITE RSP-PRINT AFTER ADVANCING MSC-CC-01. >> GO TO X-000-EXIT. >> >> MSC-CC-01 is in the SPECIAL-NAMES area as >> C01 IS MSC-CC-01. >> >> I even tried changing this to >> WRITE RSP-PRINT AFTER ADVANCING PAGE. >> and got the same result. >> >> Anyway, the output is like this... >> record 1 is x'8B' (Immed skip to channel 1) >> record 2 is x'01' (write without spacing) followed by the first line >> record 3 is x'0B' (Immed space 1 line) >> record 4 is x'01 (write without spacing) followed by the second line >> record 5 is x'0B' (Immed space 1 line) >> >> and on and on like that. In SDSF it looks like there is one blank line >> after each non-blank line. >> >> I can't seem to recreate the issue with just a simple program. >> >> It's quite perplexing! >> >> Thanks, >> Frank ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
