There can still be a serious problem with mass VARY commands despite the
huge improvements in CONSOLE and contention management, depending on how
the commands are issued. We experienced some episodes of severe degradation
while installing some new DASD subsystems. Our storage guys ran jobs on
member of a sysplex that issued a large number of commands like this:
ROUTE *ALL,V uuuu,ONLINE or OFFLINE
Command processing got so backed up that automation failed to respond to
some message traps for over an hour! The problem turned out to be
'aggregation', one system's attempt to gather responses from multiple
systems and display them all at once. It turns out that aggregation can
lead to a huge backlog of responses from ROUTEd commands even when the
commands are spaced out. Workaround is a little noticed parameter T=nnn on
the ROUTE command. From System Commands:
RO {sysname,text }
{[T=nnn,]{*ALL }[,L={a }] }
{sysgrpname } {name }
{*OTHER } {name-a }
{(sysname[,sysgrpname,sysname...])}
"T= Specifies an optional timeout interval. T= is valid with *ALL, *OTHER,
sysgrpname, or a list of system names or sysgrpnames. You can specify a
value from 0 to 999. This value indicates the maximum number of seconds MVS
waits for responses from each system before aggregating the responses.
If you specify T=0, MVS does not aggregate command responses, but
individually sends responses to the originator.
"Notes:
"1. IBM recommends that you specify T=0 when you are routing the START and
STOP commands to multiple systems. This is because the system does not
collect aggregate responses for routed START and STOP commands. If you
attempt to do so (if T= is nonzero), the system states that there is "no
response" from all of the systems, and all the START and STOP command
responses are displayed inline.
"2. IBM does not recommend that you specify T=0 for most DISPLAY commands.
Command responses from most DISPLAY commands appear in an out-of-line
display area, and the responses from multiple DISPLAY commands can be
written into the same area one right after the other, so that only the last
one is readable. If there is no display area defined, or if L=Z is used,
the responses are inline, but will probably roll off the console. Responses
from ROUTE with T=0 and a DISPLAY command specified could be useful to an
automation program and as a hardcopy record, but not for a human operator."
I myself would add Note 3: If you are issuing commands from within a batch
job, you don't care about aggregation, so please do specify T=0 to save
yourself a lot of grief.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
Mark Zelden
<[EMAIL PROTECTED]
CHNA.COM> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: Vary devices online and offline
08/28/2007 06:41
AM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
On Tue, 28 Aug 2007 09:12:15 -0400, John Eells <[EMAIL PROTECTED]> wrote:
>Rob Scott wrote:
>> In the "old" days, issuing lots of vary operator commands could cause
system problems - I am not sure if that has been fixed yet.
><snip>
>
>In z/OS R7, the code was changed to attach up to 32 subtasks to process
>VARY OFFLINE commands in parallel. In z/OS R8, it was changed to do the
>same for VARY ONLINE. We think this should have done a lot to relieve
>contention for, e.g., SYSIEFSD Q4 (and if I remember right--always a
>dangerous assumption--SYSIEFSD VARYDEV) while also processing VARYs for
>a large number of devices in considerably less time.
>
The problems Rob was probably referring to had more to do with
commands "backing up" and blowing away the commtask (console).
The console restructure took care of that problem. Although
obviously if you can do the commands in parallel, there is a much
less chance of them "backing up". But the same (console) problem
could happen in the "old days" from commands other than VARY also.
Our "vary offline at IPL" program still has a .2 second delay built
into it between commands because of the problem (changed from
.5 second delay several years ago due to the speed of modern
machines).
I remember a similar issue under MVS/XA where MSTJCL00 had a
region size coded of 32M and ran out of virtual storage.
Mark
--
Mark Zelden
----------------------------------------------------------------------
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
