In listserv%201005061204514780.0...@bama.ua.edu, on 05/06/2010
at 12:04 PM, Paul Gilmartin paulgboul...@aim.com 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
In 4be3273c@bremultibank.com.pl, on 05/06/2010
at 10:31 PM, R.S. r.skoru...@bremultibank.com.pl 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
In 4bdd7bea.5070...@bremultibank.com.pl, on 05/02/2010
at 03:19 PM, R.S. r.skoru...@bremultibank.com.pl said:
IBM says it's 32760.
No.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We don't have to
In listserv%201005021133302062.0...@bama.ua.edu, on 05/02/2010
at 11:33 AM, Paul Gilmartin paulgboul...@aim.com 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
In
1991037664-1272805461-cardhu_decombobulator_blackberry.rim.net-4242174...@bda026.bisx.prod.on.blackberry,
on 05/02/2010
at 01:04 PM, Ted MacNEIL eamacn...@yahoo.ca said:
Remember that the maximum blksize on dasd is 27998 ...
No. It's not.
It's 32765.
I might believe 32767 for unkeyed and
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
W dniu 2010-05-06 19:04, Paul Gilmartin pisze:
On Thu, 6 May 2010 12:11:29 -0400, Shmuel Metz (Seymour J.) wrote:
In4bdd7bea.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:
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
W dniu 2010-05-03 00:35, Rick Fochtman pisze:
---snip
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*
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,
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
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
On 05/02/2010 08:26 PM, Scott Barry wrote:
On Sun, 2 May 2010 08:46:49 -0400, Lizette Koehler stars...@mindspring.com
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
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
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
: +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
Paul Gilmartin wrote:
snip
Where's the track capacity formula?
snip
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
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
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
snip
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.
/snip
I've been reviewing our tape usage with FATS and the TMC BLKCNT is the
number of
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
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
...@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
On Sun, 2 May 2010 08:46:49 -0400 Lizette Koehler stars...@mindspring.com
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
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
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
[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
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.
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
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
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
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
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
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
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
-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
BTW, you can specify greater than 32760.
I specify 32767 with SMF data all the time on disk.
SNIP
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!
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
---snip
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
On Sun, 2 May 2010 08:46:49 -0400, Lizette Koehler stars...@mindspring.com
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
40 matches
Mail list logo
