From:	SMTP%"nick@nick01.demon.co.uk" 14-JUN-1994 14:05:55.51
To:	EVERHART
CC:	
Subj:	Re: System service to implement "$ SET MESSAGE filespec" ???

X-Newsgroups: comp.os.vms
From: nick@nick01.demon.co.uk (Nick de Smith)
Subject: Re: System service to implement "$ SET MESSAGE filespec" ???
Organization: his office
Reply-To: nick@nick01.demon.co.uk
X-Newsreader: Simple NEWS 2.0 (ka9q DIS 1.24)
Lines: 67
Date: Mon, 13 Jun 1994 13:47:14 +0000
Message-ID: <771515234snz@nick01.demon.co.uk>
Sender: usenet@demon.co.uk
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET

In article <01HDDLFW4UUSQT5RQF@psulias.psu.edu> JLW@psulias.psu.edu writes:

> I have an application which needs to choose, at run time, between three or
> more nonexecutable image message files.  Once the choice is made, the chosen
> message file is to become the process level message file for the duration of
> the application.

 [*snip* - various over-complicated possibilities removed]

First, create each message file with a different facility code. Link all the
message files with your application (the message codes will not clash as each
file has a different facility code).
 
Next establish a handler, using LIB$ESTABLISH, that checks the signal
array for your private facility codes, and depending on which of your several
sets of messages it wishes to display, changes the facility code in the message
to match that of the required set and displays or re-signals the message.
If you are doing this in C you can use $VMS_STATUS_FAC_NO( ul_status ) or:

e.g. (untested C pseudo-code...)

#define K_PRIVATE_FAC_NO      42      // Facility # of base message file
#define K_PRIVATE_FAC_NO_1    43      // Facility # of private file #1
  (... etc. These values could be picked up from each message file as
            external long constants. The message utility creates constants
            of the form xxx$_FACILITY, where "xxx" is the facility name,
            and thus these could be used instead of hard-coded values.
            e.g. external long constant FILE_1$FACILITY;
                 #define K_PRIVATE_FAC_NO_1     FILE_1$FACILITY
                 ...etc.
  )

unsigned long
Handler(
  unsigned long al_signal[]     ,       // Signal array
  unsigned long al_mechanism[]  )       // Mechanism array
{
  unsigned long ul_status = al_signal[ 1 ]; // Get signalled code

  if ( ((ul_status & STS$M_FAC_NO) >> STS$V_FAC_NO) == K_PRIVATE_FAC_NO ) {
        ul_status &= ~STS$M_FAC_NO;     // Clear old facility number
        switch ( ul_required_message_file ) {
        case 1: ul_status |= (K_PRIVATE_FAC_NO_1 << STS$V_FAC_NO);
                break;
        case 2: ul_status |= (K_PRIVATE_FAC_NO_2 << STS$V_FAC_NO);
                break;
        ...etc.
        }
   }
   // display message ul_status (will automatically come from right file).
   // (or set ul_status back into signal array and return SS$_RESIGNAL to
   //  let other code display the, now altered, message).
}

This method is supported, non-cludgy, can be changed at any time, and is
simple to maintain! Note that in production code you should scan the signal
array for all signals, and check/set each in turn...(people often forget that
LIB$SIGNAL can raise several messages). Depending on how you link the sets
of message files to your application, you may have a problem with clashing
message names in the LINKer, each with a different value. You can get round
this by giving each message file a different facility name, and then using
$GETMSG to set the facility name to your preferred text on retrieval.

Hope this helps.

Nick  nick@nick01.demon.co.uk
      European DECUS OpenVMS Chairman