× 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 had a similar issue where everything worked fine except my 5250 sessions
(telnet). The only resolution was to stop and restart the telnet service
from DSP01 console. A ticket with IBM came up with the following 3 PTF
fixes. I had just installed the latest Cumes/groups/hypers the month
before (May) when I ran into this issue during June's IPL. The issue
reoccurred during August's IPL, so I installed that last PTF which I did
not have on my system. It's an individual PTF at this time. I have since
IPL'd this box twice for testing (our dev system). We did not hit this
issue during July's IPL, when the system was still without the PTF. So it
remains to be determined whether the fix is permanent yet.

Here are the PTF's that the IBM'er recommended:
PTF Description
SI46187
SI46186
SI46958 just released (Improve reliability of Telnet startup when two
Telnet start commands occur at the same time. (SE52141))

Thank you,

William G. Epperson Jr.
Systems Communications Analyst II

2420 East Pikes Peak
Colorado Springs, CO 80909

Office: 719-365-8831




Mission: To provide the highest quality health care
Vision: To create an outstanding health system where patients heal and
people thrive
Values: Compassion - Integrity - Quality - Respect - Teamwork

www.memorialhealthsystem.com

The information contained in or attached to this electronic message is
privileged and confidential, intended only for the use of the individual
(s) named above. If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please inform the
sender immediately and remove any record of this message.






From: Paul Therrien <ptherrien@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 08/01/2012 02:15 PM
Subject: RE: Cannot connect with Telnet client, other TCP/IP clients
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Thanks for the detailed resolution info.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Wednesday, August 01, 2012 2:28 PM
To: Midrange Systems Technical Discussion
Subject: Re: Cannot connect with Telnet client, other TCP/IP clients

So here is the solution in case somebody runs into this (but this is a such
a corner case I doubt it'll come up).

There WAS a warning in the QTCPWRK job that I chose to ponder and then
ignore because I *thought* I knew what the cause was. The warning was:

WARNING: Host 420000247EDB also using IP 192.168.200.210.

Now a couple of things led me down the wrong path here. First, the MAC
address is clearly one from IBM i. And I assumed (wrongly) that the MAC
address must have been local to the new 720 since it seemed like TCP/IP
wasn't getting off the box. As it turned out the MAC address was from an
adapter on the old 520 and it was a virtual adapter that wasn't even on my
radar because it was part of an old Linux partition that I had long since
deleted (yet, the line was varied on and active so......)

Interesting note: The interface associated with the adapter was
192.168.200.220 (which is why the warning on the 720 didn't register).
However, it was subnetted to 255.255.255.240 (I think) and I think that
was the issue (although it has been 15 years since I sat in TCP/IP
class...). In any case, I was told to run this in STRSQL:

select internet, lind, cnntype from qusrsys/qatocifc

And the virtual adapter was listed as a type 'p' and was apparently the
culprit.

Once we varied off the adapter (which I subsequently deleted), stopped and
restarted the interface and then cleared the arp cache on my PC, BANG ZOOM!
I connected immediately.....

Self inflicted wounds are always the most painful.....

Pete Helgren
Value Added Software, Inc
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 8/1/2012 12:06 PM, Jim Oberholtzer wrote:
CFGTCP; option 2.

You may have to stop the IP interfaces using option 1 (and very
potentially remove all of them too) before removing the routes. The
*DIRECT routes have always gone away when I delete the line
configuration. (copy it to source first to recover it easily)

While Larry and others are much better at networking than I, when
configuring IP on IBM i I always get just the base IP address and
route correct first, then start adding the other stuff that's needed
for all the communications types, adding each one at a time to
pinpoint when something goes wrong.


Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

--
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.

--
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 ...

Follow-Ups:
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.