Discussion:
Count with no Data and no Key ? (CKD internals again)
(too old to reply)
R.S.
2018-02-22 13:16:11 UTC
Permalink
Is it allowed in CKD to have Count only in a physical record?
I mean Count field with zero-length Data (and zero-length Key).
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Christopher Y. Blaicher
2018-02-22 13:30:45 UTC
Permalink
You can have a zero length key and data, it is called an End Of File (EOF) marker.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627-3803
E: ***@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: Thursday, February 22, 2018 8:17 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Count with no Data and no Key ? (CKD internals again)

Is it allowed in CKD to have Count only in a physical record?
I mean Count field with zero-length Data (and zero-length Key).

--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

________________________________



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-02-22 15:11:21 UTC
Permalink
Zero data count is an EOF regardless of the key length.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Christopher Y. Blaicher <***@SYNCSORT.COM>
Sent: Thursday, February 22, 2018 8:32 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Count with no Data and no Key ? (CKD internals again)

You can have a zero length key and data, it is called an End Of File (EOF) marker.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627-3803
E: ***@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1kn9JOamxUjZYRhUd8ebWJpFiYn5pIy-l-4FS30Rre1jykcnuwhoH9C793p67vTEubxowjGG29Io7nBEJxPsytUkNv-mqDTneHgjLC4e7v8Mg9GOdXZ-nfNu17wNBD5XfGMQJZJaJY84jbGPbxGoFsyK0zJ-9IeHb-yhX0nWz36gjfdNgWuQbda4YLyUYh2xGSINRxX5pQhJBOeHMLc5oGP7vOnw7H8T4q7OEt7DGoz2BTf2ImKmRX3YDG412UVKTGr-WmjdCaunsH9pFoLQvxVKxTunXIGEWPEzrLC0yUDkmNdjg--pEXAOFfNM00MKP7OKB6AFCv3_t0mUKssMc1sRsvHShhY69GqiBTY4_swYkMrsI7OySLp4XcsafZOsh/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: Thursday, February 22, 2018 8:17 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Count with no Data and no Key ? (CKD internals again)

Is it allowed in CKD to have Count only in a physical record?
I mean Count field with zero-length Data (and zero-length Key).

--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, http://secure-web.cisco.com/1Bp5M43ZWroZULmxHmQR3irmdowwWpHz3H6SEB9aUxCHW9GBG9MVIbdzpFq3oOOK9lphvb7yYs-IRY3JysJxwDbA9qx_NyboRuUMPtmaZB5NQSDOIBIg_eaiJ_udFYFW6vd9k6zmbORubNHuPS4UZgB7Tkss4AWkl0D7tskqmn0qxEbmmbLDgCMUBh3gIIdSp-ydkltU1GfImT3Sfew9kfjNUJwulL8eH_xElCxaewnb_VE7fp8sRWSr9wos_GKs1_NN-vdaHIXjLivhRd8OR_eHi_S48JMVI3HfP4B_tehbyS9CV8mi96DgK89xEy67HdTnaDS1dnlpd58wcisZDweQRz6vUGfDri0S74QetZJw/http%3A%2F%2Fwww.mBank.pl%2C%20e-mail%3A%20kontakt%40mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

________________________________



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-02-22 15:50:30 UTC
Permalink
I just found that in PDS every (?) data record is interleaved with null
record (count, no key, no data).
More precisely: null record is at the end of directory and between all
member records, even for members occupying several records.

So PDS contains multiple EOFs, even more than one EOF per member. ;-)

Note: the above are physical records, not logical ones.
--
Radoslaw Skorupka
Lodz, Poland
Post by Seymour J Metz
Zero data count is an EOF regardless of the key length.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Thursday, February 22, 2018 8:32 AM
Subject: Re: Count with no Data and no Key ? (CKD internals again)
You can have a zero length key and data, it is called an End Of File (EOF) marker.
Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627-3803
Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1kn9JOamxUjZYRhUd8ebWJpFiYn5pIy-l-4FS30Rre1jykcnuwhoH9C793p67vTEubxowjGG29Io7nBEJxPsytUkNv-mqDTneHgjLC4e7v8Mg9GOdXZ-nfNu17wNBD5XfGMQJZJaJY84jbGPbxGoFsyK0zJ-9IeHb-yhX0nWz36gjfdNgWuQbda4YLyUYh2xGSINRxX5pQhJBOeHMLc5oGP7vOnw7H8T4q7OEt7DGoz2BTf2ImKmRX3YDG412UVKTGr-WmjdCaunsH9pFoLQvxVKxTunXIGEWPEzrLC0yUDkmNdjg--pEXAOFfNM00MKP7OKB6AFCv3_t0mUKssMc1sRsvHShhY69GqiBTY4_swYkMrsI7OySLp4XcsafZOsh/http%3A%2F%2Fwww.syncsort.com
Data quality leader Trillium Software is now a part of Syncsort.
-----Original Message-----
Sent: Thursday, February 22, 2018 8:17 AM
Subject: Count with no Data and no Key ? (CKD internals again)
Is it allowed in CKD to have Count only in a physical record?
I mean Count field with zero-length Data (and zero-length Key).
--
Radoslaw Skorupka
Lodz, Poland
======================================================================
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, http://secure-web.cisco.com/1Bp5M43ZWroZULmxHmQR3irmdowwWpHz3H6SEB9aUxCHW9GBG9MVIbdzpFq3oOOK9lphvb7yYs-IRY3JysJxwDbA9qx_NyboRuUMPtmaZB5NQSDOIBIg_eaiJ_udFYFW6vd9k6zmbORubNHuPS4UZgB7Tkss4AWkl0D7tskqmn0qxEbmmbLDgCMUBh3gIIdSp-ydkltU1GfImT3Sfew9kfjNUJwulL8eH_xElCxaewnb_VE7fp8sRWSr9wos_GKs1_NN-vdaHIXjLivhRd8OR_eHi_S48JMVI3HfP4B_tehbyS9CV8mi96DgK89xEy67HdTnaDS1dnlpd58wcisZDweQRz6vUGfDri0S74QetZJw/http%3A%2F%2Fwww.mBank.pl%2C%20e-mail%3A%20kontakt%40mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
________________________________
ATTENTION: -----
The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-02-22 15:54:31 UTC
Permalink
I seriously doubt that; it would generate a Unit Exception trying to read the second record of the member. You're clearly misinterpreting something.

There is a EOF after the directory and an EOF after each member. There is no EOF in the middle of a member.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of R.S. <***@BREMULTIBANK.COM.PL>
Sent: Thursday, February 22, 2018 10:51 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Count with no Data and no Key ? (CKD internals again)

I just found that in PDS every (?) data record is interleaved with null
record (count, no key, no data).
More precisely: null record is at the end of directory and between all
member records, even for members occupying several records.

So PDS contains multiple EOFs, even more than one EOF per member. ;-)

Note: the above are physical records, not logical ones.


--
Radoslaw Skorupka
Lodz, Poland
Post by Seymour J Metz
Zero data count is an EOF regardless of the key length.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Thursday, February 22, 2018 8:32 AM
Subject: Re: Count with no Data and no Key ? (CKD internals again)
You can have a zero length key and data, it is called an End Of File (EOF) marker.
Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627-3803
Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1kn9JOamxUjZYRhUd8ebWJpFiYn5pIy-l-4FS30Rre1jykcnuwhoH9C793p67vTEubxowjGG29Io7nBEJxPsytUkNv-mqDTneHgjLC4e7v8Mg9GOdXZ-nfNu17wNBD5XfGMQJZJaJY84jbGPbxGoFsyK0zJ-9IeHb-yhX0nWz36gjfdNgWuQbda4YLyUYh2xGSINRxX5pQhJBOeHMLc5oGP7vOnw7H8T4q7OEt7DGoz2BTf2ImKmRX3YDG412UVKTGr-WmjdCaunsH9pFoLQvxVKxTunXIGEWPEzrLC0yUDkmNdjg--pEXAOFfNM00MKP7OKB6AFCv3_t0mUKssMc1sRsvHShhY69GqiBTY4_swYkMrsI7OySLp4XcsafZOsh/http%3A%2F%2Fwww.syncsort.com
Data quality leader Trillium Software is now a part of Syncsort.
-----Original Message-----
Sent: Thursday, February 22, 2018 8:17 AM
Subject: Count with no Data and no Key ? (CKD internals again)
Is it allowed in CKD to have Count only in a physical record?
I mean Count field with zero-length Data (and zero-length Key).
--
Radoslaw Skorupka
Lodz, Poland
======================================================================
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, http://secure-web.cisco.com/1Bp5M43ZWroZULmxHmQR3irmdowwWpHz3H6SEB9aUxCHW9GBG9MVIbdzpFq3oOOK9lphvb7yYs-IRY3JysJxwDbA9qx_NyboRuUMPtmaZB5NQSDOIBIg_eaiJ_udFYFW6vd9k6zmbORubNHuPS4UZgB7Tkss4AWkl0D7tskqmn0qxEbmmbLDgCMUBh3gIIdSp-ydkltU1GfImT3Sfew9kfjNUJwulL8eH_xElCxaewnb_VE7fp8sRWSr9wos_GKs1_NN-vdaHIXjLivhRd8OR_eHi_S48JMVI3HfP4B_tehbyS9CV8mi96DgK89xEy67HdTnaDS1dnlpd58wcisZDweQRz6vUGfDri0S74QetZJw/http%3A%2F%2Fwww.mBank.pl%2C%20e-mail%3A%20kontakt%40mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
________________________________
ATTENTION: -----
The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, http://secure-web.cisco.com/1mvdDMrZluZYgkbKYwg9pyqzH8UJo6EKsNyaA1u9ySA8rePbros9bt0hKfe2L9Yp9MsslVIx1PVKOKGT7O4KI8xd9cBysELgHtoEx4nkMnVTTLadsw7zFzWuwiloCKcAXKfNJuhGQsOJ5xqyR2bFqU6Wx6qFEPyXrO2_kdxd9Ew2SnaPxZ3pdaGDHAg8TTxGNaq8zqn6isoKgpTb3KJs3fg_LGhiaTAATOgD2AD76XUeER-rK2_6nqsWS5thsjIIwcYKvpYmuQtmMkYKcAjihZ-1uoENb04_b1JdwY-PDgfcMjMLKh8rWhdZHhYnYtsb-WWCOjUcMxFF-i8iroEH4TftGBOY-2c7hfipJbwiUnC4/http%3A%2F%2Fwww.mBank.pl%2C%20e-mail%3A%20kontakt%40mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-02-22 21:24:36 UTC
Permalink
Post by Seymour J Metz
I seriously doubt that; it would generate a Unit Exception trying to read the second record of the member. You're clearly misinterpreting something.
There is a EOF after the directory and an EOF after each member. There is no EOF in the middle of a member.
Makes sense.

Now, just curious, what about a block with a data length of 4, where the data
are a BDW with a count of 4?

Also, just curious, I understand that on tape a block <18 (? still?) is bypassed
as a noise record. But it's possible that with RECFM=VB the last block might,
by happenstance, consist of as few as 8 bytes (BDW=8; RDW=4). How do
tape drivers deal with this? Poorly? With RECFM=VBS, a null segment could
be used for padding.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-03-07 19:01:31 UTC
Permalink
1. A BDW with a length field of 4 would give you a DASD record with KL=0, DL=4,
which does not generate a UE.

2. I haven't looked at the code for anything newer than 3420 GCR (6250 BPI),
and have never tried it on 3480 or later, but I would expect wonky results for short blocks. I don't recall what the SMF
dump utilities do about this.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Thursday, February 22, 2018 4:25 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Count with no Data and no Key ? (CKD internals again)
Post by Seymour J Metz
I seriously doubt that; it would generate a Unit Exception trying to read the second record of the member. You're clearly misinterpreting something.
There is a EOF after the directory and an EOF after each member. There is no EOF in the middle of a member.
Makes sense.

Now, just curious, what about a block with a data length of 4, where the data
are a BDW with a count of 4?

Also, just curious, I understand that on tape a block <18 (? still?) is bypassed
as a noise record. But it's possible that with RECFM=VB the last block might,
by happenstance, consist of as few as 8 bytes (BDW=8; RDW=4). How do
tape drivers deal with this? Poorly? With RECFM=VBS, a null segment could
be used for padding.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-02-23 12:31:34 UTC
Permalink
Also, just curious, I understand that on tape a block <18 (? still?) is bypassed as a noise record.
Wow! Interesting! Where is that documented?
But it's possible that with RECFM=VB the last block might, by happenstance, consist of as few as 8 bytes (BDW=8; RDW=4). How do tape drivers deal with this? Poorly? With RECFM=VBS, a null segment could be used for padding.
Now you made me curious. [1] Damn! ;-)

I really hope someone can answer you...

Groete / Greetings
Elardus Engelbrecht

[1] - Currently outside my scope of work, but hey, I worked with that things as a Storage Admin in the prehistoric days. 8-)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-02-23 13:34:21 UTC
Permalink
I don't know internals, but definitely one can use short blocks on DASD,
18B is not a limit. You can use 18 or 5 if you want. Of course the
tracks utilization will be extremely poor, but that's different story.

BTW: I'mt not sure, but it seems the null record inside a member is when
the member span track boundary.
Obviously there are multiple EOFs (null records) inside a PDS.
--
Radoslaw Skorupka
Lodz, Poland
Post by Elardus Engelbrecht
Also, just curious, I understand that on tape a block <18 (? still?) is bypassed as a noise record.
Wow! Interesting! Where is that documented?
But it's possible that with RECFM=VB the last block might, by happenstance, consist of as few as 8 bytes (BDW=8; RDW=4). How do tape drivers deal with this? Poorly? With RECFM=VBS, a null segment could be used for padding.
Now you made me curious. [1] Damn! ;-)
I really hope someone can answer you...
Groete / Greetings
Elardus Engelbrecht
[1] - Currently outside my scope of work, but hey, I worked with that things as a Storage Admin in the prehistoric days. 8-)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Christopher Y. Blaicher
2018-02-23 14:47:50 UTC
Permalink
Radoslaw,
The access methods detect the key=0, count=0 records and process them as EOF, which is how they signify the end of a PDS member. Every member has an EOF record with the rare exception of a member that ends at the end of the track on the last track of a data set. I don't know how that is done for a PDSE as I have never dug into that. I had to deal with EOF when writing EXCP and STARTIO code, but I used BSAM when dealing with PDSE's, there weren't many back when I was doing that. Maybe others can comment on PDSE structure.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627-3803
E: ***@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: Friday, February 23, 2018 8:35 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Count with no Data and no Key ? (CKD internals again)

I don't know internals, but definitely one can use short blocks on DASD, 18B is not a limit. You can use 18 or 5 if you want. Of course the tracks utilization will be extremely poor, but that's different story.

BTW: I'mt not sure, but it seems the null record inside a member is when the member span track boundary.
Obviously there are multiple EOFs (null records) inside a PDS.

--
Radoslaw Skorupka
Lodz, Poland
Post by Elardus Engelbrecht
Also, just curious, I understand that on tape a block <18 (? still?) is bypassed as a noise record.
Wow! Interesting! Where is that documented?
But it's possible that with RECFM=VB the last block might, by happenstance, consist of as few as 8 bytes (BDW=8; RDW=4). How do tape drivers deal with this? Poorly? With RECFM=VBS, a null segment could be used for padding.
Now you made me curious. [1] Damn! ;-)
I really hope someone can answer you...
Groete / Greetings
Elardus Engelbrecht
[1] - Currently outside my scope of work, but hey, I worked with that things as a Storage Admin in the prehistoric days. 8-)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

________________________________



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-02-23 16:28:22 UTC
Permalink
It's actually the DASD controller that detects EOF on a Read Data CCW.

As for PDSE, the dataset is formatted into control intervals and there are data in the dataset used by the access method to delineate logical records and members.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Christopher Y. Blaicher <***@SYNCSORT.COM>
Sent: Friday, February 23, 2018 9:49 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Count with no Data and no Key ? (CKD internals again)

Radoslaw,
The access methods detect the key=0, count=0 records and process them as EOF, which is how they signify the end of a PDS member. Every member has an EOF record with the rare exception of a member that ends at the end of the track on the last track of a data set. I don't know how that is done for a PDSE as I have never dug into that. I had to deal with EOF when writing EXCP and STARTIO code, but I used BSAM when dealing with PDSE's, there weren't many back when I was doing that. Maybe others can comment on PDSE structure.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627-3803
E: ***@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1dBXA1VOot0VhcJPyS0f0lV29UxXfkVkaujE-zhq-t0zR-KthKuytozr3JyTPZZMTCbrYMQoQ-177KkrrmbJQMUw4vrtPiQerUXk2n7oQek2ZUxWxv40lpRrnYhDJ_Q15H7xEAtm571r4VM5CxIMxrG7bVg4pWKVG3fV7t2ZeSnC_jpD1hDpUjJDR3n95FleAcg7JfttAZpcCX6iajU2tkWYU-2hpsMHAMDyoymkMpuRe4hOGP0mTN4LxwtxpojFtOwQ1h44n9CSbMW7NgsjURQV3eEkMACcxfoK7b5W3M0QLAlmp-j3RZNlLiGJQqJR0DVdLzzRaWBYPM40NoTtIN-ttgdpY4VLJhrydfvLDwDJuBidE0m5TlOCTSzFaa-TtaP8KBaf3nIZOrmbXcITrxx77XiKS-qSZjvzpzHzDXOUmt37Cpninr5Imlm9-TPua/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: Friday, February 23, 2018 8:35 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Count with no Data and no Key ? (CKD internals again)

I don't know internals, but definitely one can use short blocks on DASD, 18B is not a limit. You can use 18 or 5 if you want. Of course the tracks utilization will be extremely poor, but that's different story.

BTW: I'mt not sure, but it seems the null record inside a member is when the member span track boundary.
Obviously there are multiple EOFs (null records) inside a PDS.

--
Radoslaw Skorupka
Lodz, Poland
Post by Elardus Engelbrecht
Also, just curious, I understand that on tape a block <18 (? still?) is bypassed as a noise record.
Wow! Interesting! Where is that documented?
But it's possible that with RECFM=VB the last block might, by happenstance, consist of as few as 8 bytes (BDW=8; RDW=4). How do tape drivers deal with this? Poorly? With RECFM=VBS, a null segment could be used for padding.
Now you made me curious. [1] Damn! ;-)
I really hope someone can answer you...
Groete / Greetings
Elardus Engelbrecht
[1] - Currently outside my scope of work, but hey, I worked with that things as a Storage Admin in the prehistoric days. 8-)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, http://secure-web.cisco.com/1cZpWFg1q4dWP-I1YXw_qPAjd01BWKf8NA900djhQAtIeU04gUAeOz7dZ2Rir8ADBpfOBBubAzo753XS0XdrHXrVdPQ1UMij7F5emD_bCyQuEIJHN7ubp_pq1EVm-VoCv5-ohg-evgcmnDPm4oUTJpaEu5RlylcJWBSjwSXxuAGNsmmXTnvu_jz7yucCXypINmhVxUsaaHFnm-Dtheybndr8Lix9vOOo3epCuADP2hBsgXJeyfgnX3BQjPDHhZQrnn_rUwA6ZWSdPgP0RNbGksok47Ct_EH-XmX5bzlSo50nvCNdl7FR-Ck6PEqcWZ-rmuzUeC5mSqu-5cgTSK-ohHcrHqG5fC70JWBPdGsTajnQrOsW5I_nIhjI0DgUSIUmt0JNg-c0mB8uf-GyN69xb1w9FvIyVezSUMWkfIHUS0l0/http%3A%2F%2Fwww.mBank.pl%2C%20e-mail%3A%20kontakt%40mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

________________________________



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-02-23 15:10:27 UTC
Permalink
The access methods detect the key=0, count=0 records and process them as EOF, which is how they signify the end of a PDS member. Every member has an EOF record with the rare exception of a member that ends at the end of the track on the last track of a data set. ...
VIO has its own surprising rules. I once (circa XA) caused paging space
exhaustion by reading an uninitialized data set allocated as
UNIT=VIO,SPACE=(0,large)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2018-02-23 15:20:30 UTC
Permalink
I've done the same thing. In my case, it was TSOE TRANSMIT, which at the time used VIO for the temporary data set created for transmission purposes. That can be changed in PARMLIB IKJTSOxx TRANSREC to something other than VIO. VIO really makes no sense in a modern mainframe environment but can still cause mischief if not throttled back.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Friday, February 23, 2018 7:12 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Count with no Data and no Key ? (CKD internals again)
The access methods detect the key=0, count=0 records and process them as EOF, which is how they signify the end of a PDS member. Every member has an EOF record with the rare exception of a member that ends at the end of the track on the last track of a data set. ...
VIO has its own surprising rules. I once (circa XA) caused paging space exhaustion by reading an uninitialized data set allocated as
UNIT=VIO,SPACE=(0,large)

-- gil


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...