Conference vaxaxp::vmsnotes

201.0. "FIS and installed images" by CSC32::HENNING (A rose with no thorns) Mon Feb 17 1997 09:31

    Have reproduced an image activation behavior that seems a bit odd -- or
    perhaps my understanding of it is wrong.  When a program calls
    LIB$FIND_IMAGE_SYMBOL to map to a shareable image, shouldn't the image
    activator check for a KFE and map to that version, even if a higher
    version of the shareable image file exists?
    
    The attached procedure demonstrates that, if I OPEN/WRITE a new version
    of the shareable image, FIS returns OPENIN/FLK errors -- implying that
    the image activator tried to map to the newly created file instead of
    the installed shareable image:
    
	$ SET DEFAULT SYS$LOGIN
	$ ON ERROR THEN CONTINUE
	$ CREATE SHAREABLE.C
	#include stdio
	
	void func_1( a,b,c )
	int a;
	float b;
	char c;
	{
	        printf("\nNow in func_1 !\n");
	        printf("Values received were: %d - %f - %c \n", a,b,c );
	}
	
	$ CREATE FIND_IMAGE.C
	
	#include stdio
	#include string
	#include descrip
	
	main()
	{
	 static $DESCRIPTOR( file_desc, "SHR" );
	 static $DESCRIPTOR( symbol_desc1, "FUNC_1" );
	
	 static void (*ptr)();          
	 static int stat;               
	 void LIB$STOP();
	 int LIB$FIND_IMAGE_SYMBOL();
	
	 stat = LIB$FIND_IMAGE_SYMBOL( &file_desc, &symbol_desc1, &ptr, 0 );
	 if((stat & 1) != 1) LIB$STOP( stat );
	 ptr( 9999, 10.0005, 'c');
	}
	
	$ CC SHAREABLE
	$ CC FIND_IMAGE
	$ LINK /SHARE SHAREABLE,SYS$INPUT/OPT
	UNIVERSAL=FUNC_1
	$!
	$ LINK FIND_IMAGE
	$!
	$ DEFINE SHR SYS$LOGIN:SHAREABLE.EXE
	$ INSTALL ADD/OPEN/HEADER/SHARE SHR
	$ RUN FIND_IMAGE
	
	Now in func_1 !
	Values received were: 9999 - 10.000500 - c
	$!
	$ OPEN/WRITE NEWFILE SHR
	$ RUN FIND_IMAGE
	%LIB-E-OPENIN, error opening DKA300:[HENNING]SHAREABLE.EXE; as input
	-RMS-E-FLK, file currently locked by another user
	%TRACE-E-TRACEBACK, symbolic stack dump follows
	module name     routine name             line       rel PC    abs PC
	
    	                                                    0000E714  0000E714
	                                                    80C22F5F  80C22F5F
	                                                    0000E36B  0000E36B
	                                                    0000E680  0000E680
	----- above condition handler called with exception 0001828A:
	%RMS-E-FLK, file currently locked by another user
	----- end of exception message
	                                                    0000E5EA  0000E5EA
	FIND_IMAGE      main                      2073      00000039  00000451
	%RMS-E-FLK, file currently locked by another user
	%TRACE-E-TRACEBACK, symbolic stack dump follows
	module name     routine name              line      rel PC    abs PC
	
	                                                    0000E5EA  0000E5EA
	FIND_IMAGE      main                      2073      00000039  00000451
	%RMS-F-FLK, file currently locked by another user
	%TRACE-F-TRACEBACK, symbolic stack dump follows
	module name     routine name              line      rel PC    abs PC
	
	FIND_IMAGE      main                      2074      00000054  0000046C
	$ SHOW DEVICE/FILE
	
	Files accessed on device $1$DKA300: (KRILL) on 17-FEB-1997 08:11:57.02
	
	Process name      PID     File name
	                00000000  [000000]INDEXF.SYS;1
	DECW$SESSION    00000057  [HENNING]DECW$SM.LOG;71
	**EIRS**        00000062  [HENNING.COM]SETHOST.COM;1
	**LST_SCHED**   00000065  [HENNING.COM]SETHOST.COM;1
	HENNING         00000060  [HENNING.MAIL]MAIL.MAI;1
	HENNING         00000060  [HENNING]LWK_PERSONAL.LINKBASE;1
	_FTA11:         00000064  [HENNING]X.COM;3
	                00000000  [HENNING]SHAREABLE.EXE;1
	_FTA11:         00000064  [HENNING]SHAREABLE.EXE;2
	$ CLOSE NEWFILE
	$ INSTALL DELETE SHR
	$ DEASSIGN SHR
    
    Subsequent execution of FIND_IMAGE fail with EOF errors as long as
    SHAREABLE.EXE;2 exists.  Used SET WATCH FILE/CLASS=ALL to verify
    runtime access to SHAREABLE.EXE;2.
    
    
    Thanks for your input on this,
    Mary

  Mary,

    A customer recently pointed out that if you have 2 versions of an image,
  the older of which is INSTALLed and the newer has a different symbol vector,
  then LIB$FIND_IMAGE_SYMBOL will generate "odd" errors. 

    My explanation was that LIB$FIND_IMAGE_SYMBOL has to work in 2 phases,
  the first opens the image file as an ordinary RMS file, presumably to
  examine the symbol table. If necessary the second phase then activates the 
  image.

    Now, since the rules for opening an RMS file and activating images
  are subtly different, in this particular case, the phases end up looking 
  at different files. (phase 1 - latest version, phase 2 KNOWN file).

    If the 2 versions of the image are "isomorphic" (that is, their symbol
  vectors or transfer vectors are identical, but the routines themselves
  may be different), opening 2 files is transparent, and the "normal" image
  activation rules are followed. However, if the files are different,
  just about anything can happen. Your case, the image file being locked,
  is a variation on the theme (and who ever locks an image file??).

    I can't get too excited about this being a "problem", as you have to try
  pretty hard to cook up a pathological case to make anything go wrong. The
  only ways to "fix" the problem would be to teach the "phase 1" lookup use
  image activation rules to find the image to be opened (and note that a
  recent discussion in this conference concluded that it isn't possible to
  determine if an older version of a file is installed), or have
  LIB$FIND_IMAGE_SYMBOL always activate the same image it reads the symbol
  table from. In either case, there is a strong possibility that the wrong
  image will be activated silently. I'd argue that the current behaviour is
  preferable precisely because it generates errors and highlights what is
  almost certainly an error in file names.

    I suppose a 3rd possibility would be to have LIB$FIS do a sanity check
  and generate a specific error for this case (though that may break existing
  programs?).
						John Gillings, Sydney CSC

re .0
    
    John is correct although I would have thought that the standard VMS
    image activation would occur first and the LIB$FIND_IMAGE_SYMBOL read
    of the symbol table would occur second. Either way, the fact that the
    two pieces of software both open the file but use different rules to
    locate the file would explain the behaviour.
    
    Why on earth does the customer open the image in this way? If it hurts,
    don't do it.
    
>    Subsequent execution of FIND_IMAGE fail with EOF errors as long as
>    SHAREABLE.EXE;2 exists.
    
    This is expected behaviour because the OPEN/WRITE has created a new
    empty file (;2). Because the main image is no longer installed, even
    the VMS image activation is just going to the top version which is not
    a valid image.

    Thanks much, guys -- and I apologize for the late comeback!

    One last ? - this does appear to be expected behavior, based on review
    of both your comments and the LIBFNDIMG source.  Am I correct in
    assuming this?  I ask this because the customer would like this SPR'd,
    but I believe it more appropriate to forward customer's request as a
    "suggested enhancement".
    
    Thanks for your comment!

I would IPMT it, if nothing else but to get some more documenation
on the effects of new logicals.

The code appears to be 'fixable' by using the KF's DEV/FID values and
not depending on the actual filename to open the file.