Re: IBM Assembler History
The CIA/NSA. When they get a copy of every IP message going through a
few ISP hubs, sometimes the second message gets back onto the
internet. I have one particular web site that keeps track of which
forum posts you have been sent. About 80% of the time it sends the
page a second time with all the unread flags turned off, with about a
2-3 second delay. Worse is the first page of display, because it
starts at the first unread post then the second page goes to the next
page so I have to go back to the previous page of 10 posts then go
forward. Other times I start reading a page and it refreshes after a
few seconds.
toggle quoted message
Show quoted text
On Sun, Dec 6, 2020 at 11:58 AM Jeremy Nicoll <yahgrp87@...> wrote:
On Sun, 6 Dec 2020, at 17:43, Ham Radio wrote:
[Edited Message Follows] Why do I (and presumably other people too) get two copies of some
messages, the latter one always seemingly starting with that [text]?
--
Jeremy Nicoll - my opinions are my own.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
|
Re: Show disk usage in TK4-
"1) With RECFM=FB, the block's size must be a multiple of the record length.? Plainly 28332
isn't a multiple of 80."
a 3390-1 has a tracksize?of 56,664.
56664 / 80 = 708 records per track. 354 records per half-track. half-track is 28320, so i was off by 12 bytes on the blocksize.
my bad.?
Joe
> DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)
nope.
Two things:
1) With RECFM=FB, the block's size must be a multiple of the record length.? Plainly 28332
isn't a multiple of 80.
2) There are overheads in a block.? In a Count-Key-Data disk type (such as a 3390), a data
block is preceeded by a count block and (possibly) a key block.? In a physical 3390 blocks
are (were) stored in sets of 32 bytes (? so long since I've needed to know) - which includes
ECC data.
So each of these three block types takes a multiple of 32 bytes.? While a count block is 5
bytes long (fwiw, 1 byte for record's number on track, 2 bytes for the length of the key block
(obviously zero if unkeyed) and two bytes for the length of the data block) it still consumes 32
bytes on the track.
In addition there are inter block gaps - in a 3390, each a multiple of 32 bytes.? Both between
the count, key and data blocks and between sets of CKD blocks.? I forget their sizes.
has actual maximum block size at various blocks per track values.? The maximum block size
to store 2 blocks per track is 27998.? Any size larger means one block per track, and any size
larger than 32760 requires low level access techniques.
So 27998 is the largest realistic block size for most purposes.? Rounding down to a multiple
of 80 bytes gives
DCB=(LRECL=80,BLSKIZE=27920,RECFM=FB)
In addition, taking some other things from this thread, in MVS type systems,
- data sets are allocated in, at a minimum, units of tracks.? A one byte data set consumes at
least a whole track.
- data sets are allocated in extents - which can range in size from a track to an entire disk.
Once a track is allocated to a dataset, it is not available to another dataset.
If you are looking at 'how full is a disk', you really need to look at two things:
- how many tracks are allocated to a dataset
- how much of each dataset's allocation is actually occupied by data.? My recollection of Linux
and Windows is that unused space within a file's allocation is going to be somewhat less than
1 KB.? In MVS is an be an entire disk.
You might also find IEHLIST of use.
((plain) MVS's version is much the same.)? One advantage it seems to have is that it can
provide each data set's "LAST BLK(TTTT-R)" - that is you can calculate how much of the
data set's allocation is, in fact, unused .
Obviously, as others have mentioned, this, as with IBHLSPAC, is the 'logical' space inside
the disk.? If the track is compressed, it doesn't relate to how much space each track
consumes in the hosting Linux/Windows environment.? An allocated track full of zeros takes
less space than a 'free' track full of random stuff left over from when it was used.
James Campbell
On 5 Dec 2020 at 17:30, Joe Monk wrote:
> Patrik,
>
> Youre conflating a couple of concepts.
>
> 1 is LRECL - this is the size of 1 record
> 2 is BLKSIZE - this is the size of 1 block
>
> The only reason we care about bytes in the? mainframe world is for blocking
> factor, how many records can I fit in 1 block, which can fit on a track?
> So, we only care about? the number of bytes per track for that reason. A track
> is always a fixed number of bytes. A cylinder is ALWAYS 15 tracks.
>
> Example: on a 3390, a track is 56,664 bytes. If I have 80 byte fixed
> records, then I can fit 708 records on a track. BUT - when using QSAM,
> efficient dasd usage mandates half-track blocking, or 1 block should be
> about 28,332 bytes. This means 1 block should be about 354 records...
>
> So in JCL:
>
> DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)
>
> Joe
>
> On Sat, Dec 5, 2020 at 4:42 PM Patrik Schindler <poc@...> wrote:
>
> > Hello Jay,
> >
> > Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:
> >
> > > Take a look at
> >
> > Thanks a lot, will do and report back. From the sample output, it?s not
> > too helpful for a rookie like me: I don?t yet have a feeling (or better:
> > deep understanding) for juggling with cylinders and tracks. I?m used to
> > bytes, but isn?t the size (in byte) per track device dependent?
> >
> > Maybe an additional column with percentage-used would be more helpful for
> > a first glance? I?ll see if I could bring this thing into TK4-, and maybe I
> > can enhance the source. Tomorrow. Here?s nearly midnight...
> >
> > :wq! PoC
> >
--
This email has been checked for viruses by AVG.
|
Hi
I know that around here parentheses may not be appreciated, but it turns out I do.
Many people here seem to work on Linux/Mac/Windows using bad editors (yep!? I am wearing flame-retardant underwear :) ).?
I am using the Editor.
Once I started poking around this very nice part of the Internet I did what I usually do when I learn something new (i.e., some programming tool): I looked around for an ... Emacs mode to edit JCL.? The idea being to manage and edit jobs on my machine and submit them to the card reader, as Jay Moseley suggests and as it is possible to do on TK4- (have not checked how to do something similar on, say, VM).
Contrary to the common lore that "there is an Emacs command for that", I could not find a jcl-mode.el out there!? It then became a categorical imperative to write one.
The result is the IRON MAIN (iron-main) Emacs package which includes a jcl-mode.
For the two of you who may be interested, the link to the GitHub repository is the following:
If you want the long story and some explanations about how I wrote the package, you can read the longish blog entry right here:
There is one advantage that you gain using IRON MAIN w.r.t. using command line tools to interact with the socket card reader.? Recent versions of Windows flag netcat and derivatives as "bad guys".? IRON MAIN jcl-mode uses Emacs process-send-region to load the card reader, therefore you do not need netcat et al. anymore; plus everything is nicely integrated in Emacs.
I checked that the submission process works under TK4- and under a "Jay Moseley's build" I have on my machine by submitting a simple job that just allocates a PDS in the MVS instance. Check the file 'tests/testsubmit.jcl'; you just have to tweak the user, password and HLQ if needed.
I hope this will help somebody.? It has been fun and I am glad to make a minimal (if pointless) contribution to this community.
All the best
--
Marco Antoniotti
Somewhere over the rainbow
|
Re: IBM Assembler History
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Jeremy
Nicoll
Sent: 06 December 2020 17:58
To: ML - H390-MVS-io <[email protected]>
Subject: Re: [H390-MVS] IBM Assembler History
On Sun, 6 Dec 2020, at 17:43, Ham Radio wrote:
[Edited Message Follows] Why do I (and presumably other people too) get two copies of some
messages, the latter one always seemingly starting with that [text]?
Because they use the web interface to submit the message, then change it after submission. The group owner or a moderator with permission can disable message editing so they would have to reply to their own message to amend. --
Jeremy Nicoll - my opinions are my own.
Dave G4UGM
|
Re: IBM Assembler History
On Sun, 6 Dec 2020, at 17:43, Ham Radio wrote: [Edited Message Follows] Why do I (and presumably other people too) get two copies of some messages, the latter one always seemingly starting with that [text]? -- Jeremy Nicoll - my opinions are my own.
|
Re: IBM Assembler History
Evidently, Assembler F was written by 3 or 4 people. ?Some comments in the source code state something like ¡°call
Joe¡¯s parser¡±, ¡°call Frank¡¯s routine¡±, etc.
I knew the author of Assembler G, Rene Peterson, when I worked at the University of Waterloo.
Not only was Assembler G way faster that Assembler F, ?it had a squished cross reference listing feature. ?That feature alone probably saved thousands of trees!
--
Regards,
Bernie (did 360 assembler programming on IBM Model 75 in late 1960s)
|
Re: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-
Mike,
Your explanation of a PDS is the "down and dirty details" - however, we have ACCESS METHODS that are supplied to deal with all the special handling.
The operating system supplies : BDAM - Basic Direct Access Method, QSAM, Queued Access Method, VSAM (Virtual Storage Access Method). BPAM (Basic Partitioned Access Method) - BSAM - Basic Sequential Access Method ...
There are variations - ISAM (Indexed Sequential Access Method)
I hope you are NOT trying to do this - yourself -
We have utilities that specifically deal with Partition Data Sets (PDS) - to read/write/update -reorganize etc.
I am not sure what your comment concerning AFP libraries is referencing -??
In the CURRENT world of z/OS - we have yet another access method called Object Access Method - that uses DB2 - (in what is called a special type of VSAM data set - called a VSAM LINEAR DATA SET -
Also - a NEWER form of the PDS - that is called PDSE - Partition Data Set EXTENDED - that has some advantages - that solve some of the limitations that our PDSs have had...
-J-
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Mike Schwab Sent: Sunday, December 6, 2020 11:45 AM To: [email protected]Subject: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4- The track is the empty disk space. The blocksize is the physical block. VSAM writes Control Intervals (blocks) in multiples ofr 512, up to 4096. Larger control intervals are possible but are broken down into these physical blocks since they don't result in higher space utilization. VSAM files are often used for applications where you want to update records in place. Non VSAM datasets you get to choose the physical block size. .Short blocks can be created at the end of a dataset when you close. Updates in place are permitted only if you don't change the length of the block. Load modules are very, very interesting. First it is a PDS, so you have a PDS directory consisting of Key length 8 block size 256 containing 3 to 7 membernames and a pointer to the data, and empty names to fill the number of requested blocks. Then you have the eof record for the directory, which allows reading the directory as DSORG=PS file. After that you have the members. TXT records for the header, I think they are 80 bytes. Then a 8 bytes control record to read the next block. The actual load module block is then a multiple of 1024 bytes up to the remaining space on the track or the specified blocksize. These two records repeat until the end of the member. Writing a member is always to the end. Replacing a member is writing the new contents to the end and the old contents no longer have a reference. Compression is then accomplished by skipping to the first unreferenced area, then moving the next member forward and repeating to the end. Advance Function Printing (AFP) libraries are optimized with an 18K blocksize. On Sun, Dec 6, 2020 at 6:30 AM Patrik Schindler <poc@...> wrote:
Hello,
Am 06.12.2020 um 06:39 schrieb jacampbellaus@...
So 27998 is the largest realistic block size for most purposes.
Rounding down to a multiple of 80 bytes gives
DCB=(LRECL=80,BLSKIZE=27920,RECFM=FB) Thanks for that explanation. I¡¯m glad to see that in the end, bytes are what really counts, even on MVS. Cylinder and track calculations appear to be a relict from the limited hardware of yesteryears, requiring (?) an unload of these to the user instead of the CPU.
In addition, taking some other things from this thread, in MVS type
systems,
- data sets are allocated in, at a minimum, units of tracks. A one
byte data set consumes at least a whole track. Now, that is what I call a solid basic information! Q: Is a track comparable to a sector in conventional disks? How do blocks fit into this picture? What about physical vs. logical block sizes?
- data sets are allocated in extents - which can range in size from a track to an entire disk.
Once a track is allocated to a dataset, it is not available to another dataset. Sounds logical to me.
If you are looking at 'how full is a disk', you really need to look at two things:
- how many tracks are allocated to a dataset
- how much of each dataset's allocation is actually occupied by
data. My recollection of Linux and Windows is that unused space
within a file's allocation is going to be somewhat less than
1 KB. In MVS is an be an entire disk. Yes and no. Allocated tracks are not free, and as far as I understand, the free tracks count is what matters. Correct?
How much of each dataset's allocation is actually occupied by data is more of a ?how efficient is data stored¡°, expressed as overhead for preallocated tracks. I don¡¯t care about this. What¡¯s more, I guess to find out this ?empty space within datasets¡° within the countless DS¡¯s on a system could be tedious.
You might also find IEHLIST of use.
.
zos.v2r4.idau100
/iehlist.htm
((plain) MVS's version is much the same.) One advantage it seems to
have is that it can provide each data set's "LAST BLK(TTTT-R)" -
that is you can calculate how much of the data set's allocation is, in fact, unused . Thanks for that hint!
Obviously, as others have mentioned, this, as with IBHLSPAC, is the
'logical' space inside the disk. If the track is compressed, it
doesn't relate to how much space each track consumes in the hosting
Linux/Windows environment. An allocated track full of zeros takes less space than a 'free' track full of random stuff left over from when it was used. This ?others¡° was me. ;-)
Thanks a lot! I¡¯m much closer to my goal now! And I had some ?aha¡° while reading your explanations.
:wq! PoC
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all?
|
Re: Show disk usage in TK4-
The track is the empty disk space. The blocksize is the physical
block. VSAM writes Control Intervals (blocks) in multiples ofr 512,
up to 4096. Larger control intervals are possible but are broken down
into these physical blocks since they don't result in higher space
utilization. VSAM files are often used for applications where you
want to update records in place.
Non VSAM datasets you get to choose the physical block size. .Short
blocks can be created at the end of a dataset when you close. Updates
in place are permitted only if you don't change the length of the
block.
Load modules are very, very interesting. First it is a PDS, so you
have a PDS directory consisting of Key length 8 block size 256
containing 3 to 7 membernames and a pointer to the data, and empty
names to fill the number of requested blocks. Then you have the eof
record for the directory, which allows reading the directory as
DSORG=PS file. After that you have the members. TXT records for the
header, I think they are 80 bytes. Then a 8 bytes control record to
read the next block. The actual load module block is then a multiple
of 1024 bytes up to the remaining space on the track or the specified
blocksize. These two records repeat until the end of the member.
Writing a member is always to the end. Replacing a member is writing
the new contents to the end and the old contents no longer have a
reference. Compression is then accomplished by skipping to the first
unreferenced area, then moving the next member forward and repeating
to the end.
Advance Function Printing (AFP) libraries are optimized with an 18K blocksize.
toggle quoted message
Show quoted text
On Sun, Dec 6, 2020 at 6:30 AM Patrik Schindler <poc@...> wrote:
Hello,
Am 06.12.2020 um 06:39 schrieb jacampbellaus@...
So 27998 is the largest realistic block size for most purposes. Rounding down to a multiple
of 80 bytes gives
DCB=(LRECL=80,BLSKIZE=27920,RECFM=FB) Thanks for that explanation. I¡¯m glad to see that in the end, bytes are what really counts, even on MVS. Cylinder and track calculations appear to be a relict from the limited hardware of yesteryears, requiring (?) an unload of these to the user instead of the CPU.
In addition, taking some other things from this thread, in MVS type systems,
- data sets are allocated in, at a minimum, units of tracks. A one byte data set consumes at
least a whole track. Now, that is what I call a solid basic information! Q: Is a track comparable to a sector in conventional disks? How do blocks fit into this picture? What about physical vs. logical block sizes?
- data sets are allocated in extents - which can range in size from a track to an entire disk.
Once a track is allocated to a dataset, it is not available to another dataset. Sounds logical to me.
If you are looking at 'how full is a disk', you really need to look at two things:
- how many tracks are allocated to a dataset
- how much of each dataset's allocation is actually occupied by data. My recollection of Linux
and Windows is that unused space within a file's allocation is going to be somewhat less than
1 KB. In MVS is an be an entire disk. Yes and no. Allocated tracks are not free, and as far as I understand, the free tracks count is what matters. Correct?
How much of each dataset's allocation is actually occupied by data is more of a ?how efficient is data stored¡°, expressed as overhead for preallocated tracks. I don¡¯t care about this. What¡¯s more, I guess to find out this ?empty space within datasets¡° within the countless DS¡¯s on a system could be tedious.
You might also find IEHLIST of use.
/iehlist.htm
((plain) MVS's version is much the same.) One advantage it seems to have is that it can
provide each data set's "LAST BLK(TTTT-R)" - that is you can calculate how much of the
data set's allocation is, in fact, unused . Thanks for that hint!
Obviously, as others have mentioned, this, as with IBHLSPAC, is the 'logical' space inside
the disk. If the track is compressed, it doesn't relate to how much space each track
consumes in the hosting Linux/Windows environment. An allocated track full of zeros takes
less space than a 'free' track full of random stuff left over from when it was used. This ?others¡° was me. ;-)
Thanks a lot! I¡¯m much closer to my goal now! And I had some ?aha¡° while reading your explanations.
:wq! PoC
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
|
Re: Show disk usage in TK4-
Hello, Am 06.12.2020 um 06:39 schrieb jacampbellaus@... So 27998 is the largest realistic block size for most purposes. Rounding down to a multiple
of 80 bytes gives
DCB=(LRECL=80,BLSKIZE=27920,RECFM=FB) Thanks for that explanation. I¡¯m glad to see that in the end, bytes are what really counts, even on MVS. Cylinder and track calculations appear to be a relict from the limited hardware of yesteryears, requiring (?) an unload of these to the user instead of the CPU. In addition, taking some other things from this thread, in MVS type systems,
- data sets are allocated in, at a minimum, units of tracks. A one byte data set consumes at
least a whole track. Now, that is what I call a solid basic information! Q: Is a track comparable to a sector in conventional disks? How do blocks fit into this picture? What about physical vs. logical block sizes? - data sets are allocated in extents - which can range in size from a track to an entire disk.
Once a track is allocated to a dataset, it is not available to another dataset. Sounds logical to me. If you are looking at 'how full is a disk', you really need to look at two things:
- how many tracks are allocated to a dataset
- how much of each dataset's allocation is actually occupied by data. My recollection of Linux
and Windows is that unused space within a file's allocation is going to be somewhat less than
1 KB. In MVS is an be an entire disk. Yes and no. Allocated tracks are not free, and as far as I understand, the free tracks count is what matters. Correct? How much of each dataset's allocation is actually occupied by data is more of a ?how efficient is data stored¡°, expressed as overhead for preallocated tracks. I don¡¯t care about this. What¡¯s more, I guess to find out this ?empty space within datasets¡° within the countless DS¡¯s on a system could be tedious. You might also find IEHLIST of use.
/iehlist.htm
((plain) MVS's version is much the same.) One advantage it seems to have is that it can
provide each data set's "LAST BLK(TTTT-R)" - that is you can calculate how much of the
data set's allocation is, in fact, unused . Thanks for that hint! Obviously, as others have mentioned, this, as with IBHLSPAC, is the 'logical' space inside
the disk. If the track is compressed, it doesn't relate to how much space each track
consumes in the hosting Linux/Windows environment. An allocated track full of zeros takes
less space than a 'free' track full of random stuff left over from when it was used. This ?others¡° was me. ;-) Thanks a lot! I¡¯m much closer to my goal now! And I had some ?aha¡° while reading your explanations. :wq! PoC
|
Re: Show disk usage in TK4-
"Greg Price" <procegrog@...> writes: On 2020-12-06 2:45 AM, Patrik Schindler wrote:
today I was wondering, how much unallocated space I have available
on the various volumes I use the LISTVOL command on TSO for this - not sure if it is on TK4-
or not.
Cheers,
Greg
It's there. At least on my tk4- Update 8 system <#secure method=pgpmime mode=sign>
|
Re: Show disk usage in TK4-
DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB) nope. Two things: 1) With RECFM=FB, the block's size must be a multiple of the record length. Plainly 28332 isn't a multiple of 80. 2) There are overheads in a block. In a Count-Key-Data disk type (such as a 3390), a data block is preceeded by a count block and (possibly) a key block. In a physical 3390 blocks are (were) stored in sets of 32 bytes (? so long since I've needed to know) - which includes ECC data. So each of these three block types takes a multiple of 32 bytes. While a count block is 5 bytes long (fwiw, 1 byte for record's number on track, 2 bytes for the length of the key block (obviously zero if unkeyed) and two bytes for the length of the data block) it still consumes 32 bytes on the track. In addition there are inter block gaps - in a 3390, each a multiple of 32 bytes. Both between the count, key and data blocks and between sets of CKD blocks. I forget their sizes. has actual maximum block size at various blocks per track values. The maximum block size to store 2 blocks per track is 27998. Any size larger means one block per track, and any size larger than 32760 requires low level access techniques. So 27998 is the largest realistic block size for most purposes. Rounding down to a multiple of 80 bytes gives DCB=(LRECL=80,BLSKIZE=27920,RECFM=FB) In addition, taking some other things from this thread, in MVS type systems, - data sets are allocated in, at a minimum, units of tracks. A one byte data set consumes at least a whole track. - data sets are allocated in extents - which can range in size from a track to an entire disk. Once a track is allocated to a dataset, it is not available to another dataset. If you are looking at 'how full is a disk', you really need to look at two things: - how many tracks are allocated to a dataset - how much of each dataset's allocation is actually occupied by data. My recollection of Linux and Windows is that unused space within a file's allocation is going to be somewhat less than 1 KB. In MVS is an be an entire disk. You might also find IEHLIST of use. /iehlist.htm ((plain) MVS's version is much the same.) One advantage it seems to have is that it can provide each data set's "LAST BLK(TTTT-R)" - that is you can calculate how much of the data set's allocation is, in fact, unused . Obviously, as others have mentioned, this, as with IBHLSPAC, is the 'logical' space inside the disk. If the track is compressed, it doesn't relate to how much space each track consumes in the hosting Linux/Windows environment. An allocated track full of zeros takes less space than a 'free' track full of random stuff left over from when it was used. James Campbell On 5 Dec 2020 at 17:30, Joe Monk wrote: Patrik,
Youre conflating a couple of concepts.
1 is LRECL - this is the size of 1 record
2 is BLKSIZE - this is the size of 1 block
The only reason we care about bytes in the mainframe world is for blocking
factor, how many records can I fit in 1 block, which can fit on a track?
So, we only care about the number of bytes per track for that reason. A track
is always a fixed number of bytes. A cylinder is ALWAYS 15 tracks.
Example: on a 3390, a track is 56,664 bytes. If I have 80 byte fixed
records, then I can fit 708 records on a track. BUT - when using QSAM,
efficient dasd usage mandates half-track blocking, or 1 block should be
about 28,332 bytes. This means 1 block should be about 354 records...
So in JCL:
DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)
Joe
On Sat, Dec 5, 2020 at 4:42 PM Patrik Schindler <poc@...> wrote:
Hello Jay,
Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:
Take a look at Thanks a lot, will do and report back. From the sample output, it?s not
too helpful for a rookie like me: I don?t yet have a feeling (or better:
deep understanding) for juggling with cylinders and tracks. I?m used to
bytes, but isn?t the size (in byte) per track device dependent?
Maybe an additional column with percentage-used would be more helpful for
a first glance? I?ll see if I could bring this thing into TK4-, and maybe I
can enhance the source. Tomorrow. Here?s nearly midnight...
:wq! PoC
-- This email has been checked for viruses by AVG.
|
Re: Show disk usage in TK4-
Hello Joe, Am 06.12.2020 um 00:30 schrieb Joe Monk <joemonk64@...>: Youre conflating a couple of concepts. So it seems. Thanks for your explanation! :wq! PoC
|
Re: [Marketing Mail] [H390-MVS] Show disk usage in TK4-
Hello Jeff, Am 06.12.2020 um 00:07 schrieb Jeff Bassett <bassettj@...>: Well - your comment of being helpful to a rookie....
You see, in the MAINFRAME world (except now z/LINUX) - allocation is done in three ways
BLKs - BLOCKS -
TRKS - tracks
CYL - cylinders -
So - BYTES is of no use.... I don¡¯t think it¡¯s *no* use, but maybe less useful? When I want to create a dataset for some kind of tabular data, this equates to a record length. This one I think of in Bytes. But again, maybe this is just my habit coming from stream-oriented platforms. Also OS/400 doesn¡¯t bother the user with tracks and blocks, so yes, this whole concept is very unusual to me. :-) In the early days - this was somewhat of a challenge - there are SEVERAL places to get the DISK capacity tables -
Here is one - Thanks for that reference! So, it would be not too much overhead nowadays to have this list being available in a standardized data set in an MVS environment, to help calculations, right? For rookies like me? ;-) The actual number of cylinders - the PHYSICAL disks (the most recent - are all emulated in software - and the physical storage is not a component I know that this changed years ago, but the OS heritage still requires to be backwards compatible. You see, my friend - I don't think in BYTES, just like YOU don't think in Cylinders¡ Yes, I see. :-) But then, I still miss an easy solution to have a quick overview about used and free disk space. Just like df does in UNIX or USS in z/OS. Even a percentage per volume would be helpful for a quick glance. But I'm learning more and more, there¡¯s almost nothing done quick with MVS and possibly with it¡¯s descendants. ;-) From my retrocomputing viewpoint, this is very interesting, something completely different and thus enjoyable. From my viewpoint as a (Linux) sysadmin, it¡¯s really cumbersome to get a sense of achievement before giving up because the annoyance level crossed my individual threshold level. :-) :wq! PoC
|
Re: Show disk usage in TK4-
Hello Greg, Am 06.12.2020 um 07:11 schrieb Greg Price <procegrog@...>: today I was wondering, how much unallocated space I have available on the various volumes I use the LISTVOL command on TSO for this - not sure if it is on TK4- or not.
Bingo, that¡¯s it! Still the numbers are telling me nothing, because I need to manually compare with what¡¯s available, but this is at least a built-in immediately usable. Thanks a lot! :wq! PoC
|
Re: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-
Actually, from the hardware perspective in the original designs, it is n+1 tracks. The system, and therefore ¡°normal¡± programming, sees n tracks, the +1 is the servo track. Given the shift to emulated tracks and cylinders, all that is seen now in most hardware designs is the presentation of n tracks per cylinder as the servo track is no longer necessary. ? Another way to look at this is that a track, for allocation purposes, is equivalent to a base allocation cluster of m sectors in the non-mainframe world. ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Jeff Bassett
Sent: Saturday, December 5, 2020 3:36 PM
To: [email protected]
Subject: Re: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-? Joe, 3350 is 30 trks/cyl ? I agree ¨C everything since 3380s ¨C it is 15 TRKS/Cylinder ¨C so everything NOW ¨C remember ¨C we use 3350 a lot in the older MVS systems.? ? -J-
|
Re: Show disk usage in TK4-
Indeed, the LISTVOL is in TK4-
listvol?????????????????????????????????????????? ?
?VOLUME? DEV USAGE OPN ------ FREE ------ --CONTG--
? NAME? NMBR COUNT CNT CYLS TRKS NUM DSCB CYLS TRKS
?SORT01? 131???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT02? 132???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT03? 133???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT04? 134???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT05? 135???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT06? 136???? 0?? 0 0199 0000 001 0473 0199 0000
?WORK00? 140???? 0?? 0 0554 0000 001 1361 0554 0000
?MVSRES? 148??? 31? 11 0285 0075 003 1306 0283 0024
?SMP001? 149???? 0?? 0 0516 0007 001 1360 0516 0007
?SMP002? 14A???? 0?? 0 0506 0010 001 1360 0506 0010
?SMP003? 14B???? 0?? 0 0531 0011 001 1360 0531 0011
?SMP004? 14C???? 0?? 0 0514 0012 001 1354 0514 0012
?HASP00? 152???? 1?? 0 0000 0000 000 0699 0000 0000
?PAGE00? 160???? 3?? 0 0000 0000 000 0237 0000 0000
?PAGE01? 161???? 2?? 0 0000 0000 000 0238 0000 0000
?WORK01? 170???? 0?? 0 0957 0000 001 1171 0957 0000
?WORK02? 180???? 0?? 0 0884 0000 001 0740 0884 0000
?WORK03? 190???? 0?? 0 1112 0000 001 0698 1112 0000
?MVSCAT? 191???? 1?? 0 1053 0040 005 0635 1045 0003
?PUB000? 240???? 9?? 3 0343 0089 008 1306 0318 0015
?PUB010? 241???? 0?? 0 0547 0020 002 1347 0547 0018
?MVSDLB? 248???? 4?? 1 0196 0023 001 1289 0196 0023
?PUB001? 270???? 1?? 0 0924 0003 002 1162 0924 0000
?PUB011? 271???? 0?? 0 0954 0001 001 1166 0954 0001
?PUB002? 280???? 0?? 0 1618 0028 006 0681 1618 0000
?PUB012? 281???? 0?? 0 1569 0005 003 0715 1569 0000
?PUB003? 290???? 0?? 0 1060 0029 005 0652 1060 0000
?PUB013? 291???? 0?? 0 1987 0001 002 0688 1987 0000
?READY????????
Cheers,
Rob ??????????????????????????????????
|
Re: Show disk usage in TK4-
On 2020-12-06 2:45 AM, Patrik Schindler wrote: today I was wondering, how much unallocated space I have available on the various volumes I use the LISTVOL command on TSO for this - not sure if it is on TK4- or not. Cheers, Greg
|
Re: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-
Jeff,?
Sure. But you can pretend that they are 15 and the math pretty much works the same ...
Joe
On Sat, Dec 5, 2020 at 5:35 PM Jeff Bassett < bassettj@...> wrote:
Joe,
3350 is 30 trks/cyl
?
I agree ¨C everything since 3380s ¨C it is 15 TRKS/Cylinder ¨C so everything NOW ¨C remember ¨C we use 3350 a lot in the older MVS systems.?
?
-J-
?
From: [email protected] <[email protected]>
On Behalf Of Joe Monk
Sent: Saturday, December 5, 2020 6:31 PM
To: [email protected]
Subject: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-
?
Patrik,
Youre?conflating a couple of concepts.
1 is LRECL - this is the size of 1 record
2 is BLKSIZE - this is the size of 1 block
The only reason we care about bytes in the ?mainframe world is for blocking factor, how many records can I fit in 1 block, which can fit on a track? So, we only care about ?the number of bytes per track for that reason. A?track
is always a fixed number of bytes. A cylinder is ALWAYS 15 tracks.
Example: on a 3390, a track is 56,664 bytes. If I have 80 byte fixed records, then I can fit 708 records on a track. BUT - when using QSAM, efficient dasd usage mandates half-track blocking, or 1 block should be about 28,332 bytes. This
means 1 block should be about 354 records...
DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)
?
On Sat, Dec 5, 2020 at 4:42 PM Patrik Schindler <poc@...> wrote:
Hello Jay,
Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:
> Take a look at
Thanks a lot, will do and report back. From the sample output, it¡¯s not too helpful for a rookie like me: I don¡¯t yet have a feeling (or better: deep understanding) for juggling with cylinders and tracks. I¡¯m used to bytes, but isn¡¯t the size (in byte) per
track device dependent?
Maybe an additional column with percentage-used would be more helpful for a first glance? I¡¯ll see if I could bring this thing into TK4-, and maybe I can enhance the source. Tomorrow. Here¡¯s nearly midnight¡
:wq! PoC
|
Re: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-
Joe,
3350 is 30 trks/cyl
?
I agree ¨C everything since 3380s ¨C it is 15 TRKS/Cylinder ¨C so everything NOW ¨C remember ¨C we use 3350 a lot in the older MVS systems.?
?
-J-
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Joe Monk
Sent: Saturday, December 5, 2020 6:31 PM
To: [email protected]
Subject: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-
?
Patrik,
Youre?conflating a couple of concepts.
1 is LRECL - this is the size of 1 record
2 is BLKSIZE - this is the size of 1 block
The only reason we care about bytes in the ?mainframe world is for blocking factor, how many records can I fit in 1 block, which can fit on a track? So, we only care about ?the number of bytes per track for that reason. A?track
is always a fixed number of bytes. A cylinder is ALWAYS 15 tracks.
Example: on a 3390, a track is 56,664 bytes. If I have 80 byte fixed records, then I can fit 708 records on a track. BUT - when using QSAM, efficient dasd usage mandates half-track blocking, or 1 block should be about 28,332 bytes. This
means 1 block should be about 354 records...
DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)
?
On Sat, Dec 5, 2020 at 4:42 PM Patrik Schindler <poc@...> wrote:
Hello Jay,
Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:
> Take a look at
Thanks a lot, will do and report back. From the sample output, it¡¯s not too helpful for a rookie like me: I don¡¯t yet have a feeling (or better: deep understanding) for juggling with cylinders and tracks. I¡¯m used to bytes, but isn¡¯t the size (in byte) per
track device dependent?
Maybe an additional column with percentage-used would be more helpful for a first glance? I¡¯ll see if I could bring this thing into TK4-, and maybe I can enhance the source. Tomorrow. Here¡¯s nearly midnight¡
:wq! PoC
|
Re: Show disk usage in TK4-
Patrik,
Youre?conflating a couple of concepts.
1 is LRECL - this is the size of 1 record 2 is BLKSIZE - this is the size of 1 block
The only reason we care about bytes in the ?mainframe world is for blocking factor, how many records can I fit in 1 block, which can fit on a track? So, we only care about ?the number of bytes per track for that reason. A?track is always a fixed number of bytes. A cylinder is ALWAYS 15 tracks.
Example: on a 3390, a track is 56,664 bytes. If I have 80 byte fixed records, then I can fit 708 records on a track. BUT - when using QSAM, efficient dasd usage mandates half-track blocking, or 1 block should be about 28,332 bytes. This means 1 block should be about 354 records...
So in JCL:
DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)
Joe
On Sat, Dec 5, 2020 at 4:42 PM Patrik Schindler < poc@...> wrote: Hello Jay,
Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:
> Take a look at
Thanks a lot, will do and report back. From the sample output, it¡¯s not too helpful for a rookie like me: I don¡¯t yet have a feeling (or better: deep understanding) for juggling with cylinders and tracks. I¡¯m used to bytes, but isn¡¯t the size (in byte) per track device dependent?
Maybe an additional column with percentage-used would be more helpful for a first glance? I¡¯ll see if I could bring this thing into TK4-, and maybe I can enhance the source. Tomorrow. Here¡¯s nearly midnight¡
:wq! PoC
|
Marco Antoniotti
Jeremy Nicoll
Jeff Bassett
Rob Prins