John writes:
 
...
> NS VT's 80 byte hard and fast limit is horrible!  You can run a program that
> generates a 132 column display fine locally, but try to run it over NS.
> What you get is a mess because the lines are chopped at 80 bytes.
...
 
Hmmm... I haven't seen any such limitation.  My SHOT tool has a "SET 132"
command to turn on 132-character mode.  When used, it sends the escape
sequence that a 700/92 (or R1Win)uses to switch to 132 character mode (which,
of course :( , hpterm ignores).  It seems to work fine for me, even if
I have to manually expand the hpterm window to 132 columns.  I see all
131 columns of output just fine!
 
I've tested this over NS from a 9000 (using hpterm under X-Windows) and
over NS on a PC-clone (using WRQ for Windows)...all work just fine.
 
> What you get is a mess because the lines are chopped at 80 bytes.
 
No, no evidence of chopping that I can see.
 
> Reconfigure your devices for 66 word records you say.  Done.  Now do a LISTF
 
That's different, and something that I haven't tested.  Keep in mind that
$STDLIST is usually opened, on your behalf, in MR mode ... which is why
you can FWRITE hundreds of bytes at once to a terminal, and not get the
output truncated at the file's ostensible record size (80 bytes, typically).
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html