I need help retrieving a message from Qsysopr Msgq

[elb...@cmfurniture.com]

Our bank sent us source code and line descriptions to create a bisync
communication job to send bank transactions to them.

I create the flat file, vary on their bisync line and call their
supplied communications program.

Ocassionally the line is busy, after 3 times the following message is
issued to Qsysopr

* System cannot call controller TCBCTL. No lines available. (C R)

Last week the message sat for 3 hours waiting for someone to reply to
it.

How can I monitor for a message that is being sent to Qsysopr?

The submitted communication program itself never bombs, the system is
issuing the controller message.

[Martin Brieger]

Elbert,

look into ADDRPYLE

Martin

<elb...@cmfurniture.com> wrote in message
news:3ca0ccbb...@news.vnet.net...

[elb...@cmfurniture.com]

I don't like the idea of an auto reply.

Because if there is a valid problems such as the phone line is dead. I
don't want the AS400 taking R's for days until someone realizes there
is a problem.

I need a way to trap the error so I can take a predefined response
once or twice and then email myself, if the problem continues.

I have the email code, I need a way to trap the error.

Thanks for the suggestion anyway.

[René H. Hartman]

Since you seem to have your own CL to control the communications, I'd tackle
the problem before it occurs, rather than trying to catch the error. Looks
like you're using a LIND that shares a resource with another LIND, so it
cannot be varied on. Normally you should have a dedicated line for bank
transactions, but that's not always an option.

What I'd do in the CL is vary on the line, wait 5 seconds, retrieve the
configuration status and take action on the status returned (like retrying
the vary on, or issuing a message to the responsible user).

Alternatively, you can vary on the line and controller. There's a keyword on
the controller that will force dialing out when varied on, rather than wait
for a connection request. Again using RTCFGSTS, you could wait for the line,
ctl or device to become active, indicating the connection is established,
before calling the app's comms pgm. Some supplier leave their comms pgm at
Allow Retrieve CL Source *YES, so you could do these checks from within the
actual pgm.

HTH
--
Vriendelijke groeten / Kind regards
René H. Hartman
R.H. Hartman Automatiserings Consultancy
www.hac-maarssen.nl

<elb...@cmfurniture.com> schreef in bericht
news:3ca0ccbb...@news.vnet.net...

[Dieter Bender]

Hi,

what about CHGMSGQ and set the Q to Delivery *break and register a program
for the Break messages; be sure to send back all messages you don't handle
and if you don't want to program it of your own - there are some software
packages ROBOT Console, or the International Boat anchor Manufactory has a
solution too.

Dieter

elb...@cmfurniture.com wrote:

--
Dieter Bender

www.bender-dv.de

[Karl Hanson]

Dieter Bender wrote:
>
> what about CHGMSGQ and set the Q to Delivery *break and register a program
> for the Break messages; be sure to send back all messages you don't handle
> and if you don't want to program it of your own - there are some software
> packages ROBOT Console, or the International Boat anchor Manufactory has a
> solution too.
>

> elb...@cmfurniture.com wrote:
>
> > Our bank sent us source code and line descriptions to create a bisync
> > communication job to send bank transactions to them.
> >
> > I create the flat file, vary on their bisync line and call their
> > supplied communications program.
> >
> > Ocassionally the line is busy, after 3 times the following message is
> > issued to Qsysopr
> >
> > * System cannot call controller TCBCTL. No lines available. (C R)
> >
> > Last week the message sat for 3 hours waiting for someone to reply to
> > it.
> >
> > How can I monitor for a message that is being sent to Qsysopr?
> >
> > The submitted communication program itself never bombs, the system is
> > issuing the controller message.
>
> --
> Dieter Bender
>
> www.bender-dv.de

The break handling program gets passed the message key (aka MRK) as an
input parameter. There is no need to "send back" a message if you do
RCVMSG .. RMV(*NO). You can receive the message type (RTNTYPE - eg 05
for Inquiry), MSGID, etc to determine if it a message of interest. If
desired, the message can be removed later using RMVMSG or RCVMSG ..
RMV(*YES).

Fyi, here is a note from the help for PGM parameter of CHGMSGQ:
Because the QSYSOPR message queue receives messages that
require manual operator action, only *DSPMSG should be
specified or assumed if the message queue being changed is
QSYSOPR.
I believe changing to DLVRY(*BREAK) puts a lock on the message queue,
which may prevent operators from using it - eg prevent from also
having the queue in break mode.

--
Karl Hanson

[Dieter Bender]

Hi Karl,

thanks for your deeper explanations, I've done this some years ago and I
think it must be worked out very carefully.

Dieter

--
Dieter Bender

www.bender-dv.de

[elb...@cmfurniture.com]

Thanks for the info. Your idea sounds the best so far.

I'm unfamiliar with lines and line descriptions. The bank sent all the
code and I just typed it in as they supplied it.

I'll try retrieving the status as you suggested.

Thanks