QSYSOPR break handler in restricted state? - IBM AS400

This is a discussion on QSYSOPR break handler in restricted state? - IBM AS400 ; Hi All, Is it possible to have a break-handler program allocated to QSYSOPR when the system is in restricted state (i.e. like specify a parameter specifing this when issuing CHGMSGQ when allocating the break-handler program)? Thanks in advance. Tony...

+ Reply to Thread
Results 1 to 3 of 3

Thread: QSYSOPR break handler in restricted state?

  1. QSYSOPR break handler in restricted state?

    Hi All,

    Is it possible to have a break-handler program allocated to QSYSOPR when the
    system is in restricted state (i.e. like specify a parameter specifing this
    when issuing CHGMSGQ when allocating the break-handler program)? Thanks in
    advance.

    Tony



  2. Re: QSYSOPR break handler in restricted state?


    "Anthony LaMark" wrote in message
    news:4psdh.11085$Zb5.6220@newsfe13.phx...
    | Hi All,
    |
    | Is it possible to have a break-handler program allocated to QSYSOPR
    when the
    | system is in restricted state (i.e. like specify a parameter
    specifing this
    | when issuing CHGMSGQ when allocating the break-handler program)?
    Thanks in
    | advance.
    |
    | Tony


    Yes it is possible but you may not like the answer. An interactive
    job running on the system console that puts the system in a restricted
    state can also be the break handler. What you can not do is have a
    second independent program of any type running when you are in the
    restricted state.

    Mike



  3. Re: QSYSOPR break handler in restricted state?

    Anthony LaMark wrote:

    > Is it possible to have a break-handler program allocated to QSYSOPR when the
    > system is in restricted state (i.e. like specify a parameter specifing this
    > when issuing CHGMSGQ when allocating the break-handler program)? Thanks in
    > advance.


    Yes, a break-handler can be associated with QSYSOPR or any valid message
    queue in restricted state. Restricted state doesn't stop that. However,
    the break-handler must usually be running in the single interactive job
    that's running in the controlling subsystem.

    If you somehow need such a program to run elsewhere, then you'll need to
    understand what happens when you start a second subsystem (e.g., QBATCH)
    and want everything else to stay quiet. It gets complicated fast in
    later releases of OS/400 and i5/OS. The generally understood meaning of
    'restricted state' gets a bit more technical.

    Perhaps more to the point, the need for such a program should be
    determined. What would be expected that it could do?

    If the system is in restricted state, there aren't many services
    available for a program to use. Many actions might interfere with
    whatever system function is being run --restricted state is entered in
    order to run functions that require restricted state. In general, such
    functions are expected to run attended, so there shouldn't be any break
    messages that ought to be handled except by the operator.

    If restricted state is used simply out of convenience, then there seems
    to be a fundamental contradiction. (1) Restricted state is used because
    there isn't sufficient expertise to do the work otherwise. And (2) there
    isn't sufficient expertise to understand break-handling within
    restricted state nor how to avoid the need for it -- the break-handler
    might run but not be able to do anything such as send an e-mail.

    Perhaps there'd be more help if the actual business need was described.

    Tom Liotta

    http://zap.to/tl400

+ Reply to Thread