bug or no bug?

bug or no bug?

Post by Martin Hin » Sat, 30 Mar 2002 02:06:06



I'm running V4R5 and experience the following problem:

Running the command ENDTCPSVR to prepare for night-jobs
the system posts about 30 messages telling me that job
QP0ZSPWP ended, I just wonder why?

Martin Hinze

 
 
 

bug or no bug?

Post by Joel S. Muelle » Sat, 30 Mar 2002 03:18:40


QP0ZSPWP is a program used for prestart jobs (for spawn() API,
specifically).  Normally, prestart jobs don't show up on WRKACTJOB -
pressing F14=Include will show prestart jobs (Type PJ).  Prestart job names
come from the program name (QP0ZSPWP in this case).  I am guessing that when
you ENDTCPSVR, the prestart jobs are also being ended, hence the messages.
Prestart jobs are associated with a subsystem.  There are used as a kind of
"pool" of jobs which are ready and available to take work (so you don't pay
overhead of starting a job before the work can be handed off).  I don't
think it is a bug - just ENDTCPSVR cleaning up after itself.  Just curious -
where do you see the system posting the messages?

--
Joel S. Mueller


Quote:> I'm running V4R5 and experience the following problem:

> Running the command ENDTCPSVR to prepare for night-jobs
> the system posts about 30 messages telling me that job
> QP0ZSPWP ended, I just wonder why?

> Martin Hinze


 
 
 

bug or no bug?

Post by Martin Hinz » Sun, 31 Mar 2002 17:59:34


Thanks Joel.

These Endofjobmsg's go to my MsgQ, as I submit the good-night-job. I bother
because these messages are like spam and I have to scroll through lots of
them when I want to see what happend to the last jobs I submitted before
leaving off work.

So if You have an idea to avoid that "problem" I'd very much apreciate.

Martin Hinze

 
 
 

bug or no bug?

Post by Ugo Gagliardell » Sun, 31 Mar 2002 23:57:00


 > Thanks Joel.
 >
 > These Endofjobmsg's go to my MsgQ, as I submit the good-night-job. I
 > bother because these messages are like spam and I have to scroll
 > through lots of them when I want to see what happend to the last
 > jobs I submitted before leaving off work.
 >
 > So if You have an idea to avoid that "problem" I'd very much
 > apreciate.
from your cl SBMJOB CMD(ENDTCP). If you want to control whether the
submitted job is finished RCVMSG *LAST, you'll get the name of the job,
then loop as needed, e.g. with  CHGJOB RUNPTY(50) testing CPF1290 that
mean job completed.

--
Dr.Ugo Gagliardelli,Modena,Italy-Certified uindoscrasher-AlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome
Spamers iros a la mierda/Spamers allez vous faire foutre
Spammers loop schijten/Spammers macht Euch vom Acker

 
 
 

bug or no bug?

Post by Joel S. Muelle » Thu, 04 Apr 2002 08:07:38


Martin,

What is the message ID in your MsgQ that you are seeing?  Your initial
question seem to imply it was related to prestart jobs that were available
in a subsystem, but when the END was done, those jobs were also ended, and a
message (CPF????) sent.  But, now I am starting to wonder if the message you
are seeing is actually CPF1241 (Job 123456/QUSER/QP0ZSPWP completed
normally...).  That completion message is a difficult one to get rid of,
when the job is a prestart job.  There isn't any control over whether that
message is sent or not in a spawn() prestart job scenario.  SBMJOB has that
control (MSGQ parameter - Message queue - can be set to *NONE), and a
"normal" spawn() will not send CPF1241 by default, but spawn() to a prestart
job does not have that control.  As Ugo mentioned, about the best I could
offer would be to have a program you could run which either removes those
entries (after the fact), or simply looks for messages other than the
completion message.

--
Joel S. Mueller


Quote:> Thanks Joel.

> These Endofjobmsg's go to my MsgQ, as I submit the good-night-job. I
bother
> because these messages are like spam and I have to scroll through lots of
> them when I want to see what happend to the last jobs I submitted before
> leaving off work.

> So if You have an idea to avoid that "problem" I'd very much apreciate.

> Martin Hinze

 
 
 

bug or no bug?

Post by BL » Thu, 04 Apr 2002 08:53:47


If the messages being seen are the normal "Job ... completed normally"
messages, would they not show up in the msgq of the user who
originally issued the STRTCPSVR command?  It seems to me that the
solution is to move the STRTCPSVR command to the system startup
program and let these messages go to the default message queue.

On Tue, 2 Apr 2002 17:07:38 -0600, "Joel S. Mueller"


>Martin,

>What is the message ID in your MsgQ that you are seeing?  Your initial
>question seem to imply it was related to prestart jobs that were available
>in a subsystem, but when the END was done, those jobs were also ended, and a
>message (CPF????) sent.  But, now I am starting to wonder if the message you
>are seeing is actually CPF1241 (Job 123456/QUSER/QP0ZSPWP completed
>normally...).  That completion message is a difficult one to get rid of,
>when the job is a prestart job.  There isn't any control over whether that
>message is sent or not in a spawn() prestart job scenario.  SBMJOB has that
>control (MSGQ parameter - Message queue - can be set to *NONE), and a
>"normal" spawn() will not send CPF1241 by default, but spawn() to a prestart
>job does not have that control.  As Ugo mentioned, about the best I could
>offer would be to have a program you could run which either removes those
>entries (after the fact), or simply looks for messages other than the
>completion message.

>--
>Joel S. Mueller



>> Thanks Joel.

>> These Endofjobmsg's go to my MsgQ, as I submit the good-night-job. I
>bother
>> because these messages are like spam and I have to scroll through lots of
>> them when I want to see what happend to the last jobs I submitted before
>> leaving off work.

>> So if You have an idea to avoid that "problem" I'd very much apreciate.

>> Martin Hinze

 
 
 

bug or no bug?

Post by Martin Hinz » Fri, 05 Apr 2002 16:57:24


Quote:> If the messages being seen are the normal "Job ... completed normally"
> messages, would they not show up in the msgq of the user who
> originally issued the STRTCPSVR command?  It seems to me that the
> solution is to move the STRTCPSVR command to the system startup
> program and let these messages go to the default message queue.

This is where the STRTCPSVR command is running!

Quote:> message you are seeing is actually CPF1241 (Job 123456/QUSER/QP0ZSPWP
completed
> normally...).

You are right, this is what i'm seeing. But why causes the end-command to
start this much jobs? Can't we stop this?

Martin Hinze

 
 
 

bug or no bug?

Post by Joel S. Muelle » Sat, 06 Apr 2002 00:27:18


Martin,

Based on the circumstances, I am guessing that during the ENDTCPSVR, one of
the servers is running shell scripts (QSH).  QSH uses spawn(), and attempts
to use prestart jobs if available.  If they are available, the "response"
time improves (but system thruput remains the same).  If they are not
available, it pretty much turns into a "normal" spawn(), but on the child
side, the prestart job program is still used (QP0ZSPWP).  So, it is to QSH
advantage to try and use prestart jobs.  There is an environment variable
you can set to tell QSH to _not_ use prestart jobs.  This, in turn, uses the
"normal" spawn(), and (as I mentioned), the completion message to the user
message queue is not sent in that case.  I am not sure exactly how ENDTCPSVR
processing works, but you could give this a try:

ADDENVVAR ENVVAR(QSH_USE_PRESTART_JOBS) VALUE(N)
ENDTCPSVR ...

I don't know if it will work, but give it a try (next time) and let us know.
The other solution would be to write a program that removes (just) those
messages from the user message queue, and run that program after-the-fact.

--
Joel S. Mueller


Quote:

> > message you are seeing is actually CPF1241 (Job 123456/QUSER/QP0ZSPWP
> completed
> > normally...).

> You are right, this is what i'm seeing. But why causes the end-command to
> start this much jobs? Can't we stop this?

> Martin Hinze

 
 
 

bug or no bug?

Post by Martin Hin » Sat, 13 Apr 2002 07:15:38



Quote:> I am not sure exactly how ENDTCPSVR
> processing works, but you could give this a try:

> ADDENVVAR ENVVAR(QSH_USE_PRESTART_JOBS) VALUE(N)
> ENDTCPSVR ...

> I don't know if it will work, but give it a try (next time) and let us know.
> The other solution would be to write a program that removes (just) those
> messages from the user message queue, and run that program after-the-fact.

> --
> Joel S. Mueller

Thanks Joel!

That did the job!

But...

Is there no other way to stop starting a lot of unnecessary jobs just
to finish immediately?

What am i doing wrong in starting/configuring my AS/400 as i don't see
the same behavior on other systems?

Martin Hinze

 
 
 

bug or no bug?

Post by Joel S. Muelle » Wed, 17 Apr 2002 02:44:49


Martin,

Again, I don't know all the details of ENDTCPSVR, but from my past
experience with this situation, my best advice (to limit the number of jobs
"started" in order to end the servers - sounds funny, doesn't it...) is to:
1) Only start the TCP servers you are using (namely, don't do *ALL)
2) Only end the TCP servers you started (namely, don't do *ALL)

It is my understanding, that ENDTCPSVR *ALL forces each server to "check" if
they are active or not.  Some servers can do this quickly, other servers are
not so quickly (and during this check, they run QSH shell utilities, which
causes the start up of jobs - not so efficient if they did this just to find
out they don't need to end).

Here is the catch-22 for you:  If you are concerned about the "speed" it
takes to end servers (which use QSH), then you want to configure spawn()
prestart jobs, and let QSH use those prestart jobs.  In that case (prestart
jobs), you always get the completion message.  If you are only concerned
about the completion messages, then the solution I gave you earlier appears
to work for you (good!).

You _may_ be able to avoid both issues by just starting/ending the servers
you are interested in, as I just described above.  I say "may", since it
very well may be that one of the servers you are interested in uses QSH
during its processing.  In that case, you cannot call them "unnecessary"
jobs (I think the server in question would highly disagree with you
-)   ).

I speak only for myself.
--
Joel S. Mueller



Quote:> > I am not sure exactly how ENDTCPSVR
> > processing works, but you could give this a try:

> > ADDENVVAR ENVVAR(QSH_USE_PRESTART_JOBS) VALUE(N)
> > ENDTCPSVR ...

> > I don't know if it will work, but give it a try (next time) and let us
know.
> > The other solution would be to write a program that removes (just) those
> > messages from the user message queue, and run that program
after-the-fact.

> > --
> > Joel S. Mueller
> Thanks Joel!

> That did the job!

> But...

> Is there no other way to stop starting a lot of unnecessary jobs just
> to finish immediately?

> What am i doing wrong in starting/configuring my AS/400 as i don't see
> the same behavior on other systems?

> Martin Hinze

 
 
 

bug or no bug?

Post by Martin Hin » Thu, 09 May 2002 00:40:17



Quote:> Martin,

> Again, I don't know all the details of ENDTCPSVR, but from my past
> experience with this situation, my best advice (to limit the number of jobs
> "started" in order to end the servers - sounds funny, doesn't it...) is to:
> 1) Only start the TCP servers you are using (namely, don't do *ALL)
> 2) Only end the TCP servers you started (namely, don't do *ALL)

Joel

meanwhile i had the opportunity to test the changed "good-night-job"
and it worked! I named the (started) servers in the ENTTCPSVR command
and used the ENDTCP with ENDSVR(*NO), that did the job!

Martin