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



This article describes the whole setup
http://search400.techtarget.com/tip/Connect-the-dots-Get-your-iSeries-servers-talking-to-one-another

jim


----- Original Message ----- From: "Lindstrom, Scott R." <slindstrom@xxxxxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, September 22, 2011 7:06 PM
Subject: getting SNADS to work again on a system that moved to my company


I inherited a V5R2 system with two partitions from another company. Prior to the move SNADS between them was working. It's been decades since I have worked on configuring SNADS so I am having trouble.

When the systems arrived here I changed all the TCP/IP related info and all that is working OK. But SNDNETF's are not working. So from what I've read I need to make sure I can do pass-thru between the two systems as a first step.

On systems I have managed in the past I am used to the system name, local network ID, and local control point being the same. Then I can just do a STRPASTHR <systemname> and I am good.
But on these two partitions the local network ID and local control point are the system serial number preceded by an "A60" or "S65" (rather than the system name).

When I try a STRPASTHR SYSB from SYSA I get:

Message ID . . . . . . : CPF8933 Severity . . . . . . . : 40
Message . . . . : Route to specified location not found.
Cause . . . . . : No route could be found from location *LOC to location SYSB in network *LOC using mode *NETATR. Either no route is available, or else one or more of the parameters specified does not fit the current system and network configuration.
Recovery . . . : One or more of the parameters RMTLOCNAME, RMTNETID, LCLLOCNAME and MODE might be incorrect. Use the Display APPN Information (DSPAPPNINF) command to determine which value is incorrect. Correct the appropriate parameter value and then try the request again.

Is my STRPASTHR failing because I am not specifying some other information on the command? I have tried various attempts at specifying (educated guesses) Local Location and Remote Network Identifier with no luck. The eventual goal is to get SNDNETF to work. In CFGDSTSRV I don't see anything that looks out of the ordinary leading me to believe I've left something out that I need in the STRPASTHR.

Here is some info that would be relevant:

SYSA:
====
DSPNETA:
-----------
System: SYSA
Current system name . . . . . . . . . . . . . . : SYSA
Pending system name . . . . . . . . . . . . . :
Local network ID . . . . . . . . . . . . . . . . : APPN
Local control point name . . . . . . . . . . . . : S6512345
Default local location . . . . . . . . . . . . . : S6512345
Default mode . . . . . . . . . . . . . . . . . . : BLANK

DSPAPPNINF:
----------------
Control Network
Point ID
S6512345 APPN

SYSB:
====
DSPNETA:
-----------
System: SYSB
Current system name . . . . . . . . . . . . . . : SYSB
Pending system name . . . . . . . . . . . . . :
Local network ID . . . . . . . . . . . . . . . . : APPN
Local control point name . . . . . . . . . . . . : A6012345
Default local location . . . . . . . . . . . . . : A6012345
Default mode . . . . . . . . . . . . . . . . . . : BLANK

DSPAPPNINF:
----------------
Control Network
Point ID
A6012345 APPN

Any ideas on what would need to be changed to make SNADS work when the only thing that has really changed is the TCP/IP info?

TIA,
Scott Lindstrom

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