topic Re: Changing the output of the TYPE command in Operating System - OpenVMS

Changing the output of the TYPE command

Anthony Silverman — Sun, 28 Nov 2010 10:44:57 GMT

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"?

Re: Changing the output of the TYPE command

Volker Halle — Sun, 28 Nov 2010 13:40:15 GMT

Anthony,

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

Volker.

Re: Changing the output of the TYPE command

Jan van den Ende — Sun, 28 Nov 2010 13:43:20 GMT

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

Re: Changing the output of the TYPE command

Hoff — Sun, 28 Nov 2010 16:53:02 GMT

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.

Re: Changing the output of the TYPE command

H.Becker — Sun, 28 Nov 2010 21:22:36 GMT

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!

Re: Changing the output of the TYPE command

John Gillings — Sun, 28 Nov 2010 21:47:07 GMT

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

Re: Changing the output of the TYPE command

John Gillings — Sun, 28 Nov 2010 22:27:50 GMT

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.

Re: Changing the output of the TYPE command

Craig A — Tue, 30 Nov 2010 16:35:00 GMT

Hi Anthony

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

Craig

Re: Changing the output of the TYPE command

Anthony Silverman — Wed, 01 Dec 2010 12:20:47 GMT

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.

Re: Changing the output of the TYPE command

Hoff — Wed, 01 Dec 2010 15:26:27 GMT

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.)

Re: Changing the output of the TYPE command

H.Becker — Tue, 14 Dec 2010 21:46:52 GMT

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.

Re: Changing the output of the TYPE command

John Gillings — Wed, 15 Dec 2010 01:04:54 GMT

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.