× 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.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.