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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Doug Shupe <dsh...@bellsouth.net>
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 <frank.swarbr...@outlook.com> wrote:

SPEED.
RECOVERY does not appear to make any difference.  HI-U-RBA is still 0.
________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Gerhard Adam <gada...@charter.net>
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 <frank.swarbr...@outlook.com> 
> 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
> Paul Gilmartin <0000000433f07816-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 +0000, 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

Reply via email to