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


  • Subject: RE: Remote AS/400 support over the internet
  • From: "Bob Crothers" <bob@xxxxxxxxxxxxxx>
  • Date: Tue, 13 Mar 2001 13:53:57 -0500
  • Importance: Normal

I question your statement about not being able to do 2-way sessions
like SNA ones with TCP/IP.

What do you mean?  We use TCP/IP a lot in our products and have no
problems with 2 way communications.  In fact, the connection between
our server and the AS/400 used to be APPC over SNA and is now TCP/IP.
Yes, some changes where required, but with the use of a SPECIAL file,
the program hardly knows it.

Note: We are NOT using "standard" conversations like Telnet, HTTP, etc.
But then, APPC does not follow a standard conversation protocol either.

Regards,
Bob Crothers
Cornerstone Communications
http://www.cstoneindy.com




-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of
mandy.shaw@uk.catalyst-solutions.com
Sent: Tuesday, March 13, 2001 12:32 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Remote AS/400 support over the internet

Thoughts ... (rather random)

1. You can't do 2-way sessions like SNA ones with TCP/IP, every
client-server TCP/IP connection is independent.

2. Do you actually want AnyNet, or would Telnet do the necessary for
you on
its own? Miles easier, if so, no AnyNet needed at all, just the *TELNET
TCP/IP server running their end (which it almost certainly will be
anyway,
for their own green-screen stuff), plus firewall stuff (see next
section).
Once you have Telnet going, you can do any AnyNet configuration
yourself
from your end anyway.

3. If they are getting out through their firewall and in through yours
for
Telnet purposes, that's the nasty bit of firewall configuration OK
already
if you only want Telnet. If the firewall at your end stops System A
Telneting to System B, and depending on the firewall, you may be able
to
get firewall configuration at your end automated using Telnet scripting
or
some other mechanism. Even if you can't automate it, as the problem
would
be only at your end, you might be able to do that bit manually. If the
firewall at their end stops you Telneting in, you could potentially
supply
a Telnet script or whatever to automate the firewall configuration,
although that's probably the most ticklish bit.

4. Assuming that you *can't* use Telnet but must use passthrough to
System
B for some reason, it is possible to automate the addition of the
relevant
host table  and *CFGL entries for AnyNet (ADDTCPHTE and ADDCFGLE as far
as
I can remember). I also think (though I haven't done it) that it is
possible to set up the Telnet user exit program so it can recognise the
IP
address the Telnet session is coming from. You could store this
somehow,
then to get the host name, make them sign on with a user id that
uniquely
identifies their system. Once they'd signed on, you could have their
initial program use all this info to set up all the necessary entries
on
System A for AnyNet if they weren't there already. You could provide
them
with a CL program to run that would set up the necessary stuff in
advance
to configure AnyNet System A access from their end (it would be the
same
for all remote systems).

I hope some of this helps... I am sure others will come up with a lot.
Mandy





"Mark Villa" <markvilla@knology.net> on 13/03/2001 16:36:50

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com
cc:    (bcc: Mandy Shaw/Pacific/UK)
Subject:  Remote AS/400 support over the internet




I know there are -other- appropriate ways with respect for firewalls,
VPN
for example, but this case is a narrow scope.

Scenario
=========
You have a HOST "A" and 100 machines in the field. They all have TCP
internet connections and firewalls. No remote systems  have on site
administration that you may call on.

HOST- System A talks to REMOTE System B just fine using SDLC over a
modem.
On Host System A ports and any other admin chores are not an issue.

Now, REMOTE System B upgrades and decides they don't want to use
dial-up
SDLC anymore.

REMOTE System B can telnet through the firewall to HOST System A just
fine.

The PROBLEM:
=============
I can not figure out how to start pass thru or telnet sessions "FROM"
Host
System A once System "B" has established TCP contact/sessions with HOST
System A, without performing admin at the 100 remote sites.

What I want to do is establish a 2 way path, like dial-up SDLC does,
initiated at REMOTE System B.

The real problem I am running into is not knowing their internet
address
ahead of time for definition in HOST System "A" host table, for APPC
over
TCP using *ANYNET on HOST System, that would not be an option, too much
admin. There has got to be an easier way.
Ideally I would say, okay Store #204, run this command using my IP
address
xxx.xxx.xxx.xxx, this will allow me to start a session on your system
and
look at your job log for you. This also keeps security /positive
control
under the remote site umbrella.

I have seen reference to dynamic sessions, but, not sure enough to
proceed
with investigating even more.


Thanks -very- much for any pointers. P.S. - a host package to answer
this
would be okay, but any remote changes are not possible. This would mean
it
is an ongoing chore with new stores, etc.


Mark Villa in Charleston

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



      Regards,
      Mandy Shaw

      Catalyst Solutions plc
      Kingfisher House
      Frimley Business Park
      Camberley
      Surrey
      GU16 5SG
      UK

      http://www.catalyst-solutions.com
      Email: Mandy.Shaw@uk.catalyst-solutions.com

      Telephone: +44 (0)870 166 1000
      DDI: +44 870 166 1324
      Facsimile: +44 870 168 3920
      Mobile: +44 410 447966





----------------------------------------------------------------------
----------------------------------------------------------------------
Catalyst Solutions plc.  Registered No 2918101.
Registered @ Kingfisher House, Frimley Business Park, Frimley,
Surrey. GU16 5SG   U.K.

NOTICE:
This message is intended only for the named addressee(s) and may
contain confidential and/or privileged information. If you are not the
named addressee you should not disseminate, copy or take any action
or place any reliance on it. If you have received this message in error
please notify postmaster@catalyst-solutions.com and delete the message
and any attachments accompanying it immediately.
----------------------------------------------------------------------


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

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.