Starting a telnet sesseion

[King]

Hi all,

I want to start a terminal process in my TAL program and interact with it. Is there a program file I can LAUNCH/SPWAN?

Thanks,
kl

[King]

I guess a better question to ask is which program file I will have to launch to start a telnet/terminal process?

[wbreidbach]

That is pretty easy, just use $SYSTEM.SYSTEM.TELNET. But I am wondering a bit about that idea, wouldn't it be a better idea to start a sockets communication?

[King]

Thanks for your reply.

I think I need to be more specific. My main TAL program has to start the terminal session and allows a third party process to use it as OUTPUT and TERM. My main TAL program then collects these output. Primarily, my TAL program will just OPEN and READ the terminal process. Will starting TELNET suffice?

When you say sockets do you mean using TELSERV interface? I am not familiar with that.

[dimandja]

Why don't you use an ordinary process to collect output? Why does it
have to be a terminal?

[wbreidbach]

Am Freitag, 16. März 2012 14:34:20 UTC+1 schrieb King:

The main question is: Is the 3rd party software running on the NonStop or on another system?
Let me explain:
If the software is running on the NonStop your program just has to simulate a terminal, there should no Telnet be necessary. Simulating a terminal is not a big problem.
If the software runs on another system and send the data to the NonStop I do not think that Telnet would do the trick. In that case you would either need a process reading TCP/IP input, probably started by the Listner or maybe it could be done using Telserv.
So I do not see where the Telnet makes sense but maybe I completely misundetstood your problem.

[wbreidbach]

Am Freitag, 16. März 2012 14:34:20 UTC+1 schrieb King:

Just let me explain what we are doing:
We have a process $HOME receiving output and acting as a hometerminal. The output received is recorded into 3 sequential files which are written in a round-robin mode. The records contain time and sender-id. The process is under control of the persistence monitor. In addition I have implemented the handling if inspect/debug requests. If the process is asked by deviceinfo, it responds 6.4 (6530 terminal).

[Doug Miller]

King <king.leun...@gmail.com> wrote in
news:205464.1048.1331909752703.JavaMail.geo-discussion-forums@ynnk21:

> On Friday, March 16, 2012 10:03:26 AM UTC-4, wbreidbach wrote:
>> Am Freitag, 16. März 2012 14:34:20 UTC+1 schrieb King:
>> > Hi all,
>> >
>> > I want to start a terminal process in my TAL program and interact with
> it. Is there a program file I can LAUNCH/SPWAN?
>> >
>> > Thanks,
>> > kl
>>
>> That is pretty easy, just use $SYSTEM.SYSTEM.TELNET. But I am wondering a
> bit about that idea, wouldn't it be a better idea to start a sockets communication?
>
> Thanks for your reply.
>
> I think I need to be more specific. My main TAL program has to start the terminal session
and allows a third party process to use it as OUTPUT and TERM.

It would be far simpler to have that process use your TAL program as OUT and TERM.
Why do you think you need TELNET in between?

[King]

Thanks again for your suggestions. All these are great ideas, I particularly like your first approach, that is, to make the main TAL program to become a terminal process. If fact, I'd try to make it work this way already. I must have done something wrong.

The third party process is running on the same NonStop system as the main TAL process. So TCP/IP will not be necessary.

Here is how this thing supposed to work. The main TAL process sends a request to process 2 and subsequently sends request to process 3 then process 3 to process 4. Process 4 uses the main TAL process as its OUT and TERM. Making the first request to process 2 a NOWAITed call locks up $RECEIVE ,it also holds up transactions for the main TAL process. The whole chain of requests are within one TMF transaction. That's why I thought of starting a TELNET session, which is the simplest solution without making a whole lot of changes to the main TAL program. Note: I can not make any changes to process 2, 3 or 4.

If I opted out the TELNET idea, any tip as to how to make the main TAL process becomes a terminal process?

[King]

On Friday, March 16, 2012 11:15:09 AM UTC-4, dimandja wrote:
> Why don't you use an ordinary process to collect output? Why does it
> have to be a terminal?

An ordinary process would work too. I am looking for a quick and dirty solution at this stage. I am working towards a prove of concept for now.

[King]

Doug,

Thanks for your responds. Sorry I missed that it was your idea I like.

[wbreidbach]

Am Freitag, 16. März 2012 14:34:20 UTC+1 schrieb King:

Just drop me a mail, I can send you the program I mentioned above. If you do not want those messages to be logged, check if a $NULL process exists on your system, that process is the "bitbucket", but I do not think it behaves like a terminal.

[King]

Email sent. Thanks!

$NULL is also an option. I will have to find out how I can identify the corresponding output. $NULL is a public bitbucket after all.

Thanks.

[MicroTech]

On Saturday, March 17, 2012 10:39:38 PM UTC+8, King wrote:

> I want to start a terminal process...

Being late to this thread, maybe your problem is solved by now?

Anyway, I get the feeling that you're talking about a "go-between" process, capturing whatever is communicated via your "fake terminal" process and its "target" process.

If my hunch is correct, let me know, and I'll post the HTERM code I wrote for TSE many years ago (later transmogrified into a Tandem product called VHS)!

Cheers,

Henry Norman
MicroTech Consulting
https://sites.google.com/site/microtechnonstop

[King]

Thanks. I can't say it's been solved, I am still testing with suggestions posted by fellow members. :)

Your description of "go-between" process fits best to my situation so far.

[MicroTech]

On Saturday, March 31, 2012 10:25:11 AM UTC+8, MicroTech wrote:

> I'll post the HNTERM code I wrote for TSE many years ago...

Hello King!

Actually, that was TIP (not HTERM, that was another project ;),
short for "Terminal Interceptor Process"...

I (finally!) found the source! You can download it from my Google
site, sites.google.com/site/microtechnonstop/f/hntip.zip. Please
keep in mind that the code is 21 years old (but it is Tandem TAL,
so it should compile without errors and run with no flaws), so it
is not "enlightened" (i.e., it uses the original Guardian procs).
To get it up to G/H and pTAL could be an interesting project for a
budding TAL programmer (if such beasts are still being bred...).

Documentation, as it is, in the source. I tweaked it 11 years ago
(solving an irritating "terminal break" problem.

Whether you try the code or not: Good Luck in your endeavors!

[King]

Henry,

Very cool. Thank you! I will definitely look into it.

Best regards,
King

[King]

On Friday, March 16, 2012 9:34:20 AM UTC-4, King wrote:

I actually tried using PROCESS_LAUNCH_ to start $SYSTEM.SYSTEM.TELNET to see how it works. I used WRITEX to send the Startup message and got error 70 (according to the manual, that's OK). Once I did that, I receive an error 29 and the telnet process dropped. Can't understand why.

If any of you know anything about this error, please share your thoughts. Otherwise, don't worry about it. :)

[MicroTech]

On Tuesday, April 24, 2012 12:38:12 AM UTC+8, King wrote:

> I receive an error 29 and the telnet process dropped...

King,

Error 29 is always due to a programming error (parameter
inconsistency). Check the source procedure call (that failed
with error 29) parameters against the manual, make sure all
have the proper type and content.

Cheers,

Henry Norman
MicroTech Consulting

sites.google.com/site/microtechnonstop

[Keith Dick]

I'm not sure starting TELNET will help you solve the problem as you described it in your post date 3/16 7:40 pm in my time zone. Let me explain a few things and ask a few questions.

TELNET is for establishing a telnet emulated terminal session over a TCP/IP connection, usually to another system, though you probably could use it to establish a terminal session to your own system (I've never tried that). Assuming you can establish a telnet session to your own system, the only way you would be able to see process 4's output in the telnet session is if you started process 4 from the telnet session. Is that what you had in mind?

If that is what you are trying to do, when you start TELNET, you would have to specify your TAL program's process name as the IN and OUT file, and perhaps its home terminal, though IN and OUT might be enough. You apparently are having a little trouble getting that to work, and if you decide you really want to take that approach, we can help you solve that problem.

If you can get TELNET started that way, any output it writes will appear on the TAL process' $RECEIVE. Any prompt it writes will appear on the TAL process' $RECEIVE. The TAL process would send commands to the TELNET process by REPLYing to a prompt message it received from TELNET. The TAL process would have to send commands to the TELNET process to connect to your system IP address, select the TACL service, logon, then finally send a command to start process 4. Subsequent output from process 4 would go to TELNET which would write it to your TAL process and it would appear as a message on the TAL process' $RECEIVE. Since the TAL process is also communicating with process 2 and process 3, I imagine you must do *all* of the I/O as nowait I/O with a single waiting point so that the TAL program does not end up in a deadlock. That could become a fairly complicated program, depending on how much other interaction it has to do.

The other way people have been suggesting is that when you start process 4, you give the TAL process' name as process 4's OUT and TERM file. That would work similarly to how running TELNET from the TAL process would, however you would be dealing only with output from process 4, not sending commands to establish a session, logon, etc. So it would be simpler from that regard, but probably still would need to use all nowait I/O with a single waiting point and still might be complicated.

Even though you would want process 4 to use your TAL process as its OUT and TERM file, you would not have to start process 4 from your TAL program. If you start your TAL program first, then you can use ordinary TACL RUN commands to start process 4 and specify the TAL process' name as the OUT and TERM file.

If process 4 checks the device type of its OUT or TERM file and insists that it be a terminal, you will have to mark the TAL program as a subtype 30 program so it receives the request for DEVICEINFO on its $RECEIVE and replies with some type and subtype acceptable to process 4.

There might be other, simpler ways, depending on the details of what you need to do. I would only suggest that you try to make the TAL process accept the output from process 4 if the TAL program actually needs to see that output to make some decisions. Having loops in your application's message flow isn't a very good idea. If you only need to capture the output from prcoess 4 for some sort of logging after the transaction is done, send it to a file and read it back after the transaction is done (or send it to another process to hold in its memory, then have the main TAL process send a request to that process to fetch all the output after the transaction is over. Of course, that doesn't apply if the main TAL process needs to see the output from process 4 during the transaction.

Back in that post of 3/16, you said making the first request to process 2 be nowaited locks up $RECEIVE. That makes no sense to me. Either you described it incorrectly or you misunderstood something about what was happening. That was more than a month ago, so you may have changed things a lot since then, so if that point isn't relevant any more, just ignore it.

So, in summary, you might be able to use TELNET if the guesses I made above are what you had in mind, but I doubt it is the best approach to your problem. Specifying your TAL process as the OUT and TERM files for process 4 would be better than using TELNET, but still pretty complicated, probably requiring that you do all the I/O in the transaction as nowait and use a single AWAITIO call to avoid deadlock. We can try to help you get that right, but I wouldn't recommend it if you aren't already fairly experienced with using nowait I/O. If you can find a solution that does not require sending the output of process 4 back to the main TAL process during the course of the transaction, that ought to make things much simpler. However if the TAL process absolutely needs to see that output during the transaction, maybe you will have to learn how to do the complicated programming, but try hard to think of another way.

[wbreidbach]

Am Freitag, 16. März 2012 14:34:20 UTC+1 schrieb King:

Am Freitag, 16. März 2012 14:34:20 UTC+1 schrieb King:

If you are starting a telnet process you have to specify the destination address within the startup-message like telnet 1.2.3.4 [port]. And do not forget that telnet needs the define =tcpip^process^name!
As far as I know you are able to do a loopback connection, in that case you could use telnet 127.0.0.1.
Besides of that I still do not understand why you want to start a telnet process.

[King]

Keith, Thanks for a lengthy response, first of all. You are reading my mind. You described exactly what had happened. I did mess up the NOWAIT calls. As soon as failing the startup of telent (APril 24), I reworked the TAL process and had it working with the NOWAIT calls. Just so you know, process 4 is not something I can start at a TACL prompt. It is actually started by process 3. The TERM and OUT of process 4 is determined by the TAL process, fortunately.

Thanks to some great tip from all you folks, I can capture all output from process 4 now. I managed not needing a second process (or a file for that matter) to hold the output from process 4. And you are right, it can be very messy if I am not careful with the loops. To make it more clear, process 2 and 3 are also dumping output to the TAL process, and I do not have any control over that.

To make a long story short. I got all the above accomplished.

Thanks to all contributors in this forum! Keep it going.

[King]

On Tuesday, April 24, 2012 5:22:32 PM UTC-4, wbreidbach wrote:

> If you are starting a telnet process you have to specify the destination address within the startup-message like telnet 1.2.3.4 [port]. And do not forget that telnet needs the define =tcpip^process^name!
> As far as I know you are able to do a loopback connection, in that case you could use telnet 127.0.0.1.
> Besides of that I still do not understand why you want to start a telnet process.

Wolfgang, Thanks for this tip. As I posted earlier, I managed to accomplished what I needed. However, I am not giving up on trying to start a telent from my TAL process as it may solve a different but related challenge. So I will give this a try. Thanks again!

[Keith Dick]

While you can put the remote address and port in the startup message, that is optional. The "open" command can be used to establish a connection after telnet has started and prompted for a command. Use whichever way is most convenient for you.

[King]

Henry,

I got the error 29 after

Sorry Henry, I missed your reply here.

I will look into that. Thanks for your advice.