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 [email protected] with the message: INFO IBM-MAIN
