I guess we shouldn't assume that people should realize that ENDJOB will,
actually, end a job.
Or, maybe that an active 5250 session is considered a job.

Please don't take this sarcastically. I don't mean it that way.
I'm just thinking that, if the above is the case, then I'm going to have a
real tough time trying to explain to you that you can spool up printouts
and have them NOT be associated with a job. Therefore, when they are gone
they will not show up as FIN. There are some other ramifications to that.

Another item to consider is not spooling up stuff. For example, if you're
generating a spool file, using DSPFFD OUTPUT(*PRINT) for example, but
never physically printing that spool file but only reading it with a
program, then you may want to consider using an API or some other
technique to generate the desired data.

Another thing you may want to consider is actually signing off once in
awhile. If that job stays signed on as that person for days, shared by
people on multiple shifts, then many of us would consider that poor form.
And could provide a litany of reasons why but we won't waste our time and
yours unless you ask.

Now, there are some really strange jobs that 'look' like they are gone yet
reappear. Same job, user and even job number. Even across IPLs. The
recipient of SNDNETSPLF for one. The only way to reset that is with the
previously suggested ENDJOB SPLFILE(*YES).

This mailing list archive is Copyright 1997-2015 by MIDRANGE dot 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 here. If you have questions about this, please contact