Discussion:
Changing the way how ISPF recovery datasets are allocated
(too old to reply)
Elardus Engelbrecht
2018-10-08 08:29:30 UTC
Permalink
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.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Conley
2018-10-08 13:28:48 UTC
Permalink
Post by Elardus Engelbrecht
Good day to all,
<quote>
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.
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Michael Oujesky
2018-10-08 13:53:37 UTC
Permalink
ACS rule dataset masking. My ROT is to have each special case in
it's own DATACLAS identifying why it is an exception.

BTW, we also had this happen to us while attempting to get to
extended-format as the shop standard.
Post by Elardus Engelbrecht
Good day to all,
I see these restrictions for Edit Recovery Datasets from "z/OS ISPF
<quote>
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.
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.
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Joel C. Ewing
2018-10-08 13:53:59 UTC
Permalink
Post by Tom Conley
Post by Elardus Engelbrecht
Good day to all,
I see these restrictions for Edit Recovery Datasets from "z/OS ISPF
<quote>
     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.
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 ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...