RE: Peregrine EDI software and trouble shooting a line.

["Carl Galgano" <cgalgano2@xxxxxxxxxxxxxxxxx>]

This is not an ESC message so it can not be monitored.  The best way to
handle this is to use the system reply list.  (ADDRPYLE).
cjg

Carl J. Galgano
EDI Consulting Services, Inc.
550 Kennesaw Avenue, Suite 800
Marietta, GA  30060
(770) 422-2995 - voice
(419) 730-8212 - fax
mailto:cgalgano@ediconsulting.com
http://www.ediconsulting.com
AS400 EDI, Networking, E-Commerce and Communications Consulting and
Implementation
http://www.icecreamovernight.com
Premium Ice Cream Brands shipped Overnight

"You ain't gonna learn what you don't want to know" - rw

-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com] On Behalf Of Pete Hall
Sent: Tuesday, November 19, 2002 7:48 PM
To: midrange-l@midrange.com
Subject: Re: Peregrine EDI software and trouble shooting a line.


At 12:28 11/19/2002, Rob Berendt wrote:
>Normally the Peregrine software, (or whatever their nom du jour is),
>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)

Busy signal on the other end? I used to write monitor CL programs to
watch the comm jobs and reset them if the line status became
unacceptable. I remember it being pretty easy to do, but it's been way
to long to tell you what they did, other than retrieving the status of
the comm objects and vrycfg. The basic idea is that the comm program
submits the monitor, passing its job number/user/name, and the monitor
then has the capability to end that job and submit another. When comm
job is done, both jobs end based on a marker object, data queue, message
queue, whatever.


Pete Hall
pbhall@ameritech.net
http://www.pbhall.us/