Noticing that this thread continues to focus on how to make a recall of
the PROCLIB dataset work, I think it should be re-emphasized that any
managed data set that is essential to the proper functioning of JES2, or
any other critical started task at your site, should really be assigned
a Management Class that inhibits migration. In the worst case scenario,
you might find yourself in a catch-22 situation where you can't run
something you need in order to get DFHSM functional because the
rarely-used but required datasets are migrated, or the required ML1/ML2
volume is unavailable. In the best case, start up of some important
address space may be delayed because a RECALL must first complete.
Long-running address spaces that have JCL references to data sets that
are never opened, or which only open some datasets once at start up,
have migration exposures even if they are rarely inactive. We have been
mildly burned in the past by significant delays to production CICS
startup when the CICS down period just happened to overlap with HSM
daily migration processing. Last used dates on datasets are updated at
OPEN time, so when a CICS that only OPENs a required dataset once at
startup is terminated after running for several weeks, that dataset may
immediately be eligible for migration if daily migration is active. If
the dataset is large, you can end up having to wait many minutes for
both migration and subsequent recall to complete before the critical
address space can restart. Should that period when the critical
datasets are migrated also overlap DR point-in-time backups, you may
also be leaving an additional exposure for Disaster Recovery, as during
DR, DFHSM RECALL functionality may be delayed for an extended time while
switching DFHSM to use DR alternate tape volumes, or some very recent
ML2 volumes might be unavailable.
You should check all critical address spaces, not just JES2, for managed
datasets that should be protected by a no-migrate MgmtClass, and don't
forget to include special datasets that might be required just for DR,
or which are essential for running TSO/ISPF sessions of personnel who
need to manage the early phases of actual DR or DR testing. We
preferred to handle such dataset special cases by using DFP fields in
dataset and group RACF profiles to assign a special Management Class via
RACF, as that was much simpler to change (and less likely to break
"everything") than trying to maintain those exceptions in the SMS ACS
routines.
Joel C Ewing
On 03/21/2013 11:27 AM, willie bunter wrote:
Lizette,
Thanks for the advice. I have taken note of the suggestions and hopefully I can have the changes done.
Thanks.
________________________________
From: Lizette Koehler <[email protected]>
To: [email protected]
Sent: Thursday, March 21, 2013 12:18:03 PM
Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Willie,
As others have pointed out, a couple of solutions.
1) Use USER PROCLIB datasets in JCLLIB datasets in your JCL.
2) Have a NOMIG class in SMS that will not migrate the dataset.
PROCLIBs are touchy to JES2. I typically have my users code JCLLIB
statements, and I think the job will wait for the RECALL if they were
migrated. I can test that later.
Lizette
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf
Of willie bunter
Sent: Thursday, March 21, 2013 8:22 AM
To: [email protected]
Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Good Day Readers,
Several jobs are failing due to the following :
IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-
0009,9987,SMTP01,SYS2.HESP.BPROCLIB
IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,
IEF196I SYS2.HESP.BPROCLIB
$HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN -
JCL
ERROR
The problem was caused by the library which was migrated by HSM was
recalled to
another volume - SMTP03. The volumes in this Storage Group are SMS
managed.
I was able to get our MVS support folks to refresh the JES2 proc which
rectified the
problem (jobs were rerun successsfully).
My question is should a problem of this nature occur again (pds migrated)
how can I
force HSM to recall the dsn to the original volume? In this case the dsn
was recalled to
another volume other than the orginal.
Thanks.
...
--
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
