I know of two places where it makes a difference:

In SYSGEN/IO I'm fairly certain that if you configure
your console (LDEV 20) with an RSIZE of 66, it makes
a difference versus an RSIZE of 40.

In NMMGR Profiles for a DTC, you can specify a Record
Width of 132 instead of 80 for a Profile you can use
on all your DTC ports.

But these are only configurable for wardwired 
terminals, don't know how it can be done to
change the default for Telnet or NS/VT connections.

A user can force the width with a file equation
to $STDLIST then specifying output to the file
equation:

i.e.:  FILE S=$STDLIST;REC=-132

       PRINT MYFILE >*s

Although to tell you the truth, my telnet windows
don't seem to have this problem.

Many thanks to this list over 5 years ago when I
had asked a similar question.

BT
NNNN
Tracy Johnson
MSI Schaevitz Sensors 

> -----Original Message-----
> From: Gavin Scott [mailto:[log in to unmask]]
> Sent: Friday, October 18, 2002 5:16 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Telnet Question
> 
> 
> Matt asks:
> > When we Telnet in to our HP3000 with Reflections or QC Term 
> we are limited
> > to 80 characters as returned by our HP3000.  Telnetting in 
> assigns random
> > device numbers and we never know which device a session 
> will use.  How do
> > you change this to default to 132 character mode for a 
> Telnet session.
> 
> Does this affect ordinary MPE CI command input, or is it just 
> when inside
> your application or some utility program?
> 
> If your problem is that the application you're using is 
> finding out the
> record width of the $STDIN device and using this number to 
> limit reads, then
> I don't know that there's anything you can do to fix it.
> 
> If you were using DTC ports, you could assign a "profile" 
> that would specify
> a different device record width, but I've never seen a place 
> to do this for
> telnet-created virtual LDEVs (or VT ones either for that matter).
> 
> While every "device" needs to have an associated record size, 
> and I suspect
> that all the virtual terminal devices use 80 bytes as this 
> value, I don't
> think any terminal I/O is actually affected by this value, so 
> you can read
> and write more than 80 characters with no problems.
> 
> There are however programs that retrieve the record width 
> value for $STDIN
> or $STDLIST and use this value in some way that is visible in 
> the behavior
> of the program.  A good example is the :LISTF command which 
> formats the
> width of :LISTF,0 output using the record width of $STDLIST I believe.
> 
> It wouldn't surprise me to find that a program would limit 
> the size of its
> terminal reads to the record width of $STDIN, even though this is
> unnecessary when talking to a terminal device.
> 
> Programs that read input from a !JOB see the record width and 
> record type of
> the file that was submitted to the :STREAM command, so it's 
> not unusual to
> see strange behavior from programs that aren't expecting fixed length
> records ending in lots of spaces, or problems using (or not 
> using) variable
> length records or very large record sizes in :STREAM files.  
> Some problem
> like this in the past might have caused someone to put in 
> code like this.
> 
> There could be one or more language runtimes which make some 
> assumptions
> about reads based on the record size of the input file 
> (Pascal maybe?) if
> you use their built-in I/O functions to talk to $STDIN/$STDLIST.
> 
> G.
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 

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