RE: Bunch of QPWFSERVSD & QZDASRVSD jobs sitting on jobq

["Dan Bale" <dbale@xxxxxxxxx>]

Actually, I just determined that I lied about that. <g>  Turns out that the
QSERVER subsystem is not even active on the one system where the jobs have
been collecting in the jobq.  This system IPLs every Monday morning, so
apparently this is not being started at IPL.

The startup program on the box in question has been modified, as I have just
determined.  I retrieved the source of both the QGPL and the QSYS versions
of QSTRUP.  It is interesting to note that &CPYR variable in the QGPL
version of the program is given a value of
'5738-SS1 (C) COPYRIGHT IBM CORP 1980, 1991. <snip>',
whereas the QSYS version shows
'5763-SS1 (C) COPYRIGHT IBM CORP 1980, 1994. <snip>'.
I'm not sure, but didn't 5738-SS1 belong to V2R3?

Functionally, I can see that the QGPL version is not starting QSERVER as
does the QSYS version.  Also, the QGPL starts the QSNADS sbs, whereas the
QSYS version does not.  Over on the other box, which uses the QSYS version,
I noticed that QSNADS is not referred to in that program either, but QSNADS
is active on that box.  Don't know if anyone manually starts that one, or if
something else at IPL starts it.

Advice welcomed.

Dan Bale
SAMSA, Inc.
989-790-0507
DBale@SAMSA.com <mailto:DBale@SAMSA.com>
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)


-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On Behalf Of thomas@inorbit.com
Sent: Wednesday, March 20, 2002 9:02 PM
To: midrange-l@midrange.com
Subject: RE: Bunch of QPWFSERVSD & QZDASRVSD jobs sitting on jobq


Dan:

On Wed, 20 March 2002, "Dan Bale" wrote:

> >startup program<
> This is fine and good, but sometimes the subsystems will be taken down and
> then brought back up without an IPL.  That is why I have it on the job
> scheduler.

There's nothing wrong with using the job scheduler as you're doing. However,
keep in mind that having various *jobqs held might make it pointless to
issue STRHOSTSVR. You might want to check into why that particular *jobq got
held in the first place.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com