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 <[email protected]> wrote:

SPEED.
RECOVERY does not appear to make any difference.  HI-U-RBA is still 0.
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Gerhard Adam <[email protected]>
Sent: Tuesday, May 29, 2018 4:59 PM
To: [email protected]
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 <[email protected]> 
> 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 <[email protected]> on behalf of 
> Paul Gilmartin <[email protected]>
> Sent: Tuesday, May 29, 2018 12:25 PM
> To: [email protected]
> 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 [email protected] with the message: INFO IBM-MAIN
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to