Re: CLIST and TEST subcommands
Roops,
You can
try using the Acetest application that comes with ISPF. It is
documented in the ISPF .DOC file.
It is
just so much better than TSO Test - especially when using it in
fullscreen mode under ISPF.
Wally
?
On 11/17/24 12:48 PM, Rupert Reynolds
via groups.io wrote:
toggle quoted message
Show quoted text
With a few MVS/ESA and /XA systems I used CLISTs
under TEST (because CLIST could process the results of TEST
subcommands). One command displayed PSW, disassembly, regs.
Under TK5 I've tried to do the same thing, and
my CLIST library is allocated to SYSPROC, but TEST doesn't
execute them.
Is there something I need to configure, please?
Roops
|
Re: CLIST and TEST subcommands
Follow up: I just tried explicitly using the EXEC subcommand under TEST, and that gives IKJ57021I INVALID COMMAND+
which seems to mean that EXEC needs to be defined to TEST. It could even be what stops implicit EXEC, as well.
Roops
On Sun, 17 Nov 2024, 11:48 Rupert Reynolds via , <rupertreynolds= [email protected]> wrote: With a few MVS/ESA and /XA systems I used CLISTs under TEST (because CLIST could process the results of TEST subcommands). One command displayed PSW, disassembly, regs.
Under TK5 I've tried to do the same thing, and my CLIST library is allocated to SYSPROC, but TEST doesn't execute them.
Is there something I need to configure, please?
Roops
|
CLIST and TEST subcommands
With a few MVS/ESA and /XA systems I used CLISTs under TEST (because CLIST could process the results of TEST subcommands). One command displayed PSW, disassembly, regs.
Under TK5 I've tried to do the same thing, and my CLIST library is allocated to SYSPROC, but TEST doesn't execute them.
Is there something I need to configure, please?
Roops
|
Re: Understanding PDS in MVS 3.8
Please find attached png file. This is how it looks in hex editor.
Why so many free space at the end?
|
Re: Understanding PDS in MVS 3.8
LaddievHsnus,
?
Please, do not mislead others. This question WAS NOT ANSWERED.
We are talking about free space at the end of PDS allocated space
80 x 31 = 2480 bytes. It is continuous space and it is empty. Interblock gap cannot be this big.
Please re-read the question, and re-read my previous answer, where i have added a picture.
?
Also 256 bytes is a directory block, not a data block.
Here is the quote from message you pointed to:
"Concerning PDS Files the directory was designed with 256 data byte and a key of 8 bytes containing the key of the last entry in the block. "
?
Best wishes,
Andre
|
Re: Re-create NJE38 Spool
This IDCAMS config fixed my problem: DELETE WORK00 - SPACE FORCE - CAT(SYS1.UCAT.TSO) Thanks to all who offered suggestions, you at least put me on the right track. On Sat, 2024-11-16 at 18:00 -0500, Daniel L. Srebnick via groups.io wrote: When I run this:
//IDCDEL?? JOB? CLASS=A,MSGLEVEL=(1,1),MSGCLASS=X
//STEP1??? EXEC PGM=IDCAMS???????????????????????
//WORK04?? DD?? VOL=SER=WORK04,UNIT=SYSDA,DISP=SHR
//SYSPRINT DD?? SYSOUT=*?????????????????????????
//SYSIN??? DD?? *????????????????????????????????
? DELETE WORK04 SPACE CATALOG(SYS1.UCAT.TSO)??
/*???????????????????????????????????????????????
I see this message:
IDCAMS? SYSTEM SERVICES??????????????????????????????????????????
TIME:
?????????????????????????????????????????????????????????????????????
??
???? DELETE WORK04 SPACE CATALOG(SYS1.UCAT.TSO)??????????????????????
IDC3021I USER VOLUME NOT MOUNTED?????????????????????????????????????
IDC3009I ** VSAM CATALOG RETURN CODE IS 72 - REASON CODE IS IGG0CLBL-
59
IDC0551I **ENTRY WORK04 NOT DELETED??????????????????????????????????
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8????????????
?????????????????????????????????????????????????????????????????????
??
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 8????
However, WORK04 is indeed mounted:
UNIT TYPE STATUS? VOLSER VOLSTATE??
294? 3390 O?????? WORK04? PUB/RSDNT
Perhaps I misunderstand the error?
From the USER CATALOG listing: VOLUME -------- WORK04???????????????????????????????????????????????
???? HISTORY?????????????????????????????????????????????????????????
?????? RELEASE----------------2??????????????????????????????????????
???? CHARACTERISTICS?????????????????????????????????????????????????
?????? BYTES/TRK----------58786???? DEVTYPE------X'3010200F'???? MAX-
PHYREC-SZ------32760???? DATASETS-ON-VOL--------0?
?????? TRKS/CYL--------------15???? VOLUME-TIMESTAMP:??????????? MAX-
EXT/ALLOC----------5???? DATASPCS-ON-VOL--------0?
?????? CYLS/VOL------------1113????????? X'E00075720C9B9001'?????????
I assume it is this entry above that we're trying to delete.
On Sat, 2024-11-16 at 11:18 -0800, Rob Prins via groups.io wrote:
WORK04 (as well as WORK00) seems to be owned by SYS1.UCAT.TSO.
? That tells, there was a previous DEFINE of a VSAM object on
WORK04.
Please check the catalog and the VTOC of WORK04.
In the original distribution of MVS-TK5, all the WORKxx
volumes are not owned by any catalog.
?
You can try to delete the volume record of WORK04.
You use the JCL provided by Bob Polmanter and use the
following IDCAMS control statement.
Be sure there are no other VSAM objects on WORK04.
?
DELETE WORK04 SPACE CATALOG(SYS1.UCAT.TSO)
?
Cheers,
Rob
?
|
Re: Understanding PDS in MVS 3.8
It was explained in this post from November 4th ?? The interblock gap (big)?is what is taking the space. I don’t remember how big it is on a 3390. A sequential data set only has them between each data block. A pds has 256 byte blocks with a gap between each block. Then there is one block that makes end of file of the directory. The number of directory blocks is set when the dataset is allocated.?
The gap is not data just reserved by the disk drive and the control unit.
LaddievHsnus
On Saturday, November 16, 2024, 1:56 PM, Sergio via groups.io <sergiolindo.empresa@...> wrote: Hi Andre,
I haven’t found the reason. I still don’t know the cause.
Kind Regards --
Sergio Lindo Mansilla
Software developer with DevOps?tendencies
Portfolio:?https://binary-sequence.github.io/ El 16.11.2024, a las 20:34, Andre via groups.io <procritic@...> escribió:
Sergio,
?
It looks like only i was able to reproduce your problem, and understand what you were talking about.
I confirm that when PS dataset is created it is possible to use whole allocated space and add 698 lines of text to it,
but when PO(PDS) dataset is used, somehow there is lots of free space left, even more if number of members increased.
It is visible with hex editor, and i was looking for explanation everywhere. No one really knows why, and it is NOT documented.
As you have pointed out, with only one member it is the space for almost 31 full lines of text at the end of dataset - completely empty.
Did you find any information about cause of it?
?
Best wishes,
Andre
|
Re: Re-create NJE38 Spool
When I run this:
//IDCDEL JOB CLASS=A,MSGLEVEL=(1,1),MSGCLASS=X
//STEP1 EXEC PGM=IDCAMS
//WORK04 DD VOL=SER=WORK04,UNIT=SYSDA,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
? DELETE WORK04 SPACE CATALOG(SYS1.UCAT.TSO)
/*
I see this message:
IDCAMS SYSTEM SERVICES TIME:
DELETE WORK04 SPACE CATALOG(SYS1.UCAT.TSO)
IDC3021I USER VOLUME NOT MOUNTED
IDC3009I ** VSAM CATALOG RETURN CODE IS 72 - REASON CODE IS IGG0CLBL-59
IDC0551I **ENTRY WORK04 NOT DELETED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 8
However, WORK04 is indeed mounted:
UNIT TYPE STATUS VOLSER VOLSTATE
294 3390 O WORK04 PUB/RSDNT
Perhaps I misunderstand the error?
From the USER CATALOG listing:
VOLUME -------- WORK04
HISTORY
RELEASE----------------2
CHARACTERISTICS
BYTES/TRK----------58786 DEVTYPE------X'3010200F' MAX-
PHYREC-SZ------32760 DATASETS-ON-VOL--------0?
TRKS/CYL--------------15 VOLUME-TIMESTAMP: MAX-
EXT/ALLOC----------5 DATASPCS-ON-VOL--------0?
CYLS/VOL------------1113 X'E00075720C9B9001'
I assume it is this entry above that we're trying to delete.
toggle quoted message
Show quoted text
On Sat, 2024-11-16 at 11:18 -0800, Rob Prins via groups.io wrote: WORK04 (as well as WORK00) seems to be owned by SYS1.UCAT.TSO.
? That tells, there was a previous DEFINE of a VSAM object on
WORK04.
Please check the catalog and the VTOC of WORK04.
In the original distribution of MVS-TK5, all the WORKxx
volumes are not owned by any catalog.
?
You can try to delete the volume record of WORK04.
You use the JCL provided by Bob Polmanter and use the
following IDCAMS control statement.
Be sure there are no other VSAM objects on WORK04.
?
DELETE WORK04 SPACE CATALOG(SYS1.UCAT.TSO)
?
Cheers,
Rob
?
|
Re: Understanding PDS in MVS 3.8
Hi Andre,
I haven’t found the reason. I still don’t know the cause.
Kind Regards --
Sergio Lindo Mansilla
Software developer with DevOps?tendencies
Portfolio:?https://binary-sequence.github.io/
toggle quoted message
Show quoted text
El 16.11.2024, a las 20:34, Andre via groups.io <procritic@...> escribió:
Sergio,
?
It looks like only i was able to reproduce your problem, and understand what you were talking about.
I confirm that when PS dataset is created it is possible to use whole allocated space and add 698 lines of text to it,
but when PO(PDS) dataset is used, somehow there is lots of free space left, even more if number of members increased.
It is visible with hex editor, and i was looking for explanation everywhere. No one really knows why, and it is NOT documented.
As you have pointed out, with only one member it is the space for almost 31 full lines of text at the end of dataset - completely empty.
Did you find any information about cause of it?
?
Best wishes,
Andre
|
Re: Understanding PDS in MVS 3.8
Sergio,
?
It looks like only i was able to reproduce your problem, and understand what you were talking about.
I confirm that when PS dataset is created it is possible to use whole allocated space and add 698 lines of text to it,
but when PO(PDS) dataset is used, somehow there is lots of free space left, even more if number of members increased.
It is visible with hex editor, and i was looking for explanation everywhere. No one really knows why, and it is NOT documented.
As you have pointed out, with only one member it is the space for almost 31 full lines of text at the end of dataset - completely empty.
Did you find any information about cause of it?
?
Best wishes,
Andre
|
Re: Re-create NJE38 Spool
WORK04 (as well as WORK00) seems to be owned by SYS1.UCAT.TSO.
?
That tells, there was a previous DEFINE of a VSAM object on
WORK04.
Please check the catalog and the VTOC of WORK04.
In the original distribution of MVS-TK5, all the WORKxx
volumes are not owned by any catalog.
?
You can try to delete the volume record of WORK04.
You use the JCL provided by Bob Polmanter and use the
following IDCAMS control statement.
Be sure there are no other VSAM objects on WORK04.
?
DELETE WORK04 SPACE CATALOG(SYS1.UCAT.TSO)
?
Cheers,
Rob
?
|
Re: Re-create NJE38 Spool
Daniel,
?
I was able to create the dataset on WORK04 with no issues.? But of course, I have not gone through whatever reorganization that you performed.? Im using TK5 update 3.? See below:
?
IDCAMS ?SYSTEM SERVICES ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? DEF CL ( ?NAME( NJE38.NETXXXXX ) - ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? RECSZ(4089,4089) - ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? CYL(100) - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? NUMBERED - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? CISZ(4096) - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? SHR(4 4) - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? FILE( WORK04 ) - ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? VOLUMES( WORK04)) - ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? DATA ( ?NAME( NJE38.NETXXXXX.DATA ) - ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? UNIQUE ) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
IDC0508I DATA ALLOCATION STATUS FOR VOLUME WORK04 IS 0 ? ? ? ? ??
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
?
This is the JCL that I used:
//TEMP ? ? EXEC PGM=IDCAMS ? ? ? ? ? ? ? ? ? ? ? ?
//WORK04 ? DD VOL=SER=WORK04, ? ? ? ? ? ? ? ? ? ??
// ? ? ? ? ? ?UNIT=SYSDA, ? ? ? ? ? ? ? ? ? ? ? ??
// ? ? ? ? ? ?DISP=SHR ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//SYSPRINT DD SYSOUT=* ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//SYSIN ? ?DD * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
I changed the name of the dataset because I already have a NJE38.NETSPOOL on another volume.
?
For what its worth....
?
Regards,
Bob
|
Re: Re-create NJE38 Spool
WORK04 (as well as WORK00) seems to be owned by SYS1.UCAT.TSO.
I see no existing entry for NJE38.NETSPOOL.
Do I need to tell IDCAMS to use SYS1.UCAT.TSO?
On Sat, 2024-11-16 at 09:07 -0800, Rob Prins via groups.io wrote: [Edited Message Follows] Hi Dani?l, ? Possibly WORK04 belongs to another catalog. Please check the other catalogs in your system. ? That can be done with an IDCAMS job with control statement. LISTCAT CAT('catalog name') SPACE ? Run this job for every catalog you have. If you have found the right catalog, check if there are VSAM objects allocated on that volume. ? Cheers, Rob ? BTW: the alias points to the right catalog (I assume you are running MVS-TK5).
|
Re: Re-create NJE38 Spool
Hi Dani?l,
?
Possibly WORK04 belongs to another catalog.
Please check the other catalogs in your system.
?
That can be done with an IDCAMS job with control statement.
LISTCAT CAT('catalog name') SPACE
?
Run this job for every catalog you have.
If you have found the right catalog, check if there are VSAM objects allocated on that volume.
?
Cheers,
Rob
?
BTW: the alias points to the right catalog (I assume you are running MVS-TK5).
|
Re: Re-create NJE38 Spool
The alias for NJE38 in TK5 is defined as:
DEF ALIAS(NAME('NJE38') REL('SYS1.UCAT.TSO'))
I'm a VSAM novice...how would I go about fixing what I broke here. I
mean I could just go back to the distributed volumes, but that would be
no fun and I'd learn nothing!
Thanks for any advice.
toggle quoted message
Show quoted text
On Sat, 2024-11-16 at 10:07 -0600, Mike Schwab via groups.io wrote: Wrong catalog.? All VSAM datasets on a volume must be in the same
VSAM
catalog.? Corrected with ICF catalogs.
On Sat, Nov 16, 2024 at 9:12?AM Daniel L. Srebnick via groups.io
<dan@...> wrote:
I reorganized the work packs on my TK5 system and am now trying to
re-create the NJE38 spool.
Oddly, I can create and remove it just fine on a TSO pack, but it
failed to create on a WORK pack.
Here's what JOB0010 is telling me:
IDCAMS? SYSTEM SERVICES??????????????????????????????????????????
TIME:
????????? DEF CL (? NAME( NJE38.NETSPOOL )?????????? /* <== VERIFY
*/ -
???????????????????
RECSZ(4089,4089)????????????????????????????????? -
??????????????????? CYL(50)????????????????????????? /* <== VERIFY
*/ -
???????????????????
NUMBERED????????????????????????????????????????? -
???????????????????
CISZ(4096)??????????????????????????????????????? -
??????????????????? SHR(4
4)????????????????????????????????????????? -
??????????????????? FILE( SPLVOL
)??????????????????????????????????? -
??????????????????? VOLUMES( WORK04))??????????????? /* <== VERIFY
*/ -
??????????? DATA (? NAME( NJE38.NETSPOOL.DATA )????? /* <== VERIFY
*/ -
??????????????????? UNIQUE )
IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 106 - REASON CODE IS
IGG0CLAQ-4
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12
What am I getting wrong?
|
Re: Re-create NJE38 Spool
Wrong catalog. All VSAM datasets on a volume must be in the same VSAM catalog. Corrected with ICF catalogs. On Sat, Nov 16, 2024 at 9:12?AM Daniel L. Srebnick via groups.io <dan@...> wrote:
I reorganized the work packs on my TK5 system and am now trying to re-create the NJE38 spool.
Oddly, I can create and remove it just fine on a TSO pack, but it failed to create on a WORK pack.
Here's what JOB0010 is telling me:
IDCAMS SYSTEM SERVICES TIME:
DEF CL ( NAME( NJE38.NETSPOOL ) /* <== VERIFY */ -
RECSZ(4089,4089) -
CYL(50) /* <== VERIFY */ -
NUMBERED -
CISZ(4096) -
SHR(4 4) -
FILE( SPLVOL ) -
VOLUMES( WORK04)) /* <== VERIFY */ -
DATA ( NAME( NJE38.NETSPOOL.DATA ) /* <== VERIFY */ -
UNIQUE )
IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 106 - REASON CODE IS IGG0CLAQ-4
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12
What am I getting wrong?
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all?
|
I reorganized the work packs on my TK5 system and am now trying to re-create the NJE38 spool.
?
Oddly, I can create and remove it just fine on a TSO pack, but it failed to create on a WORK pack.
?
Here's what JOB0010 is telling me:
?
IDCAMS ?SYSTEM SERVICES ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TIME:
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? DEF CL ( ?NAME( NJE38.NETSPOOL ) ? ? ? ? ? /* <== VERIFY */ -
? ? ? ? ? ? ? ? ? ? RECSZ(4089,4089) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-
? ? ? ? ? ? ? ? ? ? CYL(50) ? ? ? ? ? ? ? ? ? ? ? ? ?/* <== VERIFY */ -
? ? ? ? ? ? ? ? ? ? NUMBERED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-
? ? ? ? ? ? ? ? ? ? CISZ(4096) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-
? ? ? ? ? ? ? ? ? ? SHR(4 4) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-
? ? ? ? ? ? ? ? ? ? FILE( SPLVOL ) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-
? ? ? ? ? ? ? ? ? ? VOLUMES( WORK04)) ? ? ? ? ? ? ? ?/* <== VERIFY */ -
? ? ? ? ? ? DATA ( ?NAME( NJE38.NETSPOOL.DATA ) ? ? ?/* <== VERIFY */ -
? ? ? ? ? ? ? ? ? ? UNIQUE ) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
IDC3014I CATALOG ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
IDC3009I ** VSAM CATALOG RETURN CODE IS 106 - REASON CODE IS IGG0CLAQ-4
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12 ? ??
?
What am I getting wrong?
?
|
Re: Understanding PDS in MVS 3.8
Hi Joe,
?
Thanks for the illustration.
Just to make it clear. A Count field in a CKD device is always there by architecture and contains as I wrote CCHHRKLL. In detail the Cylinder, Head, Record, key length and data length.
This holds true for whatever block you write.? The key field is optional. You find block with keys in VTOC (44 byte DSN), PDS Directory (8-byte Member Name), ISAM Files and keyed DAM files.
?
Silvio
?
?
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Joe Monk
Sent: Monday, 4 November 2024 17:08
To: [email protected]
Subject: Re: [H390-MVS] Understanding PDS in MVS 3.8
?
" To summarize: A directory block consists of a 8-byte Count field, a 8-byte key field and a 256-byte data field."
As you can see, the DASD count field is unused. The key field contains the name of the last entry in this directory block. The reason the count field is unused is that all TTRs in a PDS are relative, so that a PDS can be moved without having
to re-calc all of the TTRs in the directory. The PDS directory count field (first 2 bytes of the entry) specify the length?of this directory block.
So, you search the keys (the FIND macro) until you come to the correct directory block. Then you read and process the directory block to locate the TTR of the member. Since you should know the LRECL and BLKSIZE from the DCB, you can get the next TTR, and do
the arithmetic?to tell you how many tracks you need to read to get the member data. (TTR of first record of this member, subtracted from TTR of the first record of next member, will give you the number of tracks to read).? ?
The PDS is described by macro IHAPDS.
?
On Mon, Nov 4, 2024 at 7:04?AM Silvio Losa via
<silvio.losa=[email protected]> wrote:
Dear all,
?
Let’s go back to the 60s where the CKD DASD Devices were developed. At that time a lot of constraints existed, especially concerning main storage. Supervisor
functions had to work in a couple of hundred bytes, no space was available to read blocks of 4K or even more into storage.
Concerning PDS Files the directory was designed with 256 data byte and a key of 8 bytes containing the key of the last entry in the block. (Note that a directory
is always in alphabetical order. New members are ‘stowed’ in the corresponding place). Key and data area headed by a count field of 8 bytes with CCHHRKLL where K is key length and LL the data length. To summarize: A directory block consists of a 8-byte Count
field, a 8-byte key field and a 256-byte data field.
?
Now jump into a simplified channel program to locate the correct directory block:
CCW 1: Search key equal or high
CCW 2: TIC *-8
CCW 3: Read Data
?
The first command compares the key given by the program with the key read from disk, if the key from disk is lower, the channel continues with the next command
which is a branch back to the first command (TIC = Transfer in channel). But if the key is equal or high the channel skips the next command and executes the third command to read the data.
Now this all happens in real time while the read head ‘travels’ over the CKD fields on the disk. The channels electronics takes some microseconds to take this
decision after receiving the key. Keep in mind that the read head is now just behind the key area. To give the channel a chance to react accordingly a space is necessary between key and data so that when CCW 3 is sent to the device the read head is still before
the data field so that the data can be read in.
With this simple channel program and multitrack operation, it’s possible to search for the correct block in a PDS directory who has the size of one cylinder with
one channel program.
?
So the “gaps” between the CKD field had to be big enough for slowest CPU where the Disk Model was supposed to be attachable.
?
Bottom line: The shorter you make the blocks and if maybe you add keys the less data can be
stored on a track due to this ‘gaps’ that were necessary with this design and constraints.
?
Best,
Silvio
?
?
?
?
?
?
It is not that easy to see what Sergio is asking about, so i made a visualization.
When PDS has only one member with size of one track, oddly enough there is some space left at the end.
What its purpose remains unknown...
|
Re: Understanding PDS in MVS 3.8
"
To summarize: A directory block consists of a 8-byte Count field, a 8-byte key field and a 256-byte data field." 
As you can see, the DASD count field is unused. The key field contains the name of the last entry in this directory block. The reason the count field is unused is that all TTRs in a PDS are relative, so that a PDS can be moved without having to re-calc all of the TTRs in the directory. The PDS directory count field (first 2 bytes of the entry) specify the length?of this directory block. 
So, you search the keys (the FIND macro) until you come to the correct directory block. Then you read and process the directory block to locate the TTR of the member. Since you should know the LRECL and BLKSIZE from the DCB, you can get the next TTR, and do the arithmetic?to tell you how many tracks you need to read to get the member data. (TTR of first record of this member, subtracted from TTR of the first record of next member, will give you the number of tracks to read).? ?
The PDS is described by macro IHAPDS.
Joe
On Mon, Nov 4, 2024 at 7:04?AM Silvio Losa via <silvio.losa= [email protected]> wrote:
Dear all,
?
Let’s go back to the 60s where the CKD DASD Devices were developed. At that time a lot of constraints existed, especially concerning main storage. Supervisor functions had to work in
a couple of hundred bytes, no space was available to read blocks of 4K or even more into storage.
Concerning PDS Files the directory was designed with 256 data byte and a key of 8 bytes containing the key of the last entry in the block. (Note that a directory is always in alphabetical
order. New members are ‘stowed’ in the corresponding place). Key and data area headed by a count field of 8 bytes with CCHHRKLL where K is key length and LL the data length. To summarize: A directory block consists of a 8-byte Count field, a 8-byte key field
and a 256-byte data field.
?
Now jump into a simplified channel program to locate the correct directory block:
CCW 1: Search key equal or high
CCW 2: TIC *-8
CCW 3: Read Data
?
The first command compares the key given by the program with the key read from disk, if the key from disk is lower, the channel continues with the next command which is a branch back
to the first command (TIC = Transfer in channel). But if the key is equal or high the channel skips the next command and executes the third command to read the data.
Now this all happens in real time while the read head ‘travels’ over the CKD fields on the disk. The channels electronics takes some microseconds to take this decision after receiving
the key. Keep in mind that the read head is now just behind the key area. To give the channel a chance to react accordingly a space is necessary between key and data so that when CCW 3 is sent to the device the read head is still before the data field so that
the data can be read in.
With this simple channel program and multitrack operation, it’s possible to search for the correct block in a PDS directory who has the size of one cylinder with one channel program.
?
So the “gaps” between the CKD field had to be big enough for slowest CPU where the Disk Model was supposed to be attachable.
?
Bottom line: The shorter you make the blocks and if maybe you add keys the less data can be
stored on a track due to this ‘gaps’ that were necessary with this design and constraints.
?
Best,
Silvio
?
?
?
?
?
?
It is not that easy to see what Sergio is asking about, so i made a visualization.
When PDS has only one member with size of one track, oddly enough there is some space left at the end.
What its purpose remains unknown...
|
Re: Understanding PDS in MVS 3.8
Dear all,
?
Let’s go back to the 60s where the CKD DASD Devices were developed. At that time a lot of constraints existed, especially concerning main storage. Supervisor functions had to work in
a couple of hundred bytes, no space was available to read blocks of 4K or even more into storage.
Concerning PDS Files the directory was designed with 256 data byte and a key of 8 bytes containing the key of the last entry in the block. (Note that a directory is always in alphabetical
order. New members are ‘stowed’ in the corresponding place). Key and data area headed by a count field of 8 bytes with CCHHRKLL where K is key length and LL the data length. To summarize: A directory block consists of a 8-byte Count field, a 8-byte key field
and a 256-byte data field.
?
Now jump into a simplified channel program to locate the correct directory block:
CCW 1: Search key equal or high
CCW 2: TIC *-8
CCW 3: Read Data
?
The first command compares the key given by the program with the key read from disk, if the key from disk is lower, the channel continues with the next command which is a branch back
to the first command (TIC = Transfer in channel). But if the key is equal or high the channel skips the next command and executes the third command to read the data.
Now this all happens in real time while the read head ‘travels’ over the CKD fields on the disk. The channels electronics takes some microseconds to take this decision after receiving
the key. Keep in mind that the read head is now just behind the key area. To give the channel a chance to react accordingly a space is necessary between key and data so that when CCW 3 is sent to the device the read head is still before the data field so that
the data can be read in.
With this simple channel program and multitrack operation, it’s possible to search for the correct block in a PDS directory who has the size of one cylinder with one channel program.
?
So the “gaps” between the CKD field had to be big enough for slowest CPU where the Disk Model was supposed to be attachable.
?
Bottom line: The shorter you make the blocks and if maybe you add keys the less data can be
stored on a track due to this ‘gaps’ that were necessary with this design and constraints.
?
Best,
Silvio
?
?
?
?
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Andre via groups.io
Sent: Monday, 4 November 2024 12:55
To: [email protected]
Subject: Re: [H390-MVS] Understanding PDS in MVS 3.8
?
It is not that easy to see what Sergio is asking about, so i made a visualization.
When PDS has only one member with size of one track, oddly enough there is some space left at the end.
What its purpose remains unknown...
|
Rob Prins
Silvio Losa