Re: Calculate Tape Bytes to Tracks

[Shmuel Metz (Seymour J.)]

In <4be3273c@bremultibank.com.pl>, on 05/06/2010
   at 10:31 PM, "R.S."  said:

>Proper answer is: Yes.

No. Proper response is to read the hardware documentation, but that
concept is obviously too difficult for you.

>Just 3 letters plus dot. No justification.

Not for you; for those who are more honest and more polite I provide more
detail.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Calculate Tape Bytes to Tracks

[Shmuel Metz (Seymour J.)]

In , on 05/06/2010
   at 12:04 PM, Paul Gilmartin  said:

>Perhaps not everywhere, but in places:

Take another look at what it says.

>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d551/2.2.16

What does the DCB have to do with the hardware limits? The phrase
"(maximum value is 32760 bytes)" refers to the text preceeding it, which
describes a keyword parameter.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Calculate Tape Bytes to Tracks

[R.S.]

W dniu 2010-05-06 19:04, Paul Gilmartin pisze:

On Thu, 6 May 2010 12:11:29 -0400, Shmuel Metz (Seymour J.) wrote:


In<4bdd7bea.5070...@bremultibank.com.pl>, on 05/02/2010
   at 03:19 PM, "R.S." said:


IBM says it's 32760.


No.


Perhaps not everywhere, but in places:

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d551/2.2.16

 BLKSIZE=absexp (maximum value is 32760 bytes)



Paul,
Bad response!
Proper answer is: Yes.
Just 3 letters plus dot. No justification.


Oh, I forgot: USS means Unix Systems Services. 

--
Radoslaw Skorupka
Lodz, Poland

P.S. I couldn't resist, kind of joker mood.


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
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: Calculate Tape Bytes to Tracks

[Paul Gilmartin]

On Thu, 6 May 2010 12:11:29 -0400, Shmuel Metz (Seymour J.) wrote:

>In <4bdd7bea.5070...@bremultibank.com.pl>, on 05/02/2010
>   at 03:19 PM, "R.S." said:
>
>>IBM says it's 32760.
>
>No.
>
Perhaps not everywhere, but in places:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d551/2.2.16

BLKSIZE=absexp (maximum value is 32760 bytes)

-- 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: Calculate Tape Bytes to Tracks

[Shmuel Metz (Seymour J.)]

In
<1991037664-1272805461-cardhu_decombobulator_blackberry.rim.net-4242174...@bda026.bisx.prod.on.blackberry>,
on 05/02/2010
   at 01:04 PM, Ted MacNEIL  said:

>>Remember that the maximum blksize on dasd is 27998 ...

>No. It's not.
>It's 32765.

I might believe 32767 for unkeyed and 33022 for keyed.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Calculate Tape Bytes to Tracks

[Shmuel Metz (Seymour J.)]

In , on 05/02/2010
   at 11:33 AM, Paul Gilmartin  said:

>SDB chooses 32760 for RECFM=U.  I suppose this is wise,

For load libraries, it's the only reasonable choice. There aren't enough
other RECFM=U data sets to worry about, but it's a bd choice for them.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Calculate Tape Bytes to Tracks

[Shmuel Metz (Seymour J.)]

In <4bdd7bea.5070...@bremultibank.com.pl>, on 05/02/2010
   at 03:19 PM, "R.S."  said:

>IBM says it's 32760.

No.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Calculate Tape Bytes to Tracks

[John Ticic]

>> I'm curious how you might be expecting to factor in IDRC 
compression with
>> the data stored on the tape?  I believe that the BLKCNT represents 
what is
>> being stored, not what got sent down the channel.
>>

>On tape drives with IDRC or other compression, MVS is only aware of
>logical blocks sent across the channel, not the physical representation
>on the tape (except very indirectly by indicators of % of media used).
>My understanding is that with compression, the compressed logical 
blocks
>are assembled by the tape controller into "super blocks" that are
>written on the physical tape, but that structure is not communicated
>back to MVS because those are issues that are completely handled at the
>tape controller level.
>

SMF 21 now contains compression information (see APAR OA20077). 

Regards

John

--
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: Calculate Tape Bytes to Tracks

[Ted MacNEIL]

>This is not to say that someone, somewhere, is not using RECFM=U for something 
>not processed by the Binder or IEBCOPY (with COPYMOD), but I have yet to hear 
>of anyone doing that.
>I'm willing to be surprised if 
someone actually is doing that.

We were, in COBOL many years ago, but had to change with the version of LE that 
came out with z/OS 1.4.
-
Too busy driving to stop for gas!

--
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: Calculate Tape Bytes to Tracks

[John Kelly]

I'm curious how you might be expecting to factor in IDRC compression with 
the data stored on the tape?  I believe that the BLKCNT represents what is
being stored, not what got sent down the channel.


I've been reviewing our tape usage with FATS and the TMC BLKCNT is the 
number of uncompressed blocks on the tape, the IDRC number of blocks is 
lower of course.

I know you've had numerous replies about arithmetic and geometry but I'd 
also suggest that you lokk for bad block sizes on tapes, users and 
installations seem less careful with tape block sizes. And as has been 
mentioned watch out or exclude 'system' tapes, eg DSS, HSM, etc.

Jack Kelly
202-502-2390 (Office)

--
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: Calculate Tape Bytes to Tracks

[John Eells]

John Eells wrote:

Paul Gilmartin wrote:

On Mon, 3 May 2010 09:22:22 -0400, John Eells wrote:


If I recall correctly, it's 32760 to accommodate BDWs and RDWs for
variable data. You can find a very long post of mine in the archives
about block sizes on DASD.


I believe the BLKSIZE includes the BDW and RDWs; they aren't additional.


Hmmm...I thought they were, so that what you specified was the "logical"
block length, as is true for RDWs, but I cannot find it documented
quickly. I'll see if I can find someone who knows for sure. They are
certainly part of the physical block that is written; the question is
whether they are added to what you specify or subtracted from what you
specify.



Turns out you're right, and I've been wrong about this for nearly 20 years.

The real reason is that the system rounds buffer space requests up to a 
doubleword boundary.  32760 rounds up to 32768, which is one byte more 
than can be represented by a 16-bit signed value.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[John Eells]

Paul Gilmartin wrote:

On Mon, 3 May 2010 09:22:22 -0400, John Eells wrote:


If I recall correctly, it's 32760 to accommodate BDWs and RDWs for
variable data.  You can find a very long post of mine in the archives
about block sizes on DASD.


I believe the BLKSIZE includes the BDW and RDWs; they aren't additional.


Hmmm...I thought they were, so that what you specified was the "logical" 
block length, as is true for RDWs, but I cannot find it documented 
quickly.  I'll see if I can find someone who knows for sure.  They are 
certainly part of the physical block that is written; the question is 
whether they are added to what you specify or subtracted from what you 
specify.





For RECFM=U, BLKSIZE=32760 is always best.


Only if the application exploits track balancing.  If the application
simply fills each physical record to BLKSIZE, half-track is better.
E.g.:


Everything I know of on z/OS that uses RECFM=U uses TRKBAL to determine 
when to write short blocks (which, by the way, returns the balance of 
remaining track capacity; I'm not sure I would call this "balancing").


This is not to say that someone, somewhere, is not using RECFM=U for 
something not processed by the Binder or IEBCOPY (with COPYMOD), but I 
have yet to hear of anyone doing that.  I'm willing to be surprised if 
someone actually is doing that.





The capacity table is in, e.g.:

Linkname: B.1.2 "Using IBM 3390 in an MVS Environment"
 URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/AM3U1001/B.1.2


Good current reference.  In Topic B.1.1.1 is the track capacity formula 
you asked about in another post, which appears at first glance to be 
identical to the one I posted in response.




--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[John Eells]

Paul Gilmartin wrote:


Where's the track capacity formula?



I don't know where it is in the current books; I have it on an old 
reference card:


Space = C + K + D

C = 10

K, of course, depends on the key length.

  If KL = 0, K=0
  Otherwise:

  K = 9 + (KL + 6KN +6)/34

  Where: KN = (KL + 6)/232

D = 9 + (DL + 6DN + 6)/34

  Where: DN = (DL + 6)/232

Each result is rounded up to the nearest integer.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[Bill Fairchild]

In the IBM-MAIN archives, inter alia.  It's in an IBM book or two somewhere 
also, of course.  I once tried to use the formula for a 3390 to compute the 
effective track size of a given blocksize of X, whatever X was for me at that 
moment.  I gave up on the formula and instead wrote a simple program to use 
XDAP to keep writing more and more blocks on the same track until I got an I/O 
error, at which point I would know how many fit successfully on the track.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Paul Gilmartin
Sent: Sunday, May 02, 2010 11:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calculate Tape Bytes to Tracks


Where's the track capacity formula?

-- 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

--
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: Calculate Tape Bytes to Tracks

[Bill Fairchild]

And you can also write one record per track that is as long as the whole track 
(ca. 56K bytes) if you use EXCP, XDAP (these first two can run unauthorized), 
EXCPVR, or STARTIO (these last two must run authorized).  But then the 
externally visible metadata - BLKSIZE, LRECL, etc. - may not be automatically 
recorded by these access methods.  And SMF data might not be automatically 
recorded either, depending on the specific low-level access method used, 
whether the program is authorized or not, etc.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Thompson, Steve
Sent: Sunday, May 02, 2010 4:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calculate Tape Bytes to Tracks

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Sunday, May 02, 2010 4:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calculate Tape Bytes to Tracks

>someone will correct me if I am incorrect - but i believe that the
maximum 
blocksize on DASD (3390-compatible) to assure 2 blocks per track is
27998

That is correct.
But, that is not the statement I was responding to.
IBM allows you to shoot yourself in the foot, and you can specify a
blocksize greater than 27998.

BTW, you can specify greater than 32760.
I specify 32767 with SMF data all the time on disk.



Since you bring it up indirectly, shouldn't LBI allow for full track
writes?

Regards,
Steve Thompson

--
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: Calculate Tape Bytes to Tracks

[Paul Gilmartin]

On Mon, 3 May 2010 09:22:22 -0400, John Eells wrote:
>
>If I recall correctly, it's 32760 to accommodate BDWs and RDWs for
>variable data.  You can find a very long post of mine in the archives
>about block sizes on DASD.
>
I believe the BLKSIZE includes the BDW and RDWs; they aren't additional.

>For RECFM=U, BLKSIZE=32760 is always best.
>
Only if the application exploits track balancing.  If the application
simply fills each physical record to BLKSIZE, half-track is better.
E.g.:

//STEPEXEC  PGM=IEBGENER
//SYSUT1  DDFILEDATA=BINARY,RECFM=U,BLKSIZE=32760,PATH='...'
//SYSUT2  DDUNIT=SYSALLDA,...

... would be better with BLKSIZE=27998.

The capacity table is in, e.g.:

   Linkname: B.1.2 "Using IBM 3390 in an MVS Environment"
URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/AM3U1001/B.1.2

-- 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: Calculate Tape Bytes to Tracks

[Joel C. Ewing]

On 05/02/2010 08:26 PM, Scott Barry wrote:
> On Sun, 2 May 2010 08:46:49 -0400, Lizette Koehler 
> wrote:
> 
>> I have a project to review all the virtual tapes in the VTS and see which
>> tape datasets could go on dasd.
>>
>> I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
>> bytes are on the tape.  Then dividing that by the number of bytes per track
>> to get a rough estimate.
>>
>> Is there a better way of doing this?  I have over 100,000 tapes to review
>> and I am trying to make sure I have a good process.
>>
>> Or is there a different formula I should be using other than
>> bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
>> set blkcnt = 1)
>>
>> Lizette
> 
> 
> I'm curious how you might be expecting to factor in IDRC compression with
> the data stored on the tape?  I believe that the BLKCNT represents what is
> being stored, not what got sent down the channel.
> 
> Also, there has been reported conditions where a BLKSIZE is not reported to
> the tape mgmt system on CLOSE, so the BLKSIZE shows up as zero -- some years
> ago, ADRDSSU and CA-VIEW each exhibited this behavior - since then it's been
> fixed.  For my tape inventory analysis exercises, I used a default of 32760,
> when not reported.
> 
> Scott Barry
> SBBWorks, Inc.
> 
On tape drives with IDRC or other compression, MVS is only aware of
logical blocks sent across the channel, not the physical representation
on the tape (except very indirectly by indicators of % of media used).
My understanding is that with compression, the compressed logical blocks
are assembled by the tape controller into "super blocks" that are
written on the physical tape, but that structure is not communicated
back to MVS because those are issues that are completely handled at the
tape controller level.

For many years (while reporting a blocksize of 0 to the Tape Management
System), ADRDSSU was somehow writing a logical block size of 64 KiB on
3480/3490.  Unless your old ADRDSSU tapes are over a decade old, 32 KiB
is probably too low a value for those.  I remember vaguely when the DSS
change to 64 KiB occurred, because our older stand-alone-IPL DSS tape
wouldn't work on the newer backups and you had to be sure to have a
newer version to be covered for DR.

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

--
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: Calculate Tape Bytes to Tracks

[John Eells]

R.S. wrote:

W dniu 2010-05-02 15:04, Ted MacNEIL pisze:

Remember that the maximum blksize on dasd is 27998 ...


No. It's not.
It's 32765.


IBM says it's 32760.

BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset
parameters.



Right.

If I recall correctly, it's 32760 to accommodate BDWs and RDWs for 
variable data.  You can find a very long post of mine in the archives 
about block sizes on DASD.


From a space utilization point of view, discounting RECFM=U, the other 
data set parameters have mostly to do with variably-blocked data, the 
amount by which the blocks vary, the distribution of the different block 
sizes, and the order in which they are written.  There are some 
interesting cases (like z/OS fonts) where there is a specific optimum.


For RECFM=U, BLKSIZE=32760 is always best.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[John Eells]

Lizette Koehler wrote:

I have a project to review all the virtual tapes in the VTS and see which
tape datasets could go on dasd.

I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
bytes are on the tape.  Then dividing that by the number of bytes per track
to get a rough estimate.

Is there a better way of doing this?  I have over 100,000 tapes to review
and I am trying to make sure I have a good process.

Or is there a different formula I should be using other than
  bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
set blkcnt = 1)



As others have observed, the LRECL doesn't matter.

If you will use the same block size for each data sets as was used to 
write it to tape, there is a formula to use to determine how many tracks 
will be used on disk.  But, it is much easier to use one of the 
reference cards' sets of tables that show blocks per track at different 
block sizes for keyed and unkeyed records to predict disk space for 
fixed block data.  If you can't lay hands on a 3390 reference card, or 
find one of the 3390 or later storage books with the same tables, DTS 
has tables in their "Storage Administration z/OS Pocket Reference," and 
perhaps you can find a copy of that.


For variable blocked data, including RECFM=U, I am afraid that by far 
the easiest way to see how much DASD space will be used is to simply 
load the data sets and look afterward.  The distribution of block sizes 
around the mean, and the order in which differently sized blocks occur 
in the data, will affect space utilization considerably.  This could be 
done programattically by reading the tape and calculating the space used 
as the blocks are read but this is a complex undertaking and probably 
not worth the effort.


If you use the largest possible block sizes for variably blocked data, 
you will likely overpredict the amount of DASD space many of them 
require--which might be better than underpredicting it, I suppose.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[Martin Kline]

>>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
parameters.

>Sometimes?
>When is it not?

Besides having to be a multiple of LRECL for FB files, another situation where 
half-track blocking is bad is for a PDS with many members sized at just over a 
half track. In this case, wouldn't each member waste slightly less than half a 
track with one half-track block and one short block? The same would apply for 
a file where DISP=MOD adds a little over 27998 bytes each time new data is 
appended. 

--
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: Calculate Tape Bytes to Tracks

[R.S.]

W dniu 2010-05-03 00:35, Rick Fochtman pisze:

---


W dniu 2010-05-02 15:04, Ted MacNEIL pisze:


Remember that the maximum blksize on dasd is 27998 ...



No. It's not.
It's 32765.



IBM says it's 32760.

BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset
parameters.


-
I've seen blocks longer than 32,767 written on 3390 SLEDs using IDAW.
What IBM quotes is the biggest BLKSIZE in JCL, not necessarily the
actual hardware max.


Both sentences can be true. Hardware limit is not the same as BLKSIZE 
limit in the operating system. I was told that VSE can use blocks of 56k 
(whole track). Linux on the same hardware has significantly different 
way of storing data on disk.


BTW: It is possible to create dataset with BLKSIZE=32767, but you cannot 
use BLKSIZE=327676 construct - it would end with JCL error.
BTW2: I said what IBM says. It was intentionally to put the word in 
IBM's mouth, because of the issues above.
BTW3: "maximum blksize on dasd is 32765" is neither what IBM says, nor 
achievable 32767, nor HW limit. 



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
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: Calculate Tape Bytes to Tracks

[Scott Barry]

On Sun, 2 May 2010 08:46:49 -0400, Lizette Koehler 
wrote:

>I have a project to review all the virtual tapes in the VTS and see which
>tape datasets could go on dasd.
>
>I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
>bytes are on the tape.  Then dividing that by the number of bytes per track
>to get a rough estimate.
>
>Is there a better way of doing this?  I have over 100,000 tapes to review
>and I am trying to make sure I have a good process.
>
>Or is there a different formula I should be using other than
> bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
>set blkcnt = 1)
>
>Lizette


I'm curious how you might be expecting to factor in IDRC compression with
the data stored on the tape?  I believe that the BLKCNT represents what is
being stored, not what got sent down the channel.

Also, there has been reported conditions where a BLKSIZE is not reported to
the tape mgmt system on CLOSE, so the BLKSIZE shows up as zero -- some years
ago, ADRDSSU and CA-VIEW each exhibited this behavior - since then it's been
fixed.  For my tape inventory analysis exercises, I used a default of 32760,
when not reported.


Scott Barry
SBBWorks, Inc.

--
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: Calculate Tape Bytes to Tracks

[Rick Fochtman]

---


W dniu 2010-05-02 15:04, Ted MacNEIL pisze:


Remember that the maximum blksize on dasd is 27998 ...



No. It's not.
It's 32765.



IBM says it's 32760.

BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
parameters.


-
I've seen blocks longer than 32,767 written on 3390 SLEDs using IDAW. 
What IBM quotes is the biggest BLKSIZE in JCL, not necessarily the 
actual hardware max.


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: Calculate Tape Bytes to Tracks

[Paul Gilmartin]

On Mon, 3 May 2010 00:05:58 +0800, Brian Fraser wrote:
>
>For some fixed length records, 27998 (or half-track) would not be the
>most efficient use of the track..
>
>Suppose a record length of 800... at half track you'd only get 68
>records on a track, 2 blocks of 27200.
>
>But if you instead used 3 blocks per track then you'd get 69 records
>per track, 3 blocks of 18400.
>
I just tried, for a 3390, RECFM=FB,LRECL=7000.  I would have been
astonished at what SDB chose, had you not alerted me.

-- 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: Calculate Tape Bytes to Tracks

[Ted MacNEIL]

>>BTW, you can specify greater than 32760.
I specify 32767 with SMF data all the time on disk.

>

>Since you bring it up indirectly, shouldn't LBI allow for full track writes?


I would assume so, but I was massaging SMF data long before LBI came along.

-
Too busy driving to stop for gas!

--
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: Calculate Tape Bytes to Tracks

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Sunday, May 02, 2010 4:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calculate Tape Bytes to Tracks

>someone will correct me if I am incorrect - but i believe that the
maximum 
blocksize on DASD (3390-compatible) to assure 2 blocks per track is
27998

That is correct.
But, that is not the statement I was responding to.
IBM allows you to shoot yourself in the foot, and you can specify a
blocksize greater than 27998.

BTW, you can specify greater than 32760.
I specify 32767 with SMF data all the time on disk.



Since you bring it up indirectly, shouldn't LBI allow for full track
writes?

Regards,
Steve Thompson

--
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: Calculate Tape Bytes to Tracks

[Ted MacNEIL]

>someone will correct me if I am incorrect - but i believe that the maximum 
blocksize on DASD (3390-compatible) to assure 2 blocks per track is 27998

That is correct.
But, that is not the statement I was responding to.
IBM allows you to shoot yourself in the foot, and you can specify a blocksize 
greater than 27998.

BTW, you can specify greater than 32760.
I specify 32767 with SMF data all the time on disk.

-
Too busy driving to stop for gas!

--
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: Calculate Tape Bytes to Tracks

[R.S.]

W dniu 2010-05-02 17:16, Ted MacNEIL pisze:

IBM says it's 32760.


Typo on my part.



BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
parameters.


Sometimes?
When is it not?
Yes, sometimes. *Usually* SDB (System Determined Blocksize) is approx 
half track, but:
a) It's not always 27998, for FB records it is multiplication of record 
size, which is obviously not always 27998.
b) For some record lenghts optimal blocksize is 1/3 of the track (3 
blocks per track).



The resource implications of 'large' block sizes have disappeared, except for 
space usage.
Space usage *and* performance. Test: simply compare F 80 and FB80 
datasets. Same amount of data records, different times.


BTW: All the above is really basic information which teached on basic 
classes, like JCL & Utilities. (At least when I teach).

That's why I suspect there is some misunderstanding here.


There are some old utilities that still require 'strange' block sizes, but I 
cannot see one bad usage of 27998, especially in Batch/TSO, as long as there is 
no hard-coded one in the programme using the dataset.


Regards
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
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: Calculate Tape Bytes to Tracks

[Chris Hoelscher]

>>Remember that the maximum blksize on dasd is 27998 ...

>No. It's not.
>It's 32765.

someone will correct me if I am incorrect - but i believe that the maximum 
blocksize on DASD (3390-compatible) to assure 2 blocks per track is 27998

Chris Hoelscher
IDMS/DB2 Database Architect
Humana Inc
502-476-2538
choelsc...@humana.com

you only need to test the programs that you want to work correctly 




The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

--
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: Calculate Tape Bytes to Tracks

[Paul Gilmartin]

On Mon, 3 May 2010 00:05:58 +0800, Brian Fraser wrote:
>
>For some fixed length records, 27998 (or half-track) would not be the
>most efficient use of the track..
>
Hmmm...  I see:

4.1.26.1.3 "z/OS V1R10.0 DFSMShsm Storage Administration Guide"

  + BLKSIZE=28332 is the capacity of half a track on a 3390 device.

Is someone assuming unformatted capacity?  SDB gives me the more familiar:

   Device type . . . . : 3390
  Data class . . . . . : **None**   Current Utilization
   Organization  . . . : PS  Used tracks . . . . : 0
   Record format . . . : FB  Used extents  . . . : 0
   Record length . . . : 1
   Block size  . . . . : 27998

-- 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: Calculate Tape Bytes to Tracks

[Paul Gilmartin]

On Mon, 3 May 2010 00:05:58 +0800, Brian Fraser wrote:
>>
>>>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
>>>parameters.
>>
>> Sometimes?
>> When is it not?

SDB chooses 32760 for RECFM=U.  I suppose this is wise, although it
seems to presume that the application will exploit the track balance
facility.

>> The resource implications of 'large' block sizes have disappeared, except 
>> for space usage.
>> There are some old utilities that still require 'strange' block sizes, but I 
>> cannot see one bad usage of 27998, especially in Batch/TSO, as long as there 
>> is no hard-coded one in the programme using the dataset.
>
>For some fixed length records, 27998 (or half-track) would not be the
>most efficient use of the track..
>
>Suppose a record length of 800... at half track you'd only get 68
>records on a track, 2 blocks of 27200.
>
>But if you instead used 3 blocks per track then you'd get 69 records
>per track, 3 blocks of 18400.
>
(Always assuming the application doesn't employ track balancing;
I believe QSAM doesn't.)

What does SDB select in this case?

It might be even worse for LRECL~Track size/5.  For BLKSIZE=LRECL,
you get 5 records/track; for BLKSIZE=LRECLx2, only 4.
Iteresting exercises (which I won't attempt):  What fixed LRECL
gives the smallest optimum BLKSIZE?  What fixed LRECL gives the
poorest ratio of half track blocking to optimum blocking?  What
does SDB select in these cases?

Where's the track capacity formula?

-- 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: Calculate Tape Bytes to Tracks

[Brian Fraser]

>
>>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
>>parameters.
>
> Sometimes?
> When is it not?
> The resource implications of 'large' block sizes have disappeared, except for 
> space usage.
> There are some old utilities that still require 'strange' block sizes, but I 
> cannot see one bad usage of 27998, especially in Batch/TSO, as long as there 
> is no hard-coded one in the programme using the dataset.

For some fixed length records, 27998 (or half-track) would not be the
most efficient use of the track..

Suppose a record length of 800... at half track you'd only get 68
records on a track, 2 blocks of 27200.

But if you instead used 3 blocks per track then you'd get 69 records
per track, 3 blocks of 18400.

--
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: Calculate Tape Bytes to Tracks

[Ted MacNEIL]

>IBM says it's 32760.

Typo on my part.


>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
>parameters.

Sometimes?
When is it not?
The resource implications of 'large' block sizes have disappeared, except for 
space usage.
There are some old utilities that still require 'strange' block sizes, but I 
cannot see one bad usage of 27998, especially in Batch/TSO, as long as there is 
no hard-coded one in the programme using the dataset.

-
Too busy driving to stop for gas!

--
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: Calculate Tape Bytes to Tracks

[R.S.]

W dniu 2010-05-02 15:04, Ted MacNEIL pisze:

Remember that the maximum blksize on dasd is 27998 ...


No. It's not.
It's 32765.


IBM says it's 32760.

BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
parameters.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
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: Calculate Tape Bytes to Tracks

[Lizette Koehler]

I am actually using the IBM TAPETOOLS.  This was just a quick and dirty
process.  I like to understand the math before I do the tool.  That way I
can eye-ball the output and know I have a good result.

Lizette


> Behalf Of O'Brien, David W. Wrote> 
> Lizette,
> 
> Have you considered IBM's Volume Mount Analyzer?
> It's free and you already have it (or as someone is bound to point out,
> you already have so you're already paying for it.) Point is, it will do
> what you want at no extra cost.
> 
> Thank You,
> Dave O'Brien
> NIH Contractor
> 
> From: Lizette Koehler [stars...@mindspring.com]
> Sent: Sunday, May 02, 2010 8:46 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Calculate Tape Bytes to Tracks
> 
> I have a project to review all the virtual tapes in the VTS and see
> which
> tape datasets could go on dasd.
> 
> I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how
> many
> bytes are on the tape.  Then dividing that by the number of bytes per
> track
> to get a rough estimate.
> 
> Is there a better way of doing this?  I have over 100,000 tapes to
> review
> and I am trying to make sure I have a good process.
> 
> Or is there a different formula I should be using other than
>  bytes = lrecl * blksize * blkcnt(and if blkcnt = 0
> I
> set blkcnt = 1)
> 
> Lizette
> 

--
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: Calculate Tape Bytes to Tracks

[Ted MacNEIL]

>Remember that the maximum blksize on dasd is 27998 ...

No. It's not.
It's 32765.
-
Too busy driving to stop for gas!

--
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: Calculate Tape Bytes to Tracks

[O'Brien, David W. (NIH/CIT) [C]]

Lizette,

Have you considered IBM's Volume Mount Analyzer?
It's free and you already have it (or as someone is bound to point out, you 
already have so you're already paying for it.) Point is, it will do what you 
want at no extra cost. 

Thank You,
Dave O'Brien
NIH Contractor

From: Lizette Koehler [stars...@mindspring.com]
Sent: Sunday, May 02, 2010 8:46 AM
To: IBM-MAIN@bama.ua.edu
Subject: Calculate Tape Bytes to Tracks

I have a project to review all the virtual tapes in the VTS and see which
tape datasets could go on dasd.

I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
bytes are on the tape.  Then dividing that by the number of bytes per track
to get a rough estimate.

Is there a better way of doing this?  I have over 100,000 tapes to review
and I am trying to make sure I have a good process.

Or is there a different formula I should be using other than
 bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
set blkcnt = 1)

Lizette

--
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: Calculate Tape Bytes to Tracks

[Binyamin Dissen]

On Sun, 2 May 2010 08:46:49 -0400 Lizette Koehler 
wrote:

:>I have a project to review all the virtual tapes in the VTS and see which
:>tape datasets could go on dasd.

:>I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
:>bytes are on the tape.  Then dividing that by the number of bytes per track
:>to get a rough estimate.

:>Is there a better way of doing this?  I have over 100,000 tapes to review
:>and I am trying to make sure I have a good process.

:>Or is there a different formula I should be using other than
:> bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
:>set blkcnt = 1)

Right off the top, do not multiply lrecl by blksize. LRECL does not really
enter into the picture.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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: Calculate Tape Bytes to Tracks

[גדי בן אבי]

Hi,

It should be blksize * blkcount.

Remember that the maximum blksize on dasd is 27998, but on tape can be 64K and 
even larger. This can mean the files will have to be reblocked when copying to 
dasd.

gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Sunday, May 02, 2010 3:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Calculate Tape Bytes to Tracks

I have a project to review all the virtual tapes in the VTS and see which
tape datasets could go on dasd.

I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
bytes are on the tape.  Then dividing that by the number of bytes per track
to get a rough estimate.

Is there a better way of doing this?  I have over 100,000 tapes to review
and I am trying to make sure I have a good process.

Or is there a different formula I should be using other than
 bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
set blkcnt = 1)

Lizette

--
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

Calculate Tape Bytes to Tracks

[Lizette Koehler]

I have a project to review all the virtual tapes in the VTS and see which
tape datasets could go on dasd.

I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
bytes are on the tape.  Then dividing that by the number of bytes per track
to get a rough estimate.

Is there a better way of doing this?  I have over 100,000 tapes to review
and I am trying to make sure I have a good process.

Or is there a different formula I should be using other than
 bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
set blkcnt = 1)

Lizette

--
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