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
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 to the amount of work involved. Consider that the
linkage editor writes however much program text as fits on the rest of
the track. IEBCOPY to
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
With essentially all z DASD being cached these days, a lot of the efficiency
issues no longer apply, leaving space as more dominant.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU]
Directory is DL=256, KL=8; that affects space calculations, although normally
it makes little practical difference.
For PDSE everything is CI formatted.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
On recent generations, the keys are kept in the memory units, and cached
in the cache hierarchy. On some prior generations, keys were cached
in the TLB. I don't remember offhand in which generation that changed.
On the 3090 machines, I remember the engineers referring to separate
key
The space calculations are in terms of the virtual 3390 presented to the
channel, and haven't changed since Old Man Noach cornered the market in Gopher
wood. How the underlying hardware deals with it depnds on the box.
In general, half track is most efficient except for load modules, where short
If the application uses TRUNC appropriately then you can still fill the track.
Normally, however, a 32K block size on DASD is only used for load modules,
which have RECFM=U.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
Thanks! That clears things up.
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.
This "Z is just Power" rumor has been around for quite a while, repeatedly
debunked, yet it persists. Anyone know where it came from? I've always
assumed that there were some gross similarities, and that some journo took
that and made it into "they're the same thing", but I have no real idea.
>> 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
“To ensure you steer clear of any legal risk of reverse engineering, it should
be performed only to the extent of allowances, such as for accessing ideas,
facts, and functional concepts contained in the product.”
I doubt MicroFocus received allowances from IBM. Especially considering they
were
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
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 the space is
still wasted because it is still
> 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
Or just code:
SPACE=(500,(10,2),RLSE),
AVGREC=K
and let the system calculate how many tracks it needs.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Sri
h Kolusu
Sent: Wednesday, November 23, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in
>> 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.
If you re-implement the code using only the published API without
referencing the old code was ruled legal in the Google
re-implementation of JAVA. Google experienced problems due to
incompatibilities between versions of Java, so this was their fix.
@ Format of a PDS. N records of K8 Block256 for the directory plus an
end of file marker. Adding or removing members involves rewriting the
entire directory, member entry update in place is possible but not
guaranteed.
Text PDSs have members that are FB or VB blocks up to the block size
until
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.
On Tue, 22 Nov 2022 at 19:47, Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> Reverse engineering to get the source code is illegal.
>
That's a remarkably broad and unsubstantiated claim.
Tony H.
--
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 ...
Ah... the "everybody does it" defense.
On 11/23/2022 4:06 AM, W Mainframe wrote:
IBM is only IBM...There are lot of CICS clone running in our world... :)This is
not a news... I have a CICS clone running in a 100% JVM... Gnucobol, BMS
supporting, Java transactions and a simulated VSAM under
On Tue, 22 Nov 2022 11:36:34 -0600 Paul Gorlinsky
wrote:
:> there are also additional KEYS to manage the LPARs themselves and PREVENT
one LPAR from looking into the storage of another LPAR.
More likely thru shadow page tables as storage can be configured in
non-contiguous chunks.
--
Binyamin
No, sometimes a smaller block size is more efficient. Also, a 32K block size
doesn't mean that all blocks 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
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
On Wed, Nov 23, 2022 at 9:29 AM Paul Gorlinsky wrote:
> Engineers always think they can improve upon the works of others.
>
Sometimes they even succeed. :-)
--
Jay Maynard
--
For IBM-MAIN subscribe / signoff / archive access
On 11/23/2022 9:29 AM, Paul Gorlinsky wrote:
Engineers always think they can improve upon the works of others.
so true, working for an airspace company many years ago I recall an off
the wall company called SCS, IIRC, Scientific computer Systems, that
sold us an engineering solution to
Seymour is correct. The POP or POO is the specification.
Any given processor could implement the specification differently. This
includes all the simulators and emulators that have been developed over the
years. When you add all the different hardware implementations, including GE,
Fujitsu,
me too, I provided Ken one example I had, I suppose he could add an
OCOPY step to copy from USS to a PDS/E
one example
//SYSIN DD *
DATA TEMPA;
SET PDB.JOBS;
DATE=DATEPART(INITTIME);
IF DATE = '05DEC2006'D
OR DATE = '12DEC2006'D;
IF SYSTEM = 'CPU3';
IF INITTIME = '.'
I've done it to USS files but not to PDSEs. I'm not sure if you can, but how
would you read an Excel file in a PDSE from a PC?
Jim Horne
NOTICE: All information in and attached to the e-mails below may be
proprietary, confidential, privileged and otherwise
That reference is specific to the 370/145.Different processors often have
different internal organizations. The only constraint is that they comply with
PoOps.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
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,
If you don't mind storing CSV's instead of spreadsheet, you can use PROC EXPORT
like this:
proc export data=HSMFSRBO outfile='/tmp/hsmfsrbo.csv'
dbms=csv replace label;
This code writes the CSV file out to the /tmp directory for the system it runs
on. Sadly, it'll take an extra
The storage key is not part of the page table. However, when the OS pages
something out, it has to record the key for the page frame so that it can
restore the key when it reads the page back into a new page fram. How and where
it records the key is up to the OS, not the architecture.
--
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
I know this is super old information ... but given the discussion so far,
it seems reasonable to at least apply the same concept ...
"The storage-protect unit has a 64 x 8 monolithic storage protection stack
that applies to main storage locations zero through 131,072 (in sequential
blocks of
Well, you have to store the key *somewhere* when the page is paged out. But
you're right, the page table entry isn't it. I don't know what I was
thinking.
I'm sure that VSM maintains its own table of correspondence between virtual
storage addresses and storage key, so the key can be applied to
IBM is only IBM...There are lot of CICS clone running in our world... :)This is
not a news... I have a CICS clone running in a 100% JVM... Gnucobol, BMS
supporting, Java transactions and a simulated VSAM under Mysql... works fine...
My toy!
lol
Dan
Sent from Yahoo Mail for iPhone
On
Many thanks for that Jay. This would certainly seem the logical place to store
it.
I'm still a bit confused though. The pop section on Page-Table Entries (page
3-51 in the 13th edition...) does not mention this (though it does have a
unused byte at the end). If the intention is to make the
53 matches
Mail list logo
