Re: Calculate Tape Bytes to Tracks

2010-05-07 Thread 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 m

Re: Calculate Tape Bytes to Tracks

2010-05-07 Thread 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 32

Re: Calculate Tape Bytes to Tracks

2010-05-06 Thread 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.bould

Re: Calculate Tape Bytes to Tracks

2010-05-06 Thread 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/dgt2d5

Re: Calculate Tape Bytes to Tracks

2010-05-06 Thread 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 key

Re: Calculate Tape Bytes to Tracks

2010-05-06 Thread 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, Sy

Re: Calculate Tape Bytes to Tracks

2010-05-06 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-04 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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 chan

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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 b

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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 B

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread Bill Fairchild
obile: +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 T

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread Bill Fairchild
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

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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. >

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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 man

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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 ac

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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 es

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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 ca

Re: Calculate Tape Bytes to Tracks

2010-05-03 Thread 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* opti

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 num

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 param

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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! --

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 maxi

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 n

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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-47

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 exp

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 'st

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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. Senat

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread Lizette Koehler
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

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread O'Brien, David W. (NIH/CIT) [C]
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

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 n

Re: Calculate Tape Bytes to Tracks

2010-05-02 Thread גדי בן אבי
...@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

Calculate Tape Bytes to Tracks

2010-05-02 Thread 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 bette