I've never worked in a shop where it was tolerable to permit DFDSS to hold
the SYSVTOC enq/reserve for the entire length of a dump - and this was on
relatively small mod 3 and mod 9 DASD, and not the huge volumes you're
talking about. For this reason, I've always had the following in place:
++USERMOD(ADRUENQ) REWORK(2006145)
/*
*/ .
++VER(Z038) FMID(HDZ11K0) .
++SRC(ADRUENQ) DISTLIB(ASAMPLIB) .
ADRUENQ CSECT
ADRUENQ AMODE 31
ADRUENQ RMODE 24
STM 14,12,12(13)
USING ADRUENQ,15
LM 14,12,12(13)
LA 15,4
BR 14
END
The tradeoffs are described in topic 8.4 Enqueue Installation Exit Routine
(ADRUENQ) in manual z/OS DFSMS Installation Exits.
Brian
On Thu, 21 Dec 2006 15:07:21 -0800, Edward Jaffe wrote:
>If you collect SMF Type 19 records, beware that an
>SMF-initialization-time LSPACE request is issued for every volume
>connected to the system. If SYSVTOC.volid is held by another system for
>any significant period of time, an IPLing system will appear to be
>"stuck". This happened to us and we had to wait over half an hour for a
>full-volume dump (occurring on another system) of a 60K cylinder DASD to
>finish before SMF would initialize and the IPL could continue. The
>contention looked like this:
>
>ISG343I 08.05.18 GRS STATUS FRAME LAST F E SYS=MVS70
>S=SYSTEMS SYSVTOC TIVSM4
>SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS
>MVS70 DFHSM70 0026 00BA2E88 EXCLUSIVE OWN
>MVS60 SMF 0018 00BFD0C0 EXCLUSIVE WAIT
>
>IBM's suggestion for a fix/workaround/solution? Don't collect SMF Type
>19 records. :-(
>
>--
>Edward E Jaffe
----------------------------------------------------------------------
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
