Hi,

While I (as usual) must admire Wirt for his outstanding abilities in writing,
seeing and not least 'meaning' - I include a little more information below -
which ought to be included in the first place, I see now:

There's this worldwide, closed network, which we're not part of. Someone in -
say - Australia sends a small message, requesting some information from us
- out on this network. However, though we're not on the network ourselves - a
very large partner of ours is. He receives the message, finds out that the
message is destined for us and hence re-route the message to us. He offers
to deliver the message to an ip-address and to a specific port on our HP
e3000.


The system must work the other way as well: We need to send a message
to someone abroad. Se we must deliver the message to the partner (the way
he wants...). He grabs the message, interprets the address and routes it out
on the ww-network to the final destination.

All this has worked for years using the SNA-protocol to access large IBM-
mainframes - but times are changing - and we're seeking new interfacing-
solutions now.

I hope this has clarified the challenge a little...

Once again - thanks to anyone that has the opportunity to answer me.

/With kind regards Hans-Ole Kaae, ScanConsult, Denmark


On 23 Apr 2002 at 12:08, [log in to unmask] wrote:

> Is the nature of this process an actual, meaningful conversation? In
> other words, the foreign host sends your 3000 some ASCII message as
> input, your 3000 processes this message, and returns processed output,
> like EDI transactions?
>
> Or, is your 3000 replying, yes, I got message #123,456, here's your
> checksum (or whatever) to confirm that I really, truly got it? If the
> latter, it sounds like a poorly defined process, since TCP/IP pretty
> much already does all of that for you, and it sounds like someone at the
> remote end is reinventing all four wheels and most of the Model-T. As
> Wirt and Wayne wrote, you have to be careful about who is allowed to
> drive the details of implementation.
>
> If the former, there are a whole bunch of ways to do this. What language
> do you like, or would like to use? COBOL or any other 3GL and NetIPC
> does this beautifully, as do the other 3GLs with Berkeley sockets, as
> does perl and its own socket handling routines. For really small files
> or amounts of text, there is TFTP, which is UDP-based.
>
> Greg Stigers
> http://www.cgiusa.com
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *