Conference noted::hackers_v1

	There are two files of interest in SYS$MESSAGE - SYSMSG.TLB and
SYSMSG.EXE.  SYSMSG.EXE, I believe, is what lets the system "know" the mess-
ages as something other than %NONAME-x-NOMSG.
	What you seem to need is a way to put your messages into SYSMSG.EXE.
I don't know if that can be done the same way that (for example) SET COMMAND
puts DCL commands into DCLTABLES.EXE.

	My first approach was to create a set of messages, compile them, and
link them with the shareable SYSMSG.EXE image to yield (I hoped) a new shar-
able image that would be the new SYSMSG.EXE.  Unfortunately, the linker would
not accept
		    SYS$MESSAGE:SYSMSG.EXE/SHAREABLE=COPY
or
		    GSMATCH=NEVER
in the options file (even though the linker reference manual says they should
work).

	My next approach involved the other file, SYSMSG.TLB.  First I created
a huge message file like this:
	    $ LIBRARY/TEXT/EXTRACT=*/OUTPUT=FOO.MSG SYS$MESSAGE:SYSMSG
Then I compiled the file FOO.MSG:
	    $ MESSAGE FOO
Then I took a peek at SYSMSG.EXE with ANALYZE/IMAGE, which told me, among other
things:
	    global section major id: %X'6A', minor id: %X'DF1FBC'
	    match control: ISD$K_MATEQU
I took this information (which may differ from system to system) and created
an options file, FOO.OPT, which had one line in it:
	    GSMATCH=EQUAL,%X6A,%XDF1FBC
Then I linked FOO:
	    $ LINK/SHARE FOO,FOO/OPTIONS
	The resulting file, FOO.EXE, is similar to SYSMSG.EXE.  I compared
the two like this:
	    $ ANALYZE/IMAGE/OUTPUT=SYSMSG SYS$MESSAGE:SYSMSG
	    $ ANALYZE/IMAGE/OUTPUT=FOO FOO
	    $ DIFFERENCES SYSMSG.ANL FOO.ANL
The only differences that showed up were identification differences:  the name
of the image, the date it was linked, etc.
	The next step, which I leave to others to try, is to append your mess-
age definitions file (DDXERR.MSG?) to FOO.MSG, compile FOO.MSG, link FOO.OBJ
with the same options file, yielding a new FOO.EXE.  Then replace SYSMSG.EXE
with FOO.EXE.
	DO THIS AT YOUR OWN RISK!!!  I offer this hack as a way to see how it's
done and, of course, in the interest of hacking.  I certainly don't recommend
using this hack as part of your installation process!  (If it were, you'd have
to put your message definitions file into SYSMSG.TLB so that other layered pro-
ducts using the same hack don't lose your messages...)

	Then again, there might be an obvious, supported way of doing this,
sitting in a manual somewhere, just waiting to be read...

	By the way, layered products should base their messages on a facility
number obtained from the facility number registrar, Benson (GUIDO::) Gray.
That's how layered products keep from conflicting with each other.
		<_Jym_>

Is there any reason why the messages have to be system wide or do they 
just have to be available to the image?

The MESSAGE command will create an object file.  This can be linked 
with the image and the image will recognize the error codes you have 
defined.  If you use the error codes outside of the image, you will get 
an error.

For example, if error code %X00990004 equates to

	'DDX-F-NSD, No such document'

then exiting the image with this code will result in the above message 
being displayed on the terminal.  On the other hand, if a user typed

	'TMP = F$MESSAGE(%X00990004)'

at the DCL level, the symbol TMP would be equated to

	'NONAME-F-???, No message number 00990004'

tom p

As mentioned in .1, system messages for VMS products are assigned, so they are
guarenteed not to conflict.

Therefore, if all you want to do is enable system messages on a system-wide
basis, the easiest solution is to add lines of the form:

    $set message sys$message:<foo>

in the file defined by the system logical SYS$SYLOGIN (usually
SYS$MANAGER:SYSLOGIN.COM).

Could it be this easy?
    				JENelson

You would really get better responses if you placed your request
in the VMSNOTES file on VAXWRK.  I don't know why you want a
"hacker's solution"; sounds like you need a real solution.

	[RE .3]:  One problem with enabling them with SET MESSAGE is that
they're blown away every time you do a new SET MESSAGE.  Also, they don't
propogate to your subprocesses.
	Also, even though it's pretty fast, it's still extra overhead when
you log in.
		<_Jym_>

Create a shareable message file from your message definitions.
Then, build a pointer file to it which you link
with your executable. The pointer contains the file spec of the 
message file.

	eg
	$ MESSAGE FOO.MSG
	$ MESSAGE/OBJECT=FOOPTR/FILE=SYS$MESSAGE:FOO
	$!
	$ LINK FOO
	$ COPY FOO.EXE SYS$MESSAGE:
	$ LINK YOUR_PROGRAM,FOOPTR
	$!

Now when your image signals errors which are defined in the FOO.MSG file,
everything will work adequately.

That's what we do for BTS.... if you want, I can set you part of our build
file. 

RE: .4

You are correct Stan, I want a real solution to be included in a VMS layered
product, released throught SDC and supported by SWS.  I will try the VMSNOTES
file on VAXWRK.  I went through official channels (i.e. asked my VMS layered
product certification representative) and got a response from Benson Gray
saying, "I don't think you can do that."

RE: .6

Thanks Nigel, I think this might be what we've been looking for.  Let me
try this out and if I can't get it to work I'll MAIL you a request for
an example.

BTW, DECdx is an officially registered VMS facility, our facility number is
158. and our facility prefix is DDX.  But what good is it if we can't get
our messages to come out?  We'll have to rename our product NONAME, and rewrite
all our error messages to be cryptic, a la "NONAME-W-NONAME, message number 
00905800303" and write a new chapter in the doc set translating the numbers back
into text!

Don.

I would recommend a thorough reading of Chapter 11 (The Message Utility)
of the VMS Utilities Reference Manual.  That chapter discusses the
creation of message codes, making them available to an image, etc.,
in great detail.

	-Neil Faiman

.6 is the correct way of doing this.

Layered products should put their message files in SYS$MESSAGE:
as part of their installation procedure.  The file could even be
installed if you felt it would be referenced a lot.
You then link pointers in with your images (not the messages themselves).

Note that this requires running the message compiler twice.
Once to get the symbol values, which you link into your program images.
A second time (with different qualifiers) to get the message text,
which you link together to create your message image.

Again, let me stress that this is fairly standard knowledge, and you
would have gotten a faster response if you had placed your question in
a more appropriate note file.

	But would it have been as much fun?
		<_Jym_>

	Hmmm... where is APRILFOOL.EXE available?

	Didier

     I have a copy of it ..
	

	Royce::dua0:[attwool.public]aprilfool.exe

	Justyn K

Also eayv04::sys$message:aprilfool.exe - some of us have it as standard ! ! !

What is aprilfool.exe?

	Try it and see!  (Famous Last Words)
		<_Jym_>

I tried it on my V4 system and got a DCL error message. Anyone got
a V4 version?


trevor

I installed/replaced it on my system and "no known entry found"
I changed the SYSMSG name to FRED and the APRILFOOL name to SYSMSG --> niet!
I run it --> Image has no transfer address
I tried to edit it --> "<ESC>[7m^Grecord longer than 255characters, truncated"
I prayed it --> no answer

How do you use it???

	Didier_tired

have you ever considered that the installation failure itself is its action?

              have you tried .. $ set message aprilfool 


		????????


	Attwoologic 

SYSMSG is mapped during startup.  A reboot is needed to strobe the new msgs.

PeterM

Not for ones own process.  Set Message changes the messages for a particular
process.

Dave

	Hey!  My VMS V4.0 system doesn't have SYSMSG.TLB on it anymore!
	Where do I get a copy?
#6	<_Jym_>\