Shareable image has a different time stamp.

[da1nonly1]

What can be the impact of a shareable image EXE file copied to a different disk and then copied back again to the original disk, we will have of course a different, although identical, exe file here. The time stamp is different. Do I need now to link again the whole image to which this shareable was linked? Let’s assume here that this shareable was either INSTALLed with the INSTALL utility or not INSTALLed.

Thanks, Yaron.

[Hein van den Heuvel · Accepted solution]

NO. Shareable image activation and verification does NOT rely on any date or time stamp. Not even the link date.
It strictly and only depend on image Major and Minor IDs as provided to the linker through the GSMATCH option in the /OPT file while linking the shareable.
RTFM:

http://h71000.www7.hp.com/doc/73final/4548/4548pro_015.html#opt_gsmatch_sec

You may also want to read:

http://h71000.www7.hp.com/doc/73final/4548/4548pro_008.html#share_ch


Now, what problem are you really trying to solve? There was an earlier question on Image Dates. Now this. Sounds to me like you have an underlying problem for which the details are still slightly obscure (but we could guess). Why not tell us about the real problem?
What action taken, What fails, which (exact!) error messages.

OpenVMS versions MIGHT be interesting.


Free advice: Slowly read and disgest ANAL/IMAGE/INT output for shareable and main images involved.

hth,
Hein.

[Hein van den Heuvel]

Ah, since you mention installed vs non-installed...


Check your logical names for the (shareable) images in question.
You can avoid using an installed image by using a logical name with an explicit version number in the target (;0 will do)

fwiw,
Hein

[John Gillings]

Yaron,

>file copied to a different disk and then
>copied back again to the original disk, we
>will have of course a different, although
>identical, exe file here. The time stamp
>is different

As Hein said, image activation has nothing to do with any date stamps on the image file. Just the GSMATCH and Symbol vector size (which definitely should NOT be changed by copying the file).

Just a point on the effect of COPY on creation and revision dates... COPY considers the output file to be "new" if you specify any part of the output file NAME, TYPE or VERSION (but not device or directory). In that case it will set the creation and revision dates to the current date and time. So, if you copy it like this:

$ COPY MYFILE.DAT NEWDISK:[NEWDIR]

the output file will be identical in all respects (including timestamps). However, if you do it like this:

$ COPY MYFILE.DAT NEWDISK:[NEWDIR]MYFILE.DAT

the contents and names will be the same, but the dates will have been updated.

Knowing this behaviour may help you copy your files around without changing dates unnecessarily (assuming that might help with whatever problem you're experiencing).

See DCL dictionary for further explanation

[Robert Gezelter]

da1nonly,

The default for the Major/Minor IDs is based on the system timestamp when the image is linked. This is eaily overriden using the GSMATCH linker option (see Section 4 of the OpenVMS Linker Manual, available from the OpenVMS WWW site at http://www.hp.com/go/openvms ).

At the 2000Compaq Enterprise Technology Symposium, I presented "OpenVMS Shareable Libraries: An Implementor's Guide". The presentation can be found at http://www.rlgsc.com/cets/2000/460.html

- Bob Gezelter, http://www.rlgsc.com

[da1nonly1]

Hi,

Thank you all for the replies. I will give some more details. I have a directory (VAX) full of executables on a disk of which the capacity becomes smaller and smaller. The thing is that many of these exes have two versions(;) , new and older which is very stupid, messy, prone to confusions and waste of space (I did not do it). I moved one of these older version exes to a different directory (copy and delete the original), the newest version remained, I didnâ t touch it. Now I donâ t even know if the file I moved was a shareable image or not, but if not, then there is no problem at all, the app will always RUN the new version. But what if this file was a shareable image that was linked with object files to form another RUNable exe (or referenced in a library of shareables)? Then it can be a problem because I donâ t really have the objects to link again. What I still have is 1) this file copied. 2) a newer version in the same location that was always there.
I understand from the previous answers that I can copy back the file to original location. I prefer not to do it because maybe I donâ t need it at all and if I do it he will be older version (remember the newer version that is always there) with a time stamp newer than the newer version, which can cause confusion.

Now I have these questions:
1. How can I know if the file I moved was a shareable image or not?
2. In case it was a shareable image, will the image to which it was linked now take the newer version that always existed in this directory?


Thanks for the answers, Yaron.

[John Gillings]

Yaron,

Use ANALYZE/IMAGE to determine image type. Here's an example of an executable image:

$ analyze/image/interactive sys$system:directory
This is an OpenVMS Alpha image file

IMAGE HEADER

Fixed Header Information

image format major id: 3, minor id: 0
header block count: 2
image type: executable (EIHD$K_EXE)
...

and shareable image:

$ ANALYZE/IMAGE/INTERACTIVE SYS$SHARE:LIBRTL
This is an OpenVMS Alpha image file

IMAGE HEADER

Fixed Header Information

image format major id: 3, minor id: 0
header block count: 2
image type: shareable (EIHD$K_LIM)
global section major id: %X'01', minor id: %X'000001'
match control: ISD$K_MATLEQ
...

For your images in question, look at the image identification information:

Image Identification Information

image name: "LIBRTL"
image file identification: "X01-001"
image file build identification: "XAG8-0060111002"
link date/time: 20-AUG-2004 17:00:49.35
linker identification: "A11-50"

This should help you identify which is the latest version of the image.

Don't worry too much about shareable image compatibility. If an image activates successfuly then it's compatible with its referenced shareable images (that's assuming the programmer hasn't tried fairly hard to break compatibility! ;-)

Look in the freeware for a command procedure called "IMAGETREE.COM" - it will display the image dependency tree for an input image. Examine the procedure code to see where the matching information comes from in the ANALYZE/IMAGE output.

[da1nonly1]

Thanks for the reply.
Is there any risk in using the ANALYZE/IMAGE command?

[Volker Halle]

Yaron,

there is no risk assocaited with running ANALYZE/IMAGE.

Volker.