----- Original Message -----
From: "Greg Shirey" <[email protected]>
Newsgroups: bit.listserv.ibm-main
Sent: Tuesday, March 30, 2010 4:35 PM
Subject: Re: PPT entries for RMM
We have nothing in SCHEDxx either.
I found the following in redbook "Converting to RMM: A Practical Guide"
http://www.redbooks.ibm.com/redbooks/pdfs/sg244998.pdf
"Update SCHEDxx if you want to ensure that the PARMLIB data set named in
the
DFSMSrmm started procedure does not cause enqueue contention while
DFSMSrmm is running. If the DFSMSrmm procedure JCL allocates the PARMLIB
data set, we recommend that you avoid the resulting enqueue. If you use
the
default of SYS1.PARMLIB, or a data set in the system PARMLIB
concatenation,
you do not need to update SCHEDxx.
If you update SCHEDxx, the DFSMSrmm started procedure will not enqueue
any
of the data sets it allocates. Someone who is authorized to use these
data sets
could scratch them while DFSMSrmm is running without DFSMSrmm knowing
about it."
HTH,
Greg Shirey
Ben E. Keith Company
Greg,
The Redbook is wrong now and was never updated. The PPT entries were way
overkill when a FREE=CLOSE would have sufficed. RMM was fixed ages ago
after a customer nuked the CDS while RMM was up. for anyone reading this,
DO NOT SCHEDxx entries for RMM! Use an RMM proc without an IEFRDER DD for
PARMLIB, and RMM will use the concatenated PARMLIB support.
Regards,
Tom Conley
----------------------------------------------------------------------
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
