Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

When does sys$starlet_c.tlb get updated?

 
OwensJ
Advisor

When does sys$starlet_c.tlb get updated?

We had a machine which used to build C/C++ projects that crashed, and put the same versions of the C/CXX compilers (7.2-1) on new machines running OpenVMS 8.3I with Update7. The problem is, code that compiled with the same compiler versions on our old build machine no longer compiles. When we researched it, it looks like the sys$starlet_c.tlb file is older on the new machines than it was on the old machine.

There were 2 additional comments at the top of the otsroutines.h from 2006 and 2007 on our old box, which do not exist in the same file on the new box. The summaries of which were:

20-MAR-2007 JML QXCM1000393572 Headers returning complex results can't be compiled by BASIC.

and

14-Dec-2006 JML QXCM1000384200 Headers returning complex results can't be compiled by C/C++ (Which seems to be where our issue is residing)

If we use the sys$starlet_c.tlb from the older machine that has those comments in the otsroutines.h to the new machines, the compile works. Yes, I am aware that this -may- be our solution, but what we really want to know is how to officially update those files to bring them up to date, because apparantly installing to I64_8.3I with Update7 Path, C V7.2-1 and CXX 7.2-1 do not update those files where we need them to be.
15 REPLIES 15
John Gillings
Honored Contributor

Re: When does sys$starlet_c.tlb get updated?

John,

Good question!

STARLET libraries belong to the operating system, so (technically) they should only be updated with OpenVMS, or when the OS is patched.

On the other hand, sometimes newer versions of some compilers may need to have updated libraries for various reasons.

In the past, compiler kits have sometimes updated system libraries. Some compilers ask if you want to rebuild libraries. Arguably language specific libraries should belong to the compiler, but then things like STARLET have strong dependencies on the OS, so it's not black and white.

Similar questions arise with language RTLs. Historically compiler versions which "stole" ownership from the OS and distributed updated RTLs in compiler kits have caused trouble from time to time. There is more exposure to potential conflicts with RTLs because they impact running programs, not just compilations.

Unfortunately, whichever path is taken, there will always be update sequences which result in unexpected differences. To track down the exact sequence, you may need to correlate installations and patches on the two systems.

To some extent, the INCLUDE files provided by STARLET are "advisory". That is, you could write your own (at least, in theory!), so you don't need to take whatever you get as gospel.

If you've found a discrepancy, I'd suggest using the library which works. Be aware of the difference, and keep a careful eye on any patches applied. If you want to take the cautious path, restore the "correct" (original?) library before installing any update or patch.
A crucible of informative mistakes
Hoff
Honored Contributor

Re: When does sys$starlet_c.tlb get updated?

To answer your implementation question, SYS$STARLET_C.TLB is updated with VMS and with various patches (PTHREAD patches had it for a while, in older versions).

This text library is entirely dependent on the VMS version.

As for another question seeking an official fix, ITRC isn't an official forum. Your chances of getting an official answer here (and particularly with the unfortunate lack of diagnostics and lack of source code) is comparatively low. Please call the support center.

HP (or whomever you contact for support) will need to see the diagnostics and possibly the source code of a reproducer. HP have a look at the PTR details associated with QXCM1000393572, and see what's up, and whether your source code modules and compilation errors match up with the OTS$ROUTINE.H definition changes.

This could well be entirely unrelated to the OTS changes, too. This wouldn't be the first time an upgrade broke something. This may be as simple as a LIBRARY /REPLACE command (from a module HP provides or from V8.3-1H1 or V8.4, or a patch kit with updates to the library, etc) or there may well be something entirely else wrong here, as this could be unrelated to the OTS$ declaration changes.

Call HP or your support provider.
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

A lot of interesting information! I had hoped that maybe it would be a cut and dry thing, but it looks like there are so many possible causes that an exact solution may not even be possible. I was thankful that at least we could trace good and bad versions of the files we needed, but looks like we may just have to do some independent testing to see how to re-create a good result.

I'll take a look at the files in question on a base 8.3 installation, followed by the pthread patch, the update 7 kit, the C compiler, and the C++ compiler, and see how it changes, if at all.
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

So far, off a base 8.3 Install I've installed

PCSI V2.0
C V7.2-1
CXX V7.2-18
Update-V0700

And none have which updated starlet yet past the initial 2006 version. It's like digging for a needle in a haystack!
Andy Bustamante
Honored Contributor

Re: When does sys$starlet_c.tlb get updated?

You might try searching sys$help:*.release_notes for mention of sus$starlet_c.tlb

Opening a case with HP and having them dig for this change is another option.

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

Yeah I hopened a case with HP yesterday. I plan to post the answer to the question if I get it from them.
abrsvc
Respected Contributor

Re: When does sys$starlet_c.tlb get updated?

Please post the first page output from an ANAL/IMAGE/HEADER for each of hte RTLs. The data and IDs should give us a clue.

Dan
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

Can you elaborate a little more? When you say "each of the RTLs" I'm a little confused. I'm only having an issue with the sys$starlet_c.tlb file (or some of its contents). If I replace it with a newer one everything we have compiles fine. I just want to know what patch updates it (if any). Do you need me to run that anal/image/header on the sys$starlet_c.tlb file? or some of its contents?
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

Andy,

I did a search so far of all of the .release_notes and the only mention outside of the CC.release_notes is some steps to update sys$starlet_c.tlb in the sys-V0200 patch, but that is an unrelated fix.

-John
abrsvc
Respected Contributor

Re: When does sys$starlet_c.tlb get updated?

SOrry to be confusing. What I was asking for was the first page of each of the 2 RTLs. The one with the updated code and the "original". The information in the header might give us a clue about what/when it was updated.

Dan
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

Here are the comparisons of the top of the ots$routines file inside of sys$starlet_c.tlb

From Version 8.3 installed:
/********************************************************************************************************************************/
/* Created: 24-Sep-2008 12:41:42 by OpenVMS SDL EV3-2-1 */
/* Source: 24-SEP-2008 12:41:39 $1$DGA68:[STARLET_H.SRC]OTS$ROUTINES.SDI;1 */
/********************************************************************************************************************************/
/*** MODULE ots$routines ***/
#ifndef __OTS_ROUTINES_LOADED
#define __OTS_ROUTINES_LOADED 1

#pragma __nostandard /* This file uses non-ANSI-Standard features */
#pragma __member_alignment __save
#pragma __nomember_alignment
#ifdef __INITIAL_POINTER_SIZE /* Defined whenever ptr size pragmas supported */
#pragma __required_pointer_size __save /* Save the previously-defined required ptr size */
#pragma __required_pointer_size __short /* And set ptr size default to 32-bit pointers */
#endif

#ifdef __cplusplus
extern "C" {
#define __unknown_params ...
#define __optional_params ...
#else
#define __unknown_params
#define __optional_params ...
#endif

#ifndef __struct
#if !defined(__VAXC)
#define __struct struct
#else
#define __struct variant_struct
#endif
#endif

#ifndef __union
#if !defined(__VAXC)
#define __union union
#else
#define __union variant_union
#endif
#endif

/**************************************************************************** */
/* * */
/* COPYRIGHT (c) 1988 BY * */
/* DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS. * */
/* ALL RIGHTS RESERVED. * */
/* * */
/* THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED * */
/* ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE * */
/* INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER * */
/* COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY * */
/* OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY * */
/* TRANSFERRED. * */
/* * */
/* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE * */
/* AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT * */
/* CORPORATION. * */
/* * */
/* DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS * */
/* SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. * */
/* * */
/* * */
/**************************************************************************** */
/* */
/* 23-Feb-2006 JML PTR 75-109-96 Add missing headers for IEEE forms of */
/* various routines. */
/* */
/* As of 23-Feb-2006 SDL has no types to describe IEEE floating */
/* data. Since the actual type is only material with respect */
/* to size of the argument (single vs double precision) we use */
/* F-Floating to represent IEEE S-Floating and D-Floating to */
/* represent IEEE T-Floating. */
/* */
/* In the course of fixing this PTR it was discovered that */
/* number of header definitions have been commented out for */
/* years. Attempts to determine why they are commented out */
/* proved futile. Rather than risk enabling them and possibly */
/* introducing a collision between the system supplied headers */
/* and private headers users may have developed to work around */
/* the lack of them, they shall remain commented out. */
/* However, their new IEEE forms will be enabled as these */
/* routines only came into existence recently. */
/* (see DPML$SHR.OPT checkin of 24-Mar-2004). */
/* */
/* OTS$CVT_T_D */
/* */
/* Convert Numeric Text to D- or F-Floating Value */
/* */
/* The Convert Numeric Text to D- or F-Floating routines */
/* convert an ASCII text string representation of a */
/* numeric value to a D_floating or F_floating value. */
/* */
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

And from whatever updated version we have that we are trying to locate:
/********************************************************************************************************************************/
/* Created: 24-Sep-2008 12:41:42 by OpenVMS SDL EV3-2-1 */
/* Source: 24-SEP-2008 12:41:39 $1$DGA68:[STARLET_H.SRC]OTS$ROUTINES.SDI;1 */
/********************************************************************************************************************************/
/*** MODULE ots$routines ***/
#ifndef __OTS_ROUTINES_LOADED
#define __OTS_ROUTINES_LOADED 1

#pragma __nostandard /* This file uses non-ANSI-Standard features */
#pragma __member_alignment __save
#pragma __nomember_alignment
#ifdef __INITIAL_POINTER_SIZE /* Defined whenever ptr size pragmas supported */
#pragma __required_pointer_size __save /* Save the previously-defined required ptr size */
#pragma __required_pointer_size __short /* And set ptr size default to 32-bit pointers */
#endif

#ifdef __cplusplus
extern "C" {
#define __unknown_params ...
#define __optional_params ...
#else
#define __unknown_params
#define __optional_params ...
#endif

#ifndef __struct
#if !defined(__VAXC)
#define __struct struct
#else
#define __struct variant_struct
#endif
#endif

#ifndef __union
#if !defined(__VAXC)
#define __union union
#else
#define __union variant_union
#endif
#endif

/**************************************************************************** */
/* * */
/* COPYRIGHT (c) 1988 BY * */
/* DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS. * */
/* ALL RIGHTS RESERVED. * */
/* * */
/* THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED * */
/* ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE * */
/* INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER * */
/* COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY * */
/* OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY * */
/* TRANSFERRED. * */
/* * */
/* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE * */
/* AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT * */
/* CORPORATION. * */
/* * */
/* DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS * */
/* SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. * */
/* * */
/* * */
/**************************************************************************** */
/* */
/* 20-Mar-2007 JML QXCM1000393572 Headers returning complex results */
/* can't be compiled by BASIC. */
/* */
/* Well clearly the routines returning complex results */
/* by value (requiring 2 registers) need header generation to */
/* be limited to only those languages KNOWN to be able */
/* to support it and likely to call them. */
/* */
/* */
/* 14-Dec-2006 JML QXCM1000384200 Headers returning complex results */
/* can't be compiled by C/C++ */
/* */
/* Now I understand why a number of headers have been commented */
/* out. When I added all the new IEEE forms, even for those */
/* VAX forms commented out, I didn't realize that C/C++ cannot */
/* return more than 64bits by value. Five of the existing IEEE */
/* routines return complex results by value and those require */
/* 2 registers. This resulted in a .h file for C/C++ that */
/* would not compile. The fix is to use iflanguage and */
/* prevent those headers from being generated for C/C++. These */
/* routines most likely will be called by Fortran anyway. */
/* */
/* 23-Feb-2006 JML PTR 75-109-96 Add missing headers for IEEE forms of */
/* various routines. */
/* */
/* As of 23-Feb-2006 SDL has no types to describe IEEE floating */
/* data. Since the actual type is only material with respect */
/* to size of the argument (single vs double precision) we use */
/* F-Floating to represent IEEE S-Floating and D-Floating to */
/* represent IEEE T-Floating. */
/* */
/* In the course of fixing this PTR it was discovered that */
/* number of header definitions have been commented out for */
/* years. Attempts to determine why they are commented out */
/* proved futile. Rather than risk enabling them and possibly */
/* introducing a collision between the system supplied headers */
/* and private headers users may have developed to work around */
/* the lack of them, they shall remain commented out. */
/* However, their new IEEE forms will be enabled as these */
/* routines only came into existence recently. */
/* (see DPML$SHR.OPT checkin of 24-Mar-2004). */
/* */
/* OTS$CVT_T_D */
/* */
/* Convert Numeric Text to D- or F-Floating Value */
/* */
/* The Convert Numeric Text to D- or F-Floating routines */
/* convert an ASCII text string representation of a */
/* numeric value to a D_floating or F_floating value. */
/* */
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

Sorry... I only have the recent one on this machine so my copy and paste was bad.

The first two lines of the original were
/* Created: 29-Jun-2006 22:45:46 by OpenVMS SDL EV3-2-1 */
/* Source: 29-Jun-2006 22:45:42 $1$DGA2027:[STARLET_H.SRC]OTS$ROUTINES.SDI;1 */

I didnt mean for them to have identical beginnings.
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

Some additional information. The header from ots$routines.h that i used was from the sys-V0300 patch in VMS83I-1H1, where it does update sys$starlet_c.tlb and has the header with that 24-sep-2008 build date of ots$routines.h.

The file that we have on our old build machine has a header build date reading
/* Created: 11-Jul-2007 11:44:44 by OpenVMS SDL EV3-2-1 */
/* Source: 11-Jul-2007 11:44:40 $1$DGA91:[STARLET_H.SRC]OTS$ROUTINES.SDI;1 */

So I know that the version I need of this file had a build date of 11-Jul-2007. Though I have found patches to sys$starlet_c.tlb in 8.3-H1 and 8.4, I'm trying to see if this version is somewhere in 8.3.
OwensJ
Advisor

Re: When does sys$starlet_c.tlb get updated?

Here is an update. To respond directly to my topic question, in OpenVMS V8.3, it doesn't get updated.

There are many patches in version 8.3 that update the .OLB file, but none that update the .TLB file.

There are patches in version 8.3-1H1 that update the .TLB file, such as VMS831H1I_SYS-V0300, but V8.3 won't run an 8.3-1H1 patch. You can however, extract just the .tlb file from the patch itself and use it. And also, upon extraction, extract components out of it. So we viewed the ots$routines.h file inside of the sys-v3.0 patch from 1H1, and it does in fact have the updates we were looking for.

You can also perform the updates yourself manually to the included version with V8.3. To fix our compilation issue, HP told us that we would need to comment out the following:


struct {float ots$divc$$ret_1_ [2];} ots$divcs(__unknown_params);
struct {double ots$divc$$ret_3_ [2];} ots$divct_r3(__unknown_params);
struct {float ots$mulc$$ret_5_ [2];} ots$mulcs(__unknown_params);
struct {double ots$mulc$$ret_7_ [2];} ots$mulct_r3(__unknown_params);
struct {float ots$powc$$ret_9_ [2];} ots$powcscs(__unknown_params);
struct {double ots$powc$$ret_11_ [2];} ots$powctct_r3(__unknown_params);
struct {float ots$powc$$ret_13_ [2];} ots$powcsj(__unknown_params);
struct {double ots$powc$$ret_15_ [2];} ots$powctj_r3(__unknown_params);

In order to fix the issues listed in the 14-DEC-2006 fix. (JML QXCM1000384200)

They did find references to this fix, however there are no existing patches for it in Version 8.3 of OpenVMS, which is why we couldn't find one. They said there were references to this fix in ACRTL-V0300 in V8.3, but that the patch is not available, and the fix is not referenced in ACRTL-V0400. So somehow the fix got lost in the process for version 8.3, though it is corrected in future versions of OpenVMS.

So, in short, if you have version 8.3 of OpenVMS, and you need to get sys$starlet_c.tlb updated, you have to obtain an updated file manually from another patch, or comment out the sections of the .h file inside of it yourself and put it back in.