Conference turris::vaxc

    The newer one (link date 22-APR-1995 00:15:52.76) is the one shipped
    on the OpenVMS VAX V6.2 CD.  I'd remove or rename the other image..
    
    B.t.w, are there 'corresponding' VAXCRTLG.EXEs there too?
    
    John.

    I'll find out about VAXCRTLG. Was that one for G-Float?
    
    What are the differences between the two versions? I was disturbed by
    the fact they both have the same image ident.
    
    Thanks,
    John Saunders
    DECdns Engineering
    DTN 226-5173

Yes, there are two VAXCRTLG.EXE	 files, and the latest one is 22-Apr-95.

Is there a list of differences between these two versions?

Thanks,
John Saunders
DECdns Engineering

    The images are from OpenVMS V6.1 and V6.2, respectively.  There was
    exactly one checkin made for the VAXCRTL V6.2 image.  That checkin
    was made on November 2, 1994 by STAR::COWAN.  The fix was to change
    the length of an XABDAT structure to 44 bytes.
    
    It is not uncommon to not see a bump in the image identifications.  The
    link date/time is sufficient to distinguish images and know exactly
    what they correspond to.
    
    Duane Smith
    

.3> Is there a list of differences between these two versions?
    
    Unlikely.  Since the VAXCRTL/G RTLs ship with OpenVMS, the obvious place
    to check is the OpenVMS V6.2 Release Notes.  Also, as I'm just an NSIS
    field person, if there's a Customer issue underneath these questions
    and a formal reposnse is required you should use Official Channels to
    log a call (as always)..
    
    John.

  > Since the VAXCRTL/G RTLs ship with OpenVMS, the obvious place
  > to check is the OpenVMS V6.2 Release Notes.  
    
    I just scanned the OpenVMS V6.2 release notes and this change is not
    reflected in the release notes.
    
    
  > Also, as I'm just an NSIS
  > field person, if there's a Customer issue underneath these questions
  > and a formal reposnse is required you should use Official Channels to
  > log a call (as always)..
    
    I'm just the project leader for the DEC C Runtime Library and am also
    responsible for the VAX C Runtime Library.  I second John's remark.
    
    Duane
    

Thanks for the replies.

It's not the customer who needed to know the differences - I did. We have a very
strange problem at the customer site, and the existance of two RTLs with the
same image ident but different times was strange enough to be the cause of the
problem. If the only change is to the size of the XABDAT structure, the problem
is probably not caused by the RTL differences.

Thanks,
John Saunders
DECdns Engineering

>If the only change is to the size of the XABDAT structure, the problem
>is probably not caused by the RTL differences.

If your code has a use for an XABDAT structure, then it could be
an issue.  In the V5.5 time frame, the size of the XAB was increased
beyond 44 bytes to allow for 2 new date fields.  However, the
VAX C defined structure was still only 44 bytes in length.
The new RTL eliminates the behavior of overwritting the bytes
beyond the XABDAT structure by setting the correct size in
the structure.  This applies to the code references such as

	struct XABDAT xabdat = cc$rms_xabdat ;

where the xab$b_bln was set to 60 when it should be 44.  The new
RTL keeps it at 44.

If your code looks at the new dates, then they are no longer filled
in by RMS because of this change.  If the data after the structure
was expected to be zeroed because RMS zeroed them for you, that would
no longer happen.

   What is the "very strange problem" you are seeing?

Early in its startup, the DNS Advertiser opens the file
SYS$SYSTEM:DNS$CACHE.VERSION:

    versionfile = open(DNS_CACHE_VERSION, O_RDONLY, 0);
    if (versionfile < 0) {
#if _DNS_OS_ == _DNS__VMS
        TraceIf(M_TRACE_DNS,perror("CA_ReadCurrentVersion"););
#endif
        return(-1);
        }

On one customer system, this fails with "%RMS-E-ACC, ACP file access failed".
The failure occurs regardless of the presence of the file.

A test program which only does the open succeeds, or else fails correctly if the
file is absent. The test program is run in the same starting environment as the
Advertiser by renaming the test program to be DNS$ADVER.EXE and using the normal
DNS Clerk startup (which is what starts the real DNS$ADVER).

This is difficult to understand, since the parameters to the "open" are
constants (DNS_CACHE_VERSION is "SYS$SYSTEM:DNS$CACHE.VERSION").

Of course, string constants in VAX C are in writeable memory. For my next trick,
I'll examine the process in memory and look at the string that _should_ be
getting passed to open.

Other than that, I'm at the point of playing "binary destroy". [Binary Destroy
is like Binary Search, except that you delete half the code each iteration, and
continue until you can no longer reproduce the problem]

Thanks,
John Saunders
DECdns Engineering

:Early in its startup, the DNS Advertiser opens the file
:SYS$SYSTEM:DNS$CACHE.VERSION:
...
:On one customer system, this fails with "%RMS-E-ACC, ACP file access failed".
:The failure occurs regardless of the presence of the file.

   "SET WATCH/CLASS=ALL FILE" in the context of the DNS Advertiser
   startup, and then invoke the startup.  (Use /CLASS=NONE to shut
   off the XQP dreck when you're done...)

:Of course, string constants in VAX C are in writeable memory. For my next trick,
:I'll examine the process in memory and look at the string that _should_ be
:getting passed to open.

   SDA and tools like DELTA/XDELTA can do this.  If you're stuck,
   an IPAST can certainly wander over into the other process and
   look at this stuff.  (HACKERS has some discussions of this.)

    Thanks, Steve.
    
    One of the things I'll try will indeed be to see if the problem will
    reproduce when the Advertiser is run from a DCL command procedure. If
    so, SET WATCH is a great suggestion - there's not that much file
    activity going on  before the problem occurs!
    
    Thanks,
    John Saunders
    DECdns Engineering

re .9:

The problem turns out to be SS$_EXQUOTA.

The customer has a low PQL_MBYTLM. The Advertiser manages to use it all by
opening LAN ports, so by the time we go to open the file, we fail.

Thanks for all the help.
John Saunders
DECdns Engineering

P.S. If the STV value had been available, we'd have had this problem fixed over
a month ago.

:The problem turns out to be SS$_EXQUOTA.
:
:The customer has a low PQL_MBYTLM. The Advertiser manages to use it all by
:opening LAN ports, so by the time we go to open the file, we fail.

:P.S. If the STV value had been available, we'd have had this problem fixed over
:a month ago.

   In larger applications, I typically place minimum process quota checks
   into the application code, I typically place minimum SYSGEN parameter
   checks into the application startup, and I *always* specify a complete
   list of process quotas when creating a mailbox, starting a process, or
   other similar operations.  I learned long ago never to trust the defaults,
   and never to trust the users to maintain the (documented) minimums...

When we fix this, we'll follow your suggestion and put the test in the startup.
The check of the SYSGEN params should also be in the Install/Configure, of
course, but you're right that they could change the parameters on us without
re-running our configure procedure. A check in the startup will catch that.

Thanks,
John Saunders
DECdns Engineering

:When we fix this, we'll follow your suggestion and put the test in the startup.
:The check of the SYSGEN params should also be in the Install/Configure, of
:course, but you're right that they could change the parameters on us without
:re-running our configure procedure. A check in the startup will catch that.

   If one seperates Installation, Configuration, and Startup into distinct
   steps -- which is what I would recommend -- one can use PCSI or VMSINSTAL
   for the installation, and one can then "bury" an undocumented callback
   in the Startup tool that is used by the Configuration tool to verify
   the settings.  I have used this technique to allow me to maintain one
   set of parameter checks -- in Startup -- but to have the configuration
   tool appropriately complain to the person running the tool.  By default,
   Startup calls this routine for every startup and prevents the startup
   if the settings are not met, unless an (undocumented) "override" logical
   name is defined.