Changing the output of the TYPE command

[Anthony Silverman]

The DCL command type/page=search filename.txt displays a menu bar at the bottom of the screen that contains "RETURN/SPACE=More, PREV/NEXT=Scroll"

How can I change the menu bar to display everything in upper case "RETURN/SPACE=MORE, PREV/NEXT=SCROLL"?

[Volker Halle]

Anthony,

use SET TERM/NOLOWER or SET TERM/UPPERCASE to force the terminal driver to convert all characters to uppercase.

Volker.

[Jan van den Ende]

Antony,

AFAIK, those texts are part of the executable.
You may try to patch it.

For pretty simple EXEs I have successfully I have done that with a simple editor (because I did not have the compiler for the source language), AS LONG AS YOU __DO__ KEEP THE STRINGS __EXACTLY__ THE SAME LENGTH.

NO guarantee of success, and because TYPE is included in VMS, every new version or patch MIGHT replace it, and require a redo.

YMMV.

Good luck & success.

Proost.

Have one on me.

jpe

[Hoff]

You don't seem to assume VMS, you seem to want or expect a Unix shell here.

It also doesn't seem that you want the TYPE command here, you likely want to use the Unix-like more or the less tools, or analogous. Various ports are available.

And there's a copy in GNV.

Interestingly, you're also asking for some added extra "fun" here as the "prev" and "next" keys aren't ubiquitous keys.

And please consider posting why are you might be asking this question. Some background? Goals? Requirements? Without some background and some requirements, we might get you the correct answer, but might well miss the best answer. We can't tailor the answer to your particular requirements, only to your point question.

[H.Becker]

The text comes from a message file and can be found in CLITULMSG.EXE. Presumed you have the privileges, you can patch the string there. It's installed, so replace it and all users will see the changed string. If you just want to see this in your environment, make the change in a local copy and define the logical cliutlmsg pointing to your copy. Include the file version in the define.

After you figured out what the length field is you can probably patch in place or make the string shorter. Happy hacking!

[John Gillings]

re Jan:

>AFAIK, those texts are part of the
>executable

No, they're not in TYPE.EXE, they're (correctly) isolated in a message file. That means you can easily support multiple languages without requiring multiple versions of the image.

See SYS$MESSAGE:CLIUTLMSG.EXE. Note there are several messages which contain the string you're interested in "RETURN/SPACE=More, PREV/NEXT=Scroll"

An upper case variant can be dealt with as if it were another language. Obtain a copy of CLIUTLMSG.MSG from the source distribution, make modifications to the message text, and recompile it into a site specific variation of the standard message file.

For more detail about the message utility see "HP OpenVMS Command Definition, Librarian, and Message Utilities Manual"

http://h71000.www7.hp.com/doc/82final/6100/6100PRO.HTML

[John Gillings]

Looking around the web I found the freeware utility UNMESSAGE which says it can decompile message files. However, it's a VAX image. Although source code is provided, it doesn't look like it will work on Alpha or IA64, even assuming the message table formats are the same. A quick glance at the code shows a $CRMPSC call with an address range which won't work on Alpha.

If you have a VAX running V7.3, you may be able to decompile its copy of CLIUTLMSG, then move the source code to Alpha or IA64 for compiling. Hoping that later versions haven't added new messages.

[Craig A]

Hi Anthony

I'm curious as to why you would want to do this.

Craig

[Anthony Silverman]

Here's the reason why I want to do this.

The company that I work for is in Israel and therefore the primary language of the end users is hebrew. Our systems have been built with a character set that is 7-bit hebrew. This means that our end users can see either hebrew or lowercase english but not both together.

The words "More" and "Scroll" that I mentioned in the original question will therefore appear as gibberish ("More" - capital M followed by 3 hebrew characters)

I like John's idea of creating a multi language version of the TYPE command. I will try to create a hebrew language version of the TYPE command.

[Hoff]

This is probably a legacy application, as comparatively few packages are using DCL and VMS as a front-end user interface, and fewer still use the internationalization interfaces and local language support. Are you working toward a transition to a different front-end? (How much are you investing in this front-end?)

VMS and DECwindows once had language variants; internationalized add-ons. Hebrew was one language that had some local language add-ons. Some of these may still exist, depending on what version is in use here. Particularly if this isn't a current release.

Also see the SYS$LANGUAGE support, and APIs including LIB$GET_USERS_LANGUAGE().

That support had some oddities; definitely test.

There was some damage around the message help files when local languages were enabled. I don't know if that got fixed, or if you had to (for instance) redirect the message help files over to the English message help files if the localized files weren't installed, for instance.

There are additional issues here, given the lack of unicode support in the operating system and tools.

Was "just" TYPE the central issue here, then I'd get rid of the TYPE command. The more or less tools with message catalogs (and C had message catalog support on recent releases) might get you where you want for this case. That gives you full control. (I've posted what amounts to full source for a type command, using C and RMS calls, if you're interested.)

[H.Becker]

I'm sure the problem is already solved and nobody cares about decompiling messages any more: so this is some more unwanted and useless information from my side.

The message format is the same on all platforms.

Once you get to the message section, an image section on VAX/ALPHA or a program segment on Integrity, you can use the decompile code from Joe Meadows's UNMESSAGE utility. Actually his tool starts with a longword vector at offset 16 in the first image section. It shows that for nonexecutable message files the message section always starts at VBN 2, no matter which platform the message file was produced for.

So I made a simple open source version based on Joe's decompile code with hard coded VBN and offset. The sources are attached - the include file, although renamed, is unchanged. I tested unmsg on Linux with a couple of message files. It should be easy porting this to VMS.

Warning, there is no check whether the passed-in file is indeed a nonexecutable message file. That wasn't the case in the orignal tool and it is known that VMS code doesn't do this either. Obviously the utility can be improved, but that wasn't the goal and may not be worth the time, or?

On the other hand, I don't see why the $crpmsc should fail to expand the P0 region on Alpha or Integrity.

[John Gillings]

Using H.Becker's source code (commented out "__attribute__ ((packed))")

dumped output for SYS$MESSAGE:CLIUTLMSG.EXE into into CLIUTLMSG.MSG, uppercased the messages in question, glued one line together, compiled and linked.

then DEFINE CLIUTLMSG to point to the new file.

Now,

$ type/page=save/search="return" CLIUTLMSG.msg

.FACILITY UTIL,286 /SYSTEM
.SEVERITY WARNING
_011E8008 "TRUE" /IDENT=NORMAL1
_011E8010 "YES" /IDENT=NORMAL2
_011E8018 "1" /IDENT=NORMAL3
_011E8020 "" /IDENT=NORMAL4
_011E8028 "FALSE" /IDENT=NEGANS1
_011E8030 "NO" /IDENT=NEGANS2
RETURN/SPACE=MORE, PREV/NEXT=SCROLL, INS/REM=PAN, SELECT=80/132, Q=QUIT

done.