Re: Copying tapes with 256K blocksizes
Fred Schmidt wrote: On Thu, 12 May 2011 14:21:15 -0500, Rick Fochtman rfocht...@ync.net wrote: ---snip--- Does the name TAPE appear in your device name table? You also need a DD statement that refers to each tape volume; IEHMOVE will modify it and use OPEN TYPE=J to access the ap[[ropriate files. Rick Yes, TAPE is in the device table, Rick. JCL used was as follows. VOLSER 200198 was a scratch tape. //COPY EXEC PGM=IEHMOVE //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=(NEW,KEEP),VOL=SER=SYS006, // UNIT=3390,DSN=SYS1.DONOT.EXIST,SPACE=(CYL,(10,10)) //INDD1DD UNIT=TAPE,DISP=OLD,VOL=SER=101178 //OUTDD1 DD UNIT=TAPE,DATACLAS=ATL3592,DISP=(,KEEP) //SYSINDD * COPY VOLUME=TAPE=101178,TO=TAPE=200198 /* -- 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 Try this: COPY DSNAME=a.b.c,FROM=TQAPE=(101178,file#),TO=TAPE=(200198,file#), x FROMDD=INDD1,TODD=OUTDD1 -- 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: Copying tapes with 256K blocksizes
On Tue, 17 May 2011 19:26:20 -0500, Rick Fochtman rfocht...@ync.net wrote: ---snip Try this: COPY DSNAME=a.b.c,FROM=TQAPE=(101178,file#),TO=TAPE=(200198,file#), x FROMDD=INDD1,TODD=OUTDD1 Yes, but if I have to specify individual file numbers, I may as well stick with my current approach of using REXX to build JCL steps to copy each file. I'm trying to avoid typing in 11,000 odd steps by hand! Fred. -- 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: Copying tapes with 256K blocksizes
On May 17, 11:13pm, Eric Jackson wrote... IEHMOVE has been functionally stable for a generation. A human generation. As described in Utilities, it doesn't copy from tape to tape, and it doesn't handle blocks greater than 32,760. That just about kills the IEHMOVE maggot option, then. I did see something along those lines in the fine manual, but it wasn't real clear. Fred -- 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: Copying tapes with 256K blocksizes
Just FYI for those following this thread, I have been talking off-list with Sams Golob and Bass, who are kindly looking at adapting their various tape copying utilities to handle 256K blocksizes. Fred. -- 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: Copying tapes with 256K blocksizes
Rick: You have proven that IEHMOVE should be nuked and or zapped out of existance. There is also a cavet if you go into multi volume to make sure you put the sequence numer in parenthess eg vol=tape=(123456,1,23456,1, etc etc Heaven help you if you have multiple iehmove datasets on a volume. Then I think you need the original listing to get it back. God I hated IEHMOVE. Ed From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Sent: Tue, May 17, 2011 7:26:20 PM Subject: Re: Copying tapes with 256K blocksizes Fred Schmidt wrote: On Thu, 12 May 2011 14:21:15 -0500, Rick Fochtman rfocht...@ync.net wrote: ---snip--- Does the name TAPE appear in your device name table? You also need a DD statement that refers to each tape volume; IEHMOVE will modify it and use OPEN TYPE=J to access the ap[[ropriate files. Rick Yes, TAPE is in the device table, Rick. JCL used was as follows. VOLSER 200198 was a scratch tape. //COPY EXEC PGM=IEHMOVE //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=(NEW,KEEP),VOL=SER=SYS006, // UNIT=3390,DSN=SYS1.DONOT.EXIST,SPACE=(CYL,(10,10)) //INDD1DD UNIT=TAPE,DISP=OLD,VOL=SER=101178//OUTDD1 DD UNIT=TAPE,DATACLAS=ATL3592,DISP=(,KEEP) //SYSINDD * COPY VOLUME=TAPE=101178,TO=TAPE=200198 /* -- 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 Try this: COPY DSNAME=a.b.c,FROM=TQAPE=(101178,file#),TO=TAPE=(200198,file#), x FROMDD=INDD1,TODD=OUTDD1 -- 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: Copying tapes with 256K blocksizes
On Thu, 12 May 2011 19:34:57 +, Linda Mooney linda.lst...@comcast.net wrote: Hi Fred, Do you have OSDITTO? Hi Linda. No. We don't have DITTO either. Cheers, Fred -- 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: Copying tapes with 256K blocksizes
On Thu, 12 May 2011 14:21:15 -0500, Rick Fochtman rfocht...@ync.net wrote: ---snip--- Does the name TAPE appear in your device name table? You also need a DD statement that refers to each tape volume; IEHMOVE will modify it and use OPEN TYPE=J to access the ap[[ropriate files. Rick Yes, TAPE is in the device table, Rick. JCL used was as follows. VOLSER 200198 was a scratch tape. //COPY EXEC PGM=IEHMOVE //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=(NEW,KEEP),VOL=SER=SYS006, // UNIT=3390,DSN=SYS1.DONOT.EXIST,SPACE=(CYL,(10,10)) //INDD1DD UNIT=TAPE,DISP=OLD,VOL=SER=101178 //OUTDD1 DD UNIT=TAPE,DATACLAS=ATL3592,DISP=(,KEEP) //SYSINDD * COPY VOLUME=TAPE=101178,TO=TAPE=200198 /* -- 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: Copying tapes with 256K blocksizes
From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Sent: Thu, May 12, 2011 2:21:15 PM Subject: Re: Copying tapes with 256K blocksizes -SNIP --unsnip-- Does the name TAPE appear in your device name table? You also need a DD statement that refers to each tape volume; IEHMOVE will modify it and use OPEN TYPE=J to access the ap[[ropriate files. Rick SNIP-- Rick: When I first saw your suggestion I almost lost my lunch:(: I guess you are serious.. I would never in 1000 years suggest IEHMOVE to anyone (even an enemy). My use of it dropped to zero back in the 1980's. It has to be the worst utility that IBM ever came up with. AFAIK it still suffers from the col 16 conyinuation and the column 72 issue and the most obscure control cards that IBM has ever come up with, IMO. Sorry to open my mouth but suggesting IEHMOVE is like suggesting a lollipop with cyanide coating to a kid. Ed -- 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: Copying tapes with 256K blocksizes
-snip--- Rick: When I first saw your suggestion I almost lost my lunch:(: I guess you are serious.. I would never in 1000 years suggest IEHMOVE to anyone (even an enemy). My use of it dropped to zero back in the 1980's. It has to be the worst utility that IBM ever came up with. AFAIK it still suffers from the col 16 conyinuation and the column 72 issue and the most obscure control cards that IBM has ever come up with, IMO. Sorry to open my mouth but suggesting IEHMOVE is like suggesting a lollipop with cyanide coating to a kid. Ed -unsnip IIRC, IEHMOVE was a programming exercise for a IBM Assembler Language Programming class. While it is, in many ways, unmitigated junk, it does have the ability to copy more than one dataset in a single job step, without a boatload of DD staements. From what I remember, it uses OPEN TYPE-J to modify the DD statements supplied, with the possible exception of volume parameters, in a way similar to DYNALLOC processing today. The OP could probably also use REXX of CLIST exclusively to accomplish his end result, I just thought I'd gag a few maggots by suggesting IEHMOVE. :-) Rick -- 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: Copying tapes with 256K blocksizes
From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Sent: Fri, May 13, 2011 3:32:34 PM Subject: Re: Copying tapes with 256K blocksizes -unsnip IIRC, IEHMOVE was a programming exercise for a IBM Assembler Language Programming class. While it is, in many ways, unmitigated junk, it does have the ability to copy more than one dataset in a single job step, without a boatload of DD staements. From what I remember, it uses OPEN TYPE-J to modify the DD statements supplied, with the possible exception of volume parameters, in a way similar to DYNALLOC processing today. The OP could probably also use REXX of CLIST exclusively to accomplish his end result, I just thought I'd gag a few maggots by suggesting IEHMOVE. :-) Rick --SNIP One of the key elements that one doesn't want to use it is that it is slow. Example (not current) we used to have a full pack PDS for source and at the time we had to us IEHMOVE to copy it to tape scratch it and reallocate it and restore it. AND YES I knew that IEBCOPY was faster but the storage it needed was more than we had. But even with a large storage it suffered unless you coded dcb=blksize= on the DD satement. Ed -- 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: Copying tapes with 256K blocksizes
I have a program that will copy 256K blocksize tapes. http://www.kmbass.com Look at COPYTPX and the subroutine needed RTAPE2. Sam -- 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: Copying tapes with 256K blocksizes
---snip--- On Tue, 10 May 2011 14:36:57 -0500, Rick Fochtman rfocht...@ync.net wrote: I can't think of any reason that REXX can't be used to allocate the appropriate tape files, invoke the utilities as needed and be done with the whole job. Does anyone know if IEHMOVE has been updated for large blksizes? It MIGHT be just what the doctor ordered. Rick It seems not, Rick, unless I'm using it incorrectly... SYSTEM SUPPORT UTILITIES IEHMOVE COPY VOLUME=TAPE=101178,TO=TAPE=200198 IEH403I UNABLE TO MOVE/COPY VOLUME FROM NON DIRECT ACCESSDEVICE Regards, Fred --unsnip-- Does the name TAPE appear in your device name table? You also need a DD statement that refers to each tape volume; IEHMOVE will modify it and use OPEN TYPE=J to access the ap[[ropriate files. Rick -- 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: Copying tapes with 256K blocksizes
Hi Fred, Do you have OSDITTO? Linda - Original Message - From: Fred Schmidt fred.schm...@nt.gov.au To: IBM-MAIN@bama.ua.edu Sent: Sunday, May 8, 2011 11:17:34 PM Subject: Re: Copying tapes with 256K blocksizes On Sun, 8 May 2011 23:46:11 -0500, Russell Witt res09...@verizon.net wrote: Fred, First, to make sure I understand what you are looking for; is the tape file you want to copy already at 256K or do you want to re-block an existing tape-file up to 256K? The reason is that some tape copy utilities (CA Copycat for example) can support files with an existing 256K blocksize; but cannot re-block a file. Also, which tape management system do you currently use? If you have CA 1 or CA TLMS; then there is CA Copycat. If you have IBM's DFSMSrmm, there is Tivolie Tape Optimizer. And there are other options (Innovations FATSCOPY and OpenTech's TAPECOPY that can work on almost all tape management systems). Of course, all of these are licensed products. If you want to do this yourself, without getting a new licensed product; then IEBGENER works fine and supports 256K blocksizes. And of course, both ICEGENER (for DFSort users) and SYNCGENR (for SYNCSORT users) are also available and can copy much faster than IEBGENER. But, none of these options will automatically re-catalog the file to the new volume or (optionally) update the Tape Management system to maintain the original creation date/time/jobname. But, I am not sure that is important to you or not. Russell Witt CA 1 L2 Support Manager Russell and others, I guess I wasnt too clear in what I was after. Firstly, the tool to copy the tape must be FREE. I know there are good vendor tools to do what I want, but this site isnt going to spend any money on getting them. Secondly, I would like to copy the entire tape as-is. Basically tell the utility to duplicate this tape. Many of the files on the source tape are 256K. I don't want to reblock them. I would prefer to maintain expiry date info and have RMM's VRS control expiration. I don't care that the datasets will not get cataloged. I know I can IEBGENER etc individual files to a new tape. But on the 1 TB raw capacity tapes we are using, we have 5,000 files and more on a tape, and I would prefer not to have to code JCL to copy each of those files! In the absence of anything better, I will write REXX to create such JCL, using RMM info about the tape datasets as the source. I know that COPYMODS and related from the CBT Tape will do pretty much what I want, but 64K blocksizes is as big as it handles, from what I read in their doco. We are RMM, but I don't know that this makes much difference. Hoping for a miracle Regards, Fred Schmidt -- 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: Copying tapes with 256K blocksizes
On Tue, 10 May 2011 14:36:57 -0500, Rick Fochtman rfocht...@ync.net wrote: I can't think of any reason that REXX can't be used to allocate the appropriate tape files, invoke the utilities as needed and be done with the whole job. Does anyone know if IEHMOVE has been updated for large blksizes? It MIGHT be just what the doctor ordered. Rick It seems not, Rick, unless I'm using it incorrectly... SYSTEM SUPPORT UTILITIES IEHMOVE COPY VOLUME=TAPE=101178,TO=TAPE=200198 IEH403I UNABLE TO MOVE/COPY VOLUME FROM NON DIRECT ACCESSDEVICE Regards, Fred -- 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: Copying tapes with 256K blocksizes
-snip- I know I can IEBGENER etc individual files to a new tape. But on the 1 TB raw capacity tapes we are using, we have 5,000 files and more on a tape, and I would prefer not to have to code JCL to copy each of those files! In the absence of anything better, I will write REXX to create such JCL, using RMM info about the tape datasets as the source. unsnip- I can't think of any reason that REXX can't be used to allocate the appropriate tape files, invoke the utilities as needed and be done with the whole job. Does anyone know if IEHMOVE has been updated for large blksizes? It MIGHT be just what the doctor ordered. Rick -- 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: Copying tapes with 256K blocksizes
On Sun, 8 May 2011 23:46:11 -0500, Russell Witt res09...@verizon.net wrote: Fred, First, to make sure I understand what you are looking for; is the tape file you want to copy already at 256K or do you want to re-block an existing tape-file up to 256K? The reason is that some tape copy utilities (CA Copycat for example) can support files with an existing 256K blocksize; but cannot re-block a file. Also, which tape management system do you currently use? If you have CA 1 or CA TLMS; then there is CA Copycat. If you have IBM's DFSMSrmm, there is Tivolie Tape Optimizer. And there are other options (Innovations FATSCOPY and OpenTech's TAPECOPY that can work on almost all tape management systems). Of course, all of these are licensed products. If you want to do this yourself, without getting a new licensed product; then IEBGENER works fine and supports 256K blocksizes. And of course, both ICEGENER (for DFSort users) and SYNCGENR (for SYNCSORT users) are also available and can copy much faster than IEBGENER. But, none of these options will automatically re-catalog the file to the new volume or (optionally) update the Tape Management system to maintain the original creation date/time/jobname. But, I am not sure that is important to you or not. Russell Witt CA 1 L2 Support Manager Russell and others, I guess I wasnt too clear in what I was after. Firstly, the tool to copy the tape must be FREE. I know there are good vendor tools to do what I want, but this site isnt going to spend any money on getting them. Secondly, I would like to copy the entire tape as-is. Basically tell the utility to duplicate this tape. Many of the files on the source tape are 256K. I don't want to reblock them. I would prefer to maintain expiry date info and have RMM's VRS control expiration. I don't care that the datasets will not get cataloged. I know I can IEBGENER etc individual files to a new tape. But on the 1 TB raw capacity tapes we are using, we have 5,000 files and more on a tape, and I would prefer not to have to code JCL to copy each of those files! In the absence of anything better, I will write REXX to create such JCL, using RMM info about the tape datasets as the source. I know that COPYMODS and related from the CBT Tape will do pretty much what I want, but 64K blocksizes is as big as it handles, from what I read in their doco. We are RMM, but I don't know that this makes much difference. Hoping for a miracle Regards, Fred Schmidt -- 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
Copying tapes with 256K blocksizes
Anyone know of a CBT Tape or other free utility that will copy tapes with 256K blocksizes? I was hoping COPYMODS or similar would do so, but it looks like they only support 64K max. Regards, Fred Schmidt NT Government, Australia -- 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: Copying tapes with 256K blocksizes
what type of device output going to? SMS routines also interface with blocksize...paste the error msg.. -- 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: Copying tapes with 256K blocksizes
On Sun, 8 May 2011 21:36:45 -0500, Ravi Gaur gaur.ravi2...@gmail.com wrote: what type of device output going to? SMS routines also interface with blocksize...paste the error msg.. -- 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 No error message, Ravi. The tape copy utilities I've found so far on the CBT Tape say they support up to 64K blocksizes. So, it would appear they aren't going to work with 256K blocksizes. Regards, Fred -- 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: Copying tapes with 256K blocksizes
Fred, Do you have dfsort? Rob Schramm On May 8, 2011 10:58 PM, Fred Schmidt fred.schm...@nt.gov.au wrote: On Sun, 8 May 2011 21:36:45 -0500, Ravi Gaur gaur.ravi2...@gmail.com wrote: what type of device output going to? SMS routines also interface with blocksize...paste the error msg.. -- 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 No error message, Ravi. The tape copy utilities I've found so far on the CBT Tape say they support up to 64K blocksizes. So, it would appear they aren't going to work with 256K blocksizes. Regards, Fred -- 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: Copying tapes with 256K blocksizes
Fred,AFIK copycat should be able to it however did you try basic ibm utilities without going to cbt tape org...? iebgener,adrdssu..Trying to understand completely what comes up if you copy over one tape to another with more than 256 blk.. -- 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: Copying tapes with 256K blocksizes
Fred, First, to make sure I understand what you are looking for; is the tape file you want to copy already at 256K or do you want to re-block an existing tape-file up to 256K? The reason is that some tape copy utilities (CA Copycat for example) can support files with an existing 256K blocksize; but cannot re-block a file. Also, which tape management system do you currently use? If you have CA 1 or CA TLMS; then there is CA Copycat. If you have IBM's DFSMSrmm, there is Tivolie Tape Optimizer. And there are other options (Innovations FATSCOPY and OpenTech's TAPECOPY that can work on almost all tape management systems). Of course, all of these are licensed products. If you want to do this yourself, without getting a new licensed product; then IEBGENER works fine and supports 256K blocksizes. And of course, both ICEGENER (for DFSort users) and SYNCGENR (for SYNCSORT users) are also available and can copy much faster than IEBGENER. But, none of these options will automatically re-catalog the file to the new volume or (optionally) update the Tape Management system to maintain the original creation date/time/jobname. But, I am not sure that is important to you or not. Russell Witt CA 1 L2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Fred Schmidt Sent: Sunday, May 08, 2011 9:13 PM To: IBM-MAIN@bama.ua.edu Subject: Copying tapes with 256K blocksizes Anyone know of a CBT Tape or other free utility that will copy tapes with 256K blocksizes? I was hoping COPYMODS or similar would do so, but it looks like they only support 64K max. Regards, Fred Schmidt NT Government, Australia -- 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
