Re: IA64 Librarian corrupts TLB's (419 Views)
Reply
Frequent Advisor
RF Thomas
Posts: 45
Registered: ‎12-14-2005
Message 1 of 8 (455 Views)
Accepted Solution

IA64 Librarian corrupts TLB's

We have IA64 running OpenVMS 8.3-1, AXP running 8.4, and VAX running 7.3.  If we insert a source file into a .TLB using the LIB utility, the TLB instantly becomes unusable by AXP and VAX systems:

 

Alpha_Dev> lib/list/full famsub.tlb
%LIBRAR-F-OPENIN, error opening AST$ROOT:[020003]FAMSUB.TLB;14 as input
-LBR-E-ILLFMT, illegal library format
Alpha_Dev>

 

On the IA64 the following is displayed:

 

IA64_Dev> library/full famsub.tlb /list
Directory of TEXT library AST$ROOT:[020003]FAMSUB.TLB;14 on 17-NOV-2011 10:13:54
Creation date:  17-NOV-2011 09:40:08      Creator:  Librarian I01-40
Revision date:  17-NOV-2011 09:49:07      Library format:   3.0
Number of modules:    217                 Max. key length:  39
Other entries:          0                 Preallocated index blocks:     27
Recoverable deleted blocks:        4      Total index blocks used:       10
Max. Number history records:      20      Library history records:        1
Library is in DCX data reduced format

CNV_FRAC         inserted  7-APR-2000 08:48:48
DASH             inserted 28-DEC-1994 13:51:49
DO_ROTAD         inserted 22-NOV-2010 13:41:41
FAMCAL           inserted  7-APR-2000 09:04:14
FAMCHG           inserted 27-JUL-2011 16:30:24
FAMCHG_ENT_VAR   inserted 27-JAN-2000 15:00:21
FAMCHG_ENT_VDC   inserted  4-JAN-2000 11:14:21

 

If we create a text library on VAX or AXP the following properties are displayed:

 

2> lib/list/full xxx.tlb
Directory of TEXT library AST$ROOT:[020003]XXX.TLB;1 on 17-NOV-2011 09:33:40
Creation date:  17-NOV-2011 10:15:02      Creator:  Librarian A09-32
Revision date:  17-NOV-2011 10:15:02      Library format:   3.0
Number of modules:      0                 Max. key length:  39
Other entries:          0                 Preallocated index blocks:     11
Recoverable deleted blocks:      0        Total index blocks used:        0
Max. Number history records:      20      Library history records:        0

2>

 

We use the same source set for all versions of OpenVMS and now we can not access our sources anywhere but the IA64.  All of our source control and software development is built using LIB.

 

Right now we can't maintain our software at AXP or VAX customers.

Honored Contributor
Volker Halle
Posts: 5,206
Registered: ‎04-26-2004
Message 2 of 8 (452 Views)

Re: IA64 Librarian corrupts TLB's

 

Could this have something to do with the DCX format ?

Does it work from the DCL prompt with LIBR commands ?

 

Volker.

Frequent Advisor
RF Thomas
Posts: 45
Registered: ‎12-14-2005
Message 3 of 8 (450 Views)

Re: IA64 Librarian corrupts TLB's

We are only using DCL commands.

Frequent Advisor
RF Thomas
Posts: 45
Registered: ‎12-14-2005
Message 4 of 8 (446 Views)

Re: IA64 Librarian corrupts TLB's

The libraries were all originally created on VAXen running VMS 6.2 and earlier  The compression was done to save disk space.  Back in those days we were working on RL02's and RA60's, so ...

 

In any case the libraries have not been compressed or rebuilt for years.  This corruption started when we converted our software to run on the IA64 and did the editing and re-insertion into the source libraries from the IA64.  Going through this process we have found that there are many undocumented new features (bugs) in hte IA64 porting of VMS.

 

We have an AXP running 8.4, so are surprised that it can't read these libraries that as far as AXP and VAX are now corrupt.

 

The problem is that we are dealing with thousands of libraries not one or two.  We also use tlb's on large customer systems to store production data.  They run in mix architecture clusters.  The cusotmers haven't yet been bitten by this problem, but when is happens we need to be able to quickly repair and move forward.  They do not compress their libraries.

Honored Contributor
Hoff
Posts: 4,962
Registered: ‎01-29-2006
Message 5 of 8 (442 Views)

Re: IA64 Librarian corrupts TLB's

Load the UPDATE V11.0 kit (which incorporates a librarian patch kit with fixes for errors in this area) or analogous collection of patches for your OpenVMS I64 V8.3-1H1 server (I presume; as there's no V8.3-1 release), and try your tests again.

 

If this is corrupt libraries or latent issues with the compatibility with older text libraries, then there's a wildcard-library-extraction libext-based DCL bulk-extraction tool here; that'll serve as a building block that can allow you to bulk-rebuild these libraries.

 

For grins, I might try turning off DCX.  But whether DCX or enabled or not, this stuff should be compatible.  So head for the patches.

Honored Contributor
Volker Halle
Posts: 5,206
Registered: ‎04-26-2004
Message 6 of 8 (439 Views)

Re: IA64 Librarian corrupts TLB's

[ Edited ]

It looks related to the DCX format !

 

I64VMS $ libr/create/text test.tlb
I64VMS $ libr test.tlb a.a
I64VMS $ libr/list/full test.tlb
Directory of TEXT library $3$DUA2:<TEST>TEST.TLB;5 on 17-NOV-2011 17:18:26
Creation date:  17-NOV-2011 17:17:46      Creator:  Librarian I01-29
Revision date:  17-NOV-2011 17:17:54      Library format:   3.0
Number of modules:      1                 Max. key length:  39
Other entries:          0                 Preallocated index blocks:     11
Recoverable deleted blocks:        0      Total index blocks used:        1
Max. Number history records:      20      Library history records:        1

A                inserted 17-NOV-2011 17:17:54

 

CHARON $ libr/list/ful test.tlb
Directory of TEXT library $3$DUA2:<TEST>TEST.TLB;5 on 17-NOV-2011 18:17:57
Creation date:  17-NOV-2011 17:17:46      Creator:  Librarian I01-29
Revision date:  17-NOV-2011 17:17:54      Library format:   3.0
Number of modules:      1                 Max. key length:  39
Other entries:          0                 Preallocated index blocks:     11
Recoverable deleted blocks:      0        Total index blocks used:        1
Max. Number history records:      20      Library history records:        1

A                inserted 17-NOV-2011 17:17:54


I64VMS $ libr/data=reduce test.tlb

 

CHARON $ libr/list/ful test.tlb
%LIBRAR-F-OPENIN, error opening $3$DUA2:<TEST>TEST.TLB;6 as input
-LBR-E-ILLFMT, illegal library format

 

I64VMS $ libr/data=expand test.tlb

 

CHARON $ libr/list/ful test.tlb
Directory of TEXT library $3$DUA2:<TEST>TEST.TLB;7 on 17-NOV-2011 18:20:31
Creation date:  17-NOV-2011 17:20:22      Creator:  Librarian I01-29
Revision date:  17-NOV-2011 17:20:22      Library format:   3.0
Number of modules:      1                 Max. key length:  39
Other entries:          0                 Preallocated index blocks:      1
Recoverable deleted blocks:      0        Total index blocks used:        1
Max. Number history records:      20      Library history records:        0

A                inserted 17-NOV-2011 17:17:54

 

 

I64VMS - OpenVMS I64 V8.2

CHARON - OpenVMS VAX V7.3

 

See, whether the patches mentioned by Hoff solve this (nothing explicitly mentioned in the VMS831H1I_LIBRAR-V0100 release notes) or use /DATA=EXPAND as a workaround.

 

And make sure to raise a call with HP.

 

Volker.



Frequent Advisor
RF Thomas
Posts: 45
Registered: ‎12-14-2005
Message 7 of 8 (431 Views)

Re: IA64 Librarian corrupts TLB's

Thank you - we have a workaround.  It will be reported.

Honored Contributor
Volker Halle
Posts: 5,206
Registered: ‎04-26-2004
Message 8 of 8 (419 Views)

Re: IA64 Librarian corrupts TLB's

The underlying problem seems to be this (see source module [LBR]OPENCLOSE):

 

The library header is stored in the first block (VBN 1) of the library file.

 

The field lhd$l_sanity (2nd longword in VBN 1) is supposed to store a 'sanity value'.

 

For libraries in DCX compressed format, OpenVMS VAX and OpenVMS Alpha store a value of %X13071956 in the LHD$L_SANITY field.

 

For uncompressed libraries, OpenVMS Alpha, VAX and I64 store %X0DEC2581

 

But OpenVMS I64 stores %X1307195C, when performing a LIBR/DATA=REDUCE operation on the library, which of course leads to a LBR-E-ILLFMT, when OpenVMS VAX or OpenVMS Alpha try to open such a library.

 

 

 

Please consider to add a pointer to this analysis, when you escalate this problem.

 

Volker.

 

 

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.