Re: sysout using machine control instead of ANSI control
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. Anne Lynn Wheeler l...@garlic.com writes: my gcard.html ... was qd conversion of (CMS) IOS3270 file that was widely available internally, I wasn't the original author, but had added the *sense* information in the file ... most of which came from the 360/67 (blue) reference card; see bottom of web page for original attribution. re: http://www.garlic.com/~lynn/2010b.html#44 sysout using machine control instead of ANSI control 360/67 blue reference card was filled in with lots of sense info for various devices ... except for A220 (HYPERChannel link adapter) which I added ... I was using lots of HYPERChannel boxes in various HSDT activities http://www.garlic.com/~lynn/subnetwork.html#hsdt This particular 360/67 reference card is stamped with Ms name (I must have borrowed and never returned). GML had been invented in 1969 by G, M, and L (first letter of their last names) at the science center ... which later was standardized as SGML ... misc. past posts http://www.garlic.com/~lynn/submain.html#sgml SGML then morphed into HTML, XML, etc ... old description of the evolution: http://infomesh.net/html/history/early and then the first webserver outside cern is slac/vm system http://www.slac.stanford.edu/history/earlyweb/history.shtml ... cern slac were sister institutions ... sharing a lot of technology and applications ... both were on BITNET/EARN (educational network using similar RSCS technology used for internal network) long-winded recent post with old early 90s information from netinfo center ... including long extract about EARN http://www.garlic.com/~lynn/2010b.htmL#36 Happy DEC-10 Day I've lots of bits and pieces from such places from the late 80s early 90s. I had bunch of CMS execs that I would periodically execute which would go out to various places on the internet and check for new/change files ... and then pull off new/changed stuff. other references to archive http://www.garlic.com/~lynn/2010b.html#23 Happy DEC-10 Day http://www.garlic.com/~lynn/2010b.html#33 Happy DEC-10 Day http://www.garlic.com/~lynn/2010b.html#34 Happy DEC-10 Day for other drift ... old email related to nsfnet backbone http://www.garlic.com/~lynn/lhwemail.html#nsfnet -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sysout using machine control instead of ANSI control
Since you have a shared I/O module, it's possible that it may have to accept a mixture of both RECFM=A and RECFM=M records. If this is the case, it would have to normalize the records before output. For final printing, the control characters would need to be in the form of channel commands and so RECFM=M would be the obvious choice of norm. After all, someone has to do the conversion whether it be the access method, JES, or this shared I/O module. It wouldn't make sense for this module arbitrarily to choose RECFM=A knowing that, at some point, some other module would have to convert to RECFM=M. A quick glance at the tables provided by Chris Mason reveals that the codes are unique with the exception of x'C1' so, unless someone is skipping to channel 10 before printing or skipping to channel 8 after printing, the shared module would not have to concern itself with ambiguity. ;-) I note that recent versions of the (green/white/yellow) Reference Summary do not list any channel skipping other than for line 1. Date: Fri, 15 Jan 2010 18:19:45 -0700 From: frank.swarbr...@efirstbank.com Subject: sysout using machine control instead of ANSI control To: IBM-MAIN@bama.ua.edu 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. _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/196390709/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sysout using machine control instead of ANSI control
On Sun, 17 Jan 2010 04:04:22 -0500, J R wrote: have to normalize the records before output. For final printing, the control characters would need to be in the form of channel commands and so RECFM=M would be the obvious choice of norm. After all, someone has to do the conversion whether it be the access method, JES, or this shared I/O module. It wouldn't make sense for this module arbitrarily to choose RECFM=A knowing that, at some point, some other module would have to convert to RECFM=M. The choice should be for the convenience of the programmer. ANSI is the mode except for a few holdout utilities such as assembler (and HLASM provides an option.) Neither the overhead of another conversion (miniscule) nor the likelihood of information degradation (none, IMO) should make performance a determining factor here. (Barring the possibility that a chain of conversions, thoughtlessly implemented, doubles the number of records at each link.) A quick glance at the tables provided by Chris Mason reveals that the codes are unique with the exception of x'C1' so, unless someone is skipping to channel 10 before printing or skipping to channel 8 after printing, the shared module would not have to concern itself with ambiguity. ;-) VM/CMS does this. Carriage control is an optiopn, but CMS makes no distinction between ANSI and machine. The (one) ambiguity is decided it favor of ANSI, a minor technical reason for the CMS programmer to choose ANSI. I have known the VM/CP side of NJE (RSCS?) to fail transfers with data errors because the incoming data used a printer CCW that referred to a channel not defined in the virtual FCB CP had chosen. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sysout using machine control instead of ANSI control
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
chrisma...@belgacom.net (Chris Mason) writes:
[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!
my gcard.html ... was qd conversion of (CMS) IOS3270 file that was
widely available internally, I wasn't the original author, but had added
the *sense* information in the file ... most of which came from the
360/67 (blue) reference card; see bottom of web page for original
attribution.
scan of real green card:
http://www.bitsavers.org/pdf/ibm/360/referenceCard/
gimick that VNET/RSCS used for networking control (TAG) information
was a no-op ('03') ccw pointing to the control information (with length
of the information) ... aka VNET/RSCS used the cp (unit record) spool
system for all its files ... so everything had to look like a printer or
punch stream (generated with appropriate channel commands, cp treated
the no-op as no-op ... but would still copy the indicated data into its
spool file).
A major internal email client was VMSG. The PROFS group at one point
acquired the source for an early copy of VMSG for the PROFS email client
code. Later the VMSG author offerred to upgrade PROFS with latest VMSG
version that had a lot more function ... the PROFS group denied that it
was using VMSG and then attempted to have the VMSG author fired. That
was suspended when the VMSG author pointed out that every PROFS message
carried his initials in the comment portion of the RSCS network control
(TAG) information.
RSCS/VNET was the dominant internal networking infrastructure ... part
of it was because of the NJE (HASP/JES) heritage using the HASP psuedo
device table to define networking nodes. The internal network was
larger than the arpanet/internet from just about the beginning until
sometime mid-85 or early 86. misc. past posts mentioning internal
network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
The early HASP networking source code changes had TUCC out in
cols. 68-71 ... and used the left-over entries in the one-byte index
(255 entry) psuedo device table; installations frequently had 60-80
psuedo (unit record) devices (printer, punch, reader) ... which left
less than 200 for defining networking nodes. By the time JES2/NJE
shipped, the internal network was already over 200 nodes.
Corporate wasn't even going to allow RSCS/VNET to be announced (this was
in the period when POK had convinced corporate to kill off vm370,
shutdown the burlington mall development group and move all the people
to POK ... justification was because POK needed all the people in order
to meet the MVS/XA ship schedule; endicott eventually managed to save
the vm370 product mission, but had to reconsitute a group from scratch;
head of POK is also considered a major contributor to VAX/VMS because so
many people left for DEC rather than move to POK).
The JES2/NJE group did manage to talk the corporation into a joint
JES2/RSCS product announcement. The issue was that even at the minimum
monthly rate that could be charged for corporate product ... it would
still cover the VNET/RSCS development costs. However, there was no
customer forcast at any monthly price that would cover the NJE
development costs (number of customers times monthly rate was always
less than NJE costs; as projected monthly rate went up, the number of
forcasted customers declined). The way out for JES2 was to combine the
RSCS+NJE costs divided by the combined RSCS+NJE customer forcast
... which finally resulted in number the business people could agree
with.
VNET/RSCS had a fairly clean layered implementation ... which among
other things allowed native drivers to co-exist with NJE drivers. In
fact, VNET/RSCS quickly became mechanism to keep different JES2s from
crashing MVS. JES2/NJE had jumbled up networking information and JES2
control information ... and network traffic between JES2 at different
releases could result in JES2 failure, also taking down the MVS system.
As a result, there was a growing library of VNET/RSCS NJE drivers ...
allowing the specific NJE driver for the release of JES2 on the other
end of the link. The VNET/RSCS NJE drivers also had a growing body of
code that would rewrite NJE headers (originating from another JES2
system) to be compatible with the directly connected JES2 system. There
is the infamous case of a modified San Jose JES2 system causing MVS
systems in Hursley to crash ... and it being blamed on VNET/RSCS
(because the Hursley VNET/RSCS NJE drivers hadn't been updated with the
latest countermeasures for keeping incompatible releases of JES2 causing
MVS to crash). misc. past posts mentioning HASP, JES2, and/or hasp/jes2
networking
http://www.garlic.com/~lynn/submain.html#hasp
Native VNET/RSCS
Re: sysout using machine control instead of ANSI control
What's the JCL DD look like? Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sysout using machine control instead of ANSI control
RECFM=FBM rather than RECFM=FBA In case of fixed records. Is this what you are looking for? Birger Heede On 16-01-2010 09:48, Brian Westerman wrote: What's the JCL DD look like? Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sysout using machine control instead of ANSI control
On Fri, 15 Jan 2010 18:19:45 -0700, Frank Swarbrick wrote: 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. This is often an artifact of simple-minded conversion from ANSI carriage control to machine. But that results in one blank line _before_ each non-blank line, not after. CMS used to do this, writing to the VM spool, but I believe it got better after a while. Is VM in your picture somehow? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sysout using machine control instead of ANSI control
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 0001 No space 09 1001 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 1011 Skip to channel 4 A9 10101001 Skip to channel 5 B1 10110001 Skip to channel 6 B9 10111001 Skip to channel 7 C1 1101 Skip to channel 8 C9 11001001 Skip to channel 9 D1 11010001 Skip to channel 10 D9 11011001 Skip to channel 11 E1 1111 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
sysout using machine control instead of ANSI control
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 ADVANCINGMSC-CC. GO TO X-000-EXIT. X-000-RSP-LINE1. WRITE RSP-PRINT AFTER ADVANCINGMSC-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 ADVANCINGPAGE. 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 -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sysout using machine control instead of ANSI control
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 4b50b1c0.6f0f.008...@efirstbank.com, Frank Swarbrick frank.swarbr...@efirstbank.com 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 ADVANCINGMSC-CC. GO TO X-000-EXIT. X-000-RSP-LINE1. WRITE RSP-PRINT AFTER ADVANCINGMSC-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 ADVANCINGPAGE. 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 The information contained in this electronic communication and any document attached
Re: sysout using machine control instead of ANSI control
I'm not a COBOL expert but I think it is caused by the after advancing - at least I seem to remember pondering this question at some point in my career and that comes to mind as the cause. Not unique to COBOL 4.2 Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Friday, January 15, 2010 19:34 To: IBM-MAIN@bama.ua.edu Subject: Re: sysout using machine control instead of ANSI control 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 4b50b1c0.6f0f.008...@efirstbank.com, Frank Swarbrick frank.swarbr...@efirstbank.com 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 ADVANCINGMSC-CC. GO TO X-000-EXIT. X-000-RSP-LINE1. WRITE RSP-PRINT AFTER ADVANCINGMSC-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 ADVANCINGPAGE. 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
