This is a discussion on DEBUG-I-DSFMISMATCH on librtl - VMS ; OpenVMS 8.3 with SYS-V0200 on rx3600 When we try to debug a particular program written in C, we get a series of errors beginning with DEBUG-I-DSFMISMATCH for LIBRTL.DSF / LIBRTL.EXE. The relevant directory entrys are: GREGG> dir librtl.*/date Directory SYS$COMMON:[SYSLIB] ...
OpenVMS 8.3 with SYS-V0200 on rx3600
When we try to debug a particular program written in C, we get a
series of errors beginning with
DEBUG-I-DSFMISMATCH for LIBRTL.DSF / LIBRTL.EXE. The relevant
directory entrys are:
GREGG> dir librtl.*/date
Directory SYS$COMMON:[SYSLIB]
LIBRTL.AIIF;1 30-JUN-2006 13:06:53.87
LIBRTL.DSF;1 29-JUN-2006 23:17:38.03
LIBRTL.EXE;1 20-DEC-2006 15:06:27.10
LIBRTL.STB;1 20-DEC-2006 15:06:27.31
Total of 4 files.
Any idea how we got here? How do I get matching dsf and exe files for
librtl?
Thanks for the help,
Don
Don,
your LIBRTL.EXE and .STB (dated 20-DEC-2006) are from VMS83I_SYS-
V0200, but HP failed to deliver an updated/matching LIBRTL.DSF file
with that ECO kit.
You may ignore this DEBUG-I-DSFMISMATCH unless you want to debug code
inside LIBRTL.
Volker.
Volker Halle wrote:
> your LIBRTL.EXE and .STB (dated 20-DEC-2006) are from VMS83I_SYS-
> V0200, but HP failed to deliver an updated/matching LIBRTL.DSF file
> with that ECO kit.
Correct. I've contacted the responsible party for building the ECO kits
so that the LIBRTL.DSF file will be included whenever LIBRTL.EXE changes.
> You may ignore this DEBUG-I-DSFMISMATCH unless you want to debug code
> inside LIBRTL.
Correct. If you want to make the DSFMISMATCH message go away, you can:
a) Rename SYS$SHARE:LIBRTL.DSF to get it out of the way. E.g., call it
LIBRTL.DSF_V83
b) Contact HP customer support and request the LIBRTL.DSF file that
should have been shipped (the one that was built on 20-Dec-2006).
-Jeff
-OpenVMS DEBUG and Kernel Tools
