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



Darren,

don't care about interfaces at the AS/400 side or the side of your application.
The underlying TCP/IP rouitng stuff should be totally transparent to your
(highlevel-) application(s).
Think of IP networks as clouds:
one cloud is the 194.130.10.x network and another is the 17.1.6.y network.


These clouds don't "know" about each other, they don't "touch" each other
since they are at different IP-ranges. To see hosts from one cloud when
looking from another cloud you need "pointers" how to get there and in case
you have private IPs (thats 10.x.y.z / 172.26.a.b / 192.168.c.d) you need
to "translate" between public and private IP-ranges and vice versa.
Now: to actually contact a system of another cloud BOTH need to know about
each other AND the way of how to get there, AT LEAST they need to know
"somebody" who knows how to reach the others (= gateway).
So it's the gateway's rule to "find a path" for you, in terms if ISP
nomenclatura this is done by inter-gateway routing protocols.
You are still with me ?
Back to your real networks: to see hosts (every machine is a host in terms
of ip networking) from net 17.1.6.y in the net 194.130.10.x you need to
define routing entries at both ends.

My example plan of your net would look like:
(the addresses of the gateways are for example only, ask your network guy)

17.1.6.254 194.130.10.254
17.1.6.y --- GATEWAY --< many other nets in between>-- GATEWAY -- 194.130.10.x
| |
this is the VPN network this is the company network



so the vpn side needs an entry like (windows)


route add 194.130.10.0 mask 255.255.255.0 17.1.6.254

and the company side needs an entry like (AS/400)

(doing from memory, no AS/400 here at hand)

IP=17.1.6.0 mask=255.255.0.0 gateway(=nexthop)= 194.130.10.254

So what you got to find out from your network guy is four things:

1+2: what are the network masks of both nets ?

3+4: what are the both gateways addresses ?

(above values were for explanation purposes only)


HTH, Philipp



Darren McBride schrieb:


Crikey, this is really starting to confuse the hell out of me. Although I
have heard these acronymns before, I haven't a clue about how and when they
are used.


All I knew up until now was that, using TCP/IP, I could pass data between
two end-points on a network (the client and the server). In my case, I have
written a set of client libraries on the AS/400 that use sockets to
communicate with my Delphi server application on the PC (the address of
which is resolved from the currently active 5250 session from where the
client application is started by the user). The Delphi program rebuilds the
information sent by the AS/400 application and then executes the requests
stored in the data (eg. read PC databases, call Word or Excel or control
Outlook etc). The results of the request are returned to the AS/400 by
replying to the request received.

Now I know that this data can be sent using TCP or UDP (ICMP is another
format for another time), and that there are specific differences between
these two formats (packet size etc). I send and receive the data in plain
text (although converted between EBCDIC and ASCII during the sending
process) over TCP, communicating to a port that can be configured on both
sides before communication begins.

On the site that I developed the toolset, everything was installed and ran
on 70 client desktops the first time (I integrated a native 5250 application
with their browser based document imaging system so that they could popup
documents at the press of a key in their 5250 session). Phew. However, when
I returned to my office and tried to run the same setup (albeit I was
accessing the 5250 session and the AS/400 now over a VPN), the AS/400
returns a failure (-1) when sending the data. The IP address range
(17.1.6.151) on the VPN, is different to the normal network address range
where everything works (194.130.10.28).

I have narrowed the problem (hopefully) down to 2 possible problems - a
firewall protecting even data coming in over the VPN or this routing table
stuff on the AS/400. The routing table on the client site has a few entries,
mostly pertinent to similar address ranges as the normal address range
mentioned above, and a default route which again appears to be a DNS server
in the same range (194.130.10.254).

I have tried adding a routing address for 17.1.6.0, but my application still
did not work. What I think I have to do now is to create a new TCP/IP
interface for this subnet (if that's what it is), and then add the routing
entry for this interface. At least that's the hope. I shall try it tomorrow.

Does this approach sound valid here ? Has anyone on this list written some
of their own TCP/IP communication programs and had any similar problems ?

Thanks,
Darren

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Philipp Rusch
Sent: 31 May 2004 21:23
To: Midrange Systems Technical Discussion
Subject: Re: TCP/IP and programming connectivityproblem
(routingtablequestion)

Are you guys talking about routing protocols ?

There is RIP Version1 and Version 2, both spoken by an AS/400.
(RIP = Routing information protocol.)

I somedays read about the AS/400 being able to learn from OSPF-packets as
well.
(OSPF = Open Shortest Path First)

There is more around than this: you have IGRP, which is Internet Gateway
Routing Protocol, and EIGRP (most Ciscos do it) which is the enhanced
version.

What is needed to "learn" a route ?

Any client side of the above mentioned routing protocols will receive
information of the surrounding peers or gateways and will try to establish
routes on this base. When you enable the "server"-portion of the protocols,
you will be able to propagate this information to other nodes in the net.
Security-wise it should be mentioned that normally the client side should
suffice, when not acting as a router between networks.
To achieve maximum safety one should not trust (foreign) routing information
packets at all and only put in static routing entries on the AS/400.

HTH, Philipp Rusch


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

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.