Ron: Not disagreeing with you but *OUR* issue that (mind you infrequently) was that a program would manage to pick up data from a previous day (and that caused havoc). I got involved in several of these and always found when it happened (picking up"invalid data") was a combination of bad programming and scheduling. The specifics are vague in my memory and too long to go into here. But to keep it short the shop had decided to manage by uusual rather than by exception. I fought for years to get them to change it. I couldn't as I didn't have DFHSM we had DMS(?) and the exception tables were miles long and enough work to keep a person busy for at least 1 day a week. I proposed going SMS and suggested they start getting ready by going GDG's. The idiot in charge of production support was a nightmare of a person who was so mired in history that he resisted.
We finally had a showdown meeting. He was so full of illiogic that it took 45 minutes of getting his logic straightened out to just get back to talk about converting over to GDG's that I was exhausted. We finally arrived at the decision to go to GDG shortly after that I left the company and was so happy I didn't have to bat my head against the wall that it was a good feeling. It took them 2-3 years to convert and they were happy as no more exemption tables and if/when it was updated. I regularly ran reports on space wasted because of no dsorg and on a daily cycle it was a couple of 3390's. Production was semi sacred and the production people got what they asked for except when I dug in my heals. Speaking of DSORG we had IDMS and I got in an argument with the IDMS people about their data sets (Data bases) the IDMS people their data sets were movable (they weren't except with their utilities) There was no real way to figure out which were Data Bases and which weren't. I did the conversion between 3380's and 3390's and of course the databases weren't marked by PSU so DFDSS moved the databases and the outage was chalked up to the DB people as the data sets were NOT movable. I won that argument and the DBA's got the egg. Ed ________________________________ From: Ron Hawkins <[email protected]> To: [email protected] Sent: Sat, April 9, 2011 3:52:16 AM Subject: Re: DATACLASS Joel, > > Also, at some point (within the last decade?) allocation of an > SMS-managed sequential data set began allocating the data set in a state > where an initial read returns an immediate EOF rather than random old > track data. It is no longer necessary for some program to explicitly > OPEN such a data set for output for cases where the file should contain > 0 records, and unlike the old days the file is no longer in an undefined > state until the first write after allocation. > JC Ewing > [Ron Hawkins] I think this comes back to what I think the OP is trying to achieved. For an SMS managed dataset to have the implicit EOF it must have a DSORG. Where this cannot be established, (by I think DADSM), it is established practice to apply a default DATACLAS to assign DSORG=PS. My recollection is DFHSM space mismanagement was the main beneficiary of the EOF, as this allowed the dataset to be migrated and have space released. Ron ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
