On 10/08/2018 08:28 AM, Tom Conley wrote: > On 10/8/2018 4:29 AM, Elardus Engelbrecht wrote: >> Good day to all, >> >> I see these restrictions for Edit Recovery Datasets from "z/OS ISPF >> Planning and Customizing" (z/OS v2.2): >> >> <quote> >> >> These restrictions apply to edit recovery data sets: >> >> They must be allocated as sequential data sets of record format U. >> They cannot be striped, or striped and compressed data sets. >> They cannot be multivolume data sets. >> >> <end-quote> >> >> One of my Storage Admin guys changed (to resolve an unrelated >> problem) the default SMS Data class to have 'DATA SET NAME TYPE' as >> EXTENDED and other new attributes resulting in that the ISPF Recovery >> datasets are 'striped'. >> >> Which means that I see 'Recovery suspended-error' in an ISPF Edit >> session and a long description what was wrong. >> >> I also see this: IGD17070I DATASET ?.ISP7195.BACKUP ALLOCATED >> SUCCESSFULLY WITH 1 STRIPE(S). >> ... then a IGD101I followed by IGD105I where it was deleted >> immediately. >> >> That change was reversed eventually because of the allocation error, >> but it may be needed to re-apply the new changes in the Data class. >> >> Question: >> >> Where can I change the allocation behaviour of ISPF to force another >> Dataclass to be selected? I already looked at ISPCCONFIG, but there >> is nothing about selecting right SMS class(es). >> >> If that is not possible, is it Ok to rather create a Data Class rule >> where <?>.ISP*.BACKUP datasets are assigned to another dataclass? Or >> are there better solutions? >> >> Many thanks in advance. >> > > If you really want to default everything to striped, then you need to > create a DATACLAS and the appropriate ACS routine code to ensure that > the recovery datasets are correct. > > Regards, > Tom Conley > ... > Obviously an implicit "else" after "default everything".
The Storage Admins need to be aware about all restrictions on these data sets, not just the striping restriction. The more inclusive statement is that SMS definitions can override data set characteristics coming from any other sources (like ISPF). So, once Storage Admins have managed to demonstrate a non-awareness of special requirements for Edit Recovery data sets, this demonstrates the need for a separate documented DATACLAS and ACS routine so they are [hopefullly] unlikely to make a similar mistake in the future. The DATACLAS/ACS code documentation should include all the restrictions and also a reference to where these restrictions may be found, should they change at some point in the future. Joel C. Ewing -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
