Re: IBM Assembler History
Kevin Monceaux wrote: I follow the list via e-mail also. I'm inclined to treat
edited messages much like I treat broken threads. I rarely
follow broken threads. If I've already read an original
message, I'm not going to reread an edited message and try
to figure what's been changed. I hear you, Kevin. HOWEVER... As for me, I do just the opposite: When I receive an email marked "[Edited Message Follows]", I *delete* the original message and keep *ONLY* the new ("edited") message. Doing so ensures my replies (should I wish to reply to what the author said) pertains to what the original author actually intended to say. It ensures only *accurate* information is retained and only *inaccurate* information is discarded. Threading is not really an issue for me. Outlook considers subsequent edited messages that might be received as part of the same thread anyway, and, like you, I don't use the groups.io web interface anyway, so threading issues are really a non-issue for me. But IMO it's important to NOT disregard/delete the author's edited message. IMO it's better to do as I do, and simply delete the *original* email instead, and keep *only* the subsequent "edited" message. Just my 2 cents. <shrug> -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: IBM Assembler History
Bernie/kevin
Not sure what you are asking. If you edit a message on-line there is only one message on-line. A second copy marked edited is sent out marked ¡°edited¡±
Dave
?testr of edit?
From: [email protected] <[email protected]> On Behalf Of Ham Radio
Sent: 07 December 2020 00:15
To: [email protected]
Subject: Re: [H390-MVS] IBM Assembler History
?
Kevin
I am in full agreement. However, if I make a serious mistake in a message i.e. Assembler F versus Assembler G, I submit a correction. ?For a typo it really does not matter.
The owner of groups.io may be interested in your concern that a second edited message should perhaps be marked ¡°edited¡±. Contact him with your feature request.
--
Regards,
Bernie (did 360 assembler programming on IBM Model 75 in late 1960s)
|
Re: IBM Assembler History
Kevin
I am in full agreement. However, if I make a serious mistake in a message i.e. Assembler F versus Assembler G, I submit a correction. ?For a typo it really does not matter.
The owner of groups.io may be interested in your concern that a second edited message should perhaps be marked ¡°edited¡±. Contact him with your feature request.
--
Regards,
Bernie (did 360 assembler programming on IBM Model 75 in late 1960s)
|
Re: IBM Assembler History
On Sun, Dec 06, 2020 at 08:51:36PM +0000, Jeremy Nicoll wrote: There's no button.... because I read the traffic by email. Worse, when
a (slightly different, I suppose) message arrives, there's nothing in its
text that shows what was changed. I follow the list via e-mail also. I'm inclined to treat edited messages much like I treat broken threads. I rarely follow broken threads. If I've already read an original message, I'm not going to reread an edited message and try to figure what's been changed. -- Kevin Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
|
Re: Show disk usage in TK4-
Hello Mike, Am 06.12.2020 um 17:45 schrieb Mike Schwab <Mike.A.Schwab@...>: The track is the empty disk space. This is about the only sentence I understood. :-) The rest of your detailed explanation doesn¡¯t make sense to me. Obviously, I lack some assumed knowledge. Thanks anyway! :wq! PoC
|
There is only the Editor. If you really must, you can choose between
M-x evil
and
M-x viper
You cannot do the opposite :) Of course, you can write a XEdit emulator in the Editor :) :) :) Cheers -- Marco Antoniotti Somewhere over the rainbow
|
Re: IBM Assembler History
On Sun, 6 Dec 2020, at 20:29, Ham Radio wrote: That is a result of using the edit feature. I try to use it minimally
but if I enter something truly incorrect, I make a edit. If you click
on the Edited button on the far right of the message, you will see the
before and after changes made by the edit. There's no button.... because I read the traffic by email. Worse, when a (slightly different, I suppose) message arrives, there's nothing in its text that shows what was changed. -- Jeremy Nicoll - my opinions are my own.
|
Re: Show disk usage in TK4-
Due to inter record gaps and the count block, 2 blocks of 27998
without a key will fit on a single 3390 track. Blocks of 27999 or more
will be 1 block per trac.
toggle quoted message
Show quoted text
On Sun, Dec 6, 2020 at 1:50 PM Joe Monk <joemonk64@...> wrote:
"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
On Sun, Dec 6, 2020 at 5:38 AM <jacampbellaus@...> wrote:
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.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
|
Re: IBM Assembler History
That is a result of using the edit feature. ?I try to use it minimally but if I enter something truly incorrect, ?I make a edit. If you click on the Edited button on the far right of the message, you will see the before and after changes made by the edit.?
--
Regards,
Bernie (did 360 assembler programming on IBM Model 75 in late 1960s)
|
Re: Show disk usage in TK4-
"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."
youre?almost there.
Page 51 may help...
Joe
"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.
|
On Sun, Dec 06, 2020 at 11:48:52AM -0800, marcoxa@... wrote: Many people here seem to work on Linux/Mac/Windows using bad editors
(yep!? I *am* wearing flame-retardant underwear :) ). I've tried various good and bad editors. I keep going back to vim. I am using *the* *Editor*. I think I tried THE editor, but it's been a while: 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. Why look for an Emacs mode to edit JCL if you're using THE? :-) -- Kevin Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
|
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
|
Marco Antoniotti
Jeremy Nicoll
Jeff Bassett