× 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 see what you're doing that's different now. Why use two AnyNet
connections on each LPAR?

I'm not sure how well this will work, In your network attributes you're
going to have:

Current system name . . . . . . . . . . . . . . : Corp400A
Pending system name . . . . . . . . . . . . . :
Local network ID . . . . . . . . . . . . . . . . : APPN
Local control point name . . . . . . . . . . . . : Corp400A
Default local location . . . . . . . . . . . . . : Corp400A
Default mode . . . . . . . . . . . . . . . . . . : BLANK
APPN node type . . . . . . . . . . . . . . . . . : *ENDNODE

If you let your devices autocreate the device created for BBOX will
probably look like this:

Device description . . . . . . . . : DEVD BBOX
Option . . . . . . . . . . . . . . : OPTION *BASIC
Category of device . . . . . . . . : *APPC

Automatically created . . . . . . : YES
Remote location . . . . . . . . . : RMTLOCNAME BBOX (or maybe
Corp400B?)
Online at IPL . . . . . . . . . . : ONLINE *NO
Local location . . . . . . . . . . : LCLLOCNAME Corp400A
Remote network identifier . . . . : RMTNETID *NETATR
Attached controller . . . . . . . : CTL ???? Could use
either I suppose. I've never used more than one AnyNet controller no
matter how many connections. But the LCLLOCNAME on an autocreated
device will come from the NetA and there can be only one. If you
manually create the devices I suppose you could over-ride this but I
don't know how reliable the results would be.

You would probably have to turn off all of the autocreate settings on
all the AnyNet controllers and rebuild it all by hand. Per KB 22995147:
When a request to start a transaction comes in from a remote system,
AnyNet/400 looks through all of the AnyNet(r) controllers (APPC
controllers with LINKTYPE(*ANYNW)) to see if there is an existing APPC
device that matches. If one is found it will be used. If a matching
device is not found, one is created under the controller with the fewest
number of devices.

Maybe your return routing is being forced to the old controller because
it has fewer active devices? Can you vary off the old controllers and
see if it works then?

AnyNet(r) Matching Parameters are here:
http://www-912.ibm.com/s_dir/slkbase.nsf/00e42b791a3dab7b862565c9004ec1a
f/65da5903ba5b92c5862566b9006efb58?OpenDocument

A long time ago I got an AnyNet configuration to work in conjunction
with a wired APPC configuration. But it took a long time (due to
similar routing issues) and the wired APPC config usage was discontinued
shortly after that.

If it was me I'd just convert the old, previously working config to the
VLAN in the host table and drop the idea of redundant connections.

Regards,

Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest




-----Original Message-----
From: Hart, Doug - EI [mailto:Doug.Hart@xxxxxxx]
Sent: Wednesday, June 11, 2008 1:35 PM
To: Midrange Systems Technical Discussion
Subject: RE: AnyNet Routing Problem


Thanks Scott but I am already at *LOCAL on each LPAR. And the names
I'm using for my VLAN are different than my wired network. My new VLAN
controller is ABOX and the RMTCPNAME (ABOX).

"Wired"
Corp400A
Corp400A.APPN.SNA.IBM.COM

"VLAN"
ABOX
ABOX.APPN.SNA.IBM.COM

--
Douglas Hart


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Ingvaldson, Scott
Sent: Wednesday, June 11, 2008 1:00 PM
To: Midrange Systems Technical Discussion
Subject: RE: AnyNet Routing Problem

Is there any chance that any of these are in your network DNS?

SYSTEMA.APPN.SNA.IBM.COM
SYSTEMA
SYSTEMB.APPN.SNA.IBM.COM
SYSTEMB

Ping all of these from a DOS prompt and see what you get. The network
DNS will override the i DNS if the Host name search priority is set to
*REMOTE. If it's not already, try changing the Host name search
priority (in CFGTCP, option 12) to *LOCAL and see if that helps.

I would seriously doubt that you are the first to try this, but anything
is possible. If it's possible you might try deleting the AnyNet
controllers and recreating them. Is your RMTCPNAME the same on each
controller or different? Worst case scenario, you ought to be able to
blow it all away and reconfigure it without too much trouble. But you
shouldn't have to. Has SL taken a comm trace?

Regards,

Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest


-----Original Message-----
From: Hart, Doug - EI [mailto:Doug.Hart@xxxxxxx]
Sent: Wednesday, June 11, 2008 11:30 AM
To: Midrange Systems Technical Discussion
Subject: RE: AnyNet Routing Problem


Yup, host tables are fine and fully qualified ping works great. IBM is
saying I might be the 1st to have this redundant AnyNet config. WRKCFGL
is also good. They have not been able to resolve this. Perhaps when I
get my partitions up to v5r4 I can replace AnyNet with Enterprise
Extender and it will work. We are working on our OS upgrades now (22
partitions/6 systems).



--
Douglas Hart


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Ingvaldson, Scott
Sent: Wednesday, June 11, 2008 11:29 AM
To: Midrange Systems Technical Discussion
Subject: RE: AnyNet Routing Problem

I'm sure that Support Line has already asked, but do you have AnyNet
definitions in your host tables? Something like
SYSTEMA.APPN.SNA.IBM.COM

These will need to point to the virtual LAN addresses on all sides.

Before AnyNet will work correctly you need to be able to ping
SYSTEMA.APPN.SNA.IBM.COM and SYSTEMA and see the response from the
correct IP address. On the other side you need to be able to ping both
SYSTEMB.APPN.SNA.IBM.COM and SYSTEMB

With a STRPASTHR I'm able to qualify the route by using a 2nd parm
(LCLLOCNAME)

If you do a WRKCFGL what do you see in QAPPNLCL?

Regards,

Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest


-----Original Message-----
From: Hart, Doug - EI [mailto:Doug.Hart@xxxxxxx]
Sent: Wednesday, June 11, 2008 9:55 AM
To: Midrange Systems Technical Discussion
Subject: AnyNet Routing Problem


We have had AnyNet configured over our wired network connecting on
several of our systems for years. Those systems (v5r3) are now
partitions on the same box. Now I configured new setups to have AnyNet
run over the LPAR Virtual LAN (VLAN). I am having no problem with new
partitions that never had the old wired setups configured, but the old
ones do not work. I have been working with IBM Support Line and traces
show that the routing is getting "lost". It seems that the send goes
out correctly but the return "sees" the old network and gets "confused".
With a STRPASTHR I'm able to qualify the route by using a 2nd parm
(LCLLOCNAME) but I want to use the SAVRSTLIB and SAVRSTOBJ commands and
they don't have parms to qualify the routing.

Has anyone been able to get a VLAN to work with the SAVRST... commands
after already having a wired AnyNet configured to the same LPAR?



--
Douglas Hart

--




This e-mail and any files transmitted with it may be proprietary and are
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the
sender. Please note that any views or opinions presented in this e-mail
are solely those of the author and do not necessarily represent those of
ITT Corporation. The recipient should check this e-mail and any
attachments for the presence of viruses. ITT accepts no liability for
any damage caused by any virus transmitted by this e-mail.


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.