Midrange News for the IBM i Community


Posted by: clbirk
endjob command
has no ratings.
Published: 04 Mar 2013
Revised: 05 Mar 2013 - 1664 days ago
Last viewed on: 23 Sep 2017 (3244 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

endjob command Published by: clbirk on 04 Mar 2013 view comments(3)

Awhile back on the forum I was looking for a way to end a certain user (or users) job. I got alot of discussion why the VP could not properly sign off, etc. but no solution.  I had thought somehow of running a report of online users, and grabbing the spool file and then creating some commands to end the job.

The other day I was looking over Giovannti Perotti's site (easy400.net) as I do use a few of his tools and saw he had a new command ENDJOBS.

 

Does exactly what I want. I can go and end like disconnected jobs or all jobs in either a subsystem or across whole system, etc.  Pretty slick.

 

So I thought I would mention it in case anyone else has a need for such.

 

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: DaleB
Premium member *
Reading, PA
Comment on: endjob command
Posted: 4 years 6 months 21 days 18 hours 32 minutes ago

In general I've found Giovanni's code to be pretty solid. His style is a lot different from mine, but it's good code. Without having looked at the ENDJOBS code, I'll guess he's used the List Jobs (QUSLJOB) API, and probably also the Retrieve Job Information (QUSRJOBI) API, both of which were no doubt mentioned in your original thread.

If you decide to roll your own:

  • First choice should almost always be an API, if one is available and it's not too complicated.
  • Next choice should be OUTPUT(*OUTFILE). Either there's no API, or the API is complicated and an equivalent outfile exists (and would be much faster to code).
  • Last choice would be OUPTUT(*PRINT) followed by CVTSPLF  and reading the resultant file. Before there were outfiles on many of the display commands (which were before most of the APIs), this was your only choice. Biggest problem with *PRINT is it's not upwards compatible; new release of OS, or even a PTF apply, can break your code.
Posted by: Ringer
Premium member *
Comment on: endjob command
Posted: 4 years 6 months 21 days 18 hours ago

Last I checked (a few years ago), he doesn't manage service program signatures very well. if you install a new version of one of his tools and don't recompile your programs, they blow up with a signature violation. Would be nice if he used a named signature instead of letting the system create one. Or maybe he is now, not sure.

Chris Ringer

Posted by: neilrh
Premium member *
Jackson, MI
Comment on: endjob command
Posted: 4 years 6 months 21 days 16 hours 41 minutes ago

The problem I used to have with the *OUTFILE solution, is that between releases there was frequently addition of new fields to the outfile, which would typically blow out the processing program on a level check. My solution was to create a temporary (use for compile) version of the outfile, and then crtdupobj to QTEMP and use that as a basis for the retrieve command, the command was smart enough to ignore the missing fields, and my program didn't need to be recompiled (and also didn't care about the new fields in the latest release outfile).

But all these hassles encouraged me to move to API's. Especially since my job used to be to fix everyone elses errors at OS upgrade for when they used OUTFILE as a solution.