Conference vaxaxp::vmsnotes

This, this was known and discussed before. Appending a version number to a file 
means 'inhibit known file lookup'. And that's what you see.

Jur.

    If it ain't documented as such it's a bug. QAR it.
    
    /a
    
    PS Install does the same thing wrt version nums.

:    If it ain't documented as such it's a bug. QAR it.

   The `specification of a version number on an image to bypass known
   file lookups' behaviour is documented.

    The 7.1 online help is excerpted below. It does not specify that the
    use of a version number invalidates the answer.
    
    It is therefore, IMHO, QAR opinion. 
    
    
    And by the way, why do all the lexicals use "item" in the example and
    then have "Argument" as the subtitle?
    
    /a
    
$ HELP LEX F$FILE A
Lexicals

  F$FILE_ATTRIBUTES

    Arguments

       

      filespec

         Specifies the name of the file about which you are requesting
         information. You must specify the file name as a character string
         expression.

         You can specify only one file name. Wildcard characters are not
         allowed.
       

      item

         Indicates which attribute of the file is to be returned. The
         item argument must be specified as a character string expression,
         and can be any one of the OpenVMS RMS field names listed in the
         following table.

                     Return
         Item        Type      Information Returned


         KNOWN       String    Known file; returns TRUE or FALSE to
                               indicate whether file is installed with
                               the Install utility (INSTALL). However,
                               returns NOSUCHFILE if a file does not exist
                               (for example, the file has been installed
                               but subsequently deleted).

>    The 7.1 online help is excerpted below. It does not specify that the
>    use of a version number invalidates the answer.

	It also does not document how to create or use a file
	specification either.  There are certain concepts that
	we are assuming people know.  If one is playing around
	with the known file list, we assume that they know how
	that list is being used.
>    
>    And by the way, why do all the lexicals use "item" in the example and
>    then have "Argument" as the subtitle?
>    
	"item" is one of the "arguments"

    re .*
    
    This is a KNOWN problem.
    
    It isn't going to be "fixed".
    
    The underlying behaviour is documented.
    From the V7.1 doco (web version)...
    
"
RUN (Image)
    
           Executes an image within the context of your process. You can
    abbreviate the RUN command to a single letter, R. 
    
    If you specify an image name in the command line with an explicit version
    number (or a semicolon), the image runs with current process privileges. If
    you do not specify an explicit version number (or semicolon), the image runs
    with any privileges with which it was installed. If you have DECnet software
    installed and want to execute an image over the network, you must have read
    (R) access to the file. 
"
    The important paragraph is first up and in bold. One couldn't ask for more
    in this place in the doco.
    
    That said, I think a reasonable case could be made for mentioning it under
    F$FILE for item "KNOWN" since this behaviour has always been confusing.
    So, Andy, are you going to enter that QAR?

It would definitely be a good idea to include this info with the
item code description - but remember that a second period in a name is
syntactically identical to a trailing semicolon.

>
>    This is a KNOWN problem.
>    
>    It isn't going to be "fixed".
>

Problem?  You are kidding, of course.

The version number escape is a useful tool to bypass known file lookups.
When developing, debugging, maintaining multiple versions of an image
or similar tasks it is very handy.  It's not a "feature" in the sardonic
use of the word, it is part of the O/S design.

It is entirely analogous to the escape that prefixing an underscore
to a username when sending mail means "do not honor any mail forwarding
defined, deliver on the specified node".

More doc

 Guide to OpenVMS File Activations

  5.2.1  Image Activation Using Logical Names

  When an OpenVMS system activates an image, it uses RMS
  to open the image file. If the program specifies the image
  file with a logical name, RMS uses the equivalence name to
  look up the image in the known file list, unless the file spec-
  ification includes a version number delimiter (a semicolon [;]
  or a period [.]). Known files are files that are installed using
  the Install utility, and the known file list provides a listing of
  these files by name and by number.

 

    Sigh. 99% of all users NEVER GET TO SEE the docco beyond online help.
    If you don't believe me, then just ask the writers.
    
    Online help should be accurate and complete. In this case it ain't and
    the incompete nature of the help can lead to misunderstandings. What's
    the problem with having *one extra line*? If it saves 1 call to the CSC
    then it has paid for itself.
    
    As to a QAR, maybe I'll have the time. I leave in one week.

Re .1 to .7

Wow! I never thought I'd spark such a flurry of responses! Thanks to everybody
for all the info.

My last question still stands, though, albeit modified by recent information -
is it possible to check what version of an image is installed?

Thanks and regards,

Simon.

    $INSTALL LIST shows the version.

Let's take this a step further. I'll let the customer explain...

> This clearly explains the behaviour of the DCL lexical f$file.
> It doesn't explain why "$ install replace image" has no visible effect.
>
> Eg. 
> $ ins lis sys$share:qkdriver_ft_jobcard
>
> DISK$CLUSTER:<CLUSTER.SYSLIB>.EXE
>   QKDRIVER_FT_JOBCARD;1
>
> $ dir sys$share:qkdriver_ft_jobcard
>
> Directory CLU_COMMON:[SYSLIB]
>
> QKDRIVER_FT_JOBCARD.EXE;3               QKDRIVER_FT_JOBCARD.EXE;2
> QKDRIVER_FT_JOBCARD.EXE;1               
>
> Total of 3 files.
>
> $ ins rep sys$share:qkdriver_ft_jobcard
> $ ins lis sys$share:qkdriver_ft_jobcard
>
> DISK$CLUSTER:<CLUSTER.SYSLIB>.EXE
>    QKDRIVER_FT_JOBCARD;1
>                    
> I find that the installed version is still ;1. The replace has had no visible
> effect, and my command proceedure can't tell whether it has been done or not.
> It works OK with the qualifiers /open/head/share, but not without.
> 
> My query then is two-part:
>
> 1) Does install replace work without qualifiers, or has it failed as install
> list would suggest.
>
> 2) If it does work, how can I tell whether it's been done ?

Thanks,

Simon.

   This looks like it might be a (minor) bug.  Please QAR or IPMT this
   (with a low priority, as the customer has a good workaround), and
   please mention the OpenVMS version and platform.  (I'll assume you 
   have checked the privileges and the error message settings, to make
   sure that the INSTALL command isn't silently failing.)

re .7
    
>Problem?  You are kidding, of course.
    
    Nope

>The version number escape is a useful tool to bypass known file lookups.
    
    Being able to bypass known file lookups is useful. However it seems that
    for every user who knows about this feature and uses it to his
    advantage (such as you and me) there is a user who doesn't know about
    this feature and gets caught out with results that defy rational
    explanation.

    re .11
    
    If adding bogus qualifiers to the INSTALL command is undesirable,
    another (untested) workaround may be to INSTALL DELETE followed by
    INSTALL CREATE.
    
    I don't think there is any supported means of finding out what version
    is INSTALLed.       

    I'm not convinced that this is a bug, I'd need to see a SHOW LOG/FULL
    of all his related logical names, I suspect there is one in the line
    which is no 'trusted' (i.e. executive-mode).
    
    From his output, I'm gathering that he is playing games with rooted
    logicals, he is using SYS$SHARE, but the install list doesn't produce
    the standard VMS$COMMON.SYSLIB path.
    
    /cmos

re .15

I've just reproduced the problem here on a DEC 3000 Model 500 running OpenVMS
V6.2.

$ d aaaaaa

Directory SYS$SYSDEVICE:[SYS0.SYSCOMMON.SYSLIB]

AAAAAA.EXE;1              39/39       21-FEB-1997 12:45:52.03  (RWED,RWED,RE,RE)

Total of 1 file, 39/39 blocks.
$ install list sys$share:aaaaaa
%INSTALL-W-FAIL, failed to LIST entry for DISK$ALPHA062:<SYS0.SYSCOMMON.SYSLIB>A
AAAAA.EXE
-INSTALL-E-NOKFEFND, Known File Entry not found
$ install add sys$share:aaaaaa/log

DISK$ALPHA062:<SYS0.SYSCOMMON.SYSLIB>.EXE
   AAAAAA;1
        Entry access count         = 0


$ copy aaaaaa.exe .exe;2
%COPY-S-COPIED, SYS$SYSDEVICE:[SYS0.SYSCOMMON.SYSLIB]AAAAAA.EXE;1 copied to SYS$
SYSDEVICE:[SYS0.SYSCOMMON.SYSLIB]AAAAAA.EXE;2 (39 blocks)
$ d aaaaaa

Directory SYS$SYSDEVICE:[SYS0.SYSCOMMON.SYSLIB]

AAAAAA.EXE;2              39/39       21-FEB-1997 12:51:45.67  (RWED,RWED,RE,RE)
AAAAAA.EXE;1              39/39       21-FEB-1997 12:45:52.03  (RWED,RWED,RE,RE)

Total of 2 files, 78/78 blocks.
$ install replace sys$share:aaaaaa/log   <-------- This doesn't do anything !!!
$ install list sys$share:aaaaaa

DISK$ALPHA062:<SYS0.SYSCOMMON.SYSLIB>.EXE
   AAAAAA;1
$ sh log sys$share/full
   "SYS$SHARE" [exec] = "SYS$SYSROOT:[SYSLIB]" (LNM$SYSTEM_TABLE)
$ sh log sys$sysroot/full
   "SYS$SYSROOT" [exec] = "$1$DKA300:[SYS0.]" [concealed,terminal] (LNM$SYSTEM_T
ABLE)
        = "SYS$COMMON:"
1  "SYS$COMMON" [exec] = "$1$DKA300:[SYS0.SYSCOMMON.]" [concealed,terminal] (LNM
$SYSTEM_TABLE)
$


So, is this a bug or isn't it ?

Many thanks and regards,

Simon.

    you are still hiding somethingfrom us. Show us the following:
    
    $ SHOW LOG/FULL AAAAAA
    
    either make sure that there is no logical AAAAAA defined, or if it
    is it probably should be /EXEC, and things should work; or specify
    the extension .EXE on your command
    
    $ install replace sys$share:aaaaaa.exe /log
                                      ^^^^
    
    without the extension specified and un untrusted logical AAAAAA I
    believe you might see the bahviour you're observing.
    
    /cmos

I've done some more testing and come to realise that INSTALL REPLACE is not
translating all the logical names in the search list, or something along those
lines. The following example shows that an INSTALL REPLACE with both images in
SYS$COMMON:[SYSLIB] fails to find the image with a higher version. The second
INSTALL REPLACE with a higher version of the image contained in
SYS$SYSROOT:[SYSLIB] works as expected. It looks more and more like a bug to me!

$ set def sys$share
$ sh def
  SYS$SYSROOT:[SYSLIB]
  =   SYS$SYSROOT:[SYSLIB]
  =   SYS$COMMON:[SYSLIB]
$ sh log aaaaaa/full
%SHOW-S-NOTRAN, no translation for logical name AAAAAA
$ dir aaaaaa

Directory SYS$COMMON:[SYSLIB]

AAAAAA.EXE;1

Total of 1 file.
$ instal add sys$share:aaaaaa/log

DISK$ALPHA062:<SYS0.SYSCOMMON.SYSLIB>.EXE
   AAAAAA;1
        Entry access count         = 0


$ copy aaaaaa.exe sys$common:[syslib]*.exe;2
$ dir aaaaaa

Directory SYS$COMMON:[SYSLIB]

AAAAAA.EXE;2        AAAAAA.EXE;1

Total of 2 files.
$ install replace sys$share:aaaaaa/log
$ rename AAAAAA.EXE;2 sys$sysroot:[syslib]*.exe;2
$ dir aaaaaa

Directory SYS$SYSROOT:[SYSLIB]

AAAAAA.EXE;2

Total of 1 file.

Directory SYS$COMMON:[SYSLIB]

AAAAAA.EXE;1

Total of 1 file.

Grand total of 2 directories, 2 files.
$ install replace sys$share:aaaaaa/log

DISK$ALPHA062:<SYS0.SYSLIB>.EXE
   AAAAAA;2
        Entry access count         = 0


It makes no difference if I specify the ".EXE" bit. By the way, I'm not hiding
anything ;^)

Thanks and regards,

Simon.

    re .18
    
>    It looks more and more like a bug to me!
    
    .12 said that over 2 weeks ago and asked that you report it formally.
    
>The second INSTALL REPLACE with a higher version of the image contained in
>SYS$SYSROOT:[SYSLIB] works as expected.
    
    Expected.
    
    INSTALL is arcane and this is a feature of its implementation.

>>    It looks more and more like a bug to me!
>    
>    .12 said that over 2 weeks ago and asked that you report it formally.

Oops. Sorry! Must've missed that one in the excitement!!!

I'll see if the customer wants to pursue this through IPMT.

Thanks to everyone for discussing this with me so far.

Simon.

May I beg your indulgencej for a further question or two ? I passed everything
on to the customer but he came back with the following -

>It's still not clear to me whether it's really accessing the old version, or
>just listing the old version. Obviously if it's just list that gives
>wrong information it's less serious than applications running the wrong version
>of software.

>What about images installed with qualifiers, where the version number doesn't
>get reported at all ? Are they correct or not ? If not, I need to apply my
>workaround to them too.

Many thanks for your continued help!

Simon.

It makes no difference whether qualifiers are used or not as to INSTALL's
behavior. 

				Steve

re .21
    
>It's still not clear to me whether it's really accessing the old version, or
>just listing the old version. Obviously if it's just list that gives
>wrong information it's less serious than applications running the wrong version
>of software.

    It is my belief that the image activator will always activate the
    listed version regardless of whether it is the highest version, provided
    that the user does not specify the version. [On the other hand if the user
    specifies the version or even just the punctuation for it then the image
    activator will activate the specified version, highest if just
    punctuation specified, and any INSTALL will be ignored.]
    
    Hence in the customer's viewpoint the more serious situation arises
    viz. ;1 is INSTALLed, INSTALL REPLACE is done for ;2 but ;1 remains
    INSTALLed and ;1 is the one that will get activated.
    
    Bottom line is that there is almost certainly a bug here. The customer
    needs to report it and then VMS Engineering will surely fix it and the
    customer won't have to use messy workarounds.
    
>What about images installed with qualifiers, where the version number doesn't
>get reported at all ? Are they correct or not ? If not, I need to apply my
>workaround to them too.

    I have not seen that whether the version number is reported depends on
    whether the INSTALL was done with qualifiers and my Alpha VMS V6.2
    system does not exhibit this behaviour. Can the customer supply a log
    file that illustrates this?
    

re .23

I've passed on your comments to the customer and have again asked him if he
wants to escalate the problem to engineering. He hasn't yet given me a straight
"yes" or "no" answer !

Thanks and regards,

Simon.