Conference turris::decc

Are there any ECOs applied to the OpenVMS 7.1 system?  

I can find one problem report on mktmp (not sure when it was introduced) but 
it should have been fixed 7.1 (it had to do with incorrectly replacing
some of the XXXX characters.

Do you have the example code?

bjm

    The customer got back with these answers:
    
    
    It is a Alpha with OpenVMS 7.1 and C-compiler 5.5, I think it worked
    with
    OpenVms 7.0 and C-compiler 5.4
    
    
    
    >Are there any ECOs applied to the OpenVMS 7.1 system?
    
    he thinks not
    
    >I can find one problem report on mktmp (not sure when it was
    >introduced) but it should have been fixed 7.1 (it had to do with
    >incorrectly replacing some of the XXXX characters.
    
    >Do you have the example code?
    
    This is the function called from many sources.
    
    char *znmktemp(string)
      char *string;
      BEGIN
        static char dest[128]; /* must be static to hold its value at
    return
    */
        int i;
    
        znpaths(string, dest); /* this is copy in VMS, In UNIX it evaluates
    environments */
        mktemp(dest);
        i=movst(dest, 0, string, 0, strlen(dest));
        string[i]=0;
        return(0);
      END
    
    Here is definitions of tempfiles and all of them works in VAX OpenVMS
    6.2
    
    #define WRKFILE   "NECTMP:wrkXXXXXX."
    #define SELFILE   "NECTMP:selXXXXXX."
    #define SPLFILE   "NECTMP:splXXXXXX.lis"
    #define DUMPFILE  "NECTMP:dumpXXXXXX.txt"
    
    Here is some examples of calls:
    
        movst(SELFILE,0,selfil,0,sizeof selfil);
        znmktemp(selfil);
        fn=creat(selfil,ZNMODE);
    
    
        i=movst0(SPLFILE,0,filnam,0,32);
        filnam[i]=0;
        znmktemp(filnam);
        *znfn=creat(filnam,ZNMODE);
    
    

The change was intentional and would have been seen by your customer had
any of the V7.0 ECO kits been installed.  From the first V7.0 ECO kit
release notes:

Problems addressed in ALPACRT01_070 kit

      o  The mktemp function generates  unique  file  specifications  by
         replacing  Xs found a user-supplied string with a derivative of
         the process id.  The problem is that only trailing Xs are to be
         replaced as opposed to Xs found throughout the string.

Duane, shouldn't the V7.1 release notes also list all changes
since the V7.0 release?

    I agree that it should.  All of the RTL teams went round and round on
    this with the OpenVMS team.  I did not look at the V7.1 release notes
    to see if this was included.
    
    This was a very big issue in the V6.1/V6.2 timeframe when we were
    fixing on the order of 100-150 problems per release.  Let's just say
    that neither release notes nor image idents are our strong points.
    
    Duane

    I've a customer who supplys software to a number of clients, that has
    come across the same thing.
    His clients can't go to v7.1 of VMS yet anyway for other reasons, but
    when they do, they'll come up against this change.
    
    I gave him the information in the ECO release notes, but he has a
    further question.
    As the RTL reference manual, (in the section on mktemp), guides
    developers away from mktemp to mkstemp, he doesn't see why mktemp's
    functionality was changed to that of mkstemp?
    (Although having looked at it doesn't mkstemp & mktemp return quite
    different things)?
    Was there a problem that bit people if there were Xs elsewhere in the
    string that were replaced that needed to be fixed, or was the change
    more along the lines of, it was always meant to work the way it now
    does on v7.1, but didn't?
    
    Thanks & regards,
    Steve.
    

    It was changed as the result of a problem report.  The report stated
    that when replacing X's from right to left, it should stop when a non-X
    character is encountered.  Otherwise, it went right ahead and began
    replacing X's in the directory specification.
    
    The behavior of this function is specified by the X/Open Specification
    which some view as a good portability guide.  In this specification, it
    distinctly says that it replaces trailing X's.  In fact, I believe it
    says it replaces exactly 6 X's.  Our implementation does not limit the
    number of X's, but a side effect of stopping at the first non-X
    character resulted in the behavior that we now see with filespecs such
    as "[]XXXXXX.LIS" not replacing any characters.
    
    I wish this had been considered by the engineer who did this work.  A
    more upward compatible behavior would have been to replace the last
    contiguous string of X's with the pattern.  This would have fixed the
    problem as well as retained upward compatibility.
    
    Duane

    This is being investigated as CRTL problem number 1718.  It appears
    that the affected platforms are:
    
    	OpenVMS RAVEN for VAX and Alpha
        OpenVMS  V7.1 for VAX and Alpha
        OpenVMS  V7.0 for VAX and Alpha with latest ECO kit (*ACRT02_070)
    
    Duane

    I've completed the modifications necessary to replace the last "group"
    of X's with the process id.  Once we have a local build and regression
    test system run, I will check this change into the VMS source pool.
    
    For OpenVMS V7.0, the fix will appear in ECO kits ALPACRT06_070 and
    VAXACRT06_070.  For OpenVMS V7.1, it will appear in ALPACRT02_071 and
    VAXACRT02_071.
    
    Please feel free to pass this information onto your customer.
    
    Duane Smith