Conference vaxaxp::vmsnotes

re .0
    
>    He now notices that the messages being output by the subprocess are not
>    being translated; he gets TPSORT-I-NOMSG. The facility and severity
>    come out properly but not the ident.
    
    I assume that the text doesn't come out correctly either.
    
    I assume that TPSORT is actually a user defined facility and that he is
    correctly using a user defined facility number.
    
    Try outputting a message at image startup i.e. before much has been
    done within the image.
    
    How are the messages being made available to the image?
    
    Process wide message file? Try it.
    Message file linked in? Try it.
    Indirect message file pointer?
    
    If a message file (.EXE) is created, is it a shareable image or not?
    
    Does a standalone test program used with the message file work
    correctly?

    Straws: PROCSECTCNT, PGQLUOTA?
    
>    	We checked and compared CHANNELCNT, CTLPAGES, PIOPAGES, bytlm,
>    fillm, the PQL parameters
    
    PQL parameters may not be relevant. Also check SYSUAF fields.

   What was the previous version of OpenVMS?  Are the images and tools
   (re)built locally, or have they been ported in and were originally
   built on some other OpenVMS VAX version?

   Message files aren't hauled around via SPAWN commands, one must SET
   MESSAGE the file in the process context, or one LINKs the image(s)
   against the message file `stub' object (an object containing little
   more than a pointer to the message image file that contains the actual
   message text), or one LINKs the messages directly into the image(s).

   How is the application locating the messages?  (It would appear that
   the message file is not LINKed into the image...)

   I had some `fun' with installed images and silent failures around image
   activations -- ended up having to install the message file, due to a
   silent `error' deep down in the image activator.  Are the image(s)
   involved INSTALLed?

   Also look at "SET WATCH/CLASS=ALL FILE", and "SET WATCH/CLASS=NONE FILE",
   to control the display of XQP activity -- FILE is a literal keyword, and
   not a filename. 

I've seen this happen with an application running under ACMS, and some
logical name definitions (i thought things like lnm$file_dev) were done in lower 
case (i can't remember the exact details). Making them all upper case solved it.

Jur.

    
    
    	Re: .1 - .3
    
    	Thanks for the input and ideas, I'll address each one with the
    customer. As a quick response, there was no ghange in VMS version, no
    change in the application, no change in how the application is started
    on the VLC vs. the model 96.
    
    	The apparent only difference is the change in system model numbers
    and that the 96 has a different system disk.
    
    	Thanks,
    
    	Dave

   
:    	The apparent only difference is the change in system model numbers
:    and that the 96 has a different system disk.

   And it's likely this -- this is probably something site-local or some
   such procedure or logical or tool or startup that was not propogated
   over to the new system or was not executed in the context of the new
   system -- that is the likely cause.  OpenVMS is heavily dependent on
   message files -- any serious errors would likely have shown by now...

>    
>   I assume that the text doesn't come out correctly either.
>
	That is correct, just returns NOMSG followed by the message number
    
>   I assume that TPSORT is actually a user defined facility and that he is
>   correctly using a user defined facility number.
>
	Exact same code as is operating sucessfully on the VLC. Initally the
	parent processes of the application were getting NOMSG; recompiling 
	fixed it but we still have the failure in the sub process.
    
>   Try outputting a message at image startup i.e. before much has been
>   done within the image.

	The first message is output very early in the image.

>    
>   How are the messages being made available to the image?

	Customer is unclear on this. He doesn't understand the differences
	between set message and linking with the message file. It looks like
	the message file is linked and set.

>    
>   Process wide message file? Try it.

	What is this?

>   Message file linked in? Try it.

	It is

>   Indirect message file pointer?
>    
	INCLUDE's external message file. An include file is created from the 
	message file and linked with the image.

>   If a message file (.EXE) is created, is it a shareable image or not?
>    
	Shareable image

>   Does a standalone test program used with the message file work
>   correctly?

	Every other process and image in the application work fine EXCEPT this
	subprocess ONLY on the model 96.
>
>   Straws: PROCSECTCNT, PGQLUOTA?

	PROCSECTCNT - VLC = 40
	PROCSECTCNT - 96  = 40

	SYSUAF.DAT copied over from the VLC to the '96. Problem remains

>    
>   PQL parameters may not be relevant. Also check SYSUAF fields.
>
	SYSUAF.DAT copied over from the VLC to the '96. Problem remains
>
>   What was the previous version of OpenVMS?  Are the images and tools
>   (re)built locally, or have they been ported in and were originally
>   built on some other OpenVMS VAX version?

	Application has been around a long time and was totally recompiled on
	the VLC and the model 96. No problems on the VLC.

>
>   Message files aren't hauled around via SPAWN commands, one must SET
>   MESSAGE the file in the process context, or one LINKs the image(s)
>   against the message file `stub' object (an object containing little
>   more than a pointer to the message image file that contains the actual
>   message text), or one LINKs the messages directly into the image(s).
>
	Image has been linked with an EXTERNAL include file which was created 
	from the .MSG file which is the same source for the non-executible 
	shareable image. A set message is also being performed.

>   How is the application locating the messages?  (It would appear that
>   the message file is not LINKed into the image...)

	FORTRAN delares the message names as externals following the example 
	in the documentation. Like the customer says, this works fine on the
	VLC. Login command procedure does SET MESSAGE too.

>
>   I had some `fun' with installed images and silent failures around image
>   activations -- ended up having to install the message file, due to a
>   silent `error' deep down in the image activator.  Are the image(s)
>   involved INSTALLed?

	Message executible is not installed, neither is the application. We
	installed the message executible yesterday with no effect.
>
>   Also look at "SET WATCH/CLASS=ALL FILE", and "SET WATCH/CLASS=NONE FILE",
>   to control the display of XQP activity -- FILE is a literal keyword, and
>   not a filename. 
>

	Subprocess runs and image and does not map DCL.

>   I've seen this happen with an application running under ACMS, and some
>   logical name definitions (i thought things like lnm$file_dev) were done 
>   in lower case (i can't remember the exact details). Making them all upper 
>   case solved it.
>
	No lower case except some DECW logicals. Same on the system that does
	not have the problem.



	And then I started theorizing with the customer, as a result of a 
discussion yesterday with Steve Dannen in our group, that possibly we have
a race condition due to the increased speed of the model '96. The image that 
the subprocess runs outputs messages immediatly apon activation and perhaps
at that time, the image activator has not completed its work with the various
shareable images.

	Sure enough, we put a 5 second LIB$WAIT at the beginning of the 
image source and then the messages were properly interpreted. This can only
mean that the MAIN starts to execute before the shareable images are ready to 
go.

	The customer will establish where the go/nogo timing threshhold lies 
and get back with me. I'll let you know.


	Dave

    
    	The customer in his timing trials found that he could go all the
    way down to a 0 LIB$WAIT. Then he found that he could remove it and the
    application would have its messages translated OK. Then he found that
    he had been recompiling the wrong source and what originally fixed the
    problem was not the 5 second LIB$WAIT but using the proper source.
    
    	Oh well...

re .6
    
    Notwithstanding the fact that the problem is fixed and that it was
    pilot error...
    
>>   How are the messages being made available to the image?

>	Customer is unclear on this. He doesn't understand the differences
>	between set message and linking with the message file.
    
    The customer probably should understand so here's a few comments.
    
    In order to use user defined messages you need to do two things.
    
    1. Make the message symbolic name to message number mapping available to
       the programming language that you are using and if this involves
       external references, make the definitions available to the linker.
    
    2. Make the message text available at run-time.
    
    You can achieve step 1 using external references and the object file
    from the message compiler to resolve them or you can go via SDL (probably
    undocumented) to make an include file of compile time definitions. [Of
    course step 1 is technically optional but it would be very poor practice
    to hard-code message numbers.]

    There are four ways of meeting the needs in step 2.
    
    2A. link message file into application executable
    
    To do this you create a message object file by compiling your message
    source and you link that in to your application executable.
    
    Advantage: More robust in the face of quota depletions. Less files to
    		ship around.
    Disadvantage: More difficult to internationalize.
    
    2B. link message file as shareable image to application executable
    
    To do this you create a message object file by compiling your message
    source and you link the resulting object file to create a shareable
    image that is the message file and then you provide that shareable image
    as an input to the link operation for the application executable
    
    2C. link message file pointer into application executable
    
    Create message shareable image as in 2B *but* then use MESS/FILE to
    create a message object file that is a pointer to the message shareable
    image and then link this object file into your application executable.
    
    2D. process wide message file
    
    Create message shareable image as in 2B and then use $ SET MESS on the
    file to make it the process message file.
    
    Disadvantage: Must be explicitly set prior to using application.
    
    P.S. Any explanation concerning asynchronous image activation and the
    shareable image not being "ready" is completely bogus.