× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I agree with Rich. If the ethernet link hiccups, an inquiry message is generated once the recovery limits are reached. The system default value QCMNRCYLMT is 2 and 5, which means that the system will make two attempts at recovery, 5 minutes apart, before sending an inquiry message CPA58EE to the system operator message queue.

You can specify larger recovery limits on the individual ethernet lines and you can also add the inquiry message to the system reply list so that the recovery can proceed completely unattended.



Rich Loeber wrote:
Sheri,

I've seen this happen when the cable connection is disturbed or the router (or
hub) it is connected to looses power for a very short time.  The first place
I've learned to look is at the QSYSOPR message queue.  If there is an error
there, then a simple 'R' to retry gets you back on track (assuming that the
physical problem has been corrected).

Rich Loeber
Kisco Information Systems
http://www.kisco.com
  ------------------------------------------------------------------------

"Rowe, Sheri" wrote:

Has anyone had a problem with their TCP connection 'dropping'?  About 8
months ago, our overnight failed as the TCP on one of our iSeries went
'down'.  The system was up and I could sign on to the console fine but
not from a Client Access session.  Tried stopping and starting TCP (all
services) and varying off and on the line, but only an IPL could get the
communication between the iSeries and my network up.

I contacted IBM who couldn't really help.  No entries in WRKPRB either.
I couldn't ping anything.

The history log had a bunch of entries to indicate the interactive
sessions and the connection to our other iSeries had terminated
TCP2617 TCP/IP connection to remote system 169.1.1.25 closed, reason
code 2. TCP2617 TCP/IP connection to remote system 169.1.1.25 closed,
reason code 3. CPF590A Session to device WT221S2 ended normally.

It happened again this past Friday.  Does anyone know what is causing
this?  And/or how I can correct it once it does happen without an IPL?

Thanks for any words of wisdom.

Sheri Rowe
Timex Canada
Markham, Ontario

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.