VSI Code Management System Version 4.8-13

Release Notes


1. Introduction

VSI Code Management System (CMS) V4.8-13 for OpenVMS x86-64, IA-64, and Alpha systems is part of VSI DECset Version 13.0-3 for OpenVMS x86-64, IA-64, and Alpha systems.

All versions of VSI Code Management System check for a license PAK from VMS Software, Inc. You must have a license PAK from VMS Software, Inc. to use this product.

VSI CMS V4.8-7, V4.8-8, and V4.8-11 were not released.

2. Fixed Issues

Fixed in VSI CMS V4.8-13:
  • Fix for DS-78 Callable CMS Examples on DECset kit are incorrect

    Some time ago, the structure for the library data block was increased from 50 longwords to 57 longwords, but that change was not reflected in the provided SDL definition and the language-specific include files.

    CMS$ROUTINES.SDL and the generated language-specific files now contain the correct size for the library data block.

  • Fix for DS-81 CMS installation process does not insert CMSSHR.EXE into SYS$LIBRARY:IMAGELIB.OLB

    During the transition from VMSINSTAL to PCSI for DECset kits, it was overlooked that CMSSHR.EXE needed to be inserted into SYS$LIBRARY:IMAGELIB.OLB. That oversight has been rectified.

Fixed in VSI CMS V4.8-12:

Prior to CMS V4.8-12, the CMS installation would provide CMS$ROUTINES.SDL in SYS$COMMON:[SYSHLP.EXAMPLES.CMS]. Unfortunately, the file provided was not legal SDL.

Now, the CMS installation provides a valid copy of CMS$ROUTINES.SDL, in addition to CMS$ROUTINES.BAS, CMS$ROUTINES.REQ, CMS$ROUTINES.H, CMS$ROUTINES.FOR, CMS$ROUTINES.MAR, and CMS$ROUTINES.PAS.

Fixed in VSI CMS V4.8-11:

Fix for SPS-1047 -- CMS ACCVIO on V9.2 (CMS V4.8-9)

A call to LIB$GET_VM used a quadword to hold the return address of the allocated memory. Since LIB$GET_VM returns a 32-bit address, the upper longword of the quadword was untouched by LIB$GET_VM. If the upper longword was non-zero, then bad things happen.

Fixed in VSI CMS V4.8-10:

During a REPLACE operation on an element with a large number of generations, the following failure message could be received:

 %CMS-E-NOREPLACE, error replacing ELEMENT
 -CMS-E-GENTOODEEP, generation edits are nested too deeply
 %VDE-E-CMSREPLACE, CMS error when replacing CMS element for
 module ELEMENT
Fixed in VSI CMS V4.8-9:

Running HELP from CMS on an OpenVMS x86-64 system would result in the error:

CMS> help
%SYSTEM-F-ACCVIO, access violation, reason mask=14, virtual
address=0000000085C0AA50, PC=00000000001654E9, PS=0000001B
Fixed in VSI CMS V4.8-6:

Fetching a file to the terminal (using the syntax of /OUTPUT=TT:) would fail with the error

%CMS-F-BUG, there is something wrong with CMS or something it calls
 -CMS-F-NOQIO, $QIO failed
 -RMS-F-SYS, QIO system service request failed
 -SYSTEM-F-NOT64DEVFUNC, 64-bit address not supported by
 device for this function
Fixed in VSI CMS V4.8-5:

CMS V4.8-4 was built incorrectly, such that unexpected errors could happen. A reported error on Alpha only is that the use of CMS with MMS via the MMS qualifier /CMS would not work; the element would not be fetched by CMS, usually causing a build error.

Fixed in VSI CMS V4.8-4:

During a VERIFY operation, CMS will occasionally report its findings as it traverses the library. In one specific situation, the library was corrupt in such a way as to prevent accurate reporting on the element name and generation that was corrupt, leading to an abrupt termination of the VERIFY operation. The fix is to check the string descriptor before use, and if the element name descriptor is malformed, the hardcoded string <element unknown> will be displayed.

Fixed in VSI CMS V4.8-3:

Under certain situations, the reference directory copy of a binary file would be corrupt. In the reported case, a zip archive file was corrupt in the reference directory, but was correct and intact when fetched.

Fixed in VSI CMS V4.8-2:

Repeated invocations of the callable routine CMS$SHOW_CLASS would sometimes not work, with no data being returned. This problem first appeared in HPE CMS V4.6, was fixed in HPE CMS V4.7, and mistakenly reappeared in VSI CMS V4.8.

Fixed in VSI CMS V4.8-1:

The CMS DIFFERENCES command did not generate the correct output if the second file was specified using the /GENERATION qualifier. In that case, the output of the second file was blank.

3. New Features and Enhancements

In VSI CMS V4.8-3:

CMS libraries may now be created at a directory depth greater than eight. Prior to this change, CMS had a check to ensure that libraries could not be created at a depth greater than eight. While RMS at one point had a limitation on dealing with directory depths greater than eight, RMS removed that restriction a long time ago.

In VSI CMS V4.8-4:

Effective with CMS V4.8-4, the installation will no longer ask if ODS-5 support is wanted. The installation will automatically install CMSSHR.EXE that has ODS-5 support. Note that ODS-5 is a proper superset of ODS-2, and that CMSSHR with ODS-5 support will work correctly on ODS-2 disks.