ADSM-L

Re: MVS-Server goes to sleep when waiting for a tape

1997-01-13 16:43:13
Subject: Re: MVS-Server goes to sleep when waiting for a tape
From: "Douglas E. Babcock" <babcock AT TMD DOT COM>
Date: Mon, 13 Jan 1997 15:43:13 CST
Hi Matthias,

This is not a problem with ADSM, but rather with MVS and MVS/DFP or
DFSMSdfp, whichever version you happen to running. The problem is that the
MVS allocation recovery routines hold an enequeue on the SYSZTIOT resource
while waiting for the operator to reply to the IEF238D message and then
while waiting for a device to become available. The long duration SYSZTIOT
enqueue (which violates some obvious multiprogramming coding rules)
effectively locks up all other tasks in the address space that need access
to the TIOT (MVS Task Input/Output Table), including those tasks doing
simple DFP requests like data set OPEN and CLOSE. The SYSZTIOT enqueue
problem caused by the Allocation recovery routines is common to any and all
multitasking MVS applications.

The only workaround I have found to the DFP limitation is to set up the
multitasking application (in this case ADSM)  in such a way to ALWAYS ENSURE
that a tape device is available, i.e. to eliminate all possible causes of
the IEF328D message. Typically, this means limiting the number of concurrent
devices in use by ADSM and/or reserving that number of devices for ADSM's
exclusive use under MVS, perhaps by defining a unique esoteric group of tape
drives exclusively for ADSM use.

I have to admit I'm not an ADSM user, so I can't provide the specifics here.
I do, however, have a great deal of experience with multitasking
applications and the underlying SYSZTIOT enqueue problem. I should also note
that the DFHSM developers ran across this problem and initially coded around
it by issuing their own "mount" message (see message ARC0366A). I believe
that later versions of DFHSM moved those HSM components that could cause
SYSZTIOT lockouts into a seperate address space (each using a unique TIOT).

The SYSZTOIT enqueue problem has been reported to IBM via numerous APARs,
including OW09138, which to the best of my knowledge have all been closed
"SUG" (suggestion, to be included in a future release). There is also an IBM
HONE REQUESTS data base item number REQ00059075.

In order to help persuade IBM to get the SYSZTIOT enqueue problem fixed, I
would strongly recommended that your site (AND OTHERS!) contact your local
IBM representative and have them issue a REQUEST CONCURRENCE action for the
IBM HONE system REQUESTS data base item number REQ00059075.

Until then, you probably need to direct your efforts towards preventing the
IEF238D message in the first place.

Hope this sheds some light on your problem.
Doug

---
At 08:58 AM 01/13/97 -0500, you wrote:
At 08:58 AM 01/13/97 -0500, you wrote:
>High to all ADSM'ers,
>
>I'm running ADSM-MVS-Server V2.1.09 and the following effect
>appears when I'm running an 'backup storage pool' :
>The tapes from the pool 'CTAPE_COLLOCATION' are to be copied
>into the backup storage pool 'MTAPE_COPYPOOL'.
>This works fine until the tape on device MTAPE will be full
>and ADSM needs the next scratch tape to be mounted.
>If there is no free device for the mount of the new tape
>the MVS-message 'IEF238D ... Reply device name...' appears.
>This message is answered with 'reply xx,wait' and so the
>next message 'IEF238D wait requested ...' appears.
>This message is answered with 'nohold'.
>This is the moment when ADSM goes to sleep until anything happens
>with the tapes ( another Task like dfhsm frees one device ).
>The problem is that the tape which is already mounted on MTAPE
>and which is full will not be dismounted until ADSM has an free
>device to mount another tape.
>This is an deadlock situation and is an ADSM-error I think.
>The problem is that not only the backup task hangs but all
>adsm processing stops. Even the client-sessions and admi-sessions
>are hanging.
>ADSM should dismount the full tape immediately and not wait
>for the next tape mounted on another device.
>I know about the 'mount-retention' parameter and set this to '0'.
>
>Anyone any  Idea ?
>
>Best regards,
>Matthias Brasch, HEW-Hamburg, M_Brasch AT compuserve DOT com
>
>

Doug Babcock <babcock AT tmd DOT com>
TMD Consulting Inc., a tiny little division of StorageTek
Standard disclaimers apply (free copy on request)
---
Personal Computer is an oxymoron. Real computers need plumbing.
Personal Computer is an oxymoron. Real computers need plumbing.
<Prev in Thread] Current Thread [Next in Thread>