Re: empty KSDS behavior - why?

[Charles Mills]

> It pays to read before write...

That's the whole subject here, right? VSAM files won't do that.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, June 4, 2018 8:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Nice irony how he not only misunderstood the statement, but introduced his
own typo/spelling error.

It pays to read before write...

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

Re: empty KSDS behavior - why?

[Steve Smith]

Nice irony how he not only misunderstood the statement, but introduced his
own typo/spelling error.

It pays to read before write...

sas

On Mon, Jun 4, 2018 at 8:45 AM, J R  wrote:

> The point made was that the paragraph did not make sense as printed.  The
> suggestion was *not* that LSR and RLS were equivalent.
>
> > On Jun 4, 2018, at 08:26, Allan Staller  wrote:
> >
> > "(I'm assuming that last usage of "RLS" > should be "LSR".)"
> >
> > No. RLS and LST are *VERY* different.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: empty KSDS behavior - why?

[J R]

The point made was that the paragraph did not make sense as printed.  The 
suggestion was *not* that LSR and RLS were equivalent. 

> On Jun 4, 2018, at 08:26, Allan Staller  wrote:
> 
> "(I'm assuming that last usage of "RLS" > should be "LSR".)"
> 
> No. RLS and LST are *VERY* different.

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

Re: empty KSDS behavior - why?

[Allan Staller]

"(I'm assuming that last usage of "RLS" > should be "LSR".)"

No. RLS and LST are *VERY* different.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Saturday, June 2, 2018 1:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

> On Jun 1, 2018, at 5:55 PM, Frank Swarbrick  
> wrote:
>
> Here's something interesting I found in the "VSAM Demystified"
> Redbook:  "Empty KSDSs: RLS allows you to open an empty KSDS without
> first loading the data set. In other modes (NSR, RLS [sic?]), this
> process is not possible."  (I'm assuming that last usage of "RLS"
> should be "LSR".)
>
> Can't find the actual IBM documentation of this, nor can I test it (we don't 
> use RLS), but it seems to add weight to my thought that this should be 
> allowed...
>
Frank,

Maybe it is a IBM marketing tool to sell RLS, if it is then it fell on deaf 
ears, as I never heard of that feature either, anyone one else?

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: empty KSDS behavior - why?

[Edward Gould]

> On Jun 1, 2018, at 5:55 PM, Frank Swarbrick  
> wrote:
> 
> Here's something interesting I found in the "VSAM Demystified" Redbook:  
> "Empty KSDSs: RLS allows you to open an empty KSDS without first loading the 
> data set. In other modes (NSR, RLS [sic?]), this process is not possible."  
> (I'm assuming that last usage of "RLS" should be "LSR".)
> 
> Can't find the actual IBM documentation of this, nor can I test it (we don't 
> use RLS), but it seems to add weight to my thought that this should be 
> allowed...
> 
Frank,

Maybe it is a IBM marketing tool to sell RLS, if it is then it fell on deaf 
ears, as I never heard of that feature either, anyone one else?

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

Re: empty KSDS behavior - why?

[Frank Swarbrick]

Here's something interesting I found in the "VSAM Demystified" Redbook:  "Empty 
KSDSs: RLS allows you to open an empty KSDS without first loading the data set. 
In other modes (NSR, RLS [sic?]), this process is not possible."  (I'm assuming 
that last usage of "RLS" should be "LSR".)

Can't find the actual IBM documentation of this, nor can I test it (we don't 
use RLS), but it seems to add weight to my thought that this should be 
allowed...



From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Wednesday, May 30, 2018 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Let's just say that I can't think of a case where I'd want that differentiation.

Anyway, obviously IBM shouldn't change the default, but it seems to me they 
could provide a new option on DEFINE CLUSTER to have it "pre-loaded" (have the 
HURBA set to non-zero).  Or perhaps provide a new IDCAMS command (or maybe 
REPRO parameter) to do it.  I may open an RFE.  Can't hurt to try?

From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, May 30, 2018 7:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Humor me -- I'm not a VSAM guy. Are there really people who are counting on 
their COBOL programs blowing up if they fail to do the right juju on their new 
VSAM file?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Wednesday, May 30, 2018 5:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Consistent behavior and backwards compatability does make it right!

You can question the original though process, but not maintaining consistency.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 29, 2018 7:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 20:42:53 -0400, Doug Shupe wrote:

>LOADED vs UNLOADED.
>
>Read the VSAM DEMISTIFIED Redbooks.
>
>When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
>output and work just fine.
>
>If you write a record and delete the record the VSAM file is now in a LOADED 
>state. You should be able to open I/O or REPRO with the REPLACE option.
>
>I surely might have missed what your trying to do but this is not rocket 
>science and has been this way for years..
>
Antiquity doesn't make something right.  The Fugitive Slave Act was the law of 
the land for years.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

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

Re: empty KSDS behavior - why?

[Steve Smith]

ACB MACRF=RST forces a VSAM file into load mode.  It doesn't seem like it
would be so difficult or incompatible to add a new MACRF option to force
initialization into "loaded" mode (as opposed to failing the OPEN as it now
does).  MACRF=RST requires some DEFINE option as well, but I'm not sure
there's any logical need for it.

sas

On Wed, May 30, 2018 at 1:33 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Let's just say that I can't think of a case where I'd want that
> differentiation.
>
> Anyway, obviously IBM shouldn't change the default, but it seems to me
> they could provide a new option on DEFINE CLUSTER to have it "pre-loaded"
> (have the HURBA set to non-zero).  Or perhaps provide a new IDCAMS command
> (or maybe REPRO parameter) to do it.  I may open an RFE.  Can't hurt to try?

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

Re: empty KSDS behavior - why?

[Seymour J Metz]

As opposed to the folly of testing at the top of the loop when that will give 
incorrect results? You've got to carve the bird at the joints, and no two birds 
are created equal. Blindly following dogmatic rules will cause errors in your 
code.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 29, 2018 3:42 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 19:12:32 +, Frank Swarbrick wrote:

>Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
>0):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
>IDC3300I  ERROR OPENING DVFJS.DUMMY1
>IDC3351I ** VSAM OPEN RETURN CODE IS 160
>IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
>IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
>
>Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
>(HI-U-RBA is now 829440):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
>IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
>IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
>
>In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 
>0).
>
And I suppose it still ABENDs if you attempt to read a record or to REPRO again
DUMMY2 to DUMMY3?  Ugh!

I believe this demonstrates the utter folly of testing at the bottom of a loop
rather than at the top.  A WHILE loop doesn't attempt to access a record when
there is none; an UNTIL loop attempts to process one record regardless.

I'm not very sympathetic to the argumemt of performance, that UNTIL
performs the test N times but WHILE performs it N+1.

Imagine "ls" or "dir" or "BLDL"'s ABENDing on an empty directory!  (Does
ISPF member list still report an error on an empty directory, or just show
an empty screen except for header lines?)

-- gil

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

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

Re: empty KSDS behavior - why?

[Charles Mills]

I give up. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, May 30, 2018 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Wed, 30 May 2018 06:15:11 -0700, Charles Mills  wrote:

>Humor me -- I'm not a VSAM guy. Are there really people who are counting on 
>their COBOL programs blowing up if they fail to do the right juju on their new 
>VSAM file?
>
Not COBOL, but from a recent ply:

On Tue, 29 May 2018 21:29:25 -0400, Roger W Suhr wrote:
>...
>I recently found out that some IBM utilities (IMS DBRC) actually expect a 
>cluster in "create mode", when switching to a new secondary RECON dataset.  If 
>you provide an initialize cluster, the DBRC utility ABENDS and says the 
>dataset had been used before and no valid header record could be found.
>So I doubt IBM will ever provide an option to do this in the DEFINE command.
> 

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

Re: empty KSDS behavior - why?

[Paul Gilmartin]

On Wed, 30 May 2018 06:15:11 -0700, Charles Mills  wrote:

>Humor me -- I'm not a VSAM guy. Are there really people who are counting on 
>their COBOL programs blowing up if they fail to do the right juju on their new 
>VSAM file?
>
Not COBOL, but from a recent ply:

On Tue, 29 May 2018 21:29:25 -0400, Roger W Suhr wrote:
>...
>I recently found out that some IBM utilities (IMS DBRC) actually expect a 
>cluster in "create mode", when switching to a new secondary RECON dataset.  If 
>you provide an initialize cluster, the DBRC utility ABENDS and says the 
>dataset had been used before and no valid header record could be found.
>So I doubt IBM will ever provide an option to do this in the DEFINE command.
> 
Why do the VSAM faithful believe that if this were done it must be done wrong!?

I see "option" as the operant word here.  If an option were provided and the
historic behavior were the default, there'd be no adverse consequence.

My only use of DEFINE CLUSTER has been creating SMP/E CSIs.  Then
I (must?) REPRO GIMZPOOL to initialize the KSDS.  I don't know whether
this provides a header record.  I don't know whether a fits-all analogue
of GIMZPOOL could be provided in SAMPLIB.  I don't know whether this
necessarily creates a record with the risk of key conflict.  But for SMP/E
CSI it can be done in the same IDCAMS step, minimally burdensome.

>There are programs available on the CBT Tape (CBTTAPE.ORG) that will 
>initialize a new cluster (intelligently).  Personally, I like the INITKSDS 
>program. 
>
ISVs, at least, dislike introducing dependencies on fourth-party products,
particularly those that may be unsupported.

-- gil

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

Re: empty KSDS behavior - why?

[R.S.]

W dniu 2018-05-29 o 20:25, Paul Gilmartin pisze:

On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:


Why would IBM have to add a key? What is necessary is to create an empty KSDS 
that can be read; add and delete is one way to do it, and doesn't leave a key 
behind. I'd prefer that they just initialized it to have the same contents as 
adding and deleting.


Is the result identical whether the added/deleted record has key high-values, 
low-values, or something
in between?

And I'll repeat my question, what is the result of REPROing a properly 
initialized
but currently empty KSDS?

Let's assume REPRO IDS(PS.FILE.SORTED) ODS(VSAM.EMPTY.KSDS)
IMHO the result is the same as with VSAM not empty, but with no 
conflicting keys.


Of course initialized VSAM file precludes use of SPEED during load.

--
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: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: empty KSDS behavior - why?

[Charles Mills]

Humor me -- I'm not a VSAM guy. Are there really people who are counting on 
their COBOL programs blowing up if they fail to do the right juju on their new 
VSAM file?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Wednesday, May 30, 2018 5:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Consistent behavior and backwards compatability does make it right!

You can question the original though process, but not maintaining consistency.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 29, 2018 7:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 20:42:53 -0400, Doug Shupe wrote:

>LOADED vs UNLOADED.
>
>Read the VSAM DEMISTIFIED Redbooks.
>
>When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
>output and work just fine.
>
>If you write a record and delete the record the VSAM file is now in a LOADED 
>state. You should be able to open I/O or REPRO with the REPLACE option.
>
>I surely might have missed what your trying to do but this is not rocket 
>science and has been this way for years..
>
Antiquity doesn't make something right.  The Fugitive Slave Act was the law of 
the land for years.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

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

Re: empty KSDS behavior - why?

[Allan Staller]

Consistent behavior and backwards compatability does make it right!

You can question the original though process, but not maintaining consistency.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 29, 2018 7:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 20:42:53 -0400, Doug Shupe wrote:

>LOADED vs UNLOADED.
>
>Read the VSAM DEMISTIFIED Redbooks.
>
>When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
>output and work just fine.
>
>If you write a record and delete the record the VSAM file is now in a LOADED 
>state. You should be able to open I/O or REPRO with the REPLACE option.
>
>I surely might have missed what your trying to do but this is not rocket 
>science and has been this way for years..
>
Antiquity doesn't make something right.  The Fugitive Slave Act was the law of 
the land for years.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: empty KSDS behavior - why?

[Roger W Suhr]

I think this is just one of the quirky things IBM has been getting away with 
for years.  It's that way, because the VSAM designers built it that way.
It's not a big enough issue to go out an fix it (e.g. Have the IDCAMS DEFINE 
command (possibly optional) open the KSDS just defined, for OUTOUT and write a 
null record and then  delete it.
I recently found out that some IBM utilities (IMS DBRC) actually expect a 
cluster in "create mode", when switching to a new secondary RECON dataset.  If 
you provide an initialize cluster, the DBRC utility ABENDS and says the dataset 
had been used before and no valid header record could be found.
So I doubt IBM will ever provide an option to do this in the DEFINE command.

There are programs available on the CBT Tape (CBTTAPE.ORG) that will initialize 
a new cluster (intelligently).  Personally, I like the INITKSDS program. 

Roger W. Suhr
suhr...@gmail.com


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, May 29, 2018 20:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 20:42:53 -0400, Doug Shupe wrote:

>LOADED vs UNLOADED.
>
>Read the VSAM DEMISTIFIED Redbooks.
>
>When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
>output and work just fine.
>
>If you write a record and delete the record the VSAM file is now in a LOADED 
>state. You should be able to open I/O or REPRO with the REPLACE option.
>
>I surely might have missed what your trying to do but this is not rocket 
>science and has been this way for years..
>
Antiquity doesn't make something right.  The Fugitive Slave Act was the law of 
the land for years.

-- gil

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

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

Re: empty KSDS behavior - why?

[Paul Gilmartin]

On Tue, 29 May 2018 20:42:53 -0400, Doug Shupe wrote:

>LOADED vs UNLOADED.
>
>Read the VSAM DEMISTIFIED Redbooks.
>
>When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
>output and work just fine.
>
>If you write a record and delete the record the VSAM file is now in a LOADED 
>state. You should be able to open I/O or REPRO with the REPLACE option.
>
>I surely might have missed what your trying to do but this is not rocket 
>science and has been this way for years..
>
Antiquity doesn't make something right.  The Fugitive Slave Act was the
law of the land for years.

-- gil

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

Re: empty KSDS behavior - why?

[Frank Swarbrick]

I realize its been this way since (probably) "day 1".  I was just wondering 
why.  In my particular use case the application opens the file for updating 
(I-O mode in COBOL) and both checks for the existence of records with certain 
keys and inserts new records.  There is no "loading" of the file with any data 
prior to the first run of the program.  Just my opinion, but I see I'm not 
alone.  I find that the case where there's a particular set of data to be 
"loaded" to the file initially to be fairly rare.

From: IBM Mainframe Discussion List  on behalf of 
Doug Shupe 
Sent: Tuesday, May 29, 2018 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

LOADED vs UNLOADED.

Read the VSAM DEMISTIFIED Redbooks.

When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
output and work just fine.

If you write a record and delete the record the VSAM file is now in a LOADED 
state. You should be able to open I/O or REPRO with the REPLACE option.

I surely might have missed what your trying to do but this is not rocket 
science and has been this way for years..

Best Regards,
Doug


On May 29, 2018, at 19:09, Frank Swarbrick  wrote:

SPEED.
RECOVERY does not appear to make any difference.  HI-U-RBA is still 0.

From: IBM Mainframe Discussion List  on behalf of 
Gerhard Adam 
Sent: Tuesday, May 29, 2018 4:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Perhaps a silly question, but were these files allocated with RECOVERY or 
SPEED?  IIRC, RECOVERY pre-formats the first control area with binary zeros.

In other words, does changing this specification change the behavior?

Adam

Sent from my iPhone

> On May 29, 2018, at 3:12 PM, Frank Swarbrick  
> wrote:
>
> Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
> 0):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC3300I  ERROR OPENING DVFJS.DUMMY1
> IDC3351I ** VSAM OPEN RETURN CODE IS 160
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
>
> Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
> (HI-U-RBA is now 829440):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
>
> In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 
> 0).
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Tuesday, May 29, 2018 12:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: empty KSDS behavior - why?
>
>> On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:
>>
>> Why would IBM have to add a key? What is necessary is to create an empty 
>> KSDS that can be read; add and delete is one way to do it, and doesn't leave 
>> a key behind. I'd prefer that they just initialized it to have the same 
>> contents as adding and deleting.
> Is the result identical whether the added/deleted record has key high-values, 
> low-values, or something
> in between?
>
> And I'll repeat my question, what is the result of REPROing a properly 
> initialized
> but currently empty KSDS?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

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

Re: empty KSDS behavior - why?

[Doug Shupe]

LOADED vs UNLOADED.

Read the VSAM DEMISTIFIED Redbooks.

When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
output and work just fine.

If you write a record and delete the record the VSAM file is now in a LOADED 
state. You should be able to open I/O or REPRO with the REPLACE option.

I surely might have missed what your trying to do but this is not rocket 
science and has been this way for years..

Best Regards,
Doug


On May 29, 2018, at 19:09, Frank Swarbrick  wrote:

SPEED.
RECOVERY does not appear to make any difference.  HI-U-RBA is still 0.

From: IBM Mainframe Discussion List  on behalf of 
Gerhard Adam 
Sent: Tuesday, May 29, 2018 4:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Perhaps a silly question, but were these files allocated with RECOVERY or 
SPEED?  IIRC, RECOVERY pre-formats the first control area with binary zeros.

In other words, does changing this specification change the behavior?

Adam

Sent from my iPhone

> On May 29, 2018, at 3:12 PM, Frank Swarbrick  
> wrote:
> 
> Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
> 0):
> 
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC3300I  ERROR OPENING DVFJS.DUMMY1
> IDC3351I ** VSAM OPEN RETURN CODE IS 160
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
> 
> Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
> (HI-U-RBA is now 829440):
> 
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
> 
> In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 
> 0).
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Tuesday, May 29, 2018 12:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: empty KSDS behavior - why?
> 
>> On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:
>> 
>> Why would IBM have to add a key? What is necessary is to create an empty 
>> KSDS that can be read; add and delete is one way to do it, and doesn't leave 
>> a key behind. I'd prefer that they just initialized it to have the same 
>> contents as adding and deleting.
> Is the result identical whether the added/deleted record has key high-values, 
> low-values, or something
> in between?
> 
> And I'll repeat my question, what is the result of REPROing a properly 
> initialized
> but currently empty KSDS?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

Re: empty KSDS behavior - why?

[Frank Swarbrick]

SPEED.
RECOVERY does not appear to make any difference.  HI-U-RBA is still 0.

From: IBM Mainframe Discussion List  on behalf of 
Gerhard Adam 
Sent: Tuesday, May 29, 2018 4:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Perhaps a silly question, but were these files allocated with RECOVERY or 
SPEED?  IIRC, RECOVERY pre-formats the first control area with binary zeros.

In other words, does changing this specification change the behavior?

Adam

Sent from my iPhone

> On May 29, 2018, at 3:12 PM, Frank Swarbrick  
> wrote:
>
> Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
> 0):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC3300I  ERROR OPENING DVFJS.DUMMY1
> IDC3351I ** VSAM OPEN RETURN CODE IS 160
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
>
> Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
> (HI-U-RBA is now 829440):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
>
> In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 
> 0).
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Tuesday, May 29, 2018 12:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: empty KSDS behavior - why?
>
>> On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:
>>
>> Why would IBM have to add a key? What is necessary is to create an empty 
>> KSDS that can be read; add and delete is one way to do it, and doesn't leave 
>> a key behind. I'd prefer that they just initialized it to have the same 
>> contents as adding and deleting.
> Is the result identical whether the added/deleted record has key high-values, 
> low-values, or something
> in between?
>
> And I'll repeat my question, what is the result of REPROing a properly 
> initialized
> but currently empty KSDS?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: empty KSDS behavior - why?

[Gerhard Adam]

Perhaps a silly question, but were these files allocated with RECOVERY or 
SPEED?  IIRC, RECOVERY pre-formats the first control area with binary zeros. 

In other words, does changing this specification change the behavior?

Adam

Sent from my iPhone

> On May 29, 2018, at 3:12 PM, Frank Swarbrick  
> wrote:
> 
> Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
> 0):
> 
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC3300I  ERROR OPENING DVFJS.DUMMY1
> IDC3351I ** VSAM OPEN RETURN CODE IS 160
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
> 
> Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
> (HI-U-RBA is now 829440):
> 
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
> IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
> 
> In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 
> 0).
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Tuesday, May 29, 2018 12:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: empty KSDS behavior - why?
> 
>> On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:
>> 
>> Why would IBM have to add a key? What is necessary is to create an empty 
>> KSDS that can be read; add and delete is one way to do it, and doesn't leave 
>> a key behind. I'd prefer that they just initialized it to have the same 
>> contents as adding and deleting.
> Is the result identical whether the added/deleted record has key high-values, 
> low-values, or something
> in between?
> 
> And I'll repeat my question, what is the result of REPROing a properly 
> initialized
> but currently empty KSDS?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: empty KSDS behavior - why?

[Frank Swarbrick]

Not quite sure what you are asking, but...

IDCAMS  SYSTEM SERVICES

 PRINT IDS(DVFJS.DUMMY1)
IDCAMS  SYSTEM SERVICES
LISTING OF DATA SET -DVFJS.DUMMY1
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
IDCAMS  SYSTEM SERVICES

 PRINT IDS(DVFJS.DUMMY2)
IDC3300I  ERROR OPENING DVFJS.DUMMY2
IDC3351I ** VSAM OPEN RETURN CODE IS 160
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, May 29, 2018 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Did you try reading in each case? I believe that you will find that the results 
differ.


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


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Tuesday, May 29, 2018 3:12 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
0):

 REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
IDC3300I  ERROR OPENING DVFJS.DUMMY1
IDC3351I ** VSAM OPEN RETURN CODE IS 160
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
(HI-U-RBA is now 829440):

 REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 0).


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 29, 2018 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:

>Why would IBM have to add a key? What is necessary is to create an empty KSDS 
>that can be read; add and delete is one way to do it, and doesn't leave a key 
>behind. I'd prefer that they just initialized it to have the same contents as 
>adding and deleting.
>
Is the result identical whether the added/deleted record has key high-values, 
low-values, or something
in between?

And I'll repeat my question, what is the result of REPROing a properly 
initialized
but currently empty KSDS?

-- gil

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

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

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

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

Re: empty KSDS behavior - why?

[Paul Gilmartin]

On Tue, 29 May 2018 19:12:32 +, Frank Swarbrick wrote:

>Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
>0):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
>IDC3300I  ERROR OPENING DVFJS.DUMMY1
>IDC3351I ** VSAM OPEN RETURN CODE IS 160
>IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
>IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
>
>Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
>(HI-U-RBA is now 829440):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
>IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
>IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
>
>In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 
>0).
>  
And I suppose it still ABENDs if you attempt to read a record or to REPRO again
DUMMY2 to DUMMY3?  Ugh!

I believe this demonstrates the utter folly of testing at the bottom of a loop
rather than at the top.  A WHILE loop doesn't attempt to access a record when
there is none; an UNTIL loop attempts to process one record regardless.

I'm not very sympathetic to the argumemt of performance, that UNTIL
performs the test N times but WHILE performs it N+1.

Imagine "ls" or "dir" or "BLDL"'s ABENDing on an empty directory!  (Does
ISPF member list still report an error on an empty directory, or just show
an empty screen except for header lines?)

-- gil

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

Re: empty KSDS behavior - why?

[Seymour J Metz]

Did you try reading in each case? I believe that you will find that the results 
differ.


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


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Tuesday, May 29, 2018 3:12 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
0):

 REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
IDC3300I  ERROR OPENING DVFJS.DUMMY1
IDC3351I ** VSAM OPEN RETURN CODE IS 160
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
(HI-U-RBA is now 829440):

 REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 0).


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 29, 2018 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:

>Why would IBM have to add a key? What is necessary is to create an empty KSDS 
>that can be read; add and delete is one way to do it, and doesn't leave a key 
>behind. I'd prefer that they just initialized it to have the same contents as 
>adding and deleting.
>
Is the result identical whether the added/deleted record has key high-values, 
low-values, or something
in between?

And I'll repeat my question, what is the result of REPROing a properly 
initialized
but currently empty KSDS?

-- gil

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

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

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

Re: empty KSDS behavior - why?

[Frank Swarbrick]

Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
0):

 REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
IDC3300I  ERROR OPENING DVFJS.DUMMY1
IDC3351I ** VSAM OPEN RETURN CODE IS 160
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
(HI-U-RBA is now 829440):

 REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 0).


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 29, 2018 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:

>Why would IBM have to add a key? What is necessary is to create an empty KSDS 
>that can be read; add and delete is one way to do it, and doesn't leave a key 
>behind. I'd prefer that they just initialized it to have the same contents as 
>adding and deleting.
>
Is the result identical whether the added/deleted record has key high-values, 
low-values, or something
in between?

And I'll repeat my question, what is the result of REPROing a properly 
initialized
but currently empty KSDS?

-- gil

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

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

Re: empty KSDS behavior - why?

[Seymour J Metz]

I'd guess that add/delete of low values and of high values would leave behing 
different structures, but that the differences wouldn't affect performance 
significantly; certainly not as much as one ABEND due to failure to prime.

As for REPRO, I'd like to know that too.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 29, 2018 2:25 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:

>Why would IBM have to add a key? What is necessary is to create an empty KSDS 
>that can be read; add and delete is one way to do it, and doesn't leave a key 
>behind. I'd prefer that they just initialized it to have the same contents as 
>adding and deleting.
>
Is the result identical whether the added/deleted record has key high-values, 
low-values, or something
in between?

And I'll repeat my question, what is the result of REPROing a properly 
initialized
but currently empty KSDS?

-- gil

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

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

Re: empty KSDS behavior - why?

[Paul Gilmartin]

On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:

>Why would IBM have to add a key? What is necessary is to create an empty KSDS 
>that can be read; add and delete is one way to do it, and doesn't leave a key 
>behind. I'd prefer that they just initialized it to have the same contents as 
>adding and deleting. 
> 
Is the result identical whether the added/deleted record has key high-values, 
low-values, or something
in between?

And I'll repeat my question, what is the result of REPROing a properly 
initialized
but currently empty KSDS?

-- gil

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

Re: empty KSDS behavior - why?

[Seymour J Metz]

Why would IBM have to add a key? What is necessary is to create an empty KSDS 
that can be read; add and delete is one way to do it, and doesn't leave a key 
behind. I'd prefer that they just initialized it to have the same contents as 
adding and deleting. 


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


From: IBM Mainframe Discussion List  on behalf of 
Edward Gould 
Sent: Sunday, May 27, 2018 11:46 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

> On May 27, 2018, at 8:51 PM, Charles Mills  wrote:
>
> Exactly. I am no VSAM guy ... but whatever magic you have to do manually go 
> get the VSAM file to be readable, why can't AMS just do that when it creates 
> the file? Is there any reason anyone would want a "virginal" (unreadable) 
> VSAM file specifically?
>
> How many ABENDs, how many application problems, how many stupid little 
> customer fixup programs and PROCs could have been saved if AMS just did that 
> from the get-go?
>
> Or am I missing something? As I say, I am no VSAM guy.
>
> Charles
Charles,
I like many others feel your pain. I can understand it in a way, say a KSDS and 
(in your world) VSAM automagically adds a record. What key would IBM possibly 
use that high end up without it being a duplicate key. RRDS would automatically 
loose 1 record as the first record would be ??. IBM decided (I think) to take 
it as its *YOUR* dataset and its up to you to prime it.
Ed


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

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

Re: empty KSDS behavior - why?

[John McKown]

On Tue, May 29, 2018 at 12:25 PM Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> I don't think the key would matter, because it can immediately be deleted,
> leaving the file "empty" but with the HI RBA appropriately set in order to
> avoid the issue.
>
> I'm glad to see I'm not the only one bothered by this.  I'm still
> wondering how much support an RFE might get.
>
> Is there any standard utility that is able to add and delete a record?  I
> don't see IDCAMS having any such option.
>

​Not that I'm aware of. Long ago one of the people here wrote a VSAMINIT
program which did a SHOWCB to get the LRECL, KEYLENGTH, and RKP. It then
did an PUT to add an "binary zeros" record; followed by a GET / ERASE pair
to delete it.

This is like pre-SMS when DADSM would allocate a PS dataset without an EOF
record at the front. I don't really know if an immediate EOF when reading a
never-written-to dataset is a good idea or not. But I guess it is a bit
more secure. Of course, if I had my way, all datasets would be
erase-on-scratch and I really sort of wished that there was an interface so
that z/OS could talk to the DASD array controller to tell it "I deleted the
data set on these tracks -- you can release them on the back end" so that
the DASD array could then "do something to" (such as security erase) the
actual data on the ​back end. Something similar to the TRIM function on an
SSD.


-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: empty KSDS behavior - why?

[Frank Swarbrick]

I don't think the key would matter, because it can immediately be deleted, 
leaving the file "empty" but with the HI RBA appropriately set in order to 
avoid the issue.

I'm glad to see I'm not the only one bothered by this.  I'm still wondering how 
much support an RFE might get.

Is there any standard utility that is able to add and delete a record?  I don't 
see IDCAMS having any such option.

From: IBM Mainframe Discussion List  on behalf of 
Edward Gould 
Sent: Sunday, May 27, 2018 9:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

> On May 27, 2018, at 8:51 PM, Charles Mills  wrote:
>
> Exactly. I am no VSAM guy ... but whatever magic you have to do manually go 
> get the VSAM file to be readable, why can't AMS just do that when it creates 
> the file? Is there any reason anyone would want a "virginal" (unreadable) 
> VSAM file specifically?
>
> How many ABENDs, how many application problems, how many stupid little 
> customer fixup programs and PROCs could have been saved if AMS just did that 
> from the get-go?
>
> Or am I missing something? As I say, I am no VSAM guy.
>
> Charles
Charles,
I like many others feel your pain. I can understand it in a way, say a KSDS and 
(in your world) VSAM automagically adds a record. What key would IBM possibly 
use that high end up without it being a duplicate key. RRDS would automatically 
loose 1 record as the first record would be ??. IBM decided (I think) to take 
it as its *YOUR* dataset and its up to you to prime it.
Ed


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

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

Re: empty KSDS behavior - why?

[Charles Mills]

Exactly.

Presumably less overhead to just set the pointer (or whatever) rather than 
actually loading and deleting a record.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, May 27, 2018 10:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Sun, 27 May 2018 22:46:52 -0500, Edward Gould wrote:

>> On May 27, 2018, at 8:51 PM, Charles Mills wrote:
>> 
>> Exactly. I am no VSAM guy ... but whatever magic you have to do manually go 
>> get the VSAM file to be readable, why can't AMS just do that when it creates 
>> the file? Is there any reason anyone would want a "virginal" (unreadable) 
>> VSAM file specifically?
>> 
>> How many ABENDs, how many application problems, how many stupid little 
>> customer fixup programs and PROCs could have been saved if AMS just did that 
>> from the get-go?
>> 
>> Or am I missing something? As I say, I am no VSAM guy.
>> 
>I like many others feel your pain. I can understand it in a way, say a KSDS 
>and (in your world) VSAM automagically adds a record. What key would IBM 
>possibly use that high end up without it being a duplicate key. RRDS would 
>automatically loose 1 record as the first record would be ??. IBM decided (I 
>think) to take it as its *YOUR* dataset and its up to you to prime it.
>
No, no!  The suggestion was that it should automagically add one record, 
*then*delete*it*.
(Others have said this suffices.)  Or, in a shortcut initialize the data set in 
such a state.
Once the record is gone, it doesn't matter what the key was.  There's nothing 
for any record
subsequently inserted to be a duplicate key of.

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

Re: empty KSDS behavior - why?

[Edward Gould]

> On May 28, 2018, at 12:38 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> No, no!  The suggestion was that it should automagically add one record, 
> *then*delete*it*.
> (Others have said this suffices.)  Or, in a shortcut initialize the data set 
> in such a state.
> Once the record is gone, it doesn't matter what the key was.  There's nothing 
> for any record
> subsequently inserted to be a duplicate key of.
IBM doesn’t want to touch your dataset, You created it and its up to you to 
prime it. But this is counter intuitive to IBM automatically encrypting all 
datasets.
> 
> (But does that create a CA/CI for a range that the customer would never use 
> and
> leave it dangling?)
> 
> What happens when the programmer REPROs an empty KSDS which formerly contained
> records in order to reorganize it and prune otiose CA/CIs?


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

Re: empty KSDS behavior - why?

[Paul Gilmartin]

On Sun, 27 May 2018 22:46:52 -0500, Edward Gould wrote:

>> On May 27, 2018, at 8:51 PM, Charles Mills wrote:
>> 
>> Exactly. I am no VSAM guy ... but whatever magic you have to do manually go 
>> get the VSAM file to be readable, why can't AMS just do that when it creates 
>> the file? Is there any reason anyone would want a "virginal" (unreadable) 
>> VSAM file specifically?
>> 
>> How many ABENDs, how many application problems, how many stupid little 
>> customer fixup programs and PROCs could have been saved if AMS just did that 
>> from the get-go?
>> 
>> Or am I missing something? As I say, I am no VSAM guy.
>> 
>I like many others feel your pain. I can understand it in a way, say a KSDS 
>and (in your world) VSAM automagically adds a record. What key would IBM 
>possibly use that high end up without it being a duplicate key. RRDS would 
>automatically loose 1 record as the first record would be ??. IBM decided (I 
>think) to take it as its *YOUR* dataset and its up to you to prime it.
>
No, no!  The suggestion was that it should automagically add one record, 
*then*delete*it*.
(Others have said this suffices.)  Or, in a shortcut initialize the data set in 
such a state.
Once the record is gone, it doesn't matter what the key was.  There's nothing 
for any record
subsequently inserted to be a duplicate key of.

(But does that create a CA/CI for a range that the customer would never use and
leave it dangling?)

What happens when the programmer REPROs an empty KSDS which formerly contained
records in order to reorganize it and prune otiose CA/CIs?

(I recall a time when HSM considered it an error to migrate a PDS with no 
members.)

-- gil

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

Re: empty KSDS behavior - why?

[Edward Gould]

> On May 27, 2018, at 8:51 PM, Charles Mills  wrote:
> 
> Exactly. I am no VSAM guy ... but whatever magic you have to do manually go 
> get the VSAM file to be readable, why can't AMS just do that when it creates 
> the file? Is there any reason anyone would want a "virginal" (unreadable) 
> VSAM file specifically?
> 
> How many ABENDs, how many application problems, how many stupid little 
> customer fixup programs and PROCs could have been saved if AMS just did that 
> from the get-go?
> 
> Or am I missing something? As I say, I am no VSAM guy.
> 
> Charles
Charles,
I like many others feel your pain. I can understand it in a way, say a KSDS and 
(in your world) VSAM automagically adds a record. What key would IBM possibly 
use that high end up without it being a duplicate key. RRDS would automatically 
loose 1 record as the first record would be ??. IBM decided (I think) to take 
it as its *YOUR* dataset and its up to you to prime it.
Ed


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

Re: empty KSDS behavior - why?

[Charles Mills]

Exactly. I am no VSAM guy ... but whatever magic you have to do manually go get 
the VSAM file to be readable, why can't AMS just do that when it creates the 
file? Is there any reason anyone would want a "virginal" (unreadable) VSAM file 
specifically?

How many ABENDs, how many application problems, how many stupid little customer 
fixup programs and PROCs could have been saved if AMS just did that from the 
get-go?

Or am I missing something? As I say, I am no VSAM guy.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Sunday, May 27, 2018 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Not really. It's more like making you create a VTOC after you've formated the 
drive instead of making the creation of the VTOC part of the formatting. 
Pre-SMS there was a similar problem with sequential DASD files; you had to open 
them for output if you wanted to use them as empty input files.

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

Re: empty KSDS behavior - why?

[Seymour J Metz]

Not really. It's more like making you create a VTOC after you've formated the 
drive instead of making the creation of the VTOC part of the formatting. 
Pre-SMS there was a similar problem with sequential DASD files; you had to open 
them for output if you wanted to use them as empty input files.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Ron 
hawkins <ronjhawk...@sbcglobal.net>
Sent: Sunday, May 27, 2018 3:24 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

I think it's more like "why do we have to format disk drives."

Even a VTOC needs to know where things start and end.

-Original Message-
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of R.S.
Sent: Saturday, May 26, 2018 2:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] empty KSDS behavior - why?

W dniu 2018-05-26 o 02:47, Paul Gilmartin pisze:
> On Sat, 26 May 2018 00:20:34 +, Frank Swarbrick wrote:
>
>> Pointless issue of the day.  This has bothered me for 20 years.  I figured 
>> its about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never 
>> been "loaded") have what seems to be to be a "special" behavior, one that is 
>> different than a KSDS that had records but no longer has any (all records 
>> have been deleted).
>>
> I suppose it's like formatting a disk: no VTOC is different from an empty 
> VTOC.
> But, yes, Why‽  Why does SMP/E require me to REPRO GIMZPOOL?  Why
> isn't this embedded in DEFINE CLUSTER?

Yes, it is like disk ad VTOC, but it *shouldn't* be like.
Indeed empty VSAM file is not the same as ever user VSAM file. It complicates 
VSAM processing in application, or to simplfy, many applications do require to 
"seed" the cluster with some dummy record before use.
Can it be changed? Well, can we relieve JCL syntax? ;-)

--
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/14WcenTauxUxkOdC529500dhYAnBt6pGtc3wdjkfqe5twVmP4G1yNK-GkHNROQRq201tTX8tGqLTg_EN7GydcDoqoK6_gLjbYld7d8-8Hv1099w4wnf3rIdGdr8XcdtQ61c9szzjm1cGxPgQWJ7slUes337UaAO5gr1b6KT7_SolB9eiO9l_KWiQ2fHvYw4CT9StnVW8xhMgUwCYsWCin2_g5UDh4v5kKxPNf1l9JvZO5qe5W26oiI_kaVeq_Im8GfrCyLy37_jnGeAdW9qKxGg3Ga67ljxp3MgKf-QchVJz8WketdCXihmPJIF6gC3BD0M053SKxvXzZgU1sBEy5H7CUKq2zVqW4q40qd0glBa2vxGr553dxQoGyivGImKUb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 
025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


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

Re: empty KSDS behavior - why?

[Ron hawkins]

I think it's more like "why do we have to format disk drives."

Even a VTOC needs to know where things start and end.

-Original Message-
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of R.S.
Sent: Saturday, May 26, 2018 2:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] empty KSDS behavior - why?

W dniu 2018-05-26 o 02:47, Paul Gilmartin pisze:
> On Sat, 26 May 2018 00:20:34 +, Frank Swarbrick wrote:
>
>> Pointless issue of the day.  This has bothered me for 20 years.  I figured 
>> its about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never 
>> been "loaded") have what seems to be to be a "special" behavior, one that is 
>> different than a KSDS that had records but no longer has any (all records 
>> have been deleted).
>>
> I suppose it's like formatting a disk: no VTOC is different from an empty 
> VTOC.
> But, yes, Why‽  Why does SMP/E require me to REPRO GIMZPOOL?  Why 
> isn't this embedded in DEFINE CLUSTER?

Yes, it is like disk ad VTOC, but it *shouldn't* be like.
Indeed empty VSAM file is not the same as ever user VSAM file. It complicates 
VSAM processing in application, or to simplfy, many applications do require to 
"seed" the cluster with some dummy record before use.
Can it be changed? Well, can we relieve JCL syntax? ;-)

--
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: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: empty KSDS behavior - why?

[Seymour J Metz]

I've considered it a minor nuisance since day one. I got used to it, but never 
learned to like it.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Frank Swarbrick <frank.swarbr...@outlook.com>
Sent: Friday, May 25, 2018 8:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: empty KSDS behavior - why?

Pointless issue of the day.  This has bothered me for 20 years.  I figured its 
about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never been 
"loaded") have what seems to be to be a "special" behavior, one that is 
different than a KSDS that had records but no longer has any (all records have 
been deleted).

For example, if a file in this "never loaded" state is opened for input by 
IDCAMS you get this:

 PRINT INFILE(CCMIGR)
IDC3300I  ERROR OPENING DVFJS.CCARD.CCMIGRX
IDC3351I ** VSAM OPEN RETURN CODE IS 160
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0

where
160
The operands specified in the ACB or GENCB macro are
inconsistent with each other or with the information in the
catalog record. This error can also occur when the VSAM
cluster being opened is empty.

If opened by SORT (DFSORT)
IEC161I 
072-053,DEFVSAM,PRINT1,CCMIGR,,,DVFJS.CCARD.CCMIGRX,DVFJS.CCARD.CCMIGRX.DATA,CATALOG.USERCAT.PPCAT

where
IEC161I (072)

  Specific information for this return code: The data set was empty, but the 
ACB (access method control block) for the data set indicated that it was being 
opened for input only.

System action

  OPEN processing ends for the data set. The error flag (ACBERFLG) in the ACB 
(access method block) for the data set is set to 160 (X'A0').


When opened by a COBOL program, you get file status 35 (An OPEN statement with 
the INPUT, I-O, or EXTEND phrase was attempted on a non-optional file that was 
unavailable.), unless you declare it as OPTIONAL, in which case you get file 
status 05 (An OPEN statement was successfully executed, but the referenced 
optional file was unavailable at the time the OPEN statement was executed. The 
file had been created if the open mode was I-O or EXTEND.)

Is this "feature" supposed to be helpful in some obscure edge case?  Or is it 
simply always annoying?

The OPTIONAL solution in COBOL is generally how we get around this issue, 
rather than loading a dummy record or something.  But why?  Why, why, why does 
this behavior even exist?

Frank


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

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

Re: empty KSDS behavior - why?

[Mike Schwab]

Yep.  One per volume.  Sorry about that.

On Sat, May 26, 2018 at 11:55 AM, Edward Gould  wrote:
>> On May 25, 2018, at 10:43 PM, Mike Schwab  wrote:
>>
>> I remember working with HSM migration control datasets a few years
>> ago.  Even for that you had to load a high key value dummy record
>> before using the dataset.
>
> Mike,
>
> I think you are talking about the SDSP VSAM data set(s).
>
> Ed
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: empty KSDS behavior - why?

[Edward Gould]

> On May 25, 2018, at 10:43 PM, Mike Schwab  wrote:
> 
> I remember working with HSM migration control datasets a few years
> ago.  Even for that you had to load a high key value dummy record
> before using the dataset.

Mike,

I think you are talking about the SDSP VSAM data set(s).

Ed



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

Re: empty KSDS behavior - why?

[Charles Mills]

In other words, it works the way it works because it works the way it works.
But why?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sri h Kolusu
Sent: Saturday, May 26, 2018 5:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

> For example, if a file in this "never loaded" state is opened for
> input by IDCAMS you get this:
>
> If opened by SORT (DFSORT)
> IEC161I
>
072-053,DEFVSAM,PRINT1,CCMIGR,,,DVFJS.CCARD.CCMIGRX,DVFJS.CCARD.CCMIGRX.DATA
,CATALOG.USERCAT.PPCAT

>
Frank,

IDCAMS gives a return code of 160 for non-initialized vsam clusters.  A
newly created vsam file will have a zero value in HURBA(HI-USEDRBA) . In
order to open the file for input or update processing , it requires that at
least one data record be initially loaded into the file. This is because
VSAM issues a VERIFY command upon opening a file to reset the end-of-file
pointer. If the file has never been loaded, the VERIFY fails because the
high used RBA (Relative Byte Address) (HI-USEDRBA) is still zero.
Therefore, VSAM files must be initially "loaded" to set the HI-USED-RBA to
a value other than zero. This is done by writing a record to the VSAM file
in "load" mode and optionally deleting the record to empty the file while
leaving the HI-USED-RBA at a non-zero value.

DFSORT has a Parm VSAMEMT to copy an empty vsam cluster . This parm
determines how an empty VSAM input data set will be processed

//STEP0100 EXEC PGM=SORT,PARM='VSAMEMT=YES'


Hope this helps..

Thanks,
Kolusu


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

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

Re: empty KSDS behavior - why?

[Sri h Kolusu]

> For example, if a file in this "never loaded" state is opened for
> input by IDCAMS you get this:
>
> If opened by SORT (DFSORT)
> IEC161I
>
072-053,DEFVSAM,PRINT1,CCMIGR,,,DVFJS.CCARD.CCMIGRX,DVFJS.CCARD.CCMIGRX.DATA,CATALOG.USERCAT.PPCAT

>
Frank,

IDCAMS gives a return code of 160 for non-initialized vsam clusters.  A
newly created vsam file will have a zero value in HURBA(HI-USEDRBA) . In
order to open the file for input or update processing , it requires that at
least one data record be initially loaded into the file. This is because
VSAM issues a VERIFY command upon opening a file to reset the end-of-file
pointer. If the file has never been loaded, the VERIFY fails because the
high used RBA (Relative Byte Address) (HI-USEDRBA) is still zero.
Therefore, VSAM files must be initially "loaded" to set the HI-USED-RBA to
a value other than zero. This is done by writing a record to the VSAM file
in "load" mode and optionally deleting the record to empty the file while
leaving the HI-USED-RBA at a non-zero value.

DFSORT has a Parm VSAMEMT to copy an empty vsam cluster . This parm
determines how an empty VSAM input data set will be processed

//STEP0100 EXEC PGM=SORT,PARM='VSAMEMT=YES'


Hope this helps..

Thanks,
Kolusu


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

Re: empty KSDS behavior - why?

[R.S.]

W dniu 2018-05-26 o 02:47, Paul Gilmartin pisze:

On Sat, 26 May 2018 00:20:34 +, Frank Swarbrick wrote:


Pointless issue of the day.  This has bothered me for 20 years.  I figured its about time I ask, why?  Why 
does an "empty" KSDS (a KSDS that has never been "loaded") have what seems to be to be a 
"special" behavior, one that is different than a KSDS that had records but no longer has any (all 
records have been deleted).


I suppose it's like formatting a disk: no VTOC is different from an empty VTOC.
But, yes, Why‽  Why does SMP/E require me to REPRO GIMZPOOL?  Why isn't
this embedded in DEFINE CLUSTER?


Yes, it is like disk ad VTOC, but it *shouldn't* be like.
Indeed empty VSAM file is not the same as ever user VSAM file. It 
complicates VSAM processing in application, or to simplfy, many 
applications do require to "seed" the cluster with some dummy record 
before use.

Can it be changed? Well, can we relieve JCL syntax? ;-)

--
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: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: empty KSDS behavior - why?

[Mike Schwab]

I remember working with HSM migration control datasets a few years
ago.  Even for that you had to load a high key value dummy record
before using the dataset.

On Fri, May 25, 2018 at 7:20 PM, Frank Swarbrick
 wrote:
> Pointless issue of the day.  This has bothered me for 20 years.  I figured 
> its about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never 
> been "loaded") have what seems to be to be a "special" behavior, one that is 
> different than a KSDS that had records but no longer has any (all records 
> have been deleted).
>
> For example, if a file in this "never loaded" state is opened for input by 
> IDCAMS you get this:
>
>  PRINT INFILE(CCMIGR)
> IDC3300I  ERROR OPENING DVFJS.CCARD.CCMIGRX
> IDC3351I ** VSAM OPEN RETURN CODE IS 160
> IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
>
> where
> 160
> The operands specified in the ACB or GENCB macro are
> inconsistent with each other or with the information in the
> catalog record. This error can also occur when the VSAM
> cluster being opened is empty.
>
> If opened by SORT (DFSORT)
> IEC161I 
> 072-053,DEFVSAM,PRINT1,CCMIGR,,,DVFJS.CCARD.CCMIGRX,DVFJS.CCARD.CCMIGRX.DATA,CATALOG.USERCAT.PPCAT
>
> where
> IEC161I (072)
>
>   Specific information for this return code: The data set was empty, but the 
> ACB (access method control block) for the data set indicated that it was 
> being opened for input only.
>
> System action
>
>   OPEN processing ends for the data set. The error flag (ACBERFLG) in the ACB 
> (access method block) for the data set is set to 160 (X'A0').
>
>
> When opened by a COBOL program, you get file status 35 (An OPEN statement 
> with the INPUT, I-O, or EXTEND phrase was attempted on a non-optional file 
> that was unavailable.), unless you declare it as OPTIONAL, in which case you 
> get file status 05 (An OPEN statement was successfully executed, but the 
> referenced optional file was unavailable at the time the OPEN statement was 
> executed. The file had been created if the open mode was I-O or EXTEND.)
>
> Is this "feature" supposed to be helpful in some obscure edge case?  Or is it 
> simply always annoying?
>
> The OPTIONAL solution in COBOL is generally how we get around this issue, 
> rather than loading a dummy record or something.  But why?  Why, why, why 
> does this behavior even exist?
>
> Frank
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: empty KSDS behavior - why?

[Paul Gilmartin]

On Sat, 26 May 2018 00:20:34 +, Frank Swarbrick wrote:

>Pointless issue of the day.  This has bothered me for 20 years.  I figured its 
>about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never been 
>"loaded") have what seems to be to be a "special" behavior, one that is 
>different than a KSDS that had records but no longer has any (all records have 
>been deleted).
> 
I suppose it's like formatting a disk: no VTOC is different from an empty VTOC.
But, yes, Why‽  Why does SMP/E require me to REPRO GIMZPOOL?  Why isn't
this embedded in DEFINE CLUSTER?

How do you create your KSDS?  IDCAMS?  Other (specify)

At least nowadays SMS properly terminates a NEW PS data set.  How many decades
did that take?

-- gil

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

empty KSDS behavior - why?

[Frank Swarbrick]

Pointless issue of the day.  This has bothered me for 20 years.  I figured its 
about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never been 
"loaded") have what seems to be to be a "special" behavior, one that is 
different than a KSDS that had records but no longer has any (all records have 
been deleted).

For example, if a file in this "never loaded" state is opened for input by 
IDCAMS you get this:

 PRINT INFILE(CCMIGR)
IDC3300I  ERROR OPENING DVFJS.CCARD.CCMIGRX
IDC3351I ** VSAM OPEN RETURN CODE IS 160
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0

where
160
The operands specified in the ACB or GENCB macro are
inconsistent with each other or with the information in the
catalog record. This error can also occur when the VSAM
cluster being opened is empty.

If opened by SORT (DFSORT)
IEC161I 
072-053,DEFVSAM,PRINT1,CCMIGR,,,DVFJS.CCARD.CCMIGRX,DVFJS.CCARD.CCMIGRX.DATA,CATALOG.USERCAT.PPCAT

where
IEC161I (072)

  Specific information for this return code: The data set was empty, but the 
ACB (access method control block) for the data set indicated that it was being 
opened for input only.

System action

  OPEN processing ends for the data set. The error flag (ACBERFLG) in the ACB 
(access method block) for the data set is set to 160 (X'A0').


When opened by a COBOL program, you get file status 35 (An OPEN statement with 
the INPUT, I-O, or EXTEND phrase was attempted on a non-optional file that was 
unavailable.), unless you declare it as OPTIONAL, in which case you get file 
status 05 (An OPEN statement was successfully executed, but the referenced 
optional file was unavailable at the time the OPEN statement was executed. The 
file had been created if the open mode was I-O or EXTEND.)

Is this "feature" supposed to be helpful in some obscure edge case?  Or is it 
simply always annoying?

The OPTIONAL solution in COBOL is generally how we get around this issue, 
rather than loading a dummy record or something.  But why?  Why, why, why does 
this behavior even exist?

Frank


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