Re: A couple of interesting COBOL V5 fixes

2016-05-23 Thread Chris Hoelscher 
Unless you take the perspective that "everything that is not illegal is legal" 
- undocumented closing of "loopholes" or making undesirable (but legal) coding 
practices now illegal doesn't seem to necessarily seem to be in the best 
interest o fhte customer ... 

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Frank Swarbrick
> Sent: Monday, May 23, 2016 1:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] A couple of interesting COBOL V5 fixes
> 
> Very interesting stuff, Bill.  Thanks for pointing them out!
> 
> Just goes to show that some shops did "interesting" things to get around
> limitations within the COBOL standard.  While IBM was "right" from some
> perspective to make the changes they did to COBOL, not considering (and
> why would they) how shops might have "abused" unintended/undefined
> behaviors, it also shows that shops often do depend on these
> unintended/undefined behaviors.
> 
> Frank
> > Date: Sun, 22 May 2016 04:00:37 -0500
> > From: bill.wood...@gmail.com
> > Subject: A couple of interesting COBOL V5 fixes
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible
> with how V4 works.
> >
> > http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330
> >
> > "In earlier versions of COBOL, customer source frequently handled
> > dynamically sized pieces of storage by using a PIC X(1) linkage
> > section data-item and then reading or writing beyond the bounds of
> > that array.  This APAR will add this type of support to COBOL V5 to
> > make the behavior consistent with COBOL V4.
> >
> > LINKAGE Example:
> >
> > WORKING-STORAGE SECTION.
> > 01  wrk-len PIC s9(08) binary.
> > LINKAGE SECTION.
> > 01  L-String1   PIC X(1).
> > 01  L-String2   PIC X(1).
> > PROCEDURE DIVISION.
> > -MAIN.
> > MOVE 1000 TO wrk-len
> > MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len)
> >
> > Behavior difference:  COBOL V4 moves 1000 bytes.  COBOL V5 moves 232
> > bytes due to differing instructions.
> >
> > TABLE ODO Example:
> > WORKING-STORAGE SECTION.
> > 01  CONTROLVAR PIC 9(5) BINARY.
> > 01  MYCONTAINER.
> > 02  MYTABLE.
> > 03 TBL OCCURS 0 TO 1 TIMES DEPENDING ON CONTROLVAR.
> >05 MYFIELD PIC X(1).
> > 02 DUMMY PIC X(300).
> > PROCEDURE DIVISION.
> > MOVE 1 TO CONTROLVAR
> > MOVE ALL 'Z' TO DUMMY
> > DISPLAY DUMMY  <= Contains all Z's
> > MOVE 300 TO CONTROLVAR
> > MOVE ALL 'M' TO MYTABLE <= MYTABLE has 1 byte of M's in V4
> > DISPLAY MYTABLE
> > MOVE 1 TO CONTROLVAR
> > DISPLAY DUMMY   <= DUMMY HAS 299 BYTES OF M's in V4.
> >
> > Behavior difference:  COBOL V4 overlays storage following MYTABLE
> > exactly as expected byte for byte.  COBOL V5 handles the overlay
> > differently such that the storage results differ from COBOL V4."
> >
> > And:
> >
> > "Problem conclusion
> >
> > The compiler was updated to ensure that in the above move
> > scenario the runtime length of the move, as implied by the
> > variable length reference modification, is always used
> > regardless of the defined length of the receiving data item in
> > the linkage section."
> >
> > Note, it won't work if compiled with SSRANGE.
> >
> > No "Local Fix" was outlined. The idea is that you no longer have to
> > fix the code :-)
> >
> > Where such techniques are used, it will make migration easier.
> >
> > Secondly, some movement on the NUMPROC(MIG) issue which has
> previously been discussed here.
> >
> > http://www-01.ibm.com/support/docview.wss?uid=swg1PI56073
> >
> > "
> **
> **
> > * USERS AFFECTED: Users of Enterprise COBOL V5.2 migrating *
> > * from a pre-V5 compiler, compiling and*
> > * running programs that were using the *
> > * NUMPROC(MIG) compiler option in pre-V5.  *
> > *  *
> >
> **
> **
> > * PROBLEM DESCRIPTION: Performance: Programs compiled with *
> > *  NUMPROC(NOPFD) using Enterprise COBOL   *
> > *  V5 is slower than programs compiled *
> > *  with NUMPROC(MIG) using a pre   *
> > *  Enterprise COBOL V5 compiler.   *
> > *  *
> >
> **
> **
> > * RECOMMENDATION: Apply the provided PTF.  *
> >
>

Re: A couple of interesting COBOL V5 fixes

2016-05-23 Thread Frank Swarbrick 
Very interesting stuff, Bill.  Thanks for pointing them out!

Just goes to show that some shops did "interesting" things to get around 
limitations within the COBOL standard.  While IBM was "right" from some 
perspective to make the changes they did to COBOL, not considering (and why 
would they) how shops might have "abused" unintended/undefined behaviors, it 
also shows that shops often do depend on these unintended/undefined behaviors.

Frank
> Date: Sun, 22 May 2016 04:00:37 -0500
> From: bill.wood...@gmail.com
> Subject: A couple of interesting COBOL V5 fixes
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible 
> with how V4 works.
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330
> 
> "In earlier versions of COBOL, customer source frequently
> handled dynamically sized pieces of storage by using a PIC X(1)
> linkage section data-item and then reading or writing beyond
> the bounds of that array.  This APAR will add this type of
> support to COBOL V5 to make the behavior consistent with COBOL
> V4.
> 
> LINKAGE Example:
> 
> WORKING-STORAGE SECTION.
> 01  wrk-len PIC s9(08) binary.
> LINKAGE SECTION.
> 01  L-String1   PIC X(1).
> 01  L-String2   PIC X(1).
> PROCEDURE DIVISION.
> -MAIN.
> MOVE 1000 TO wrk-len
> MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len)
> 
> Behavior difference:  COBOL V4 moves 1000 bytes.  COBOL V5
> moves 232 bytes due to differing instructions.
> 
> TABLE ODO Example:
> WORKING-STORAGE SECTION.
> 01  CONTROLVAR PIC 9(5) BINARY.
> 01  MYCONTAINER.
> 02  MYTABLE.
> 03 TBL OCCURS 0 TO 1 TIMES DEPENDING ON CONTROLVAR.
>05 MYFIELD PIC X(1).
> 02 DUMMY PIC X(300).
> PROCEDURE DIVISION.
> MOVE 1 TO CONTROLVAR
> MOVE ALL 'Z' TO DUMMY
> DISPLAY DUMMY  <= Contains all Z's
> MOVE 300 TO CONTROLVAR
> MOVE ALL 'M' TO MYTABLE <= MYTABLE has 1 byte of M's in V4
> DISPLAY MYTABLE
> MOVE 1 TO CONTROLVAR
> DISPLAY DUMMY   <= DUMMY HAS 299 BYTES OF M's in V4.
> 
> Behavior difference:  COBOL V4 overlays storage following
> MYTABLE exactly as expected byte for byte.  COBOL V5 handles
> the overlay differently such that the storage results differ
> from COBOL V4."
> 
> And:
> 
> "Problem conclusion
> 
> The compiler was updated to ensure that in the above move
> scenario the runtime length of the move, as implied by the
> variable length reference modification, is always used
> regardless of the defined length of the receiving data item in
> the linkage section."
> 
> Note, it won't work if compiled with SSRANGE.
> 
> No "Local Fix" was outlined. The idea is that you no longer have to fix the 
> code :-)
> 
> Where such techniques are used, it will make migration easier.
> 
> Secondly, some movement on the NUMPROC(MIG) issue which has previously been 
> discussed here.
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PI56073
> 
> "
> * USERS AFFECTED: Users of Enterprise COBOL V5.2 migrating *
> * from a pre-V5 compiler, compiling and*
> * running programs that were using the *
> * NUMPROC(MIG) compiler option in pre-V5.  *
> *  *
> 
> * PROBLEM DESCRIPTION: Performance: Programs compiled with *
> *  NUMPROC(NOPFD) using Enterprise COBOL   *
> *  V5 is slower than programs compiled *
> *  with NUMPROC(MIG) using a pre   *
> *  Enterprise COBOL V5 compiler.   *
> *  *
> 
> * RECOMMENDATION: Apply the provided PTF.  *
> 
> NUMPROC(MIG) does not require sign codes to be cleaned before
> comparing two zoned decimal data items. NUMPROC(NOPFD) requires
> sign codes to be cleaned.
> 
> Problem conclusion
> 
> A more efficient code sequence for cleaning sign codes during
> comparisons was developed."
> 
> So, NUMPROC(MIG) has not returned (and is less likely to), but NUMPROC(NOPFD) 
> has been made faster.
> 
> This is an amusing one:
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PI59344
> 
> ADD 0 TO a-zoned-decimal-field was "optimized out" under the new 
> ZONEDATA(NOPFD)/ZONEDATA(MIG). Since this was sefl-defeating (the ADD 0 would 
> cause zones, and signs, to be fixed), the ADD 0 will remain.
> 
> It is still optimized-out for ZONEDATA(PFD) because "the zone bits are 
> assumed to be correct with ZONEDATA(PFD)".
> 
> I'm not so sure

Re: z/OSMF

2016-05-23 Thread Jesse 1 Robinson 
We're rolling it out gradually. Enabled for core logon, ISPF, SDSF, and problem 
determination. Software management will be a big deal; may not step into that 
puddle.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Monday, May 23, 2016 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: z/OSMF

Have it - not using it for software management


--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI Service 
Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Monday, May 23, 2016 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] z/OSMF

Just curious to see how many have implemented z/OSMF and do you use it for 
software management?

Thanks in advance!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OSMF

2016-05-23 Thread Dyck, Lionel B. (TRA) 
Have it - not using it for software management


--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Monday, May 23, 2016 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] z/OSMF

Just curious to see how many have implemented z/OSMF and do you use it for 
software management?

Thanks in advance!





Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

z/OSMF

2016-05-23 Thread Lopez, Sharon 
Just curious to see how many have implemented z/OSMF and do you use it for 
software management?

Thanks in advance!





Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TSO receive on MultiVolume PS error

2016-05-23 Thread Mick Graley 
Yes XMIT definitely supports DSORG=PS RECFM=U data sets.
Good example being DFDSS dumps.
I regularly use DFDSS to dump multiple data sets, then XMIT that dump
data set to get a very portable RECFM=FB LRECL=80 version of the dump.
Cheers,
Mick.


On 20 May 2016 at 18:36, Jesse 1 Robinson  wrote:
> OP referred to a 'PS with Fo[r]mat U'. Does XMIT/RECEIVE even support PS 
> files with RECFM U? The only RECFM U files I know of are load modules, but 
> they are PO, not PS. In any case the error message refers to the XMITted 
> file, not the target.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Friday, May 20, 2016 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TSO receive on MultiVolume PS error
>
> On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:
>>
>>Are you sure your dataset has been transferred properly and fully and without 
>>errors before you tried out RECEIVE?
>>
> My quick check for this is (IIRC):
>
> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>
> ... at both ends of the transfer and compare the checksums and lengths.
>
> (Or you could write an assembler program using CSNBOWH.)
>
> -- gil
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Two RFE's to please vote for

2016-05-23 Thread Dyck, Lionel B. (TRA) 
Excellent 


--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 23, 2016 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Two RFE's to please vote for

On Thu, 19 May 2016 13:57:41 -0500, Dyck, Lionel B. (TRA) wrote:
>
>also for StreamIO
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47
>742
> 
I added Public comment:

o If implemented, this should work alike for Classic data sets and for UNIX 
files.

o If implemented, this should work alike under OMVS shell, TSO, and IRXJCL.

o If implemented, this should support the Standard SIGNAL ON NOTREADY.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Two RFE's to please vote for

2016-05-23 Thread Paul Gilmartin 
On Thu, 19 May 2016 13:57:41 -0500, Dyck, Lionel B. (TRA) wrote:
>
>also for StreamIO
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47742
> 
I added Public comment:

o If implemented, this should work alike for Classic data sets and for UNIX 
files.

o If implemented, this should work alike under OMVS shell, TSO, and IRXJCL.

o If implemented, this should support the Standard SIGNAL ON NOTREADY.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Query for Destination z article on using checklists in IT

2016-05-23 Thread Gabe Goldberg 
The excellent and readable book "The Checklist Manifesto: How to Get 
Things Right"  (link below to avoid wrapping) illustrates -- using 
examples from medicine, aviation, and many other contexts -- great and 
pervasive value in applying structure, planning, discipline, and 
checklists to complex projects. Working with technology, we're more than 
familiar with lists of instructions for installing, maintaining, 
debugging, and repairing what we work with. For example, VM through many 
incarnations has used an IVP (Installation Verification Program) to 
exercise basic functions. Long ago in a VM data center, we added local 
functions to the test suite. Ensuring successful IVP operation at least 
reduces unpleasant surprises when systems entered production. And 
examples in the book from aviation and the military show how checklists 
and structured reports avoid problems, solve problems, and improve 
quality by identifying weak areas.


 -- the book

Many years ago when purchasing a new mainframe, we endured meetings with 
our IBM team called Systems Assurance. Tedious though they were, they 
paid off in ensuring that we bought the right configuration, properly 
prepared the data center facility, and understood the 
delivery/installation process. It was clearly based on years of 
experience with things going not quite right. So -- I'd like to hear 
about experiences using checklists for anything mainframe related (e.g., 
designing, developing, testing, debugging, documenting). Initially, 
being brief is fine; I'll follow up for details.


As usual, please copy me directly to avoid replies being buried in list 
digests. Thanks!


--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFSORT course / Trainning materials?

2016-05-23 Thread Sri h Kolusu 
ITschak,

Please send an offline mail to our hotline dfs...@us.ibm.com and we can 
discuss in detail about the training material/classes. 

Thanks,
Sri Hari Kolusu
DFSORT Development
IBM Corporation



From:   Itschak Mugzach 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   05/22/2016 12:23 PM
Subject:DFSORT course / Trainning materials?
Sent by:IBM Mainframe Discussion List 



I am looking for DFSORT course (can be a vendor course), or free course
materials including excessive. Hope you can point me to...

Best,
ITschak



*| **Itschak Mugzach | Director | SecuriTeam Software | *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFSORT course / Trainning materials?

2016-05-23 Thread Dan Little 
Check out...

http://www.ibm.com/storage/dfsort


And the downloads...

On Sunday, 22 May 2016, Itschak Mugzach  wrote:

> I am looking for DFSORT course (can be a vendor course), or free course
> materials including excessive. Hope you can point me to...
>
> Best,
> ITschak
>
>
>
> *| **Itschak Mugzach | Director | SecuriTeam Software | *
>
> *|* *Email**: i_mugz...@securiteam.co.il  **|* *Mob**: +972
> 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

A couple of interesting COBOL V5 fixes

2016-05-23 Thread Bill Woodger 
> We have lots of COBOL that does exactly this. I voiced our concerns to Tom 
> Ross (aka Captain COBOL) on a GSE COBOL WorkGroup meeting in January. Tom was 
> there and gave presentations about COBOL v5 and ABO. Very interesting to meet 
> him and hear him speak. At that time he seemed to be aware of these 
> differences between COBOL v4 and v5 but seemed inclined to see this as the 
> customers problem. I'm glad they fixed this. It would have made the migration 
> to v5 almost impossible for us. It is hard enough without such issues.
> 
> Fred!
> 

Yes, I think that now there is the acceptance of two different types of "bad 
code" from IBM. "bad code" that doesn't work consistently with existing 
compilers, so go sort it out yourself. "bad code" which works consistently with 
the existing compilers, but relies on how the compilers work for things that, 
in the Standard, are down to the implementor. IBM are willing to look at 
getting V5+ to work the same as earlier compilers for the second type of "bad 
code".

Some things, like the new physical location of indexes, immediately after the 
table they are defined on, are going to take longer to sort out, but it's on 
the list of things to do.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A couple of interesting COBOL V5 fixes

2016-05-23 Thread Windt, W.K.F. van der (Fred) 
> Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible
> with how V4 works.
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330
> 
> "In earlier versions of COBOL, customer source frequently handled
> dynamically sized pieces of storage by using a PIC X(1) linkage section data-
> item and then reading or writing beyond the bounds of that array.  This APAR
> will add this type of support to COBOL V5 to make the behavior consistent
> with COBOL V4.
> 
> LINKAGE Example:
> 
> WORKING-STORAGE SECTION.
> 01  wrk-len PIC s9(08) binary.
> LINKAGE SECTION.
> 01  L-String1   PIC X(1).
> 01  L-String2   PIC X(1).
> PROCEDURE DIVISION.
> -MAIN.
> MOVE 1000 TO wrk-len
> MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len)
> 
> Behavior difference:  COBOL V4 moves 1000 bytes.  COBOL V5 moves 232
> bytes due to differing instructions.

We have lots of COBOL that does exactly this. I voiced our concerns to Tom Ross 
(aka Captain COBOL) on a GSE COBOL WorkGroup meeting in January. Tom was there 
and gave presentations about COBOL v5 and ABO. Very interesting to meet him and 
hear him speak. At that time he seemed to be aware of these differences between 
COBOL v4 and v5 but seemed inclined to see this as the customers problem. I'm 
glad they fixed this. It would have made the migration to v5 almost impossible 
for us. It is hard enough without such issues.

Fred!


ATTENTION:
The information in this e-mail is confidential and only meant for the intended 
recipient. If you are not the intended recipient , don't use or disclose it in 
anyway. Please let the sender know and delete the message immediately.
--



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN