IBM i Global

Dear Giancarlo

How many threads are there in that problematic job?   Use WRKACTJOB and press F11 twice until your see "Threads" column. Long ending time mostly happens to jobs with many threads. The more threads, the longer it takes.

Did that job show Status other than END during the long ending time? 

Have you looked into the job log to see details of what happened after the moment ENDJOB was issued? This may give you clues. 

Next thing to check is to run WRKSYSSTS screen and then press F11 to see job transition columns and then keep pressing F10 after you issue ENDJOB to see if you see Wait--> Inel and/or Active --> Inel showing values more than zero or not during the job ending?  If you see non-zero values, you may want to increase the Max Active value of the memory pool in which the job runs. Increase by the value of the number of threads that job has.  If this is *BASE pool, you should set its Max Active value to at least 1,000. 

Hi Giancarlo, 

SYSTOOLS.HTTPXXX uses Java methods (that's the reasons why it causes so many threads) when awaiting for Webservices to respond. There isnt much timeout values that you can pass with the SYSTOOLS functions, whereas QSYS2 you have timeout values to your disposal that can help with waiting HTTP Responses. 

I assume also when running in QSH, (if I understand and follow correctly), is causing some of those threads to stall out eventually as you are passing boundries with internals which doesnt allways work out so well between PASE and ILE. (thats my theory, difficult to prove though in some unexplained scenarios I have experienced that PASE/QSH doesnt work that well with SYSTEM java but better with OpenJDK instead). . 

You can try to convert the calls to QSYS2.HTTP functions instead which doesn't use Java (those anyways run way quicker in my opinion and is future proof). 

To suggest also submitting and running those in a specific subsystem, you can then initiate the ENDSBS additional options of  ENDSBSOPT (*CHGPTY *NOJOBLOG) if you need to end them quicker.(this will also allow the system to prioritize resources to that subsystem depending on how busy the system is at that time you are executing these commands.) 

Then lastly last option on ENDJOB SPLFILE(*YES) can also help somewhat together with what Satid mentioned  on increasing of the Max active on that pool. 

HTH 

To move away from the old Java-based HTTP functions in SYSTOOLS to the new more efficient ones in QSYS2, there are many useful articles to learn from such as these:

New HTTP functions based in QSYS2 at https://www.ibm.com/support/pages/new-http-functions-based-qsys2   

New QSYS2.HTTP Functions SQL at https://blog.faq400.com/en/db2-for-i/qsys2-http-functions-en/     

Using the New SQL HTTP Functions (Part 1 of 2) at https://techchannel.com/open-source-on-ibm-i/using-the-new-sql-http-functions-part-1-of-2/      

Using the New SQL HTTP Functions (Part 2) at https://techchannel.com/open-source-on-ibm-i/using-the-new-sql-http-functions-part-2/   

Configuring IBM i DB2 QSYS2 HTTP Functions for TLS/HTTPS Secure Communications at https://www.ibm.com/support/pages/configuring-ibm-i-db2-qsys2-http-functions-tlshttps-secure-communications    

Prueba asi:  ENDJOB ?*JOB(033720/BCOOPR/ACHPPP1)  DELAY(5)  LOGLMT(0) 

Si eso no funciona el trabajo esta realizando algun Roolback por control de compromiso

Giancarlo,

I agree with Walter.  I've found that ending jobs *CNTRLD with a 3-5 second delay works much better then *IMMED. 

Cheers,

Sandi