D Woren [ibm-main...@ldworen.net]
Sent: Wednesday, November 23, 2022 7:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
Long ago I had a theory regarding blksize=32K load module libraries
that I could demonstrate on paper but never attempted to demonstrate
for real due
On Wed, 23 Nov 2022 16:56:42 -0800, Leonard D Woren
wrote:
>You could have two members originally linked to different
>areas of the original PDS, decently utilizing 32K blocks. Now you
>IEBCOPY the data set and those two members end up one following one
>another in the target, and the
On Fri, 25 Nov 2022 12:12:36 -0800, Leonard D Woren
wrote:
>
>I've long wondered why. And in the 1980s (I think), IBM actually had
>a disk for s370 which was FBA, but only supported by DOS/VS.
>
3310 and 3370. Also supported by VM/SP. (Certain models of 3370 could also
attach to System/38)
Paul Schuster wrote on 11/24/2022 11:13 PM:
TRKCALC knows everything.
Second best, I dug up this exec from the 1990s that should get it right:
/* Rexx */
Parse Arg kl dl .
"XPROC 2 KL DL DEBUG"
If dl = "" Then Do
Say "Usage: BLK3390 keylen datalen [DEBUG]"
Exit 2
End
c = 10
If kl = 0
...@ldworen.net]
Sent: Wednesday, November 23, 2022 8:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
True.
Yet... why is space still such a big deal on mainframes? I have
almost as much disk space connected to my primary PC as 10,000 3390-9
would hold
As someone who has delved deeply into this subject for different reasons, and
without "inside" knowledge, here's what I have learned or intuited:
1. Logical volumes are entirely self-contained (think of them as files),
allocated from the arrays with all required space needed to hold metadata,
On 11/23/2022 5:19 PM, Leonard D Woren wrote:
It's time to use this brainpower for better things than optimizing the
arrangement of angels on a pinhead. Just throw more hardware at it
and move on.
We have standardized on a mixture of Mod-27 and Mod-216 volumes for all
of our SMS-managed
:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
True.
Yet... why is space still such a big deal on mainframes? I have
almost as much disk space connected to my primary PC as 10,000 3390-9
would hold.
Seeing a 3390 with 150,000 free cylinders does take some getting used
@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
Not sure when it changed (at least a decade ago), I think the
mainframe reads and writes full tracks at a time anymore.
On Wed, Nov 23, 2022 at 7:01 PM Michael Oujesky wrote:
>
> Actually, if you are doing sequential processing, zEDC is p
TRKCALC knows everything.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
i was just getting ready to say this same thing.
The 3390 reference shows that for a 3120 byte block, only 15 blocks fit on
a track, with a 16% space waste.
Your best bet is to use TRKCALC...
https://www.ibm.com/docs/en/zos/2.4.0?topic=instructions-performing-track-calculations-trkcalc-macro
Subtracting the logical blocksize from either of those capacity numbers
as you describe will not give correct results for blocks per track. The
only accurate way to determine how many blocks will fit on a 3390 track
is to use the formulas from the 3390 Reference Summary (mentioned in
previous
You're missing an allowance for an inter-block gap.
On Thu, 24 Nov 2022 at 16:14, John Gateley wrote:
> The reason for asking the question about bytes on a track is that I am
> writing programs to report on all disk datasets.
> The first program looks at all on-line disk packs and extracts all
But even if they do that under the covers at the track level, I would
expect the DS8K boxes to still allocate/reserve total physical space for
each emulated DASD unit under the worst case assumption that every track
might be fully utilized. Unless advertised as a more restricted version
of
The reason for asking the question about bytes on a track is that I am writing
programs to report on all disk datasets.
The first program looks at all on-line disk packs and extracts all format 1, 3,
8 and 9 DSCBs while also providing a summary of space available/used on each
disk (similar to
Switching from "real" 3380s & 3390s to the emulated 3380s & 3390s has been an
evolutionary path.
For example, with the P370 and its derivatives, each DASD unit was implemented
as a single file on the hosting PC; AWSDISK. Hercules implemented the same file
structure and later added a
On 11/23/2022 5:19 PM, Mike Schwab wrote:
Not sure when it changed (at least a decade ago), I think the
mainframe reads and writes full tracks at a time anymore.
In a modern DASD subsystem, all operations are full track: read, write
or replicate.
However, the mainframe itself (as defined by
As a thought exercise...
Is it possible to make zOS, storage controllers, etc. just lie to the
requesting application.
App or JCL DD: Give me space for 'x' records, with a blocksize of 'y', exactly!
storage: Ok (but not really, I'll do what's best for myself!)
I know it already lies/emulates to
DUCK YES, Sri, DUCK YES!.
I am here for this excellent content.
- KB
--- Original Message ---
On Thursday, November 24th, 2022 at 12:59 AM, Sri h Kolusu
wrote:
> > > How do I calculate the amount of space a dataset needs?
>
>
> A 3390-n device has a capacity of 56,664 bytes
Thats why we have storage groups, 64K cyl volumes with 56GB, and EAV
volumes up to 1TB so far, 220TB possible but not implemented..
On Wed, Nov 23, 2022 at 7:20 PM Leonard D Woren wrote:
>
> True.
>
> Yet... why is space still such a big deal on mainframes? I have
> almost as much disk space
On Wed, 23 Nov 2022 17:19:40 -0800, Leonard D Woren
wrote:
>True.
>
>Yet... why is space still such a big deal on mainframes? I have
>almost as much disk space connected to my primary PC as 10,000 3390-9
>would hold.
>
>Seeing a 3390 with 150,000 free cylinders does take some getting used
On Wed, 23 Nov 2022 at 20:20, Mike Schwab wrote:
> Not sure when it changed (at least a decade ago), I think the
> mainframe reads and writes full tracks at a time anymore.
>
Positive anymore!
Tony H.
--
For IBM-MAIN
Not sure when it changed (at least a decade ago), I think the
mainframe reads and writes full tracks at a time anymore.
On Wed, Nov 23, 2022 at 7:01 PM Michael Oujesky wrote:
>
> Actually, if you are doing sequential processing, zEDC is perhaps the
> best as it "write"s full-tracks, regardless
True.
Yet... why is space still such a big deal on mainframes? I have
almost as much disk space connected to my primary PC as 10,000 3390-9
would hold.
Seeing a 3390 with 150,000 free cylinders does take some getting used to.
It's time to use this brainpower for better things than
Actually, if you are doing sequential processing, zEDC is perhaps the
best as it "write"s full-tracks, regardless of the BLKSIZE
specified. With zEDC, the BLKSIZE is just the size of data passed
to/from the application and no longer the physical data "written" to disk.
Michael
At 12:14 PM
are 32K; both the linkage editor and IEBCOPY can
write short blocks to pad out a track.
From: IBM Mainframe Discussion List on behalf of Paul
Gorlinsky
Sent: Wednesday, November 23, 2022 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390
On 11/23/2022 12:31 PM, Pommier, Rex wrote:
Hi Tom, yes and no. :-)
No, it isn't true on the physical back end because all the disk is emulated on
top of FBA architectures and especially with thin provisioning, only actually
used tracks are really used. However, from a z/OS perspective yes
] on behalf of
Paul Gorlinsky [p...@atsmigrations.com]
Sent: Wednesday, November 23, 2022 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
Short block more efficient? Elaborate please. Space utilization and efficient
are not necessarily the same. Latency issues vary a lot
-MAIN@LISTSERV.UA.EDU] on behalf of
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Wednesday, November 23, 2022 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
@ Format of a PDS. N records of K8 Block256 for the directory plus an
end of file marker. Adding or removing members
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
> but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left
> over, and because tracks can't be shared between other files
Great overview, but is the note above still true with modern DS8000
boxes? It's just hard
Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Wednesday, November 23, 2022 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Bytes in a 3390 track
Hi Tom, yes and no. :-)
No, it isn't true on the physical back end because all
On Behalf Of Tom
Brennan
Sent: Wednesday, November 23, 2022 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Bytes in a 3390 track
> but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left >
over, and because tracks can't be shared between other files
Great ov
>> Great overview, but is the note above still true with modern DS8000 boxes?
>> It's just hard for me to imagine 3390 emulation logic holding that 23K
>> hostage.
Tom,
As other have mentioned on z/OS it is still valid. Run this JCL and look at
the allocation . I used the example of
On Wed, 23 Nov 2022 at 15:17, Tom Brennan
wrote:
> > but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left
> > over, and because tracks can't be shared between other files
>
> Great overview, but is the note above still true with modern DS8000
> boxes? It's just hard for me to
-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Bytes in a 3390 track
> but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left > over,
> and because tracks can't be shared between other files
Great overview, but is the note above still true with modern DS8000 boxes?
It's
> but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left
> over, and because tracks can't be shared between other files
Great overview, but is the note above still true with modern DS8000
boxes? It's just hard for me to imagine 3390 emulation logic holding
that 23K hostage.
On
in a 3390 track
>> How do I calculate the amount of space a dataset needs?
A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 bytes
are accessible by applications programmers. The largest blocksize you can
define is 32,760, which is good for tapes,but it is mere
>> How do I calculate the amount of space a dataset needs?
A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 bytes
are accessible by applications programmers. The largest blocksize you can
define is 32,760, which is good for tapes,but it is mere waste on DASD, as
Multiply record size by number of records to calculate size. Divide
by 50,000 for number of tracks, or divide by 800,000 for a firm
estimate to 500,000 for a rough estimate for number of cylinders. If
you won't need additional space, code RLSE to release unused cylinders
/ tracks.
On Wed, Nov
Needless to say... it really depends on the question that is being asked.
How do I calculate the amount of space a dataset needs?
Don't use IBM's 56664 track space number for anything but a sales thing?
The 3390 DASD under normal use, do not have 56664 bytes per track available.
d IEBCOPY can
> write short blocks to pad out a track.
>
>
> From: IBM Mainframe Discussion List on behalf of
> Paul Gorlinsky
> Sent: Wednesday, November 23, 2022 12:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bytes in
If you are doing sequential reads and writes, half track is the best
you can do. If you are random reading small records, I.E. 80 byte,
400 bytes, 2000 bytes; then smaller blocks lead to less I/O per
record, since you aren't using most of the data read, and the larger
the block the less you use.
Short block more efficient? Elaborate please. Space utilization and efficient
are not necessarily the same. Latency issues vary a lot depending on the exact
box being used for DASD. DS6K v DS8K. DS8K with rotating v solid-state ...
QSAM v BPAM v BSAM v etc...
General guidelines ...
Gorlinsky
Sent: Wednesday, November 23, 2022 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
John, The simple view is that with DASD, the bigger the block as a multiple of
the track size, the more data you can store on a track.
It almost like an IBG on the older tapes
John, The simple view is that with DASD, the bigger the block as a multiple of
the track size, the more data you can store on a track.
It almost like an IBG on the older tapes.
Best allocation or space calc is to use 1/2 track if possible, for QSAM, and
PDSs. For PDSEs using 32760 is fine
Thank you very much for that comprehensive explanation.
John
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
See page 10 of the 3390 Reference Summary, manual GX26-4577, which can
be found online.
The physical records per track calculation is complex because the
physical space (or emulated space) is divided into 1729 cells of 34
bytes each (the source of the 58,786 value), allocation is in by cells,
Thanks Steve.
I did not know about the standard record 0, now that I do it makes sense.
John
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
58786 is the number of bytes available on the raw track. 56664 is what's
left after the standard Record 0, which is present on every track of a
volume formatted for z/OS use. I don't know about other OSes, and I don't
recall seeing the 55996 figure before.
The old 3390 Reference Summary is
Hello
On all the disk volumes I have looked at, the format 4 DSCB field DS4DEVTK
(device track length) has the value 58786.
All the IBM documentation says that there are 56664 bytes in a track on a 3390
drive.
At this link https://www.lascon.co.uk/hwd-3390-disks.php reference is made to
55996
50 matches
Mail list logo
