What about running it at 132 characters/line?
Hans
$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SHOW/HEX TTY_DEFCHAR
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
TTY_DEFCHAR 180010A0 180012A0 00000000 FFFFFFFF Bitmask
OR the result with %x200 (TT$M_WRAP = ^X200). In this example, the result
is %x180010A0 . ORed with %x200 yields %x180012A0.
SYSGEN> SET TTY_DEFCHAR %x180012A0
SYSGEN> WRITE CURRENT
This should set the default terminal characteristic to be WRAP. This will
affect all terminals but since you can put a $ SET TERMINAL in SYLOGIN.COM
or LOGIN.COM, this shouldn't be too much of an issue.
If you are talking about terminal specific features that are somehow clear-
ed when you reboot, you will want to have some escape sequence output dur-
ing the initial primordial phases of the bootstrap to reset these. I'd be
more inclined to try to figure out *why* these should be reset than trying
to hack a work-around.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
> TTY_DEFCHAR 180010A0 180012A0 00000000 FFFFFFFF Bitmask
> This should set the default terminal characteristic to be WRAP.
Does this also affect OPA0: ????
Also, would VMS send out escape sequences to tell the terminal to set
wrapping to off based on the above setting ?
I was under the impression that "wrap" at the VMS (TTY_DEFCHAR) level
would cause the terminal driver to insert CR-LF into the stream, whereas
the autowrap feature of a VT terminal would automatically fold to the
next line any data that exceeds the rightmost character position (80 or
132 depending on mode).
Based on Mr Helbig's description, it would appear that VMS would send to
the terminal some escape sequence that would reset the terminal's own
local characteristics.
Is this on a VAX or Alpha machine ?
I guess most messages are less than 132 characters. However, I prefer
80 (due to the larger font) and especially for consoles, since I often
glance at them out of the corner of my eye.
> In article <h0dsq6$1lh$1...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
> >I use VT320 as console terminals. I have them set up like I want. This
> >includes AUTOWRAP. Otherwise, messages can be cut off. After a boot,
> >this setting is gone, and I have to go into the setup and "Recall" the
> >correct setting (this is quicker than explicitly resetting it). This
> >happens far too early to correct it via SET TERMINAL in the startup. Is
> >there any way around this problem?
> >
>
> $ MCR SYSGEN
> SYSGEN> USE CURRENT
> SYSGEN> SHOW/HEX TTY_DEFCHAR
>
> Parameter Name Current Default Min. Max. Unit Dynamic
> -------------- ------- ------- ------- ------- ---- -------
> TTY_DEFCHAR 180010A0 180012A0 00000000 FFFFFFFF Bitmask
>
> OR the result with %x200 (TT$M_WRAP = ^X200). In this example, the result
> is %x180010A0 . ORed with %x200 yields %x180012A0.
I currently have the default %X180012A0. If I understand you correctly,
this should already contain AUTOWRAP.
> This should set the default terminal characteristic to be WRAP. This will
> affect all terminals but since you can put a $ SET TERMINAL in SYLOGIN.COM
> or LOGIN.COM, this shouldn't be too much of an issue.
Right, that's what I was looking for, but it seems I already have it.
> If you are talking about terminal specific features that are somehow clear-
> ed when you reboot, you will want to have some escape sequence output dur-
> ing the initial primordial phases of the bootstrap to reset these. I'd be
> more inclined to try to figure out *why* these should be reset than trying
> to hack a work-around.
It happens on all of my machines. I have nothing fancy in the startup
in this respect.
> VAXman- @SendSpamHere.ORG wrote:
>
> > TTY_DEFCHAR 180010A0 180012A0 00000000 FFFFFFFF Bitmask
>
> > This should set the default terminal characteristic to be WRAP.
>
> Does this also affect OPA0: ????
Interesting question; I'm only concerned with OPA0: since for others
SYS$SYLOGIN is executed.
> Is this on a VAX or Alpha machine ?
I see the problem on both.
CSI ? 7 h : set autowrap on.
CSI ? 7 l : set autowrap off.
(for the "off", the character is lowercase L as in "elle").
Check when you power on the vax/alpha to see if it sends that ?7l
command, then check when you type "boot" to see if it sends it early on
(firmware) or later on (VMS).
> I would suggest you put the terminal in "display control codes" mode.
>
> CSI ? 7 h : set autowrap on.
> CSI ? 7 l : set autowrap off.
The problem is that the problem occurs at the very beginning of the
startup, even before SYLOGICALS.COM is executed.
> Check when you power on the vax/alpha to see if it sends that ?7l
> command, then check when you type "boot" to see if it sends it early on
> (firmware) or later on (VMS).
How?
By putting the terminal in "display control codes" mode...
--
Bob Eager
It affects default terminal characteristics.
>Also, would VMS send out escape sequences to tell the terminal to set
>wrapping to off based on the above setting ?
I don't know but there may be an escape sequence causing some sort of
a terminal reset. I'd have to review the bootstrap detail to be more
certain of it.
My quick and dirty solution for you would be to put <CSI> or <ESC>[ and ?7h
in SYS$SYSTEM:STARTUP.COM
Replace:
$stdrv$start_msg = f$fao("%STDRV-I-STARTUP, OpenVMS startup begun at !%D",0)
With:
$write sys$output "<ESC>[?7h"
$stdrv$start_msg = f$fao("%STDRV-I-STARTUP, OpenVMS startup begun at !%D",0)
> My quick and dirty solution for you would be to put <CSI> or <ESC>[ and ?7h
> in SYS$SYSTEM:STARTUP.COM
It happens even before that, e.g. when doing a minimum boot. The
messages about cluster connections, write bitmaps etc.
PATCH the copyright message in EXEC_INIT.
If it is after VMS has booted, then you might consider doing a search
for ?7l in all of the executables involved with early VMS booting. And
then using PATCH (in absolute mode) to change the L into an H.
STARTUP.COM is run during a minimum boot. Perhaps you meant a
conversational boot.
AEF
Maybe there's something in the shutdown procedure? Perhaps in
SYSHUTDWN.COM?
Be sure to be on the lookout for SET TERM/INQUIRE. That puts my VT420
in No Auto Wrap mode.
I used to have this very same problem, but I can't reproduce it now.
I'll report back if I find what it was.
AEF
My recollection is that, very early in the boot sequence, possibly
in the console code, the system sends some sort of "reset" sequence
to the terminal (or at least to the keyboard). This came up in the
context of KVM switches and Fred Kleinsorge relayed the inside
scoop. [I'm likely quite wrong in the details, but at the high level,
I think I've got it right.]
Now whether this would cause a VT420 to revert from user
settings, I've no idea.
-Ken
> On Jun 7, 9:05=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> remove CLOTHES to reply) wrote:
> > In article <00A8CACD.C109A...@SendSpamHere.ORG>, VAXman-
> >
> > @SendSpamHere.ORG writes:
> > > My quick and dirty solution for you would be to put <CSI> or <ESC>[ and=
> ?7h
> > > in SYS$SYSTEM:STARTUP.COM
> >
> > It happens even before that, e.g. when doing a minimum boot. =A0The
> > messages about cluster connections, write bitmaps etc.
>
> STARTUP.COM is run during a minimum boot. Perhaps you meant a
> conversational boot.
Yes, right, thanks (I don't do it that often).
> My recollection is that, very early in the boot sequence, possibly
> in the console code, the system sends some sort of "reset" sequence
> to the terminal (or at least to the keyboard).
I doubt it does a reset to factory defaults though.
If yu set the terminal to have autowarp and then save those settings,
then I would expect a "reset" command to restore saved settings which
would include the "autowrap".
Going back to VT100 days, my first action after powering up a new one
was to disable the margin bell and hardware autowrap via the firmware
setup. AFAIR, neither got reset to factory defaults in the normal
course of running VMS.
I understand why Philip wants autowrap in this context, but for a
typical SMG style application, you don't really want it.
--
Paul Sture
<ken.fa...@gmail.com> wrote in message
news:201a4ac1-9be4-45db...@q14g2000vbn.googlegroups.com...