× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Rob,

If I didn't mention this previously, this was a JVM job.
Do they normally take longer to end, I believe so?

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, July 30, 2015 8:08 AM
To: Midrange Systems Technical Discussion
Subject: Re: Job taking long time to end - CPC1165

When you read the help for the command ENDSBS you will see the following:
*IMMED
The jobs are ended immediately. When a job being ended has a
signal handling procedure for the asynchronous signal SIGTERM,
the SIGTERM signal is generated for that job and the QENDJOBLMT
system value specifies a time limit. ...

What this is saying is that you might want to look at who supplied that program and see if they have some documentation on how to configure that SIGTERM signal. Perhaps they have a .INI file or some such thing that you can modify. Failing any desire to clean this up normally you could look at that system value.

Except in the most extreme circumstances, such as a train derailment immediately outside our building spewing toxic chemicals and we have to shut down now, I try to use ENDSBS *CNTRLD with a time limit which seems to match QENDJOBLMT. This allows those processes that have SIGTERM signal to process it accordingly. Also, if you have a RPG programmer who actually gives a rip about clean alternatives to break out of a Never Ending Program they can check %SHTDN (Shut Down).

Tell you what, I'll submit a DCR to have them add *ENDJOBLMT, with help pointing to the system value QENDJOBLMT, to the DELAY parameter for ENDJOB. As part of that request I will ask that they change the default for the DELAY parameter from *NOLIMIT to *ENDJOBLMT. Hey, if those jobs that use SIGTERM processing don't care about *NOLIMIT anyway, why not? Do you really use ENDSBS QINTER OPTION(*CNTRLD) DELAY(*NOLIMIT) and have QINTER wait until all 600+ workstation users signoff before ending?
You could always use CHGCMDDFT to change it back, or start coding the
DELAY(*NOLIMIT) parameter into your shutdown and stop relying upon defaults.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 07/29/2015 08:50 AM
Subject: Job taking long time to end - CPC1165
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



On our R&D LPAR, I was ending some subsystems for a maintenance refresh
of data.
Normally, ENDSBS SBS(INTERFACD1) OPTION(*IMMED) will end all jobs in the
subsystem in less than 10 seconds.

One job threw a CPC1165, followed by a CPC1166, took over 2 minutes to
end.

I've never seen this behavior.

System values set at defaults.
I'm not sure increasing the system values would help.

Any thoughts from the group?

System value . . . . . : QENDJOBLMT
Description . . . . . : Time limit during immediate ending of a job

Seconds . . . . . . . : 120 30-3600

System value . . . . . : QPWRDWNLMT
Description . . . . . : Maximum time for PWRDWNSYS *IMMED
Seconds . . . . . . . : 900 0-32767



CPC1207 Completion 50 07/28/15 16:55:07.400361 QWTMMTRS
QSYS 0247 *EXT *N
From user . . . . . . . . . : QSYS

Thread . . . . : 00000001

Message . . . . : Subsystem ending
immediately.
CPC1165 Completion 50 07/28/15 16:55:07.813862 QWTMMTRS
QSYS 0771 *EXT *N
From user . . . . . . . . . : QSYS

Thread . . . . : 00000001

Message . . . . : SIGTERM signal
sent to job 472732/DEVD1/OBNORM01D.
Cause . . . . . : Job
472732/DEVD1/OBNORM01D is being ended immediately. The
job has a signal handling procedure
for the asynchronous signal SIGTERM. A
SIGTERM signal has been sent to the
job. A time limit of 120 seconds will be
used to ensure that the job ends.
CPC1166 Completion 50 07/28/15 16:57:08.378316
QWTMETMR QSYS 01BC *EXT *N
From user . . . . . . . . . : QSYS

Thread . . . . : 00000001

Message . . . . : Time limit
reached for SIGTERM signal handler.
Cause . . . . . : Job
472732/DEVD1/OBNORM01D did not complete during the
time allowed. An immediate end job
request was issued by the system. The
time limit was 120 seconds.
Recovery . . . : If the time limit of 120
seconds is not enough time for the
SIGTERM signal handler to complete,
contact your system administrator
to increase the time allowed by the
QENDJOBLMT and QPWRDWNLMT system
values.
CPF1164 Completion 00 07/28/15 16:57:09.485652 QWTMCEOJ
QSYS 014A *EXT *N
Thread . . . . : 00000001

Message . . . . : Job
472732/DEVD1/OBNORM01D ended on 07/28/15 at 16:57:09;
18.756 seconds used; end code 50 .

Cause . . . . . : Job
472732/DEVD1/OBNORM01D completed on 07/28/15 at
16:57:09 after it used 18.756
seconds processing unit time. The job had
ending code 50. The job ended after
1 routing steps with a secondary ending
code of 0. The job ending codes
and their meanings are as follows: 0 - The
job completed normally. 10 - The
job completed normally during controlled

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.