ENDING QINTER

10 pts.
Tags:
ENDSBS
iSeries
QINTER
We end QINTER middle of night for a backup - if an interactive session has a keyboard error onscreen, QINTER will not go down! Any way to stop this or trap the sessions with keyboard errors?

Software/Hardware used:
iSeries

Answer Wiki

Thanks. We'll let you know when a new response is added.

If you end qinter with *IMMED parameter, then It should go down. If you’re using *CNTRLD, then it will not go down.

Discuss This Question: 3  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Splat
    If you'd rather allow a little leeway for your users, put a value in the DELAY parameter (the value is in seconds).
    7,185 pointsBadges:
    report
  • MurrayInfoSys
    We send a message to the ACTIVE workstations at 1 hour before we shut down the sub-system. Then 30 min. Then 5, 4, 3, 2, 1. Then we terminate the SBS *IMMED. You can lead a horse to water, but you can not make it drink.
    940 pointsBadges:
    report
  • TomLiotta
    A subsystem will not end until the jobs running in it end. A job the is having trouble might be unable to end normally. The ENDJOBABN command is intended to help with that condition for such jobs, but that should be thought of as a next-to-last resort. Normally, ENDSBS QINTER OPTION(*CNTRLD) DELAY(30) should give sufficient time to expect that jobs that watched for a shutdown request would have responded. After 30 seconds elapsed, the remaining jobs would be sent a signal as if ENDJOB OPTION(*IMMED) was sent to each of them. Each may take a few seconds to run the end-of-job processes such as converting messages in the job's external message queue into a spooled joblog. (Under extreme circumstances, a job can take quite a few minutes simply getting that done.) After some delay (usually determined by experience on that system), the subsystem status can retrieved to see if it's finished shutting down. That might indicate looping back for one or more additional delays and status tests. At some point, logic determines that things have taken too long. This might be when the list of still-active jobs is retrieved from the subsystem. Each job on the list might then be processed with ENDJOBABN. Be aware of the ENDJOBABN help text; for example "The ENDJOBABN command cannot be issued against a job until 10 minutes have passed following the request for immediate ending." Additional considerations are noted in the help text, particularly for possible effects that may need attention at the next IPL. In short, it can take some programming if you want to cover unusual conditions. Or you can have an operator sit while waiting. One of the most troublesome parts is getting a subsystem restarted when it gets stuck going down. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following