Re: TAA tool WRKIFS

On 26-Jan-2012 11:35 , John McKee wrote:

Trying to get a handle on how much is in IFS, I started the TAA tool
WRKIFS. That was over an hour ago. It did not submit a job to
batch. System Request elicits a BEEP. Like it was running an API
under the covers.

Can I go to another workstation and kill this interactive job
without hosing something?

An ENDJOB OPTION(*CTRLD) DELAY(100) [even if not specifying that longer than default=30 delay\wait time] should not cause a problem, unless the code running in the ended job does not properly clean-up after itself. However, consider...

FWiW:

Rather than just unconditionally end the [request or] job... there may be value in first investigating for what might possibly be wrong. The first thing I would usually do was to SNDBRKMSG to the workstation message queue [the device name] of the interactive job to see if that has any effect on the job not responding to the SysReq.

Perhaps both of dspjoblog job(TheJob) output(*print) and wrkjob job(TheJob) output(*print) for the other job before any ENDJOB. The joblog might, for example, show a device error which would explain the failure of the SysRqs. If a review of that spooled output is of no assist [e.g. no message and\or no call stack] then try also strsrvjob job(TheJob), and if that completes without error, then also issue a dmpjobint.

Having done those steps, even if the origin of the problem is not obvious, then some doc collections to allow for problem investigation would have been obtained while the job was active. If an attempt is made to end the job is done first, then not all of that information would be available if the request to end the job succeeds; i.e. not much left to review if further investigation seems warranted. And worse, if the request to end the job seems to have little effect, such that the job is seemingly never-ending, then there would have been little worthwhile problem-determination doc collection made available. Problem determination attempts made after the request to end the job are generally not very useful doc collections; i.e. usually requiring a problem re-create to investigate the problem anew.

Regards, Chuck