Conference turris::decc

    I certainly have never seen this before.

    I was afraid of that....sigh:(  I'll keep plugging away at this.

I noticed that the customers libraries were compressed.... (basically reaching
.. I know).  I had them decompress all their libraries, including starlet.olb. 
They got farther, and are now seeing different errors.

 - Linking shared ORACLE image (ORACLE)
%LINK-W-USEUNDEF, undefined symbol .`?b# referenced
        in psect $LINK$ offset %X00000070
        in module C$MBOXIO file SYS$COMMON:[SYSLIB]STARLET.OLB;2
%LINK-W-ILLTIR, illegal relocation command (49223.)
        in module C$MBOXIO record 1698 file SYS$COMMON:[SYSLIB]STARLET.OLB;2
%LINK-W-ILLTIR, illegal relocation command (5.)
        in module C$MBOXIO record 1699 file SYS$COMMON:[SYSLIB]STARLET.OLB;2


Would you agree that if starlet were corrupt or something else on the system was
corrupt, it would show up linking straight C code???  Could the Oracle part be
linking in a strange - possibly - not quite legal way?

If the ILLTIR wasn't showing up, I would say we don't have an action item,
however, that waring does say to contact us:


 ILLTIR,  illegal relocation command 'command-name'
          in module 'module-name' record 'record-name' file 'file-
          name'

  Facility:     LINK, Linker Utility

  Explanation:  A module contains an invalid object language command.

  User Action:  Contact a Digital support representative about the appropriate


Thanks,

Elin

   I'd first suspect a library corruption.

   Try temporarily replacing STARLET with a copy off a distribution kit.
   (This obviously omits anything the customer or a DIGITAL or third-party
   layered product added into STARLET.)

Any other idea's.

    Not that I have any ideas, but what ECO level is this OpenVMS V6.1 for
    Alpha system running for the CRTL?  
    
    The image ident information from 
    
      $ ANALYZE/IMAGE SYS$SHARE:DECC$SHR.EXE
    
    would be sufficient.
    
    Duane

   Exactly what is the LINK command in use?

   Is it possible to upgrade the DEC C compiler from the `V4.1' listed in
   the base note?  (That's an old C compiler from the early days of DEC C,
   V5.5-003 is the current DEC C release.  V4.1 used the GEM BL27 backend,
   while V5.5-003 uses GEM BL32 -- more than a few changes have been made
   between these baselevels...)

   Can the customer provide a *short* standalone source example, and a
   command procedure containing the requsite DCL commands needed to build
   the images from the source, and the results of an invocation of this
   command procedure, for our inspection?

I have asked for the image ident info from the DECC$SHR image.  Still waiting on
that.

They pulled a fresh copy of STARLET.OLB off their distribution. Now they get:

	%link-w-gsdtyp, illegal gsd record type in module sys$ssdef

I have asked (again) for a short reproducer.

This is a tough one, I really appreciate the help.

-elin

   Even if you can't get a reproducer, if you can show us the sequence
   of commands and the error(s) on the target system, we might be able
   to spot a usage error...  (We're still flying blind here -- we need
   at least the output from a SET VERIFY of the failing procedure(s)...)

   Also try an ANALYZE/DISK [/REPAIR] on SYS$SYSDEVICE: -- I'm beginning
   to suspect this system disk might be corrupted...  

   Check for errors via SHOW ERRORS or DECevent and look for CPU, memory,
   or disk errors.  Check for a bad or over-long or cheesy-cables SCSI
   configuration, check for any sort of `unusual' VMScluster configuration
   hardware, and for any `unusual' VMScluster-related SYSGEN settings, etc.  

Re: .10

I have the customer's logfile... it is pretty big... You can copy it from

	irdane::dka100:[tmpfile]sethost.log

Thanks,

Elin

   I've received a copy of that log file -- the set-up and the failing
   LINK command is, uh, rather large: just under 13,000 lines of DCL,
   with a single LINK command weighing in at just under 150 lines of
   DCL and options file and symbol vectors -- and it's not that heavily
   commented, either...

   I'd strongly recommend contacting the specific organization that
   wrote that procedure, and bringing them into this loop.  (They may
   have seen this before -- they certainly have a history of unusual
   OpenVMS programming techniques...)

   If you want to pursue this through DIGITAL, we're going to need a copy
   of the MAP file that LINK generated.  (I suspect that file is going to
   be huge, too.)   My *guess* is that this is something specific to how
   that particular product is being linked, at least until proven otherwise.
   (And in any event, the support organization for that product will need
   to be brought into the support loop with DIGITAL...)  The MAP may/will
   point us at the source of that bogus symbol...

   You might also want to try another installation kit, as it looks like
   that product involves circa 30 object libraries, and an assortment of
   objects and explicit LINKER directives.  (On the off chance there is
   a corruption in the distribution kit, or there is a need for a specific
   kit for this version of OpenVMS...)

Thanks.. will pass that information on .... putting on my armor:-)

	Given that the LINK is large, if you haven't installed the latest
applicable ALPLINK ECO, you may want to do so.  There was a rather serious
bug in the V6.1 linker, and another, more obscure bug in the V6.2 linker,
which showed itself when the size of an image section grew larger than
65535 blocks.  The latest ECO fixes both of these.

re: .14.. I'll try that, thanks.

The following is from the link map... does it tell us anything - besides that
the creator is an oooolllllddd DEC C??


C$MBOXIO        V4.5                 1196 SYS$COMMON:[SYSLIB]STARLET.OLB;1
 8-DEC-1995 05:18  DEC C X1.3-014E
%LINK-W-USEUNDEF, undefined symbol
<ETX>.<NUL>`<NUL><NUL><STX><ETX><SOH>?�<BS><
NUL>b# referenced
        in psect $LINK$ offset %X00000070
        in module C$MBOXIO file SYS$COMMON:[SYSLIB]STARLET.OLB;1
%LINK-W-ILLTIR, illegal relocation command (49223.)
        in module C$MBOXIO record 1698 file SYS$COMMON:[SYSLIB]STARLET.OLB;1
%LINK-W-ILLTIR, illegal relocation command (5.)
        in module C$MBOXIO record 1699 file SYS$COMMON:[SYSLIB]STARLET.OLB;1

   I'd need to see the entire link map.  (It's probably huge, too.)

   The previously-mentioned LINKER patch definitely sounds interesting.

   As for the "kevlar comment", I'd bring that support organization in
   to help DIGITAL and the customer, and not point a finger at them. 
   I'd expect they may/will have seen this problem before.

   I've done a quick check of STARLET.OLB from the OpenVMS Alpha V6.1
   distribution, and it reports itself as "C$MBOXIO" "V4.5", and was
   built "1-APR-1994 20:15" by "DEC C X1.3-014E".  (In other words,
   this looks like vanilla V6.1.)

   That the application is linking against STARLET.OLB for this and
   other symbols appears, uh, unusual, as I would have expected most
   applications to link against the DEC C shareable image, not the
   object libraries.

He ended up doing a checksum on the c$mboxio module and it did NOT match what a
good one was. He verified with the field that his hardware was OK - scsi
controllers and all - so he pulled a fresh copy of the c$mboxio module and
inserted it in starlet.old and now all is running just fine.  That is too
strange - since he said he said he pulled starlet.olb from his dist, and that
failed too.  But it would appear that the vendor stuff directly points to a
specific starlet.. So I asked him if they are running a defragger. They were,
but turned it off due to problems.  He had not recompressed his disk since
turning it off.  I suggested that he do that next scheduled pm.  He will...

He says THANKS!!! to all for the help.

	The customer should definitely install the ALPLINK ECO
(as well as a few others) if staying on V6.1 for any length of time.