|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.