Hi Richard,
The kinds of things we do are mostly interactive... We're supporting over two dozen remote boxes. Telnet, moving objects between boxes, some DDM libraries/files, sending spool files (SNADS)... All the normal stuff you'd expect...
We have no desire to change the method of communication at this point... I understand there may be more attractive options, still, the change is perceived to be too costly in terms of complexity, time and effort at this point... I confess there is a skill set gap in terms of the level of comfort required to make the leap from AnyNet to Enterprise Extender, etc... And coordinating a change like that will require lots of testing on some test boxes, before moving to production, etc...
This is our DSPNETA today...
Allow AnyNet support . . . . . . . . . . . . . . : *YES
Allow APPN virtual support . . . . . . . . . . . : *NO
Allow HPR transport tower support . . . . . . . : *NO
From what I'm hearing, we will eventually have to investigate the path from AnyNet to Enterprise Extender...
Hope it's not too painful or fraught with peril...
In the mean time, we're trying to come up with a clever band aid approach we can employ pragmatically...
Just thought I'd give this venerable forum a shot...
Thanks,
Jeff
________________________________
From: Richard Schoen <richard@xxxxxxxxxxxxxxx>
To: "midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, September 16, 2013 12:54 PM
Subject: RE: Keeping A Specific TCP/IP Port Alive
I have a more important question.
What apps are you running to the remote site that require APPC over TCP/IP ?
APPC over TCP/IP is probably not needed in most cases today unless you're doing some SNA specific stuff.
You could also write a job that circles and pings the remote servers every xx seconds if there's not a keep alive setting in your APPC apps.
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
------------------------------
message: 2
date: Mon, 16 Sep 2013 09:19:08 -0700 (PDT)
from: jklipa <jklipa@xxxxxxxxx>
subject: Keeping A Specific TCP/IP Port Alive
Greetings,
Keep Alive APPC over TCP/IP -?iSeries Connections Crossing a Firewall
There is a potential problem that can adversely affect?communication sessions between?
AS/400s within Our network and AS/400s outside?of Our network. What I?m hoping?
to find is a way to keep a connection alive to?a specific ?target? port across a firewall.?
(Because I?m old school, I?m going?to refer to our iSeries boxes as AS/400?s for nostalgic?
purposes. The earliest?O/S version we?re running is V5R4M0.) There are several AS/400s?
inside and outside our network that we need to communicate with on a daily basis...
Problem definition
This problem occurs when a specific set of circumstances are?encountered.
1.)??? An AS/400 (source) server inside Our network?firewall attempts to communicate?
with an AS/400 (target) server that lives?outside Our network firewall. For example,?
source server A attempts to?connect with target server Z. Or vice versa.
2.)??? More than one communication link is??established? between the source/target systems.
3.)??? One or more of the existing connections have?been idle so long they have exceeded?
the firewall-imposed timeout and are?essentially ?walking dead? connections which cannot be revived.
4.)??? The source system requires more than one?simultaneous connection to the target system.
Scenario
(This is my understanding of how things work, I could be wrong...)
midrange.com
