RE: Peregrine EDI software and trouble shooting a line.

~~~>works fine.  But lately we've been having an issue with recurring
~~~>errors during communications.  Sometimes it works; sometimes it
~~~>doesn't. A sample is:
~~~>CPA5902:  Controller CN2196BSC not contacted. Call out
~~~request failed.
~~~>(C
~~~>R)

By default these are going to message queue QSYSOPR.
You likely want to know programmatically instead of the system doing an auto
answer from the reply list.

For example:
Assuming you trap the failed attempt, you retry at intervals then cancel
when had enough.
To trap is the tough part. Since the communications subsystem is
asynchronous to our JOBS they never communicate the status of progress, just
the result, back to the caller.

We had a lot of dial outs going on and changing defaults, etc. was not
really a good option.
My answer was to:
Start a 24/7 monitoring program that allocates the message queue before any
real QSYSOPR grabs the queue. The messages are listened for by doing a
RCVMSG on that queue. Operationally, when the 24/7 program is normally
running it remains in a MSGW status until a message is sent to the queue and
if it's yours you can answer it in your CL otherwise wait for the next. I
used data areas to see which job evoked the call to determine how to answer
the message.

Dial up has never been something I could count on in a program, so without
an operator you have to monitor it somehow.
The program came in handy for other problem jobs too.

Mark Villa in Charleston SC