| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 969.1 | | TALLIS::NELSON | It's not the years it's the mileage! | Tue May 20 1997 17:31 | 14 |
|
Are you getting error messages from VTX (I'm assuming that's the
product in question)? I would guess it's how your message file is
built. We have some long-standing problems with message files, but
always it was the error messages weren't getting found at runtime but
doing a SET MESSAGE fixed the problem -- never a problem with the
reverse. And actually, I think I have seen that message on VAX.
What does ANALYZE/IMAGE on your VAX message file produce?
Brian
|
| 969.2 | | TALLIS::NELSON | It's not the years it's the mileage! | Tue May 20 1997 17:39 | 34 |
|
I used the online help database to identify that message, and what
I got was:
IVSECIDCTL, invalid section identification match control
Facility: SYSTEM, System Services
Explanation: The match control field in the section identification
argument
to identify a global section contains an invalid
number.
User Action: Verify that the call to the service is coded correctly.
See the OpenVMS System Services Reference Manual for
coding
specifications.
Certainly sounds like a problem in your build process. It's often
the case that problems on one platform won't show up until you port to
another platform because of assumptions and dependencies. Just because
something works doesn't mean there isn't a problem. What link command
are you using?
Brian
|
| 969.3 | | GALVIA::polomt.ilo.dec.com::duke | | Thu May 22 1997 10:15 | 86 |
| Brian,
The user reports that VTX does actually work OK. However he has some old
utilities that just report an error status and which do a $set message in
order to get the text. Since the product works OK, I'm reducing the
priority on the call.
Re the link statement:
The link command I'm using on VAX is:
$ LINK/SHARE=VTX$EXE:VTX$MSGSHR/NODEBUG/NOTRACEBACK -
VTX$OBJ:VTXMSGSHR,-
VTX$SRC:VTX$IDENT/OPTIONS
where:
VTX$SRC:VTX$IDENT.OPT contains:
SYS$SHARE:VAXCRTL.EXE/SHARE
VTX$OBJ:VTXMSGSHR is created from:
$ MESSAGE/NOLIST/OBJECT=VTX$OBJ:VTXMSGSHR/NOSYMBOL VTX$SRC:VTXMSG
In order for the other components to link, the same message file was used
to create a pointer object to be used in the link commands:
$ MESSAGE /OBJECT=VTX$OBJ: /NOLIST VTX$SRC:VTXMSG
/FILE=VTX$MSGSHR/NOTEXT
$ LIBRARY/REPLACE VTX$OBJ:TRANSLATION.OLB
VTX$OBJ:VTXMSG.OBJ
This looks OK to me.
-ronan
ps:
I did a $anal/image/out=m.out on vtx$msgshr.exe on both Alpha and VAX:
Alpha:
======
IMBUSY > sear m.out "match"/win=(2,1)
image type: shareable (EIHD$K_LIM)
global section major id: %X'0E', minor id:
%X'6CA8EC'
match control: ISD$K_MATEQU
I/O channel count: default
***************
base VBN: 0
global section major id: %X'02', minor id:
%X'000000'
match control: ISD$K_MATLEQ
global section name: "TIE$SHARE_001"
VAX
=====
IMSLOW > sear m.out "match" /win=(2,1)
image type: shareable (IHD$K_LIM)
global section major id: %X'19', minor id:
%X'BD26C6'
match control: ISD$K_MATEQU
I/O channel count: default
***************
base VBN: 0
global section major id: %X'04', minor id:
%X'000005'
match control: ISD$K_MATLEQ
global section name: "VAXCRTL_001"
***************
base VBN: 0
global section major id: %X'01', minor id:
%X'000001'
match control: ISD$K_MATLEQ
global section name: "CMA$TIS_SHR_001"
***************
base VBN: 0
global section major id: %X'01', minor id:
%X'00000E'
match control: ISD$K_MATLEQ
global section name: "LIBRTL_001"
***************
base VBN: 0
global section major id: %X'81', minor id:
%X'00800D'
match control: ISD$K_MATLEQ
global section name: "MTHRTL_001"
|
| 969.4 | | TALLIS::NELSON | It's not the years it's the mileage! | Fri May 23 1997 11:56 | 35 |
|
Ronan,
> The user reports that VTX does actually work OK. However he has some old
>utilities that just report an error status and which do a $set message in
>order to get the text. Since the product works OK, I'm reducing the
>priority on the call.
> Re the link statement:
I don't know what causes that error you're seeing, I've never had
the time to look into it (but always wondered). You can verify that
other components do the same thing very easily. Ages ago I got tired
of trying to figure out what product a message came from, so I wrote a
command file to do a SET MESSAGE to every file in sys$message in turn
and see if an obscure message number would turn into something human
digestible. This led me to the discovery that quite a few components
on VAX show the same error you're getting.
There are further indications that VEST is not at fault here. The
VEST message file, VEST$MSG.EXE, is itself translated. You can do a
SET MESSAGE just fine.
I'd compare ANALYZE/IMAGE of VEST's message file with yours. Also,
I'll post how we build our message file in case that helps.
Unfortunately, I just don't have the cycles to look into such a low
priority thing, especially when circumstantial evidence would indicate
there's no problem with VEST.
Brian
|
| 969.5 | | TALLIS::NELSON | It's not the years it's the mileage! | Fri May 23 1997 12:01 | 53 |
|
From our MMS files:
---------------VEST$KIT.MMS------------------------
.MSG.OBJ
MESSAGE/NOSYMBOLS/OBJ=$(MMS$TARGET) $(MMS$SOURCE)
.MSG.EXE
name := $(MMS$TARGET_NAME)
name = f$element(1,":",name)
MESSAGE/NOSYMBOLS/OBJ=OBJ$:'name'.OBM $(MMS$SOURCE)
LINK/SHAREABLE=$(MMS$TARGET) OBJ$:'name'.OBM
emt$library:vest$msg.obj : emt$sources:vest_msg.msg
MESSAGE /OBJECT=$@ $<
---------------VEST$MSG.MMS--------------------------
emt$test:vest$msg.exe : emt$library:vest$msg.obj
LINK/SHARE=$@ $(MMS$SOURCE), emt$sources:vest_ident.opt/opt
emt$library:vest$msg.obj : emt$sources:vest_msg.msg
MESSAGE/OBJ=$@ $(MMS$SOURCE)
---------------VEST_IDENT.OPT-------------------------
! Generated by version.com invoked by NELSON on 19-MAR-1997 13:57:53.56
! BL3V_VST:[VST.BL3V.SOURCES]VEST_IDENT.OPT
!
! set the ident in the VEST image:
!
IDENT="V1.1A-0"
---------------VEST_MSG.MMS-----------------------------
emt$library:vest_msg.obj : emt$sources:vest_msg.msg
MESSAGE/FILE_NAME=VEST$MSG/OBJ=$@ $<
!
! This next line is to get around a depend problem that relates from
! vest_msg.h being an intermediate file.
!
emt$library:error_messages.obj : emt$sources:vest_msg.h
emt$sources:vest_msg.h : emt$sources:vest_msg.sdl
SDL/LANG=C=$@ $<
emt$sources:vest_msg.sdl : emt$sources:vest_msg.msg
MESSAGE/NOOBJECT/SDL=$@ $<
|
| 969.6 | | GALVIA::DUKE | Ronan | Mon May 26 1997 06:25 | 25 |
| Brian,
> I don't know what causes that error you're seeing, I've never had
> the time to look into it (but always wondered). You can verify that
> other components do the same thing very easily. Ages ago I got tired
> of trying to figure out what product a message came from, so I wrote a
> command file to do a SET MESSAGE to every file in sys$message in turn
> and see if an obscure message number would turn into something human
> digestible. This led me to the discovery that quite a few components
> on VAX show the same error you're getting.
I did a search through on the Alta-Vista'd notes conferences and found quite a
few instances of this. The typical reply was something to the effect of "there
was a problem with the how we built the file and it's fixed now". I didn't
find explanation of what the problem was or how it was fixed. Frustrating,
since I've read and re-read the message documentation.
> Unfortunately, I just don't have the cycles to look into such a low
> priority thing, especially when circumstantial evidence would indicate
> there's no problem with VEST.
That's OK - thanks for your replies.
-ronan
|