Conference turris::decc

:Since then, users are unable to run certain images.  These images fail
:because vaxc2decc is not installed, and they get an error telling them
:that the image must be installed.

   These `certain' images are likely themselves installed, likely
   with either /PRIVILEGE or /PROTECT.  (This places a `cascading'
   requirement on component images -- it's not just this image,
   it's any shareable the image is linked against...)

:Crt$startup.com did install this image, but it is not in vmsimages.dat
:in v6.2.  I suspect that it was simply overlooked, and that so few
:customers actually use it that we rarely see problems because of it.
:Is this correct, or is there something else going on?

   Looks reasonable.  I'd migrate directly to `native' DEC C code
   when possible, obviously...

For now, I have told the customer to manually installed the image
with /open/share/header, and that I would check with engineering
to see if there is something else that should be done.

:Is this simply an oversight, or am I missing something more important?
:If an oversight, would you consider this a problem report and address this
:in a future version of OpenVMS (if not already addressed).

   This is something that should be reported against OpenVMS VAX, as
   the change would be made there...  (Since most stuff works fine by
   default, and there have apparently been few reports of this, and
   since this is easy to fix, I'd consider leaving the image uninstalled,
   and document how the system manager can install it.  Only if there
   were a number of reports would I install it.)

crt$startup.com did install vaxc2decc.exe.  It is my understanding
that if autogen had been run at some time after crt$startup.com had
been invoked then the images would have been preserved in
sys$manager:vmsimages.dat after the upgrade.

I believe that after manually installing vaxc2decc.exe if the customer
runs autogen through the genparams phase a new vmsimages.dat will be
generated and vaxc2decc.exe will be preserved after future upgrades.

I also think that vaxcg2decc.exe is in the same boat as vaxc2decc.exe.

I have posted this note in the crtl_internal notes conference as note
1666.  I think that a long term solution might be for
vms$images_master.dat to be updated to include vaxc2decc.exe and
vaxcg2decc.exe in the future i.e. in the OpenVMS VAX V7.2 timeframe.
I'll need to look into this solution further though to be sure it is
correct.
    

   AUTOGEN doesn't load an images into the VMSIMAGES.DAT file unless it's
   been coded to do so -- otherwise, that file would contain zillions of
   combinations of customer-installed images in short order...  By default,
   AUTOGEN loads the contents of SYS$MANAGER:VMS$IMAGES_MASTER.DAT (and
   maybe a few other files, depending on the system) into VMSIMAGES.DAT.

Command file
============
$ set noon
$!
$ crea sub.c
#include <stdio.h>
void a() { puts("hello, world"); }
$!
$ crea mai.c
void a(void);
main() { a(); }
$!
$ cc/vaxc mai.c, shr.c
$!
$ define/NoLog shr sys$disk:[]shr.exe
$ define/NoLog vaxc2decc sys$share:vaxc2decc.exe
$!
$ lin/notrace/share=shr.exe sys$input:/opt
shr.obj
universal=a
vaxc2decc/share
$ lin mai, sys$input:/opt
shr/share
$!
$ if f$file("shr", "known")
$ then
$	install replace shr /share /open /header /protec
$ else
$	install add     shr /share /open /header /protec
$ endif
$!
$ if f$file("vaxc2decc", "known")
$ then
$	install replace vaxc2decc /share /open /header
$ else
$	install add     vaxc2decc /share /open /header
$ endif
$!
$ run mai
$ install remove vaxc2decc
$ run mai
$ install replace shr /share /open /header /priv
$ run mai
$ install add vaxc2decc
$ run mai
$ install remove vaxc2decc
$ install remove shr

Result
======
$ set noon
$!
$ crea sub.c
#include <stdio.h>
void a() { puts("hello, world"); }
$!
$ crea mai.c
void a(void);
main() { a(); }
$!
$ cc/vaxc mai.c, shr.c
$!
$ define/NoLog shr sys$disk:[]shr.exe
$ define/NoLog vaxc2decc sys$share:vaxc2decc.exe
$!
$ lin/notrace/share=shr.exe sys$input:/opt
shr.obj
universal=a
vaxc2decc/share
$ lin mai, sys$input:/opt
shr/share
$!
$ if f$file("shr", "known")
$ else
$	install add     shr /share /open /header /protec
$ endif
$!
$ if f$file("vaxc2decc", "known")
$ else
$	install add     vaxc2decc /share /open /header
$ endif
$!
$ run mai
hello, world
$ install remove vaxc2decc
$ run mai
%DCL-W-ACTIMAGE, error activating image SHR
-CLI-E-IMGNAME, image file DISK:[DIRECTORY]SHR.EXE
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image
$ install replace shr /share /open /header /priv
$ run mai
%DCL-W-ACTIMAGE, error activating image SHR
-CLI-E-IMGNAME, image file DISK:[DIRECTORY]SHR.EXE
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image
$ install add vaxc2decc
$ run mai
hello, world
$ install remove vaxc2decc
$ install remove shr

>>   AUTOGEN doesn't load an images into the VMSIMAGES.DAT file unless it's
>>   been coded to do so -- otherwise, that file would contain zillions of

My mistake on that.  I was trying to find the correct references having to do 
with vmsimages.dat in the doc set and found only a few, which lead to a 
little confusion.

I thought that there was some way to get autogen to say "save these as known
installed files" - but that didn't really make a lot of sense since I've seen
so many product startup procedure re-install things.

Brian

Thanks for all of the replies.  I'll let my customer know that engineering
is looking into this, and will take appropriate actions, whatever that is.
In the meantime, I will advise him to manually install this image.

Thanks,

Jerry

>>is looking into this, and will take appropriate actions, whatever that is.

It will most likly be to get the "vaxc2" images in the vms$images_master.dat
file in a future release of OpenVMS.

bjm

:                          -< currently planed action >-

   I've always wanted to use a hammer on AUTOGEN, myself... :-)