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 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 an
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 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 th
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
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 q&d 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#ha
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 writes: > my gcard.html ... was q&d 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 "M"s 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