[Info-vax] Reverse telnet to a terminal emulator?

[VAXman- at SendSpamHere.ORG]

In article <j05a2a$2k6$1 at speranza.aioe.org>, Snowshoe <no at spam.please> writes:
>On 7/19/2011 8:05 PM, VAXman- @SendSpamHere.ORG wrote:
>> In article<j050dd$fh5$1 at speranza.aioe.org>, Snowshoe<no at spam.please>  writes:
>>> On 7/19/2011 5:08 PM, VAXman- @SendSpamHere.ORG wrote:
>>>> In article<j04nl8$q39$1 at speranza.aioe.org>, Snowshoe<no at spam.please>   writes:
>>>>> I have done this in the past, sort of. (swiped
>>>>> SYS$EXAMPLES:ALPHA_LOGGER.C and changed the non-pseudoterminal portion)
>>>>>    The pseudoterminal part is actually strange code if you have to tamper
>>>>> with it, but I didn't.
>>>>
>>>> What's so strange about it?
>>>
>>> [snip code]
>>>
>>> The buffers must be in that specially allocated memory which must be
>>> page aligned, your data can't be just anywhere. (I got bit by this when
>>> one of my changes meant the PTD side tried to access memory outside its
>>> special area, and it failed. I had to add an extra copy of my data to
>>> its special area)
>>
>> It does not need to be page aligned.  Your buffers must come from the
>> memory allocated and assigned to the pseudo-terminal in the PTD$CREATE.
>
>I recall it being required to be page aligned in the VAX days.  Maybe 
>that changed.  With $QIO, my buffers can be anywhere I want.
>
>> I'd just divvy up the allocated region and put chunks on a queue that
>> you can allocate and deallocate buffers from.  A piece of cake with a
>> INSQxx and REMQxx in Macro.
>>
>>
>>> I/O to a device that doesn't use $QIO. That's kind of weird for VMS.
>>
>> Your code will issue $QIOs to the FTAx device.  That's not that weird
>> for VMS.
>
>I meant for the non-terminal end.  If you'll recall with the TW/PY pair, 
>the TW end was a normal terminal which used normal terminal driver 
>$QIOs, and you issued $QIOs to get the data to/from the emulator end 
>(PYxx: ).  The program writes to its TW terminal, you do a $QIO read 
>from the corresponding PYxx: to get the data.
>With the FT driver, you have this odd set of parallel services to do the 
>emulator.

What's so odd?  PTD$READ/PTD$WRITE



>> The PTD$READ is really simple.  You get handed the data that was seen
>> at the FTAx device in an AST.  Read the buffer.  Simple.
>
>As simple as $QIO READVBLK on PYxx:, except the funky buffer.

Funky buffer?



>>> I've also tinkered with the TW/PY pseudoterminal pair, long long ago.
>>> The PY end used standard QIOs. Want to see what the application just
>>> wrote to the terminal? Just $QIO READVBLK to the PY device.
>>
>> As did I.  The TW/PY pseudo-terminal worked but was much more effort.
>
>I found TW/PY easier.
>
>>> Not super-strange, just not what I expect from VMS.
>>
>> You don't expect ASTs?
>
>I expect to be able to put my buffers where I want.
>
>I don't expect a set of parallel routines:
>
>PTD$READ instead of $QIO READVBLK
>PTD$WRITE instead of $QIO WRITEVBLK
>PTD$CANCEL instead of SYS$CANCEL
>PTD$SET_EVENT_AST instead of $QIO SETMODE or something.
>etc.
>
>None of these are earth-shattering, it's just not what I'm used to 
>seeing coming from VMS Engineering.

Well, then I'd better quit while I'm ahead and stifle mention of the RMS
routines.  I'll let you continue issuing your $QIOs for all of your disk
I/O needs.



>The example code in SYS$EXAMPLES (and your code) calls the PTD handle a 
>"channel". It's a short int, like a real VMS channel. I'll have to poke 
>around in SDA to see if it really is a standard VMS channel (and if so, 
>to what).

It is a channel but what does it matter?  The FTAx device will appear to
any application to be a typical terminal.  Your application can read and
write from and to this FTAx device like it can to ANY terminal.  You, on
the other side, talk to the terminal with PTD$READ -- to get what the ap-
plication wrote to the FTAx -- and PTD$WRITE -- if you need to supply an
input to the application (ie. the keyboard).  And, FWIW, you can use the
"PTD handle" (aka, channel) and pass it to $GETDVI to get typical device
info (for example, DVI$_PID if you wanted to know who owns the terminal).
So, it IS a channel to the device.

This is getting as silly as the argument which ensued recently in one of
the "Linked-In" forums wherein a former VMS engineer claimed that VMS is
not VMS unless it runs solely/wholly on VAX.  The stuff running on Alpha
and Itanium is not VMS! :rolleyes:

Do you code in C?  Do you complain about printf()s with null-terminated
strings?  That's most definitely NOT VMS-like.

In the time it's taken you to complain about this, you could have had a
prototype coded.  I gave you the crux of the program.  You'd only have 
needed to take the data in the PTD.READ_AST and issue a socket send() or
	$QIO	efn	= #EFN$C_ENF,-
		chan	= socket_channel,-
		func	= IO$_WRITEVBLK,-
		iosb	= some_iosb,-
		astadr	= (your-option),-
		astprm	= (your-option),-
		p1	= PTD.IO_BUFFER,- <== addr: PTD.READ_AST param+4
		p2	= buffer_size,-   <== word@ PTD.READ_AST param+2
		p4	= any_appropriate_flags
since the send() is not very VMS like.

If I keep replying to this thread, I'll have done all your work!  ;)

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.