Connecting clients to Tandem Pathway servers via TCP/IP...
lawren...@cwusa.com
functionalities. I can provide more infomation if anyone is
interested.
Steve Murphy
1. Use java either RMI with JPathsend or servlets
2. Write your own program to listen for requests on a port and either
handle the session itself, or pathsend to a 'session server' that does
the accept_nw2, then loop doing recv, SERVERCLASS_SEND_, send for the
life of the session.
3. Use RPC or RSC (search tandem.com or TIM).
Sent via Deja.com http://www.deja.com/
Before you buy.
Priyo Mustafi
on a port. I am trying to develop a program which is
similar to the tandem listner but will pathsend to a
tandem server when it gets a connection from a webserver,
but I am getting errors (see accept_nw message posted).
I did not quite understand your procedure. Can you
explain in little more detail or point me to the
literature.
Thanks in advance
Priyo
QjoeW.Ep...@Tmindspring.Ycom wrote:
>
> PMFJI, but
>
> It is not necessary to develop a process on the Tandem to listen to
> some port, or to spend (waste) money on RSC or somesuch product, as
> long as you will always be using TCP to connect the client to a server
> running under Pathway. If you'll be using transport protocols other
> than TCP/IP, or need some of the flexibility of RSC, then by all means
> go for it. But there is a much easier and simpler solution, IMHO.
>
> Just configure a service under the Tandem Telnet server for the
> application, and one or more windows tied to that service for the
> potential users. The service doesn't even have to be on the Telnet
> menu, so regular ol' TACL users wouldn't even know it's there. And
> there are other security features in the service and window
> configurations under Telnet that may prove useful (e.g., limiting the
> IP address(es) that can connect to a service/window).
>
> Then configure a static terminal under Pathway for each window, a
> terminal that is tied to an IDS requester (that you must develop) that
> is coded to do a SCOBOL send to whatever server is appropriate. The
> requester could look at the message do determine the appropriate
> server, or perform other functionality that seems appropriate, before
> sending the message it received from the remote client.
>
> Of course, this means the client has to create an IP socket through
> the Telnet port, and interpret and respond to the prompt Telnet throws
> up with the name of the service you've defined, but this is something
> that should be easily accomplished in Java.
>
> Good Luck!
> ```
> Joe
> (remove "q.w.e.r.t.y" to reply by email)
> ===
> Q: How many surrealists does it take to screw in
> a lightbulb? A: Two. One to hold the giraffe and the
> other to fill the bathtub with brightly colored
> machine tools.
> ===
> On Fri, 02 Jun 2000 13:42:11 GMT, Steve Murphy
> <steve_...@my-deja.com> spewed forth:
Steve Murphy
approx 100 lines?
Chiffer
QjoeW.Ep...@Tmindspring.Ycom writes:
>But there is a much easier and simpler solution, IMHO.
>
>Just configure a service under the Tandem Telnet server for the
>application, and one or more windows tied to that service for the
>potential users. The service doesn't even have to be on the Telnet
>menu, so regular ol' TACL users wouldn't even know it's there. And
>there are other security features in the service and window
>configurations under Telnet that may prove useful (e.g., limiting the
>IP address(es) that can connect to a service/window).
It looks to me like this would introduce:
1) Yet another single point of failure. Funneling your comms through TELSERV
means that loss of TELSERV kills all of your connections. It also means that
TELSERV will be a concentrated source of CPU consumption. You're already
exposed to these 2 issues with everything running through the TCP/IP
process...sticking TELSERV between TCP/IP and your servers gives you yet
another place where you have to contend with those problems.
2) A fair amount of unnecessary I/O cost. Instead of just the I/O cost involved
with each server talking to TCP/IP process, TELSERV would bear *that* cost (in
one CPU) + you would have the added cost of each server talking to TELSERV.
Personally, I don't think TELSERV adds enough to this equation to merit the
long-term extra cost.
3) Loss of the flexibility that Pathway gives you in terms of dynamic process
and thread management. Having to configure static windows in TELSERV and
pre-start processes against those windows is somewhat limiting. How does the
TELSERV approach handle peaks and valleys of activity without always
configuring for the worst-case peak? With the TELSERV approach, how does one
change configuration or code on-the-fly without impacting client processes
(with Pathway you can send an IPC to your listener telling it to use a
different server class for new connections).
Of course, I'll also admit that using TELSERV is a reasonable approach if:
1) You need something right now.
2) You're unfamiliar with TCP/IP sockets programming.
It's definitely a YMMV thing.
K2
>It looks to me like this would introduce:
>
>1) Yet another single point of failure. Funneling your comms through TELSERV
Maybe, but it is a tested one, used by tons of users/systems/applications, whereas an
in-house developed listener-like process and its interaction to a server handling the socket
needs a bit of quality coding as well (i.e. the TELSERV solution is 'proven', the other
solution is not)
>means that loss of TELSERV kills all of your connections. It also means that
True.
>TELSERV will be a concentrated source of CPU consumption. You're already
I don't think this holds, as also pointed out by Joe.
>exposed to these 2 issues with everything running through the TCP/IP
>process...sticking TELSERV between TCP/IP and your servers gives you yet
>another place where you have to contend with those problems.
This will go away in G06.08 (ok, ok, this is very new) with the Jaguar implementation of
TCP/IP (i.e. multiple, clustered, processes spread over a pool of cpus providing load
spreading/balancing and fault tolerance for the TCP/IP process(es)). To me this sound like a
good alternative for the K/D series NSAN.
>2) A fair amount of unnecessary I/O cost. Instead of just the I/O cost involved
>with each server talking to TCP/IP process, TELSERV would bear *that* cost (in
>one CPU) + you would have the added cost of each server talking to TELSERV.
Not sure about this one, but the traffic does not go through the telserv process I don't
think. Telserv is more like a switch linking the endpoints of the conversation and then not
interfering anymore.
>3) Loss of the flexibility that Pathway gives you in terms of dynamic process
>and thread management. Having to configure static windows in TELSERV and
>pre-start processes against those windows is somewhat limiting. How does the
This I agree to.
Kevin Benson
used as a solution here? It seems like a fair amount of work to get
this going with TELSERV.
TIA,
KB
QjoeW.Ep...@Tmindspring.Ycom wrote:
>See my comments below ...
>
>On 05 Jun 2000 16:00:14 GMT, chi...@aol.com.luna (Chiffer) spewed
>forth:
>
>>In article <ghhgjsoed8k7sv4iq...@4ax.com>,
>>QjoeW.Ep...@Tmindspring.Ycom writes:
>>
>>>But there is a much easier and simpler solution, IMHO.
>>>
>>>Just configure a service under the Tandem Telnet server for the
>>>application, and one or more windows tied to that service for the
>>>potential users. The service doesn't even have to be on the Telnet
>>>menu, so regular ol' TACL users wouldn't even know it's there. And
>>>there are other security features in the service and window
>>>configurations under Telnet that may prove useful (e.g., limiting the
>>>IP address(es) that can connect to a service/window).
>>
>>It looks to me like this would introduce:
>>
>>1) Yet another single point of failure. Funneling your comms through TELSERV
>>means that loss of TELSERV kills all of your connections. It also means that
>>TELSERV will be a concentrated source of CPU consumption. You're already
>>exposed to these 2 issues with everything running through the TCP/IP
>>process...sticking TELSERV between TCP/IP and your servers gives you yet
>>another place where you have to contend with those problems.
>
>A valid consideration, but then you have the same problem with users
>connecting to the system for a TACL prompt or Pathway SCOBOL requester
>having the same thing problems when connecting over TCP/IP.
>
>>2) A fair amount of unnecessary I/O cost. Instead of just the I/O cost involved
>>with each server talking to TCP/IP process, TELSERV would bear *that* cost (in
>>one CPU) + you would have the added cost of each server talking to TELSERV.
>>Personally, I don't think TELSERV adds enough to this equation to merit the
>>long-term extra cost.
>
>TELSERV and the Pathway application server processes do not directly
>interact. IMHO, as far as Pathway is concerned (for the most part)
>TELSERV is merely an I/O process that provides subdevices that act
>like terminals.
>
>And again, every Pathway application faces these same issues. I
>believe it should be the responsibility of the client to retry its
>transaction/message (whatever) in the event of an error, giving up
>only after a certain number of retries have been exhausted.
>
>>3) Loss of the flexibility that Pathway gives you in terms of dynamic process
>>and thread management. Having to configure static windows in TELSERV and
>>pre-start processes against those windows is somewhat limiting. How does the
>>TELSERV approach handle peaks and valleys of activity without always
>>configuring for the worst-case peak? With the TELSERV approach, how does one
>>change configuration or code on-the-fly without impacting client processes
>>(with Pathway you can send an IPC to your listener telling it to use a
>>different server class for new connections).
>
>This point is not valid, for the reason I said above. TELSERV does
>not talk to the Pathway servers. It provides the subdevice that can
>be configured in Pathway as a static terminal (to run a particular IDS
>requester). These static terminals, I'm sure you must know, are no
>different, when it comes to server interaction, than the dynamic
>terminals created when you do a RUN of a PROGRAM from a PATHCOM
>prompt. The biggest difference is that they don't go away like
>dynamic terminals. And if you properly configure the TCP process, and
>code the IDS requester correctly, they won't be stopped when a
>connection is dropped.
>
>The IDS requester that the TCP will run for these terminals is going
>to get the same treatment as any other SCOBOL requester, at least when
>it comes to how it gets access to Pathway servers. And PATHMON is
>going to manage those servers no differently than it would for any
>other environment.
>
>So how is this different (when it comes to Pathway server management),
>than an in-house-developed listener going through a LINKMON process?
>
>>Of course, I'll also admit that using TELSERV is a reasonable approach if:
>>
>>1) You need something right now.
>>2) You're unfamiliar with TCP/IP sockets programming.
>
>True, especially the first condition. If you don't have the
>facilities on your machine for *doing* sockets programming, such as no
>C compiler or equivalent headers for the programming in (p)TAL, then
>the second condition isn't applicable, though.
>
>>It's definitely a YMMV thing.
>
>Indeed. And as I mentioned in another part of this thread, there are
>other problems with this approach, such the interaction between the
>client and the server(s) being restricted to a conversational mode.
>```
>Joe
>(remove "q.w.e.r.t.y" to reply by email)
>===
>"Whenever people say 'we mustn't be sentimental', you can take it they
>are about to do something cruel. And if they add, 'we must be
>realistic', they mean they are going to make money out of it."
> Brigid Brophy
Remove NOSPAM for replies
Cornerstone Software, Inc.
Internet: kevinb...@corsof.com
WWW: http://www.corsof.com/
Chiffer
writes:
>Not sure about this one, but the traffic does not go through the telserv
>process I don't think.
If you connect to a TELSERV then your data is going to flow through TELSERV for
the lifetime of that TCP connection. It does not hand off the TCP connection to
any other process.
FWIW, I think Joe and I have different models of requester/server in mind. If I
understand what he's describing, Joe is envisioning the traditional Tandem
based SCOBOL requestor connecting via Pathway to a server class. The non-local
client accesses the SCOBOL requestor with a fairly dumb terminal interface thru
TELSERV. Did I get that right Joe?
What I was describing is a requestor that is hosted somewhere other than the
Tandem (e.g. a UNIX based X client) that wishes to use the backend services of
the Tandem application. In such a case, the client could be directed to an
appropriate Pathway server by a fairly simple listener process. The server
(multithreaded or not) could then receive its requests via the TCP stream and
talk directly to the client. The flow would be Unix client -> TCP/IP -> Tandem
server with SERVERCLASS_SEND calls used by the listener for notifying available
servers of new connections that need to be handled.
Jim Hinsch
operates in two modes: Server or Client.
Server mode: External clients write to or read from a Tandem TCP/IP address
and port. Our product receives the messages. Based on configuration, the
product forwards the messages to a process and gets a reply, pathsends to a
Pathway server, or writes to a file.
In client mode, any tandem program can read and write to any TCP/IP address
as though they were a local Tandem process.
With no coding changes, you can cause any Pathway server to forward its
messages off to any server in any Pathway on any Tandem accessible via
TCP/IP. Talk node-to-node without Expand.
See http://www.mastercomputergroup.com/descriptions/tcpipdr.htm for
documentation.
E-mail: Sa...@www.MasterComputerGroup.com for an evaluation copy (6
months).
Art Rice
wrote:
>Surely it would be much simpler for those with license to a Tandem C
>compiler, since such examples are readily available.
>
>Someone pointed out there is documentation of how to do IP sockets
>programs in TAL. I'd love to hear about that again. The points
<snipped>
here it is. I think Joel sheppard posted this one.
---------------------------------------------------------------------------------------------------------
It is doable in TAL/pTAL but C would be a better long term choice.
The Tandem supplied file $SYSTEM.ZTCPIP.TALDOCUM Titled
" Interfacing TAL programs to TCPIP Socket Library"
provides instructions and guidelines.
Excerpt from the 1st page of that document.
The Socket Library currently interfaces with applications written in
`C`. This paper addresses an adaptation of the Socket Library able to
support applications written in TAL or pTAL. A variety of details
will change, but the overall functionality, organization, and
operational mechanisms will remain intact. The Socket Library
documentation as found in the Tandem TCP/IP Programming Manual should
be adequate to introduce the reader to the Socket Library and this
paper assumes as much. Additionally, it is assumed that the reader is
familiar with TCPIP and the TAL/pTAL programming language. The
specific details and exceptions which must be considered to write a
TAL application will be found in in the following sections.
In article <8gigo7$iuu$13$1...@news.t-online.com>,
wag...@cs-software-gmbh.de
says...
>
>Hi Cliff,
>
>TCP/IP on NSK is available only via the C programming language and the
>function calls involved ("sockets") look completely different than any other
>communication subsystem on Tandem. However we have a product called
>CS-TCP/IP-CI which acts as a gateway process and lets TCP/IP look (almost,
>because there are a few more things to consider with TCP/IP) exactly like
>X25AM. With this product you can use your favourite function calls (like
>SETMODE, SETPARAM, CONTROL, WRITE, READ) to interface to TCP/IP.
>
>Talking to a printer via TCP/IP may however be a different issue. What you
>need there depends a bit on the way the printer talks TCP/IP. The standard
>for printing over TCP/IP is called LPR/LPD, this is an Internet standard and
>most network printers understand that "language". For that kind of
>connection we also have a solution: CS-PRINT with the optional LPR module.
>By the way: CS-PRINT can also print over X.25, so it probably could replace
>your existing solution...
>
>If you need more information please contact
>
>CS Software GmbH
>Schiersteiner Strasse 31
>D-65187 Wiesbaden
>Phone ++49 611 8908555
>Fax ++49 611 8908556
>eMail werner...@cs-software-gmbh.de
>www.cs-software-gmbh.de
>
>
>Tandem&Unisys Utility <gh...@ghit.co.uk> schrieb in im Newsbeitrag:
>392BB15D...@ghit.co.uk...
>> Hi all,
>>
>> we have written an X25 print process which has work well for years now
>but
>> would like to convert it to call a printer over TCPIP.
>>
>> I was hoping I could just replace the code which makes the X25
>Call/Disconnects
>> whith code to make a TCPIP "call".
>>
>> Is this possible? and if so what proc calls are involved?
>>
>> Thanks
>>
>> Cliff Mould
>
>
--
Art Rice **
Special Data Processing Corporation
--------------------------------------
All opinions expressed are mine and do
not reflect the views of my employer.
lawren...@cwusa.com
when you have time to explore all its functionality.
On Mon, 05 Jun 2000 07:06:35 GMT, Priyo Mustafi <priyo...@home.com>
wrote:
>You mentioned that there is another option than listening
>on a port. I am trying to develop a program which is
>similar to the tandem listner but will pathsend to a
>tandem server when it gets a connection from a webserver,
>but I am getting errors (see accept_nw message posted).
>
>I did not quite understand your procedure. Can you
>explain in little more detail or point me to the
>literature.
>Thanks in advance
>Priyo
>
>QjoeW.Ep...@Tmindspring.Ycom wrote:
>>
>> PMFJI, but
>>
>> It is not necessary to develop a process on the Tandem to listen to
>> some port, or to spend (waste) money on RSC or somesuch product, as
>> long as you will always be using TCP to connect the client to a server
>> running under Pathway. If you'll be using transport protocols other
>> than TCP/IP, or need some of the flexibility of RSC, then by all means
>> go for it. But there is a much easier and simpler solution, IMHO.
>>
>> Just configure a service under the Tandem Telnet server for the
>> application, and one or more windows tied to that service for the
>> potential users. The service doesn't even have to be on the Telnet
>> menu, so regular ol' TACL users wouldn't even know it's there. And
>> there are other security features in the service and window
>> configurations under Telnet that may prove useful (e.g., limiting the
>> IP address(es) that can connect to a service/window).
>>
>> Then configure a static terminal under Pathway for each window, a
>> terminal that is tied to an IDS requester (that you must develop) that
>> is coded to do a SCOBOL send to whatever server is appropriate. The
>> requester could look at the message do determine the appropriate
>> server, or perform other functionality that seems appropriate, before
>> sending the message it received from the remote client.
>>
>> Of course, this means the client has to create an IP socket through
>> the Telnet port, and interpret and respond to the prompt Telnet throws
>> up with the name of the service you've defined, but this is something
>> that should be easily accomplished in Java.
>>
>> Good Luck!
>> ```
>> Joe
>> (remove "q.w.e.r.t.y" to reply by email)
>> ===
>> Q: How many surrealists does it take to screw in
>> a lightbulb? A: Two. One to hold the giraffe and the
>> other to fill the bathtub with brightly colored
>> machine tools.
>> ===
>> On Fri, 02 Jun 2000 13:42:11 GMT, Steve Murphy
>> <steve_...@my-deja.com> spewed forth:
>>
>> >In article <39356cd3....@news.cwi.net>,
>> > lawren...@cwusa.com wrote:
>> >> I have designed and written the software that provide such
>> >> functionalities. I can provide more infomation if anyone is
>> >> interested.
>> >>
>> >
>> >1. Use java either RMI with JPathsend or servlets
>> >2. Write your own program to listen for requests on a port and either
>> >handle the session itself, or pathsend to a 'session server' that does
>> >the accept_nw2, then loop doing recv, SERVERCLASS_SEND_, send for the
>> >life of the session.
>> >3. Use RPC or RSC (search tandem.com or TIM).
>> >
>> >
AJITAV DUTTA
> I have designed and written the software that provide such
> functionalities. I can provide more infomation if anyone is
> interested.
While trying to search for some info on the same topic your post came up on Google search.
Can you please provide me the information on how to connect clients to Tandem Pathway via TCP/IP.