IBM Red Alert, July 02, 2009

2009-07-02 Thread Michael R. Mayne

This dropped into my in-box this morning, please check it out.

Text:
---
Abstract:

z/OS 1.8 and z/OS 1.9 with PTFs for OA28473 can result in VSAM datasets
with invalid creation dates being deleted
Description:

HSM may expire and delete VSAM data sets because of an invalid creation
date caused by a DSS RESTORE or HSM RECALL/RECOVER of a VSAM data sets.
This occurs after the application of PTF's UA46732/UA47067 for z/OS 1.8
or PTF's UA46733/UA47068 for z/OS 1.9 when DFSMSdss alters the creation
date of the VSAM data set to an incorrect date (e.g. 1901.921 or
something similarly invalid). You can see the invalid date via LISTCAT
or IEHLIST for the data set. DFSMShsm may expire these data sets during
Primary Space Management or Secondary Space Management based on your
expiration attributes in the associated Management Class for the SMS
managed data sets or based on the specific expiration date for Non-SMS
managed data sets.

DFSMShsm uses DFSMSdss Logical Data Set RESTORE to RECALL and RECOVER
VSAM data sets, therefore the same problem can result.

See APAR OA29102 for additional details and methods to identify data
sets that may have been affected.
Recommended Actions:

Please apply fix for OA29102 to prevent the problem.
---
Link:
http://www14.software.ibm.com/webapp/set2/sas/f/redAlerts/20090702.html

Could get ugly...

-Mike

--
Michael R. Mayne
Systems Programmer III
Huntsville Hospital System
101 Sivley Rd. SW
Huntsville, AL 35801-4421

Email: michael.ma...@hhsys.org
Email: mma...@hhsys.org (old)
Tel: (256) 265-9012




Confidentiality Note: 
http://www.huntsvillehospital.org/footer/disclaimer/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM Red Alert, July 02, 2009

2009-07-02 Thread Paul Gilmartin
On Thu, 2 Jul 2009 14:30:37 -0500, Michael R. Mayne wrote:

HSM may expire and delete VSAM data sets because of an invalid creation
date caused by a DSS RESTORE or HSM RECALL/RECOVER of a VSAM data sets.
This occurs after the application of PTF's UA46732/UA47067 for z/OS 1.8
or PTF's UA46733/UA47068 for z/OS 1.9 when DFSMSdss alters the creation
date of the VSAM data set to an incorrect date (e.g. 1901.921 or
something similarly invalid).

More subtle might be the possibility that DFSMSdss alters the
creation date to something valid but incorrect (however
implausible) such as 1956.025.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM Red Alert, July 02, 2009

2009-07-02 Thread Michael R. Mayne
Good point...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IBM Red Alert, July 02, 2009

2009-07-02 Thread Anthony Fletcher
APAR OA28473 had a PTF for z/OS 1.10 (UA47631) as well as the PTFs for 
z/OS 1.9 and 1.8.
UA47631 is not marked PE.

This may be valid because the z/OS 1.10 code would have to have additional 
processing for EAV - but what if it should have been marked PE as well?

Has anyone asked IBM to confirm that this is not an oversight and that 
UA47631 is not PE as well?

Anthony Fletcher

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html