**************************** ECO SUMMARY INFORMATION **************************** Release Date: 14-Sep-2006 Kit Name: HP-I64VMS-TDMS_DEV-V0200-ECO1-1.PCSI HP-I64VMS-TDMS_RTO-V0200-ECO1-1.PCSI HP-AXPVMS-TDMS_DEV-V0200-ECO1-1.PCSI HP-AXPVMS-TDMS_RTO-V0200-ECO1-1.PCSI Kit Applies To: OpenVMS ALPHA V7.3-2 or higher OpenVMS I64 V8.2-1 or higher Approximate Kit Size: HP-I64VMS-TDMS_DEV-V0200-ECO1-1.PCSI - 72976 blocks HP-I64VMS-TDMS_RTO-V0200-ECO1-1.PCSI - 24032 blocks HP-AXPVMS-TDMS_DEV-V0200-ECO1-1.PCSI - 54304 blocks HP-AXPVMS-TDMS_RTO-V0200-ECO1-1.PCSI - 18416 blocks Installation Rating: INSTALL_3 Reboot Required: No Superseded Kits: None Mandatory Kit Dependencies: None Optional Kit Dependencies: None HP-I64VMS-TDMS_DEV-V0200-ECO1-1.PCSI Checksum: 3547172368 HP-I64VMS-TDMS_RTO-V0200-ECO1-1.PCSI Checksum: 1498557270 HP-AXPVMS-TDMS_DEV-V0200-ECO1-1.PCSI Checksum: 3415877261 HP-AXPVMS-TDMS_RTO-V0200-ECO1-1.PCSI Checksum: 3024586141 ======================================================================= Hewlett-Packard OpenVMS ECO Cover Letter ======================================================================= ________________________________________________________________________________ Ported TDMS software for OpenVMS - Alpha (Alpha TDMS) - I64 (I64 TDMS) Release Notes V2.0-C20060831; September-14-2006 E-Mail: Robert.Sampson@hp.com This document expands on the release notes from VAX TDMS V1.9B. The old DIGITAL document order number is "AA-M062I-TE". This software is now built for both Alpha and I64 platforms using the same source code and build procedures. All source and build changes that were required for the I64 TDMS porting effort are either fully compatible with Alpha TDMS, or conditionally compiled and executed for the correct target platform. As of this writing, the HP TDMS Porting Services Team offers remedial support for the use of its ported TDMS software on the following OpenVMS platforms: OpenVMS Release TDMS Software Debuted Support OpenVMS =============== Release to be on This Offered Platform Build Target Supported Target Thru Please Note! ======== ======= ======= ============== ======= ======= ================ AXPVMS V7.2-2 V7.2-2 V1.9-20031201C 2003-12 2005-12? no new support AXPVMS V7.2-2 V7.3-1 V1.9-20031201C 2003-12 2005-12? no new support AXPVMS V7.2-2 V7.3-2 V1.9-20031201C 2003-12 2007-02? ongoing support AXPVMS V7.2-2 V7.2-2 V8.2-B20050228 2005-02 2005-12? no new support AXPVMS V7.2-2 V7.3-1 V8.2-B20050228 2005-02 2005-12? no new support AXPVMS V7.2-2 V7.3-2 V8.2-B20050228 2005-02 2007-02? ongoing support AXPVMS V7.2-2 V8.2 V8.2-B20050228 2005-02 2008-02? no new support I64VMS V8.2 V8.2 V8.2-B20050228 2005-02 2008-02? no new support AXPVMS V7.2-1 V8.2 V2.0-C20060831 2006-08 2009-08? current versions AXPVMS V7.2-1 V8.3 V2.0-C20060831 2006-08 2009-08? current versions I64VMS V8.2-1 V8.2-1 V2.0-C20060831 2006-08 2009-08? current versions I64VMS V8.2-1 V8.3 V2.0-C20060831 2006-08 2009-08? current versions We plan to continue accepting problem reports for Alpha TDMS V1.9-20031201C running on OpenVMS Alpha V7.3-2, either until another Alpha TDMS release is required to correct problems, or until PVS is discontinued for the platform; whichever occurs first. In order to avoid encountering known and corrected bugs, all current and recommended ECO kits should be installed promptly on each OpenVMS system. Sustaining Engineering no longer offers Prior Version Support (PVS) for OpenVMS Alpha V7.2-2. PVS will not be offered at all for OpenVMS Alpha V7.3-1. At least two years of PVS is planned (with the entry date yet to be determined) for OpenVMS Alpha V7.3-2. The HP TDMS Porting Services Team can effectively test and support its ported TDMS software on only a few distinct platforms at any given time. We no longer offer support for the use of Alpha TDMS on versions of OpenVMS Alpha older than V7.3-2, although requests from any current support customers who are still running on V7.2-2 or V7.3-1 will be honored on a best-effort basis through 2005. OpenVMS I64 V8.2 is the first release for HP Integrity Servers on which we offer support for the use of I64 TDMS. We provide remedial support only to evaluators and paid support customers for licensed systems. Renewals may or may not be offered for each calendar year. This support plan is subject to change, and does not constitute any specific commitment. Purchasers of licenses and remedial support renewals receive written notice of a specific support commitment, to be provided through the end of either the current or the next calendar year, as agreed at the time of purchase. If any of these support plans present any problems, please inform the HP TDMS Porting Services Team as soon as possible. The information in this document is subject to change without notice and should not be construed as a commitment by Hewlett-Packard Company. Hewlett-Packard Company assumes no responsibility for any errors or omissions in this document. At the time of each revision, the author believes that the information in this document is both correct and complete. Please report any errors or omissions by e-mail to "Robert.Sampson@hp.com". The TDMS software described in this document is proprietary to, and embodies the confidential technology of, Hewlett-Packard Company. Possession, use, or copying of this software and media is authorized only pursuant to a valid written licensing or contractual agreement with Hewlett-Packard Company. This software has never been released as a product. Support is provided only under the specific terms of a valid written contract with Hewlett-Packard Company. No responsibility is assumed for the use or reliability of software or equipment that is not supplied by Hewlett-Packard Company. Hewlett-Packard Company makes no representations that the interconnection of its products and services in the manner described in this document will not infringe existing or future patent rights, nor do the descriptions contained in this document imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. These release notes describe software intended only for specific approved and tested use by specific authorized and licensed customers. Hewlett-Packard Company makes no warranties, expressed or implied, regarding the merchantability or fitness of its software for any use whatsoever, except as may be provided for supported products (e.g. for VAX TDMS) by a warranty, support agreement, or Software Product Description, or as may be provided for services (e.g. for ported TDMS software) under a contract. Hewlett-Packard Company may, at its option, agree to meet the terms of specific acceptance criteria. Hewlett-Packard Company shall incur no liability whatsoever for any damages that may result from the use of its software, except as specified by an applicable and valid written agreement. Otherwise, the user assumes any and all risks. © 2006 Hewlett-Packard Company. All Rights Reserved. The following are trademarks of Hewlett-Packard Company. Most of them were acquired as assets of the former Compaq Computer Corporation and Digital Equipment Corporation: OpenVMS, VMS, VMScluster, VMSmail; VAX, VAXcluster, VAXmail; Alpha, AlphaServer, AlphaStation; DIGITAL, DECscheduler, DECmessageQ, DECnet, DECtrace; and the DIGITAL, Compaq, HP, and Hewlett-Packard logos. Other trademarks and registered trademarks are the property of the respective holders. ________________________________________________________________________________ Contents Preface 1 New Features and Technical Changes 1.1 TDMS in the Year 2000 and Beyond 1.1.1 The Sliding Date Window Enhancement 1.1.2 Before and After the Sliding Window Enhancement 1.2 New Features for TDMS Version 1.9 1.2.1 License Management Facility 1.2.2 New TDMS EXIT HANDLER 1.3 New Features for ported TDMS software 1.3.1 Optional optimized shareable image provided 1.3.2 TDMS$ALLOW_SIGNAL_FROM_MSGS enables "-CMU-I-SIGNAL_FROM" messages 1.3.3 Kits are provided in PCSI format 1.3.4 TDMS forms may be displayable from Datatrieve 1.3.5 Online TDMS documentation is provided with kits 1.4 Customer Reported Test Results 1.4.1 JFA (travel reservations software) 1.4.2 SHG (travel agency; uses JFA software) 1.4.3 DSFA (national government social services) 1.4.4 LO&C (private bank) 1.5 Significant Technical Changes for ported TDMS software 1.5.1 Context for AFK ASTs 1.5.2 Object files for FDU FED memory-resident forms 1.5.3 THD component 1.5.4 Quadword integer math 2 Problems Corrected 2.1 Corrections for TDMS Version 1.9 2.1.1 Possible Loss of Data using Vertical Traversal 2.1.2 Displaying Fields in Scrolled Regions 2.1.3 Correction of Date/Time Select Access Violation 2.1.4 Correction for Deleting Non-existent Field Validation 2.1.5 Correction of Pasting to Scrolled Area 2.1.6 Correction of Quadword Range Specfication 2.1.7 Correction of TDMS FORM Date Entry 2.1.8 Astprm Parameter for TSS$DECL_AFK Calls now Optional 2.1.9 TSS$CANCEL Problem 2.1.10 RDB Example 2.1.11 RDU SPAWN Example 2.2 Corrections for Alpha TDMS Version 1.9B 2.2.1 2001-10-12: ACCVIO in ARY014, DEF_KEY1, MOD03; invalid negative loop increment 2.2.2 2001-10-24: ACCVIO in TSS_21555; linkage problem with AFK AST as initially ported 2.2.3 2001-10-29: Could not install Alpha TDMS kit; no TDMS or CDD-PLUS license 2.2.4 2001-11-13: Field validators were not working; invalid data structures were generated by aligning variables 2.2.5 2001-11-21: TOOFEWARG in BASIC AST routines for OpenVMS Alpha before V7.2-2 2.2.6 2001-11-21: TSS$OPEN failure in OPN002, OPN010; THD stack size was too large 2.2.7 2001-12-03: ACMS/ENTER and ACMS/DEBUG would hang with TDMS present; THD synchronization was not working 2.2.8 2001-12-04: Last double-wide or double-size form line was shown normal-size; invalid data structures were generated by aligning variables 2.2.9 2002-01-03: CONVERR in TSSCNL; PASCAL sources improperly declared record argument 2.2.10 2002-01-08: Blank date fields in DAT002; problem with quadword integer math as initially ported 2.2.11 2002-01-14: PASCAL application failure; no PACKED prefix for %DICTIONARY array fields; new default alignment did not match TDMS and ACMS for VARYING STRING 2.2.12 2002-01-25: SYS$LIBRARY:ACMSREQ.RLB was missing on Alpha 2.2.13 2002-07-08: "OUTPUT %TOD" in request definition consistently caused RDU failure; RDU$CREATE_TOD_FIELD_REF called RDU$ALLOCATE_REF with a different third argument 2.2.14 2003-01-28: Date or time input conversion often produced corrupted values; caused by both old and new coding errors 2.3 Corrections for Alpha TDMS V1.9-20031101C 2.3.1 2003-09-02: ACCVIO occurred in TSS$SIGNAL for any saved signal vector with more than one argument 2.3.2 2003-11-01: Circular help form reference consistently caused RDU failure; preset pointer value was valid on VAX, but not Alpha 2.4 Corrections for Alpha TDMS V1.9-20031107C 2.4.1 2003-11-07: File locations were not specified by [SYSHLP.EXAMPLES.TDMS]TDMSBLDSAMPLE.COM 2.4.2 2003-11-07: New TDMS shutdown command procedure [SYSMGR]TDMSHUTDOWN.COM 2.5 Corrections for Alpha TDMS V1.9-20031201C 2.5.1 2003-11-13: TRACALL and TRARET trace messages did not display routine names after early I64-related porting changes 2.5.2 2003-11-18: Compile errors from BASIC source files in TDMS$EXAMPLES; caused by an attempt to reduce the number of RDU warning messages 2.5.3 2003-11-21: Spurious "internal range conversion" message from FDU; variable too small for H-float datum in FDUSTRNUMCMP.C 2.5.4 2004-03-12: TDMSBLDSAMPLE.COM problems with evaluation license 2.6 Corrections for I64 TDMS E8.2-20040908A 2.6.1 2004-08-17: FDU FED ACCVIO; routine UAR$FIELD_DONE improperly declared 2.6.2 2004-08-30: CONVERR/NONPRICHA application failures; table TSS$GZ_NON_PRINTABLE_CHAR_TABLE improperly declared 2.6.3 2004-09-03: ACCVIO at PAG$AFK_AST line 1167 in TSS_21555; AFK AST delivery transfer problem as initially ported 2.6.4 2004-09-06: ACCVIO at TIO$OUT line 693 in TSS_21555; problem with "thread" context in exit handler 2.7 Corrections for I64 TDMS E8.2-20040920B 2.7.1 2004-09-20: %ILINK-I-DIFTYPE for function THD$KPS_START 2.7.2 2004-09-20: %ILINK-I-DIFTYPE for function LIB$INITIALIZE 2.8 Corrections for I64 TDMS V8.2-20050131A 2.8.1 2005-01-11: Kit rebuilt due to incompatible change in linker output 2.9 Corrections for TDMS V8.2-A20050228 (Alpha and I64) 2.9.1 2005-02-22: New TDMS$TOLERANT logical name 2.10 Corrections for TDMS V8.2-B20050228 (Alpha and I64) 2.10.1 2005-02-28: Maximum "threads" changed back to 4096 2.10.2 2005-02-28: Now using common source code and build procedures 2.11 Corrections for TDMS V2.0-C20060831 (Alpha and I64) 2.11.1 2006-08-31: Problem with TDMS license fixed 3 Restrictions 3.1 Incompatibility with Previous Versions 3.2 Command Line Editing Turned Off 3.3 Converting FMS Forms to TDMS Forms 3.4 Terminal Hang in XOFF Mode 3.5 Optional Parameter for TSS$DECL_AFK 3.6 Clearing the Event Flag on Asynchronous TDMS Calls 3.7 Optional Parameters for Asynchronous Calls 3.8 TDMS Exit Handler 3.9 Microcode Problem with VT100 Terminals 3.10 RDU Return to DCL Level 3.11 Enqueue Limit Problem in Building Request Library Files 3.12 TDMS Floating-Point Support 3.13 TDMS D-Format Floating-Point Problem 3.14 Type-Ahead Buffer Overflowing 3.15 PASCAL and Parameter Passing 3.16 TDMS Supported Terminals 3.17 Calls to TDMS and DATATRIEVE 3.18 Accessing a CDD Node That Has an Associated Password 3.19 Uncorrected Hardcopy Documentation Errors 3.20 Indexed fields restriction in FDU 3.21 Horizontally indexed field restriction in FDU LIST 3.22 Abnormal Exits [CONTROL/Y] from TDMS Applications 3.23 New default number of created threads and default stack size for each created thread 3.24 Using TDMS with ACMS 3.24.1 ACMS logical names and ACMSGEN parameters 3.24.2 Use of multiple screen managers 3.24.3 CP's die if TSSSHR is present but license key is expired or missing 3.25 TDMS software is limited to 32-bit addressing and call arguments 3.26 Obtaining support for ported TDMS software 3.27 Required and recommended software versions 4 Known or Suspected Problems or Limitations 4.1 Incorrect error reporting of undeclared field in request file 4.2 Incorrect Location Specified of File Installed on Your System 4.3 VAX H-float format is not fully supported by the OpenVMS Alpha and OpenVMS I64 language compilers 4.4 Available related OpenVMS solutions; former DIGITAL products, etc. 4.4.1 PL/I compiler 4.4.2 DIBOL compiler, translator, support and programming services 4.4.3 Oracle Rdb and CDD/Repository 4.4.4 Freeware; BLISS, SDL, etc. 4.4.5 Software Partners Solution Index 4.4.6 Partner Products & Services Catalog 4.5 AST routines may require change for old OpenVMS Alpha versions 4.6 Floating values get truncated (not rounded) by default when converted to (packed and/or fixed) decimal formats 4.7 Compiler command qualifiers can help with VAX source code compatibility 4.8 Compilers can "break" working VAX code by aligning or rearranging variables 4.9 Performance and compatibility issues for ported applications 4.9.1 Alignment faults 4.9.2 VAX floating-point formats on OpenVMS I64 and Alpha 4.9.3 Leading blanks may be displayed after decimal point 5 Guidelines for Submitting a Software Problem Report ________________________________________________________________________________ Preface This manual contains a description of various features and limitations of Terminal Data Management System (TDMS) software. It describes changes that correct problems in previous versions, and it gives guidelines for submitting a software problem report. Intended Audience This manual is intended for all TDMS users. The information in the release notes affects all components of TDMS and applications that run TDMS. Operating System Information VAX TDMS V1.9B is compatible so far with all current and supported versions of OpenVMS VAX. Mature Product Support (MPS) is still available at this writing, but may be withdrawn with notice posted on the web: http://h71000.www7.hp.com/serv_support.html (under the heading "For more information":) Prior Version Support - Europe Prior Version Support - Americas/Asia Pacific http://www.hp.com/hps/os/os_pvs_amap.html (redirects you to the top of one of these pages:) http://h20219.www2.hp.com/services/cache/11779-0-0-225-121.aspx#Dp (Americas/Asia Pacific) http://h20219.www2.hp.com/services/cache/11810-0-0-225-121.aspx#Prime (Europe) Ported TDMS software is provided only under contract, and only in the form of services, not products. Please check the title page of these release notes for the list of platforms on which we currently plan to offer support for the use of our ported TDMS sofware. Please check the web for the current support status of each OpenVMS operating system platform (architecture and version): http://h71000.www7.hp.com/openvms/openvms_supportchart.html Structure This manual is divided into five chapters: Chapter 1 Contains information on new and previous features and technical changes in TDMS. Chapter 2 Contains information describing the TDMS problems corrected since Version 1.9. Chapter 3 Contains information describing TDMS restrictions. Chapter 4 Contains information describing known problems with this version of TDMS. Chapter 5 Contains information for submitting a software problem report. Related Manuals The following manuals contain further information on the topics covered in this book: o TDMS Forms Manual o TDMS Request and Programming Manual o TDMS Reference Manual o OpenVMS documentation set Conventions The following special symbols are used in this book: Color Color in examples shows user input. $ The dollar sign represents the DIGITAL Command Language (DCL) prompt. Your DCL prompt may be different. References to Products This manual may refer to HP, Compaq, DIGITAL, and Oracle products with abbreviated names. If Oracle CDD/Repository software is installed on your system, references in this manual to the "Common Data Dictionary" or "CDD" refer to the DMU format dictionary. CDD/Repository supports dictionary definitions in two distinct formats: o DMU format - dictionary definitions that you can create and manipulate with the DMU, CDDL, and CDDV utilities, and other products that do not support the new features of CDD/Repository. o CDO format - dictionary definitions that you can create and manipulate with the CDO utility, the CDD/Repository call interface, and other supporting products. You can create and manipulate definitions that you intend to use in your TDMS applications in the DMU format dictionary using DMU, CDDL, CDDV, and other products that do not support the new features of CDD/Repository. Your site may have products that support the new features of CDD/Repository. If so, you may benefit by using these products to create definitions in the CDO format dictionary. These definitions can be read by both your TDMS applications and the products that support the new features of CDD/Repository. For more information on the DMU format dictionary, CDO format dictionaries, and CDD/Repository in general, see the Oracle CDD/Repository User's Guide. 1 ________________________________________________________________________________ New Features and Technical Changes The key functionality of TDMS has not changed from version 1.9 or from the subsequent mandatory update version 1.9A. This version of the TDMS software incorporates a sliding date window enhancement that provides customers with more flexibility in resolving TDMS Year 2000 problems. 1.1 TDMS in the Year 2000 and Beyond TDMS supports several formats of date field on its forms. These include 2-digit and 4-digit year date formats. TDMS validates date fields and translates all date fields formats into the standard OpenVMS binary date format which is then passed to the application. In order to successfully translate 2-digit year date fields into their corresponding binary format, TDMS has to supply the missing 2 digits of the year (that is, the century digits). TDMS has always used the century digits as specified by the system clock. This is entirely consistent with the way that incompletely specified dates are interpreted in OpenVMS. At the turn of the century, the behavior of TDMS as described above will mean that 2-digit year dates from the screen will be interpreted differently. All 2-digit year dates will be processed as being in the 21st century, exactly 100 years later than previously. 1.1.1 The Sliding Date Window Enhancement TDMS now uses a sliding date window enhancement for the translation of TDMS 2-digit year dates. This enhancement allows for the modification of the behavior of TDMS so that the century digits applied to a 2-digit year date may be based on a customer specified value. On each occasion TDMS is required to expand a 2-digit year date it will attempt to translate a logical name called TDMS$BASE_YEAR. Valid values for this logical name are 4-digit numbers in the range 1859 - 9900. TDMS searches the PROCESS table followed by the GROUP table and finally the SYSTEM table and will use the first valid value found. If no valid translation of the TDMS$BASE_YEAR logical is found then the behavior of TDMS in processing 2-digit year dates remains exactly as in previous versions of TDMS. This 4-digit number resulting from a valid translation of the TDMS$BASE_YEAR logical name is used by TDMS to define the first year of a 100 year window in which all 2-digit year dates fall. For example, a value of 1980 defines a 100 year date window of 01-JAN-1980 to 31-DEC-2079. Customers who wish to have TDMS continue to translate 2-digit year dates in the 20th century should set the TDMS$BASE_YEAR logical to the value 1900 while customers who wish to have TDMS behave exactly as before should not define the logical name. 1.1.2 Before and After the Sliding Window Enhancement The following Table illustrates the behavior of TDMS in translating two-digit years without the sliding date window enhancement. __________________________________________________________ Field System Contents____Clock_______Value_Received_by_Application_____ 12/25/68 20th 25-DEC-1968 Century 12/25/68 21st 25-DEC-2068 ____________Century_______________________________________ The following Table illustrates the behavior of TDMS in translating two-digit years with the sliding date window enhancement. __________________________________________________________ Field System Value Received by Contents____TDMS$BASE_YEAR__Clock_______Application_______ 12/25/68 Undefined or 20th 25-DEC-1968 Invalid Century 12/25/68 Undefined or 21st 25-DEC-2068 Invalid Century 12/25/68 Defined=1958 Any 25-DEC-1968 Century 12/25/68 Defined=1968 Any 25-DEC-1968 Century 12/25/68 Defined=1978 Any 25-DEC-1968 Century 12/25/68 Defined=1900 Any 25-DEC-1968 ____________________________Century_______________________ 1.2 New Features for TDMS Version 1.9 The sections that follow describe the additions and changes to TDMS for Version 1.9. 1.2.1 License Management Facility Beginning with VAX TDMS V1.9 and OpenVMS VAX V5.0, TDMS software requires a license key. Before installing TDMS software, you must first obtain, register, and load an appropriate license key for each licensed system. License Management Facility (LMF) is used to register, manage, and track software licenses on OpenVMS systems. LMF includes the DCL LICENSE command and the SYS$UPDATE:VMSLICENSE.COM command procedure. For more information on registering and loading your license key, please refer to the appropriate TDMS Installation Guide. For complete information on using LMF, please refer to the OpenVMS License Management Utility Manual, available on the web at http://h71000.www7.hp.com/doc/index.html . The minimum license for running TDMS applications developed on another system is TDMS-RT; the license for full development use is TDMS; on OpenVMS VAX,Alpha, or I64 respectively. Ported TDMS software is priced differently for each of three system tiers; "W" for a Workstation with only one CPU, E for an Enterprise server with two to seven CPUs, and G/Q for a "Global" server with eight or more CPUs. For purchasing help, contact your local HP sales office, and e-mail Dave.Lewis@hp.com . VAX TDMS requires a CDD-PLUS license, but ported TDMS software does not, since Oracle Corporation no longer makes use of it. However, before any TDMS kit can be installed, except for the ported TDMS software run-time only (RTO) kits, the CDD Repository product from Oracle must first be installed and running. 1.2.2 New TDMS EXIT HANDLER The TDMS EXIT HANDLER has been enhanced for Version 1.9. TDMS establishes an EXIT HANDLER that is invoked at image rundown. This EXIT HANDLER resets terminal characteristics for those devices that did not perform a tss$close. The characteristics reset are LINE_EDIT and WRAP. In the ACMS environment this EXIT HANDLER can sometimes "hang" waiting for IO to complete to virtual terminals that no longer have physical devices attached to them. This "hang" then causes the ACMS CP process to "hang". To avoid this potential problem, customers may define a logical specifying whether or not TDMS is to invoke the new EXIT HANDLER. The logical "TSS$EXIT_CLEANUP" may be defined to any string beging with the character "y", "Y", "t", or "T", and TDMS will invoke the EXIT HANDLER. If the logical is defined to be anything else, the TDMS EXIT HANDLER will not be invoked. If the logical is not defined (the default) the TDMS EXIT HANDLER will be invoked. ________________________Note ________________________ If the choice to disable exit cleanup is made, terminals that were not closed properly may not be reset to their original characteristics. _____________________________________________________ 1.3 New Features for ported TDMS software 1.3.1 Optional optimized shareable image provided Starting with the 2002-02-01 field test update, both the development kit and the run-time-only kit provide SYS$SHARE:TSSSHR_OPT.EXE. This image is built from object libraries having modules compiled with some optimizations added, and some run-time checks removed. It can optionally be used in place of the standard image, SYS$SHARE:TSSSHR.EXE, which should first be renamed or copied, and retained for future use. The optimized image should be tried only where a need has been established. It should first be determined that excessive TDMS CPU time is a known contributor to an actual performance problem. There is a small, but real, risk that the different code could possibly induce or reveal software problems that are not apparent with the standard image. Therefore, use of the optimized image is not recommended until it has been carefully tested with your applications. 1.3.2 TDMS$ALLOW_SIGNAL_FROM_MSGS enables "-CMU-I-SIGNAL_FROM" messages Starting with the 2002-02-07 field test update, the annoying "-CMU-I-SIGNAL_FROM" messages have been suppressed. They are now normally not displayed at all; neither by FDU, nor by RDU, nor by the TSS$SIGNAL call. However, if desired, and when gathering data for a software problem report, these messages can be enabled by defining the logical name "TDMS$ALLOW_SIGNAL_FROM_MSGS". It can be defined in any of the tables on the "LNM$DCL_LOGICAL" search list. Any valid equivalence name can be used: $ mcr fdu ! without logical name FDU>modify form cholula %FDU-E-ERRLOCNOD, error locking object 'CHOLULA', type 'CDD$FORM' -CDD-E-NODNOTFND, directory or object not found %FDU-E-NOFRMMOD, Form CHOLULA not modified FDU> Exit $ define/user tdms$allow_signal_from_msgs anything $ mcr fdu ! with logical name FDU>modify form cholula %FDU-E-ERRLOCNOD, error locking object 'CHOLULA', type 'CDD$FORM' -CDD-E-NODNOTFND, directory or object not found -CMU-I-SIGNAL_FROM, PC=000E28D4, PS=0000001B %FDU-E-NOFRMMOD, Form CHOLULA not modified -CMU-I-SIGNAL_FROM, PC=000A2FB0, PS=0000001B FDU> Exit $ mcr rdu ! without logical name RDU>modify request tabasco %RDU-E-ERRLOCNOD, error locking object 'TABASCO', type 'CDD$REQUEST' -CDD-E-NODNOTFND, directory or object not found %RDU-E-NOREQMOD, no request modified RDU> Exit $ define/user tdms$allow_signal_from_msgs anything $ mcr rdu ! with logical name RDU>modify request tabasco %RDU-E-ERRLOCNOD, error locking object 'TABASCO', type 'CDD$REQUEST' -CDD-E-NODNOTFND, directory or object not found -CMU-I-SIGNAL_FROM, PC=000948E4, PS=0000001B %RDU-E-NOREQMOD, no request modified -CMU-I-SIGNAL_FROM, PC=000A4264, PS=0000001B RDU> Exit $ run ftexe:scr001 ! without logical name %TSS-F-CONVERR, data type conversion error -TSS-I-TRAOUTPUT, REC001.FORM.RSFLD1[1] of value "....." output to SFLD1[1] -TSS-I-TRAFIELD, REC001.FORM.RSFLD1[1] is length=5, dtype=14, class=9 at %X0010F768 -TSS-I-TRAFIELD, SFLD1[1] is length=5, dtype=14, class=1 at %X0010F780 -TSS-F-NONPRICHA, field contains non-printable characters $ define/user tdms$allow_signal_from_msgs anything $ run ftexe:scr001 ! with logical name %TSS-F-CONVERR, data type conversion error -TSS-I-TRAOUTPUT, REC001.FORM.RSFLD1[1] of value "....." output to SFLD1[1] -TSS-I-TRAFIELD, REC001.FORM.RSFLD1[1] is length=5, dtype=14, class=9 at %X0010F768 -TSS-I-TRAFIELD, SFLD1[1] is length=5, dtype=14, class=1 at %X0010F780 -TSS-F-NONPRICHA, field contains non-printable characters -CMU-I-SIGNAL_FROM, PC=000951EC, PS=0000001B 1.3.3 Kits are provided in PCSI format Starting with V1.9-20031101C, TDMS installation kits are provided in PCSI format. VMSINSTAL kits are no longer provided. This new format makes installation and removal much easier. The kits contain an updated service installation document ("TDMS$EXAMPLES:SERVICE_INSTALL.HTML") that describes the new procedure for kit installation. This file can be extracted from a kit (replace xxx with the kit type; DEV, RTO, or EVA) for browsing prior to installation as follows: $ PRODUCT EXTRACT FILE TDMS_xxx/SELECT=SERVICE_INSTALL.HTML 1.3.4 TDMS forms may be displayable from Datatrieve The Datatrieve for OpenVMS VAX product installation procedure specifically provides an option to build the DTRSHR shareable image in a way that allows Datatrieve to display TDMS forms. Because of an early decision not to offer TDMS software as a product on OpenVMS Alpha, this option was permanently removed from the installation procedure for the Datatrieve for OpenVMS Alpha product. Thus, on both OpenVMS Alpha and OpenVMS I64, the Datatrieve product installation procedure provides the option to display DECforms forms and FMS forms, but not TDMS forms. Acting on customer demand from Ireland and Portugal, an effort was made to restore this feature for Alpha TDMS. A specially-built DTRSHR image was provided. The TSSSHR image was modified to provide all of the required symbols in its symbol vector. A latent problem that prevented TSSSHR from finding the form name requested by Datatrieve in the request library file was also corrected. For the previous Alpha TDMS release (V1.9-20031201C) and Datatrieve V7.2A-2, the specially-built SYS$COMMON:[SYSTEST.TDMS]DTRSHR.EXE shareable image had to be activated instead of the Datatrieve-supplied image. The SYS$COMMON:[SYSTEST.TDMS]DTR_TDMS.COM procedure was used for this purpose, as illustrated by the following example: $ @SYS$COMMON:[SYSTEST.TDMS]DTR_TDMS.COM DTR> DECLARE Y LONG. DTR> DISPLAY_FORM PERSNL_BASIC_ADD_FORM IN TDMS$EXAMPLES:PERSON.RLB - CON> RETRIEVE USING BEGIN Y = GET_FORM PERS_NUMBER ; END ; [ form is displayed; must be completely filled in, then press Enter ] DTR> PRINT Y DTR> EXIT $ These two files (DTRSHR.EXE and DTR_TDMS.COM) have been removed from the E8.2 TDMS software kits. The Datatrieve V7.3 production release is expected to coincide with the OpenVMS V8.2 release for both Alpha and I64. [Hopefully; tbd] Defining the logical name DTR$ENABLE_TDMS [tbd] as [tbd] while building a DTRSHR image during installation or customization will, if all goes well, allow DTRSHR to activate TSSSHR and display TDMS forms. However, just as with ACMS, Datatrieve product management has not made (and will not be making) any new commitment of support; neither to interoperate constructively nor to prevent interacting destructively with TDMS software on any platform other than OpenVMS VAX. Please be aware that this feature is supported only on a best-effort basis, and only by the HP TDMS Porting Services Team. 1.3.5 Online TDMS documentation is provided with kits The VAX TDMS product documentation set is so far still orderable, but only in hardcopy printed form. Unlike most other OpenVMS VAX layered product documentation, it has never been published in the Online Documentation Library (ODL). This hardcopy documentation is rather expensive. It is printed in black ink only, on small paper stock, drilled with three binding holes centered 3.5 inches apart. This format is not suitable for any readily-available standard ring binders. The small custom binders are no longer provided, and they are also expensive to order in the small numbers needed. It was quickly recognized during the initial Alpha TDMS porting effort that a remedy would be needed for this documentation problem. It was decided that converting these hardcopy documents into an online format would provide added value to Alpha TDMS customers. The (incomplete) SDML source files were first converted to HTML format using DECdocument. The segmented HTML files comprising each converted document were merged and reformatted into single, large HTML files, mostly using the extensible OpenVMS EVE editor (DCL EDIT/TPU) with the EDT keypad (EVE SET KEYPAD EDT) and learned key sequences. All of the document art (except three figures) was missing from the available source files, so it was painstakingly re-created from the hardcopy documents by hand-coding HTML tables. The documents were then proofread and compared with the hardcopy. The relatively few differences were reconciled. The relatively few errors found were corrected, regardless of their source. This conversion process required at least 301 hours of effort. After installing a ported TDMS software PCSI kit, these documents can be found in "SYS$COMMON:[SYSHLP.EXAMPLES.TDMS]*.HTML". The TDMS startup procedure "SYS$COMMON:[SYSMGR]TDMSTRTUP.COM" defines the system logical name TDMS$EXAMPLES for this directory. Use a web browser (Mozilla is now preferred over Netscape for OpenVMS) to open the file "TDMS$EXAMPLES:INDEX.HTML". It provides convenient links to the six HTML documents: VAX TDMS Pocket Guide ("POCKET.HTML") VAX TDMS Installation Guide ("INSTALL.HTML") VAX TDMS Forms Manual ("FORMS.HTML") VAX TDMS Request and Programming Manual ("REQUEST_AND_PROGRAMMING.HTML") VAX TDMS Reference Manual ("REFERENCE.HTML") Alpha/I64 TDMS Service Installation Guide ("SERVICE_INSTALL.HTML") The last document is a revised version of the installation guide. For Mozilla on OpenVMS, use the "Open File..." dialog (Ctrl+O is a shortcut) to navigate down to this file. From the top level (a list of disk device names), select the system disk. Then select "sys$common" (or "vms$common"), "syshlp", "examples", "tdms", and finally, "index.html". This ensures that the links will work with Mozilla. All current licensees are permitted to copy these HTML files as text to a favorite desktop or notebook computer, for viewing with the available web browsers. Because these documents are formatted as very large single web pages, there is typically a noticeable delay (perhaps even seconds) while the browser loads them. Once loaded, though, each document's internal links (e.g. Contents and Index) should provide quick random access. In the Forms Manual, some of the examples contain Javascript. If this is supported by the browser, video blinking effects are active when the mouse pointer is positioned over some of the simulated terminal displays. Figure 6-3 is perhaps the most striking example. Some browsers, such as Mozilla, require the installation of a plug-in to support this feature. 1.4 Customer Reported Test Results 1.4.1 JFA (travel reservations software) One problem was reported; RDU failed on OUTPUT %TOD. This was fixed in the 2002-07-08 software update. Please see section 2.1.1.7 for more information. The JFA test plan submitted for field test exceeded the acceptance criteria. Testing was started on Monday 2002-06-24, and ended on Wednesday 2002-07-24. JFA reviewed the HTML TDMS documents and suggested changes. JFA executed its field test plan on a VMScluster with an AlphaServer DS10 called HEFA, possibly a DS20, and a VAX 4000-600A. The FATS tour operator's reservation system is written in Cobol. It uses both DBMS and Rdb databases (now Oracle products). It also uses ACMS; the majority of screens are called as exchange steps, but a few programs use direct calls to TDMS and do not use ACMS tasks. The maximum number of users who concurrently tested FATS was twelve. JFA achieved its stated goals: o Primarily test the software from the developer's standpoint, with emphasis placed on using RDU and FDU to build FATS. o Also test the resulting FATS run-time system for correct operation and acceptable performance, on behalf of some end-user customers. o Test the use of existing request libraries (already built with VAX TDMS RDU) to run on the Alpha platform, with both ACMS EXCHANGE steps and direct TSS$ calls. o Rebuild all requests and request libraries from scratch using Alpha TDMS RDU, and test the use of these on Alpha. o Test FDU to design a limited number of new screens, then build and test requests which use these screens. o After JFA testing is complete, work with Compaq/HP to invite an end-user customer (SHG) to participate, testing run-time Alpha TDMS with FATS. JFA followed its stated test schedule as closely as possible: o Installation (½ day) o Test FATS functions on Alpha using existing VAX request libraries (3 days) Function Description Forms Requests Invoked by ======== ==================== ===== ======== ============= * GENAVAIL bookings process ~20 40 ACMS Exchange * AFLIGHT flights maintenance 2 5 TSS$ calls * HOLCAT brochure maintenance 2 6 TSS$ calls * QUOTAS accommodation quotas 5 10 TSS$ calls * LOCATION geographical data 16 20 ACMS Exchange * Other functions, as time permitted o Build request libraries on Alpha using MMS; check logs (1 day) o Test even more FATS functions with the new request libraries (4 days) o Use FDU to create new forms, and RDU to create a new request library, then test (4 days) * Create a GENAVAIL bookings main view form called CM0041_F01 * Create a HOLCAT form called SU33_F01 * Create a QUOTAS room allocation screen JFA acceptance and performance criteria were tested and met as stated: o Screen displays appear the same as with VAX TDMS. o Tour operator reservation process works correctly, producing valid holiday bookings. o FDU form editor and RDU behave as with VAX TDMS. o RDU build timings showed performance similar to VAX TDMS. o Migration: Forms and request libraries can be moved unmodified from VAX to Alpha. o Compatibility: Request libraries are compatible between platforms. o Stability: No failures of forms editor or run-time calls. A reported RDU bug was fixed. o Responsiveness: Performance was at least equal to VAX, when the same data was compared on two screens side by side. Screens are painted with no visible delays. o Scalability and Concurrency: The FATS system works with multiple users. o UK features (such as dates in DD-MM-YY format) work correctly. o TDMS works under ACMS with applications running both on local and remote nodes. o Direct TSS$ calls work as with VAX TDMS. Two development licenses were purchased in late March 2003. 1.4.2 SHG (travel agency; uses JFA software) The SHG test plan submitted for field test met the acceptance criteria. Testing was started on Monday 2002-08-05, and was believed to have ended by the end of September 2002. SHG is an end user of the JFA FATS travel reservations system. It tested the run-time-only Alpha TDMS kit, strictly as it will be deployed and used as an integral component of FATS. It did not test the development kit (FDU and RDU) at all. Within the first week, tests had been run on all components of FATS that use TDMS, except for XTRALOAD. No problems were found. NEWPRICE uses DECforms (not TDMS), and could not be tested, for lack of a suitable DECforms license. SHG made a TDMS test run with about twenty reservations users logged in at the same time. Assistance from JFA was awaited and provided. After that, 25 people began using the system in a live environment. No problems were reported. Then, 25 more users were added, for a total of 50 users in the live environment. Adding more users was planned. Two run-time only licenses were purchased in late April 2003. 1.4.3 DSFA (national government social services) Testing was started on Wednesday 2002-07-17, and ended on or about Friday 2002-08-30. DSFA conducted its field test in parallel with migrating its applications from VAX to Alpha for the first time. Martin Brennan provided on-site assistance with both efforts. No remote assistance was requested. Alpha TDMS was installed on the test system. A reasonably small, simple application was selected as the first to be ported, and was built on Alpha. All fields were checked to ensure that they worked and performed the same way as on the VAX systems, using the same database. Regression testing was performed to ensure that the same results were obtained on both VAX and Alpha. Updates, etc. were tested using an exact copy of the VAX database on the Alpha. The development team reported early that it was very pleased with the results. No problems were encountered with Alpha TDMS; expected results were achieved for all cases tested. Some more complicated TDMS forms and ACMS workspaces (using arrays, signed numeric fields, linked lists, etc.) were selected for testing. The same methods were used to test all cases against the VAX version of the same application. Another application was cleanly built on Alpha. The testers checked it for consistency and performed regression testing, in the same manner as before. A preliminary performance test was conducted with about 25 concurrent users. Due to the good performance results, the decision was made to defer a planned full stress test until after completing the field test. A recommendation was to be made whether to proceed with the TDMS migration to Alpha. The recommendation was positive. An initial development license was purchased in late April 2003. 1.4.4 LO&C (private bank) Testing was started on Wednesday 2002-07-17, and ended on Tuesday 2002-07-23. Three applications were built and tested, and a few forms were modified. Unspecified standard approval tests were performed, unfortunately without involving any users. No problems were encountered. This was considered good news for the firm, since TDMS had been the main reason for maintaining the remaining VAX 10000 systems. Holidays and late planning prevented further contribution to the field test. A decision was made to indefinitely defer migration of the VAX environment, and communicated in late May of 2003. However, these migration plans were eventually revisited. Three licenses were purchased in late January 2004. 1.5 Significant Technical Changes for ported TDMS software 1.5.1 Context passing for AFK ASTs VAX TDMS implements PAGCHN context passing for AFK (application function key) ASTs (asynchronous system traps) by providing a transfer vector (consisting of entry register save mask and jump instruction with address fixup) at the start of each PAGCHN context data structure. The context is then fetched from a known relative offset on the stack. Over several months in late 2001, with some guidance from OpenVMS Engineering and the Calling Standard documentation, this context passing mechanism was ported to Alpha TDMS, by replacing the VAX transfer vector with an Alpha bound procedure descriptor at the start of each PAGCHN context data structure. A short Macro-64 transfer routine provides the PAGCHN address (bound procedure descriptor address from R27) to the AST routine as the sixth actual argument in R21. The argument count (low byte of AI/R25) is also filled in with the value six. Names and attributes of code psects are specified so that the linker places the transfer routine code immediately before the AST code, eliminating load and jump instructions. This results in an efficient implementation of AFK ASTs which is compatible with the Alpha calling standard. Please refer to section 2.2.2 for further details. Over about ten days in early 2003, with further guidance from OpenVMS Engineering, a similar mechanism was used for I64 TDMS, which was actually simpler to implement. The Alpha bound procedure descriptor was replaced by the I64 bound function descriptor. A transfer routine called OTS$JUMP_TO_BPV is already provided by OpenVMS I64, specifically for use with bound function descriptors. The context is passed to the AST in R9 by specifying special linkage. Over a few days in late 2004, regression testing uncovered a problem with the bound function descriptor, and the problem was corrected. Please refer to section 2.6.3 for further details. 1.5.2 Object files for FDU FED memory-resident forms VAX TDMS implements memory-resident forms for the FDU form editor (FED) by using a utility program called FDVCDDOBJ to package each TDMS form from the CDD into an OpenVMS VAX object file. The linker is then used to assemble the forms into a linked list in the FDU program. Over about one week in May 2001, FDVCDDOBJ was converted to generate object files in the OpenVMS Alpha format. Over about one month in April and May 2003, with some guidance from OpenVMS Engineering, FDVCDDOBJ was converted to generate object files in the OpenVMS I64 (ELF) format. The source code has been modified to compile correctly for any of three recognized target platforms: VAX, ALPHA, or IA64. 1.5.3 THD component VAX TDMS implements a simple form of "threading" (actually more like context switching using co-routines) with its THD component, which is very similar to (and very compatible with) the ACMS product's THD component on OpenVMS VAX. From late May through late November 2001, an attempt was made (with reasonable success) to re-implement TDMS THD using POSIX threads, a.k.a. pthreads, formerly DECthreads. This also required extensive changes for thread-awareness. Not much effort was expended to investigate or test for potential thread-safety issues. Very early during initial field test, the pthreads implementation was abandoned (or at least set aside), in order to provide interoperability with the ACMS product on OpenVMS Alpha. Please refer to section 3.23 for further details. Fortunately, ACMS Engineering kindly provided its ACMS THD OpenVMS Alpha source code for Alpha TDMS THD. Over about one week in November 2001, the ACMS Alpha THD was integrated into Alpha TDMS. From mid-May through mid-November 2003, possible strategies were discussed with the ACMS and OpenVMS Engineering groups, for porting the THD component to OpenVMS I64. On a few occasions, attempts were made to perform some of this porting work. As OpenVMS Engineering had advised, ACMS Engineering ported its ACMS THD to OpenVMS I64, using the newly-enhanced OpenVMS KPS routines, and again kindly provided the source code for I64 TDMS THD. No low-level machine language was required for this new implementation, aside from the OpenVMS KPS routines themselves. This improves on the VAX and Alpha THD implementations, which depend heavily on Macro-32 for their implementations. The I64 THD also appears to be highly portable to OpenVMS Alpha V8.2 or higher. In the event of any compelling need, it could most likely easily replace the existing Alpha THD. Within one day in June 2004, the ACMS I64 THD was easily "dropped" into I64 TDMS. 1.5.4 Quadword integer math The VAX TDMS source code was written almost entirely in Bliss-32, a language dialect that has no direct support for operations on quadword integers. VMS date conversions make use of quadword integer math. VAX TDMS performed divide and multiply operations on these by calling the undocumented COB$DIVQ_R8 and COB$MULQ_R8 COBOL language support run-time library routines with special JSB linkage. These routines are not available for the use of native OpenVMS Alpha code. The initial attempt during April 2001 to replace them with in-line Bliss-32 code did not work properly. Please refer to section 2.2.10 for further details. One day in January 2002, the DIVQ and MULQ replacement routines were implemented in C for Alpha, but unfortunately with coding errors that went undiscovered for about a year. One day in January 2003, in response to a problem report from an HP employee, these coding errors were finally corrected, along with two other software problems that had interfered with some of the date conversions. Please see section 2.2.14 for further details. Porting to I64 did not require any further changes to these routines. 2 ________________________________________________________________________________ Problems Corrected This chapter describes corrections in TDMS after Version 1.7, for problems that existed in previous versions of TDMS, and for problems associated with porting the software to Alpha and I64. 2.1 Corrections for TDMS Version 1.9 2.1.1 Possible Loss of Data using Vertical Traversal In previous versions of TDMS, requests could experience field data loss if all of the following conditions are true. 1. The request contains a USE FORM request display instruction and does not contain a DISPLAY FORM request display instruction. 2. The request defined the UP_FIELD or FIRST_FIELD functions using Defined Key Functions. 3. The TDMS form is defined with non-default input field ordering. For example, input starts with the bottom-most form field instead of the top and left most form field. 4. The DONE function key is pressed after vertically traversing fields using the UP_FIELD or FIRST_FIELD function without entering data into fields. Some data field values previously displayed when the USE FORM request was performed may be returned to the user application as nulls, (binary zeroes). This could also cause a data conversion error if an attempt to display the "nulled" field value were made in a subsequent request. 2.1.2 Displaying Fields in Scrolled Regions In previous versions of TDMS the following requests did not work on scrolled regions: BLINK FIELD %ALL, BOLD FIELD %ALL, DEFAULT FIELD %ALL, RESET FIELD %ALL, RETURN FIELD %ALL, REVERSE FIELD %ALL, and UNDERLINE FIELD %ALL. This problem has been corrected. Displaying default field values in a scrolled region previously failed in the following circumstances: o The field was a scrolled-region. o The request specified a form field instruction in conjunction with an %ALL mapping. o No previous INPUT/OUTPUT mapping occurred in the request to fill the bounds. Default field values now display correctly in scrolled regions under the previous conditions. 2.1.3 Correction of Date/Time Select Access Violation Previously, an access violation would occur during the layout phase in FDU after initiating selection with , then typing a space, then entering GOLD T or GOLD D. This has been corrected. FDU now behaves as expected by including the time or date field as part of the user selected area. 2.1.4 Correction for Deleting Non-existent Field Validation After selecting the layout phase from the FDU menu, a user may place the cursor on the field and delete its validator by using GOLD ENTER to bring up the validator menu. Option 14 deletes existing field validators so that new ones can be applied. Previously, if option 14 was entered without a field validator existing, selecting this option would result in an access violation. This has been corrected. FDU now returns to the form without displaying an error message regardless of whether the validator exists or not. In the case where the validator does not exist, nothing happens. The user is simply returned to the form. In the case where the validator does exist, it is deleted as expected and then the user is returned to the form. 2.1.5 Correction of Pasting to Scrolled Area In the previous version of TDMS an ACCVIO error was generated upon exiting FDU if the user CUT a field from the form and PASTEd it into an existing scrolled region. If the field was inserted twice, the process entered an infinite loop. This problem has been corrected. FDU no longer access violates or loops. The new behavior is for FDU to signal an error (ring the terminal bell) and ignore the paste instruction. 2.1.6 Correction of Quadword Range Specfication In previous versions of TDMS, if Quadword Integer is specified in the Validators menu, the internal values generated for the range check were: -9723372036854775808 through 9723372036854775807 This has been corrected. The range check values are now: -9223372036854775808 through 9223372036854775807 2.1.7 Correction of TDMS FORM Date Entry In previous versions of TDMS, invalid dates may be accepted during form field data. More specifically, the leap year calculation algorithm was incorrect. Thus, some February 29th dates may have been accepted for non-leap years. This problem has been fixed. 2.1.8 Astprm Parameter for TSS$DECL_AFK Calls now Optional In previous versions of TDMS, not including the optional astprm parameter in the TSS$DECL_AFK call may result in errors. For example: If a COBOL program contained a call to TSS$DECL_AFK and attempted to use the OMITTED syntax to specify that this parameter was omitted, an Access Violation could occur. This problem has been fixed. 2.1.9 TSS$CANCEL Problem In previous versions of TDMS, using TSS$CANCEL to cancel a request may result in Access Violation or Bugcheck errors. In a TDMS application, if the first request contains Program Request Keys (PRK's) or user Defined Function Keys (DFK's) and is cancelled via TSS$CANCEL, and the second or subsequent requests contain neither PRK's nor DFK's, the second or subsequent requests may experience access violation or bugcheck errors. This problem has been fixed. 2.1.10 RDB Example Section 16.4.3.3 on page 16-24 of the hardcopy VAX TDMS Request and Programming Manual provided the following incorrect RDB example: ! Initialize a counter for the array. Counter = 0 ! Load a collection of records in the array. &RDB& FOR S in Salary_history &RDB& WITH S.Id_number = Salary_rec::Id_number &RDB& GET Salary_rec::Sal_array(Loop_index)::Start_date = S.Start_date &RDB& Salary_rec::Sal_array(Loop_index)::End_date = S.End_date &RDB& Salary_rec::Sal_array(Loop_index)::Salary = S.Salary &RDB& END_GET The variable Counter was initialized, but not used. The example has been corrected to read: ! Initialize a counter for the array. Counter = 0 ! Load a collection of records in the array. &RDB& FOR S in Salary_history &RDB& WITH S.Id_number = Salary_rec::Id_number &RDB& GET Salary_rec::Sal_array(Counter)::Start_date = S.Start_date &RDB& Salary_rec::Sal_array(Counter)::End_date = S.End_date &RDB& Salary_rec::Sal_array(Counter)::Salary = S.Salary &RDB& END_GET When this example was used with the TDMS %INCLUDE syntax shown in section 16.4.3.2 at the top of the same page (16-24), the RDB precompile failed. The failure occurred because %INCLUDE is performed at compile time. At precompile time, the record is not known to the application. This example was corrected in the online HTML documentation, on or before 2004-04-14. However, as mentioned in section 3.19, the correction went unpublished in the hardcopy documentation. 2.1.11 RDU SPAWN Example Section 2.29A on page 2-79.3 of the hardcopy VAX TDMS Reference Manual contained the following incorrect example: RDU>SPAWN FDU LIST FORM TEST_FORM/OUTPUT=TEST_FORM.LIST/NOWAIT The example was incorrect because the /NOWAIT qualifier was in the wrong position. Also, another /OUTPUT qualifier was needed to direct the output from the SPAWN command. The corrected example follows: RDU>SPAWN/NOWAIT/OUTPUT=SUB_PROCESS.LOG - RDU>_ FDU LIST FORM TEST_FORM/OUTPUT=TEST_FORM.LIST This example was corrected in the online HTML documentation, on or before 2004-04-14. However, as mentioned in section 3.19, the correction went unpublished in the hardcopy documentation. 2.2 Corrections for Alpha TDMS Version 1.9B 2.2.1 2001-10-12: ACCVIO in ARY014, DEF_KEY1, MOD03; invalid negative loop increment The first visible symptom was an ACCVIO in image TSSSHR, module TSS$THD, routine TSS$$FIND_RECCHN_TID, line 982+4, on virtual address 00000020: 982 IF .CUR_RECCHN[RECCHN$L_TID] EQLU .TID This error was immediately followed by: %DECthreads bugcheck (version V3.15-267), terminating execution. % Reason: schPriority: unrecognized class % The current thread sequence number is 2, at 0x0423DB40 The apparent cause of both errors was serious corruption (partial clearing) of memory. A much more helpful symptom had been hidden by a condition handler. Then it was revealed by debugging. This was an ACCVIO in image TSSSHR, module FDV$PFT, routine PFT_SBK, line 623+18, on virtual address 00891F6E: 610 ! Scroll the override video attributes in the SCA 611 612 incr I from .SCA[ SCA_U_AREA_SIZE ]-1 to 1 by -1 do 613 incr J from 0 to .SCA[ SCA_U_LCTE_COUNT ]-1 do 614 begin 615 bind 616 SCAVOTO = SCA[ SCA_Z_SCAVO ] + SCAVO_K_SIZE * 617 ( .I * .SCA[ SCA_U_LCTE_COUNT ] 618 + .J ) : $SCAVO, 619 SCAVOFROM = SCA[ SCA_Z_SCAVO ] + SCAVO_K_SIZE * 620 ( (.I-1) * .SCA[ SCA_U_LCTE_COUNT ] 621 + .J ) : $SCAVO; 622 623 SCAVOTO[ SCAVO_V_VID_OVER ] = 624 .SCAVOFROM[ SCAVO_V_VID_OVER ]; DBG> set break FDV$PFT\PFT_SBK\%LINE 623 DBG> go break at FDV$PFT\PFT_SBK\%LINE 623 in THREAD 2 DBG> e i,j FDV$PFT\PFT_SBK\%LINE 612\I: 1 FDV$PFT\PFT_SBK\%LINE 613\J: 0 DBG> cancel break FDV$PFT\PFT_SBK\%LINE 623 DBG> set break/exception DBG> go ! break occurred on ACCVIO exception DBG> e i,j FDV$PFT\PFT_SBK\%LINE 612\I: -554 FDV$PFT\PFT_SBK\%LINE 613\J: 0 Loop index "I" was never intended to have a negative value. The VAX BLISS compiler apparently interpreted the meaning of the negative loop increment on line 612 in a way that matches the programmer's intent, but does not correctly implement the language as specified. The Alpha BLISS compiler performs exactly the correct test specified for the language. An "incr" indexed loop should end when the index is greater than the final value. In this case, the initial and final values are both one, and the step value is negative one. The loop would have to execute about two billion times before the index could roll over from -(2^31) to (2^31)-1, finally having a value greater than one, and ending the loop. Serious memory corruption occurred well before then. The indexed loop at line 612 was corrected to read: decr I from .SCA[ SCA_U_AREA_SIZE ]-1 to 1 do 2.2.2 2001-10-24: ACCVIO in TSS_21555; linkage problem with AFK AST as initially ported An ACCVIO fatal error occurred during AFK AST delivery. The virtual address was the same as the PC: 0x0414BB4000550140. This 64-bit P2 address obviously does not make sense for 32-bit Alpha TDMS. This was caused by a serious problem with the initial attempt to implement AFK ASTs on Alpha, in which the AST routine's procedure descriptor was copied to the start of each PAGCHN data structure. In order to make this approach work, a copy of the entire linkage section for the TSSSHR image would have also been required, and its pointers would have had to be relocated. The resulting complexity and inefficiency would have made this approach very impractical or even infeasible. The solution was to adopt a much more suitable implementation, using a bound procedure descriptor, as indicated by the OpenVMS Alpha Calling Standard document. Please refer to section 1.5.1 for further details. 2.2.3 2001-10-29: Could not install Alpha TDMS kit; no TDMS or CDD-PLUS license The initial porting customer immediately called attention to these license issues. A TDMS license, issued for Compaq internal use only, had been in use on the porting development system. The same license worked on both VAX and Alpha. An incorrect assumption had been made that VAX TDMS licenses issued to customers would also work on both VAX and Alpha. Another incorrect assumption had also been made that Oracle was issuing and requiring a CDD-PLUS license. The installation procedure was changed to no longer require a TDMS license, since those issued to customers work only on VAX. Other license names were introduced later. The installation procedure was also changed to no longer require a CDD-PLUS license, since Oracle neither issues nor requires it. The Oracle CDD/Repository software also does not perform run-time checking for this license. 2.2.4 2001-11-13: Field validators were not working; invalid data structures were generated by aligning variables When the "unsigned word" field validator (#9) was assigned as an attribute to a field from FDU, all input values in the field were rejected with a "Value out of range" message. Each of these eight field validators (for signed and unsigned byte, word, longword, and quadword) specifies a range pair (minimum and maximum value). Their components had been declared as separate variables. On Alpha, each declared variable is aligned on a longword boundary by default. This introduced padding bytes, making the data structures invalid. The solution was to specifically declare a single variable for each data structure that needs to be contiguous. The same problem was later reported for the "unsigned longword" field validator (#11). The same fix, first included in the initial acceptance field test kit, also corrects this symptom. 2.2.5 TOOFEWARG in BASIC AST routines for OpenVMS Alpha before V7.2-2 Under OpenVMS Alpha V7.2-1, some of the regression test programs written in BASIC would fail during AST delivery. The following messages were displayed. The %CMA-F-EXCCOPLOS message came from the pthreads THD implementation, which was later replaced with ACMS THD. [ %CMA-F-EXCCOPLOS, exception raised; some information lost ] -BAS-F-TOOFEWARG, Too few arguments -BAS-I-FROMOD, In module !AC On versions of OpenVMS Alpha prior to V7.2-2, AST routines specified in calls to SYS$SETIMR and SYS$DCLAST may be delivered with only one actual argument, known as the AST parameter (ASTPRM). Other AST routines might not follow this rule; for example, the out-of-band character AST that can be delivered to a process by the terminal driver. However, on OpenVMS VAX and OpenVMS Alpha V7.2-2 and V7.3, AST routines specified in calls to SYS$SETIMR and SYS$DCLAST are delivered with five actual arguments: ASTPRM, R0, R1, PC, and PSL. Most of the AST routines in these BASIC programs were declared with five formal arguments. For each routine, BASIC performs a run-time check to compare actual versus formal argument counts. If they do not match, a condition of either TOOFEWARG or TOOMANYARG is signalled. This run-time check can be disabled only for the first routine declared in a program module, by starting the source file with a labeled "OPTION INACTIVE=SETUP" line, which may also have other, undocumented effects. These source files declare the main program first, so the AST routines perform the check. Apparently the only way to prevent this is to compile each of the AST routines as a separate source file. The chosen solution was different, as follows. When compiling these BASIC programs for a version of OpenVMS Alpha prior to V7.2-2, one formal argument should be specified for this kind of AST. This can be done by adding the /VARIANT qualifier to the BASIC command, giving a value of one to the %VARIANT built-in lexical function. Or, any non-zero integer value can be explicitly specified. For OpenVMS VAX, OpenVMS Alpha V7.2-2 or higher, and OpenVMS I64, the AST should have five formal arguments. This can be done by not adding the /VARIANT qualifier, giving a value of zero to %VARIANT. Or, a value of zero can be explicitly specified. The source file can be coded like this: 2000 SUB AST_ROUTINE ( LONG ASTPRM & %IF (%VARIANT = 0%) %THEN , R0, R1, PC, PSL %END %IF ) Without /VARIANT (or value zero), the compiler sees five formal arguments: 2000 SUB AST_ROUTINE ( LONG ASTPRM, R0, R1, PC, PSL ) With /VARIANT (or value non-zero), the compiler sees only one formal argument: 2000 SUB AST_ROUTINE ( LONG ASTPRM ) This change was made to the following BASIC regression test source files: AFK008 ASY001 ASY002 ASY003 ASY003VM BUGACMS01 CAN001 CAN002 CAN003 CAN004 CAN005 CAN006 CAN008 CAN009 CAN010 CAN011 CAN012 CAN013 CAN014 CAN015 CAN016 CAN019 CPY002 KNL002 OPN007 OPN008 RLB001 SAV010 SAV015 SAV020 SAV021 TSSCAN04 VER010 WBKFDVCCH WML003 2.2.6 2001-11-21: TSS$OPEN failure in OPN002, OPN010; THD stack size was too large TSS$OPEN would always fail after seven successful calls. The job-wide PGFLQUOTA was one million pagelets; less than 512 MB. Each thread was created with a stacksize of 64 MB. After seven threads were created, there was not enough virtual memory available to create an eighth. The stacksize was decreased to 128 KB. This was double the maximum thread stack size allowed for VAX TDMS, yet allowed for several thousand successful TSS$OPEN calls. This change was completed on 2001-10-15. The test programs then worked most of the time, but were prone to intermittent hangs and failures. Threads synchronization routines were corrected so that the main thread could make a created thread continue or resume execution, whether before or after that thread had explicitly suspended itself. Thread initialization was fully synchronized with the main thread. Threads were created pre-detached, so that they would be deleted automatically when terminated, to release their resources. This change was completed on 2001-10-16. The test programs then consistently ran to completion. The THD facility was later replaced with one derived from ACMS source code. This action does not appear to have re-introduced any of the above problems. 2.2.7 2001-12-03: ACMS/ENTER and ACMS/DEBUG would hang with TDMS present; THD synchronization was not working If SYS$SHARE:TSSSHR.EXE was present on the system, the ACMS/ENTER and ACMS/DEBUG commands would hang. These problems were corrected in the acceptance field test update of 2001-12-03, in order to allow testing with ACMS to proceed. The TSS$$THD_LOOP routine was rewritten to properly synchronize its activity with the main thread. After this change, ACMS/ENTER no longer hangs. The ACMS Installation Verification Procedure (IVP) also runs without hanging in the debugger portion. 2.2.8 2001-12-04: Last double-wide or double-size form line was shown normal-size; invalid data structures were generated by aligning variables A TDMS request would always incorrectly display any form having one or more double-wide or double-size lines. The last such line on the form (nearest to the bottom of the screen) was displayed with normal size. The expected attribute (either double width or the bottom half of double size) was missing for that one line only. The form editor (FED) displayed all lines with the correct attributes. The fixed portion (LAT_FIELDS) of the line attributes data structure had been declared as a separate variable from the variable-length attributes entries table portion (ATE_FIELDS). On Alpha, each declared variable is aligned on a longword boundary by default. This inserted a padding word containing zeros at the start of the attributes entries table. This was interpreted and ignored as an entry for line zero with no attribute specified. The table was thrown off by one entry. The last entry was dropped. The last line with an attribute entry was thus always displayed as normal size (no attribute). The solution was to specifically declare a single variable (LAT) for the entire line attributes data structure. A BIND declaration (similar to the Fortran EQUIVALENCE and BASIC MAP statements) was used to specify that the table of attributes entries (LAT_TABLE) was also contained within LAT, directly after the fixed portion. 2.2.9 2002-01-03: CONVERR in TSSCNL; PASCAL sources improperly declared record argument The following message text was displayed, and the test was prematurely terminated. %TSS-F-CONVERR, data type conversion error -TSS-I-TRAOUTPUT, SCHEDULE_OPTIONS_TYPE.SCHEDULE_OPTIONS_TYPE.STATION_OR_OPEN_3[26] of value "..." output to STATION_OR_OPEN_3[26] -TSS-I-TRAFIELD, SCHEDULE_OPTIONS_TYPE.SCHEDULE_OPTIONS_TYPE.STATION_OR_OPEN_3[26] is length=3, dtype=14, class=9 at %X001393D0 -TSS-I-TRAFIELD, STATION_OR_OPEN_3[26] is length=3, dtype=14, class=1 at %X001393E8 -TSS-F-NONPRICHA, field contains non-printable characters -CMU-I-SIGNAL_FROM, PC=00084F6C, PS=0000001B This error caused the TSS$REQUEST call to return immediately and silently. The program then terminated when it called TSS$SIGNAL to display the above message text. Running the program under the debugger with SET BREAK/EXCEPTION, the signal was caught where it was raised during the request: image\module\routine[+offset] line rel PC abs PC TSSSHR\TSS$REQMAP\TSS$$REQ_MAP_CONV_ERR 1949 0000000000001864 00000000000BD794 TSSSHR\TSS$REQMAP\TSS$$REQ_MAP_ONE_ONE 1586 0000000000000FA0 00000000000BCED0 TSSSHR\TSS$REQMAP\TSS$$REQ_MAP_MANY_MANY 1206 0000000000000A14 00000000000BC944 TSSSHR\TSS$REQMAP\TSS$$REQ_MAP 602 00000000000003DC 00000000000BC30C TSSSHR\TSS$REQ\TSS$$REQUEST_PHY 1432 0000000000000FC4 00000000000AAB14 TSSSHR\BLI$CALLG\BLI$CALLG 12933 00000000000000BC 0000000000084F6C TSSSHR\TSS$THD\TSS$$THD_CALL 927 00000000000004CC 00000000000AC94C TSSSHR\TSS$THD\TSS$$THD_LOOP 836 00000000000003F8 00000000000AC878 TSSSHR\BLI$CALLG\BLI$CALLG 12933 00000000000000BC 0000000000084F6C TSSSHR\THD$COMMON_CODE\THD$CALL_THREAD 1076 00000000000007A4 0000000000082DF4 TSSSHR\THD$COMMON_CODE\THD$START 1011 00000000000006EC 0000000000082D3C TSSSHR\THD$ALPHA_CODE\THD$SWITCH_STACK 3071 00000000000000EC 0000000000084E4C TSSSHR\THD$ALPHA_CODE\THD$SWITCH_STACK 2371 00000000000000C4 0000000000084E24 TSSSHR\THD$COMMON_CODE\THD$RMS_DONE 1905 0000000000001A18 0000000000084068 PROCESS_MANAGEMENT\\EXE$AST_RETURN 0000000000026BD0 FFFFFFFF80110BD0 PROCESS_MANAGEMENT\\SYS$WAITFR+000C4 00000000000290E4 FFFFFFFF801130E4 TSSSHR\TSS$THD\TSS$$THD_CONTINUE 776 0000000000000280 00000000000AC700 TSSSHR\TSS$REQ\TSS$$REQUEST 1019 0000000000000760 00000000000AA2B0 TSSSHR\TSS$ENTRY\TSS$$ENTRY_CALL 1903 00000000000010EC 000000000009F21C TSSSHR\TSS$ENTRY\TSS$$ENTRY 1510 0000000000000C20 000000000009ED50 TSSSHR\TSS$ENTRY\TSS$REQUEST 2602 0000000000001FBC 00000000000A00EC TSSCAN01\TSSTIMEOUT\TSS_TIMEOUT 899 0000000000000734 0000000000020F74 TSSCAN01\HARDCOPY\HARDCOPY 2889 0000000000000494 0000000000020494 IMAGE_MANAGEMENT\\SYS$IMGSTA+001BC 00000000000174DC FFFFFFFF87DE94DC Working backward, it was found that the first copy of the text containing the non-printable characters was allocated by TSS_TIMEOUT on the original user stack. This storage held temporary copies of the actual call arguments. The formal argument was declared as a packed array of 1024 characters, which is not big enough to contain an entire record of data type SCHEDULE_OPTIONS_TYPE. Any stack contents beyond the first 1024 characters were vulnerable to corruption. The TDMS request was likely to read a corrupt record from the stack, and to corrupt the stack by writing the entire modified record back to it. This was a programming error in the PASCAL sources for the TSSCNL regression test. It could very easily cause the same error on VAX (although it apparently does not), or cause other potential undetected problems. The solution was to change the passing mechanism for the formal record parameter list in the declaration of the TSS_TIMEOUT function, and to make similar appropriate changes to several of the variant TSS$REQUEST calls. This allows TDMS to access the record variables that have the appropriate sizes, rather than copies of character arrays that may be too small. This solution closely resembles the suggestion made by section 3.15: PASCAL and Parameter Passing. Each actual record parameter in a TSS_TIMEOUT function call is still passed by reference: %REF record-variable The formal record parameter list for TSS_TIMEOUT now specifies that each record pointer is to be passed by immediate value: %IMMED record_0 : [LIST]POINTER 2.2.10 2002-01-08: Blank date fields in DAT002; problem with quadword integer math as initially ported Date fields were sometimes not getting filled in. Result screens 5, 6, 7, 8, 10, and 11 differed from the benchmark screens. The first problem occurred when the PF1-KP5 program request key (PRK) was pressed in the date 2 field. The previous PF1-KP2 PRK in the date 1 field worked as expected. This problem was caused by a programming error that had been introduced during the initial porting effort. In routine CVT_FDV_TO_ADT, quadword integer divide and multiply operations are used to extract separate date and time values from a VMS quadword absolute time (ADT field). The VAX version used the undocumented COBOL run-time library routines COB$DIVQ_R8 and COB$MULQ_R8 to perform these operations. These routines are not available on OpenVMS Alpha, except to VEST-translated VAX images. The initial Alpha implementation failed to properly perform the divide operation. The 32-bit Alpha BLISS compiler does not directly support quadword integer divide or multiply. Fortunately, some other compilers do, including FORTRAN and CC. The solution was to provide DIVQ and MULQ routines in the source file QUADMATH.C: #if __VAX #include #endif /* * These divide and multiply routines are provided * for programming language dialects that do not * directly support quadword integer math operations. * Each argument is the address of a quadword integer, * stored as an array of two longwords. */ /* * DIVQ() obtains the quotient of a dividend * and a divisor, all signed quadword integers. * * On Alpha, the compiler supports quadword integer * division by generating a run-time library call. * Code has been added to prevent alignment faults * that the arguments might otherwise have caused. */ void DIVQ ( const __int32 dvd[2], const __int32 dvr[2], __int32 quo[2] ) { #if __VAX /* no need; continue to use COB$DIVQ_R8 on VAX */ #else unsigned __int64 advd, advr, aquo; /* copy in the dividend to align it */ advd = dvd[1]; advd <<= 32uL; advd |= dvd[0]; /* copy in the divisor to align it */ advr = dvr[1]; advr <<= 32uL; advr |= dvr[0]; /* compute the aligned quotient (RTL routine called) */ aquo = advd / advr; /* copy out the quotient longwords */ quo[0] = aquo & 0xFFFFFFFFuL; aquo >>= 32uL; quo[1] = aquo & 0xFFFFFFFFuL; #endif } /* DIVQ() */ /* * MULQ() multiplies two quadword integers * (either signed or unsigned works the same), * to get only the low-order quadword of the * (possibly octaword) integer product. * * The single Alpha instruction MULQ performs * the equivalent operation. Code has been * added to prevent alignment faults that the * arguments might otherwise have caused. */ void MULQ ( const unsigned __int32 mlr[2], const unsigned __int32 mcd[2], unsigned __int32 prd[2] ) { #if __VAX /* no need; continue to use COB$MULQ_R8 on VAX */ const __int32 zero = 0; /* low-order term; sign corrections may be needed */ if (mlr[0] && mcd[0]) { lib$emul(&mlr[0], &mcd[0], &zero, &prd[0]); if ((__int32)mlr[0] < 0) prd[1] += mcd[0]; if ((__int32)mcd[0] < 0) prd[1] += mlr[0]; } else prd[0] = prd[1] = 0u; /* cross terms; ignore overflow; sign correction is not needed */ if (mlr[0] && mcd[1]) prd[1] += mlr[0] * mcd[1]; if (mlr[1] && mcd[0]) prd[1] += mlr[1] * mcd[0]; #else unsigned __int64 amlr, amcd, aprd; /* copy in the multiplier to align it */ amlr = mlr[1]; amlr <<= 32uL; amlr |= mlr[0]; /* copy in the multiplicand to align it */ amcd = mcd[1]; amcd <<= 32uL; amcd |= mcd[0]; /* compute the aligned product (MULQ instruction generated) */ aprd = amlr * amcd; /* copy out the product longwords */ prd[0] = aprd & 0xFFFFFFFFuL; aprd >>= 32uL; prd[1] = aprd & 0xFFFFFFFFuL; #endif } /* MULQ() */ 2.2.11 2002-01-14: PASCAL application failure; no PACKED prefix for %DICTIONARY array fields; new default alignment did not match TDMS and ACMS for VARYING STRING The data structure looked valid when debugging the PASCAL application, but looked like garbage to the ACMS debugger in the workspace. A reproducer was requested and furnished. The resulting program displayed the following text: %TSS-F-CONVERR, data type conversion error -TSS-I-TRAOUTPUT, VARYING_FIX_REC.T_VARYING_FIX.LINK_STATUS[1] of value "..4.192." output to LINK_STATUS[1] -TSS-I-TRAFIELD, VARYING_FIX_REC.T_VARYING_FIX.LINK_STATUS[1] is length=8, dtype=14, class=9 at %X002E7380 -TSS-I-TRAFIELD, LINK_STATUS[1] is length=8, dtype=14, class=1 at %X002E7398 -TSS-F-NONPRICHA, field contains non-printable characters -CMU-I-SIGNAL_FROM, PC=000751EC, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows image\module\routine[+offset] line rel PC abs PC TSSSHR\BLI$CALLG\BLI$CALLG 12933 00000000000000BC 00000000000751EC TSSSHR\TSS$SIGNAL\TSS$$SIGNAL 373 00000000000002E0 0000000000096F80 TSSSHR\TSS$ENTRY\TSS$$ENTRY_CALL 1903 00000000000010EC 000000000008F49C TSSSHR\TSS$ENTRY\TSS$$ENTRY 1510 0000000000000C20 000000000008EFD0 TSSSHR\TSS$ENTRY\TSS$SIGNAL 2614 0000000000002880 0000000000090C30 VARYING_FIX\VARYING_FIX\VARYING_FIX 129 0000000000000958 0000000000020958 IMAGE_MANAGEMENT\\SYS$IMGSTA+00154 0000000000017474 FFFFFFFF87DE9474 The CDD record definition is: DEFINE RECORD CDD$TOP.REC.VARYING_FIX_REC. T_VARYING_FIX STRUCTURE. NODE_NAME ARRAY 1:10 DATATYPE TEXT 6. NODE_ADDR ARRAY 1:10 DATATYPE VARYING STRING 7. LINK_STATUS ARRAY 1:10 DATATYPE TEXT 8. CURRENT_CONFIG ARRAY 1:10 DATATYPE TEXT 3. NEW_CONFIG ARRAY 1:10 DATATYPE TEXT 3. END T_VARYING_FIX STRUCTURE. END VARYING_FIX_REC RECORD. The %DICTIONARY directive translates this into PASCAL as follows: T_VARYING_FIX = PACKED RECORD NODE_NAME : ARRAY [1..10] OF PACKED ARRAY [1..6] OF CHAR; NODE_ADDR : ARRAY [1..10] OF VARYING [7] OF CHAR; LINK_STATUS : ARRAY [1..10] OF PACKED ARRAY [1..8] OF CHAR; CURRENT_CONFIG : ARRAY [1..10] OF PACKED ARRAY [1..3] OF CHAR; NEW_CONFIG : ARRAY [1..10] OF PACKED ARRAY [1..3] OF CHAR; END; { record T_VARYING_FIX } This data type declaration generated by the %DICTIONARY directive starts with "PACKED RECORD"; no alignment bytes are added between record fields. However, the array fields in the generated declaration do not start with "PACKED ARRAY", allowing Alpha PASCAL default natural alignment. Each VARYING STRING array element of the NODE_ADDR field is a word- counted string (.ASCIW) aggregate. With VAX (byte) alignment in effect, each element requires nine bytes of storage. With Alpha (natural) alignment in effect, an alignment byte is added, so each element requires ten bytes of storage. The absence of the "PACKED" keyword before the first "ARRAY" keyword causes a padding byte to be added to each element of the array when natural alignment is enforced. The padding byte is only omitted when natural alignment is disabled. Natural alignment can be disabled for the entire PASCAL compile command by the /ALIGN=VAX qualifier. However, this could unnecessarily degrade performance on Alpha. A better solution is to place the [ALIGN(VAX)] attribute immediately before a separate TYPE section containing only the %DICTIONARY directive. This disables natural alignment only for the declaration made within the scope of that TYPE section. For example: [ALIGN(VAX)] TYPE %DICTIONARY 'CDD$TOP.REC.VARYING_FIX_REC/LIST' TYPE UWORD = [WORD] 0..65535; VAR WK_VARYING_FIX : T_VARYING_FIX; Although the PASCAL language reference manual indicates that the [ALIGN(VAX)] attribute can also be placed before a VAR section, that does nothing to alter the alignment of a previously-declared data type, e.g. T_VARYING_FIX. 2.2.12 2002-01-25: SYS$LIBRARY:ACMSREQ.RLB was missing on Alpha ACMS deliberately does not provide TDMS support files on platforms other than VAX (Alpha and I64). The default menu request library was missing, so ACMS/ENTER would exit with the following messages: Open failure on menu request library SYS$LIBRARY:ACMSREQ.RLB Forcing EXIT from ACMS Exit from ACMS completed at dd-mmm-yyyy hh:mm:ss.cc Starting with the 2002-01-11 acceptance field test update, the development kit provides this file. Starting with the 2002-01-25 field test update, the run-time-only kit also provides this file. ACMS/ENTER displays a menu as expected when this file is present. The development kit also provides SYS$LIBRARY:ACMSREQ.BAK, which is a DMU backup of the CDD requests and forms used for ACMSREQ.RLB. You can build customized menu request libraries by modifying these requests and forms. 2.2.13 2002-07-08: "OUTPUT %TOD" in request definition consistently caused RDU failure; RDU$CREATE_TOD_FIELD_REF called RDU$ALLOCATE_REF with a different third argument RDU> replace request AG56_F01_R1 AG56_F01_R1.RDF %CMU-F-INVARG, invalid argument passed to routine -CMU-F-INROUTINE, error detected in routine CMU$CREATE_AND_QUE_ADB %TRACE-F-TRACEBACK, symbolic stack dump follows [MODIFIED] img module routine line rel PC abs PC RDU CMU$MEMADS CMU$CREATE_AND_QUE_ADB 2532 00000FEC 0008C2BC RDU CMU$BUILD CMU$ALLOCATE_BINARY_BLOCK 2053 000004A0 0006E4E0 RDU RDU$FIELD RDU$ALLOCATE_REF 1070 00000454 000DB644 RDU RDU$TODFLD RDU$CREATE_TOD_FIELD_REF 989 000002FC 000EDFAC RDU RDU$FIELD RDU$CREATE_FIELD_REF 1535 00000EE0 000DC0D0 RDU RDU$BLDMAP RDU$BUILD_MPL 2953 00002BBC 000CB6BC RDU BLI$CALLG BLI$CALLG 12635 000000BC 00055D5C RDU RDU$FORM_FIELD RDU$FIND_FORM_SUBFIELD 1512 00000F00 000E0980 RDU BLI$CALLG BLI$CALLG 12635 000000BC 00055D5C RDU CMU$BUILD CMU$PROCESS_LIST 3081 00001CD4 0006FD14 RDU RDU$FORM_FIELD RDU$FIND_FORM_TOP 1186 000007C4 000E0244 RDU RDU$FORM_FIELD RDU$FIND_FORM_FIELD 1070 0000048C 000DFF0C RDU RDU$FIELD RDU$FIND_MATCHING_FIELDS 1747 0000145C 000DC64C RDU BLI$CALLG BLI$CALLG 12635 000000BC 00055D5C RDU RDU$BLDMAP RDU$BUILD_MAP_SETUP 2291 00001D4C 000CA84C RDU RDU$BLDMAP RDU$BUILD_REQUEST_MAP 1606 00000B70 000C9670 RDU BLI$CALLG BLI$CALLG 12635 000000BC 00055D5C RDU CMU$BUILD CMU$PROCESS_LIST 3081 00001CD4 0006FD14 RDU RDU$BINARY RDU$BUILD_REQUEST_REH 2082 000015B8 000B8EB8 RDU RDU$BINARY RDU$BUILD_REQUEST_REQ 1509 00000884 000B8184 RDU RDU$BUILD RDU$BUILD_REQUEST_BINARY 2122 00001FA4 000A7B44 RDU RDU$BUILD RDU$VALIDATE_FULL_REQUEST 3005 00003410 000A8FB0 RDU RDU$DEFINE RDU$DEFINE_PARSE 2917 00000230 000A54A0 RDU CMU$TARGET_NODE CMU$TARGET_NODE_SETUP 1953 00000480 0009EE70 RDU RDU$REQEXC RDU$REPLACE_REQUEST 1669 00001A9C 000A47EC 0 *P1 addr *P1 addr 0 *S0 addr *S0 addr 0 *S0 addr *S0 addr RDU 0 000461D4 000561D4 RDU CMU$CLIHND CMU$PARSE_COMMAND 620 00000708 000998E8 RDU CMU$CLIHND CMU$GET_CMD 425 00000244 00099424 RDU CMU$MAIN CMU$PROCESS_CMDSTM 1419 00001484 00098B74 RDU CMU$MAIN CMU$START 635 00000768 00097E58 RDU RDUSHR RDU$START 461 000001F4 0006E024 RDU RDU$MAIN RDU$MAIN 836 00000610 0006DD30 0 *S0 addr *S0 addr During each test run, CMU$CREATE_AND_QUE_ADB was successfully called 742 times before the failure. It occurred only after RDU$ALLOCATE_REF was called from RDU$CREATE_TOD_FIELD_REF, line 989. The third actual argument used for this call was REF_ACS. This was changed to REF_ADB, to match a call to RDU$ALLOCATE_REF from RDU$CREATE_LITERAL_FIELD_REF, which works without problems. This eliminated the reported symptom, allowing RDU to process the request without reporting an error. The VAX BLISS compiler apparently interpreted REF_ACS as equivalent to REF_ADB when used as an actual argument, but the Alpha BLISS compiler does not. 2.2.14 2003-01-28: Date or time input conversion often produced corrupted values; caused by both old and new coding errors A triad of software problems affected input from date and time fields. Sadly, they went entirely undetected during regression and field testing. Then an alert HP Services employee in Ireland noticed and reported the problems he encountered while testing the PERSONCOB.EXE sample application from the field test kit. The problems listed below were found and fixed for routine CVT_FDV_TO_ADT in TSSREQCVT.BLI, and for routines DIVQ and MULQ in QUADMATH.C: Problem #1: Only two bytes were allocated for a variable intended to contain a counted ASCII (ASCIC) string for the two-digit century applied to the three date formats for which only two digits are specified as the year: (1) "DD-MMM-YY"; (2) "MM/DD/YY"; (4) "DD-MM-YY". This variable should have had at least three bytes allocated. This problem existed in VAX TDMS, yet apparently somehow did not affect input date conversions. Problem #2: The subtrahend and minuend arguments had been placed in the wrong order in a SUBM macro call. Problem #3: DIVQ and MULQ needed to have their arguments declared as unsigned longword integer arrays, to prevent any problems with their conversion to or from unsigned quadword integers. 2.3 Corrections for Alpha TDMS V1.9-20031101C 2.3.1 2003-09-02: ACCVIO occurred in TSS$SIGNAL for any saved signal vector with more than one argument A blanket update was made to all of the exception handler routines, just prior to the previous release (2003-01-28), which introduced a bug into routine TSS$$HNDLR. During the effort to debug forms display from Datatrieve, the RMS STS/STV information was added to the signal vector for TSSFDV$_IOL errors. This caused an ACCVIO to occur when attempting to reference the saved signal vector. The fix restored the correct behavior for routine TSS$$HNDLR, which is to specify the address of the saved signal vector as the primary return status. 2.3.2 2003-11-01: Circular help form reference consistently caused RDU failure; preset pointer value was valid on VAX, but not Alpha A locally-declared dummy descriptor DUM_DESC, in routine FDU$GET_FORM_SIZES, in module FDU$RETRIEVE_FORM_INFO, was given a preset pointer value of 1000 decimal, which is 3E8 hex. This was the ACCVIO virtual address. It is a valid address on VAX, but not on Alpha, due to the larger size of the inaccessible guard page for small virtual addresses. Most likely the problem was not reported earlier because a circular help form reference is not made all that often, and this case is not checked by existing regression tests. The fix selected was to declare the dummy descriptor differently (using BIND), so that the pointer field now references the string "unique" instead. When the above problem was fixed, another was revealed. A formal argument had been added to the FDV$CNVCDDBFD routine, but a check for the presence of the last argument using actualcount() had not been updated to match. This problem was also corrected. The number of RDU$BUILD_FORM_EXTERNAL calls in the traceback depended on the number of forms that were processed before the circular reference was encountered. %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000003E8, PC=FFFFFFFF804C0760, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows img module routine[+offset] line rel PC abs PC LIBOTS OTS$MOVEM+00100 0 00000000 804C0760 RDU FDV$CDDBFD CNV_ADD_STRING 3359 00002BF8 0005E278 RDU FDV$CDDBFD CNV_HDR 2142 00000768 0005BDE8 RDU FDV$CDDBFD FDV$CNVCDDBFD 1918 00000098 0005B718 RDU FDU$RETRIEVE_FORM_INFO FDU$GET_FORM_SIZES 972 000000F0 000A4530 RDU RDU$BUILD_FORM RDU$GET_FORM_SIZES 2039 000018A0 000BBE00 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1226 000002AC 000BA80C RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD_FORM RDU$BUILD_FORM_EXTERNAL 1438 00000884 000BADE4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD_FORM RDU$BUILD_FORM_TOP 1253 00000480 000BA9E0 RDU RDU$BUILD RDU$BUILD_ITEM_TOP_DISPATCH 1997 00001BF4 000AC0E4 RDU BLI$CALLG BLI$CALLG 12933 000000BC 00055D6C RDU CMU$BUILD CMU$PROCESS_LIST 3184 00001CD4 00071B24 RDU RDU$BUILD RDU$BUILD_REQUEST_TOP 1767 00001558 000ABA48 RDU RDU$BUILD RDU$VALIDATE_FULL_REQUEST 3059 000033F4 000AD8E4 RDU RDU$DEFINE RDU$DEFINE_PARSE 2930 00000230 000A9DF0 RDU CMU$TARGET_NODE CMU$TARGET_NODE_SETUP 2009 00000480 000A3640 RDU RDU$REQEXC RDU$CREATE_REQUEST 792 000008E0 000A7F80 DCL CLI$DCL_PARSE 0 7AE30350 7AE30350 SYSTEM_PRIMITIVES_MIN AMAC$EMUL_CALL 0 80075BA4 80075BA4 SYSTEM_PRIMITIVES_MIN AMAC$EMUL_CALL 0 80075BA4 80075BA4 RDU 0 000461E4 000561E4 RDU CMU$CLIHND CMU$PARSE_COMMAND 647 00000708 0009F4E8 RDU CMU$CLIHND CMU$GET_CMD 452 00000244 0009F024 RDU CMU$MAIN CMU$PROCESS_CMDSTM 1574 00001678 00085B18 RDU CMU$MAIN CMU$START 693 00000718 00084BB8 RDU RDUSHR RDU$START 488 000001F4 0006FE34 RDU RDU$MAIN RDU$MAIN 926 000006C4 0006FB34 RDU 0 0005F1EC 0006F1EC IMAGE_MANAGEMENT SYS$IMGSTA+00154 0 87DE9494 87DE9494 2.4 Corrections for Alpha TDMS V1.9-20031107C 2.4.1 2003-11-07: File locations were not specified by [SYSHLP.EXAMPLES.TDMS]TDMSBLDSAMPLE.COM Test PCSI installations revealed that no location was specified for the two input files (TDMSFORMS.BAK and PERRDU_PRK.COM) or the four output files (DEPART.RLB, EMPLOYAVO.RLB, EMPLOYEE.RLB, PERSON.RLB). This caused several failures and omissions to occur when the PCSI installation executed this procedure as a test. The fix selected was to specify the same location (TDMS$EXAMPLES:) for all of these input and output files. The TDMS startup command procedure TDMSTRTUP.COM defines this logical name (TDMS$EXAMPLES). 2.4.2 2003-11-07: New TDMS shutdown command procedure [SYSMGR]TDMSHUTDOWN.COM It was noted during test PCSI removals that no TDMS shutdown command procedure was provided. This left [SYSLIB]TSSSHR.EXE marked for deletion, but still installed. It also left up to four logical names defined in the system table (TDMS$EXAMPLES, TDMS$EDIT, RDU$EDIT, FDU$EDIT). The fix selected was to provide [SYSMGR]TDMSHUTDOWN.COM, and to specify it in the stop clause of an "execute start... stop..." statement in the PCSI product description files. The TDMS startup command procedure [SYSMGR]TDMSTRTUP.COM is specified in the start clause. 2.5 Corrections for Alpha TDMS V1.9-20031201C 2.5.1 2003-11-13: TRACALL and TRARET trace messages did not display routine names after early I64-related porting changes While comparing the results of regression tests run on OpenVMS Alpha V7.3-2 with their benchmarks, it was noted that the TRACALL and TRARET trace messages displayed garbage instead of the routine names. Debugging showed that the routine name fields were not properly de-referenced to provide the addresses of the counted routine name strings. The changes that caused this bug were made to the source file TSSENTRY.BLI on 2002-11-25 and 2003-05-20. The first relevant change made was to naturally align the fields of the TSS$Z_PRD data structure. This eliminated the unaligned relocation linker warnings that had appeared after symbols were added to the TSSSHR shareable image symbol vector, which allowed Datatrieve to display TDMS forms on OpenVMS Alpha. The second relevant change made was to eliminate "complex" link-time constant expressions (LTCEs). These are supported by the OpenVMS Alpha and OpenVMS VAX compilers and linker. Support for these expressions has also been added to OpenVMS I64 V8.2, since source code compatibility was a major goal for this release. However, the OpenVMS I64 ELF object format and linker support, as provided in V8.1, did not provide the OpenVMS-specific extensions required to support the use of these expressions. The compilers could not instruct the linker to perform the necessary link-time calculations and operations. In any case, the linker could not have interpreted any such ELF object format extensions, even if they had been generated by the compilers. In order to make early porting progress, all LTCEs had already been replaced with simple relocatable address values. The LTCEs had consisted of offsets (relative addresses), computed by subtracting addresses known at link time in field presets. When these were changed to simple absolute addresses, two field references needed to be de-referenced, but were overlooked. This problem was not detected until much later, when the regression tests were run, and the new results were compared with their benchmarks. The fix selected was to prepend a de-reference operator (".") at the two appropriate places in TSSENTRY.BLI. 2.5.2 2003-11-18: Compile errors from BASIC source files in TDMS$EXAMPLES; caused by an attempt to reduce the number of RDU warning messages When TDMSBLDSAMPLE.COM was rewritten during 2003-10-09 through 2003-11-17, some of the integer fields in the record definitions were changed from signed to unsigned, in an effort to reduce the number of warning messages issued by RDU. BASIC does not support the use of unsigned integer types. This resulted in a number of %BASIC-E-ILLMODMIX and %BASIC-E-RECKEYQAD messages. The fix selected was to change these unsigned integer fields back to signed, and to specify the additional expected RDU warning messages in TDMSBLDSAMPLE.COM. 2.5.3 2003-11-21: Spurious "internal range conversion" message from FDU; variable too small for H-float datum in FDUSTRNUMCMP.C While comparing the results of regression tests run on OpenVMS Alpha V7.2-2 with their benchmarks, it was noted that the FDURNG test failed by provoking a spurious FDU$_INTCNVERR message from FDU. This occurred when attempting to position past the high (maximum) field for the first entry on the range list field validator editing form. Debugging showed that the problem began in function FDU$STRING_NUM_COMP from source file FDUSTRNUMCMP.C. This function was originally provided by BLISS source file FDUFVPMSC.B32. It was first converted from VAX to Alpha BLISS. In order make it more naturally maintainable, it was converted to Fortran source file FDUCNUMS.FOR in April 2001. Since the early cross tools provided a C cross compiler but no Fortran cross compiler (on an OpenVMS Alpha host platform, for an OpenVMS I64 target platform), and native compilers would not be available until later, the function was again converted to the C-language source file FDUSTRNUMCMP.C in May 2003. The latent bug was introduced at that time. Only eight bytes (64 bits) were allocated for variable HVAL, instead of the required sixteen bytes (128 bits) for an H-float datum. When HVAL was written, the address of the second argument string descriptor was cleared. This caused the conversion of the second numeric string to fail. The function returned zero, and the caller (routine FDU$COLLECT_RANGE from source file FDUTSS.BLI) displayed the message. The fix selected was to declare the HVAL variable as a 128-bit "long double", instead of a 64-bit "__int64" integer. A further check was added, so that any attempt to compile with the qualifier "/L_DOUBLE_SIZE=64" would produce an appropriate error message. Although its data type and format are declared incorrectly, HVAL is not directly used or checked by the function itself. It is used for an intermediate conversion step from numeric string to H-float, which is then converted to X-float for comparison. 2.5.4 2004-03-12: TDMSBLDSAMPLE.COM problems with evaluation license A customer evaluated Alpha TDMS shortly before making a purchase. During installation of the evaluation kit with an evaluation license loaded, when executing TDMSBLDSAMPLE.COM to build the sample applications, this error was signaled several times: %CMU-E-FILENAME, file in error is: SYS$SYSROOT:[SYSMGR]RDU.TMP; -RMS-E-FLK, file currently locked by another user -CMU-I-SIGNAL_FROM, PC=0009E34C, PS=0000001B %TRACE-E-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC RDU CMU$CTRLC CMU$RMS_SIGNAL 1253 000000000000127C 000000000009E34C RDU CMU$FILE_MAN CMU$CREATE_FILE 729 0000000000000738 0000000000089128 RDU CMU$STREAM_MAN CMU$OPEN_STREAM 400 00000000000002F4 0000000000093E74 RDU CMU$OUTPUT CMU$OPEN_OUTPUT 364 00000000000001FC 00000000000932AC RDU CMU$MAIN CMU$START 653 0000000000000644 0000000000084914 RDU RDUSHR RDU$START 488 00000000000001F4 000000000006FC64 RDU RDU$MAIN RDU$MAIN 927 00000000000006C4 000000000006F964 RDU 0 000000000005F01C 000000000006F01C 0 FFFFFFFF8025FE94 FFFFFFFF8025FE94 %RMS-E-FLK, file currently locked by another user %DCL-W-SKPDAT, image data (records not beginning with "$") ignored These errors prevented RDU from processing several request definitions, resulting in an incomplete sample build operation. The immediate cause of the problem was the output generated during license checking, due to the evaluation license. The solution, which was also discovered and reported by this customer, was to remove the /USER qualifier from all of the... $ DEFINE/USER SYS$OUTPUT RDU.TMP ...commands in the procedure, and to place the command... $ DEASSIGN SYS$OUTPUT ...following the RDU commands preceded by the DEFINE command. Some reasonably sensible source code changes related to license checking were also made, but these did not have any apparent effect on the reported problem. This problem would have affected only then-current evaluation customers, so corrected kits would have had to be sent out only to them. Corrected kits were still given the same V1.9-20031201C version designation, since no new general release was required. 2.6 Corrections for I64 TDMS E8.2-20040908A 2.6.1 2004-08-17: FDU FED ACCVIO; routine UAR$FIELD_DONE improperly declared An ACCVIO fatal error occurred on OpenVMS I64 when attempting to assign form attributes in the FDU form editor (FED). This problem caused many of the TDMS regression tests to fail. %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=9AA0233E18406000, PC=0000000018406000, PS=0000001B break on unhandled exception preceding SHARE$LIBOTS_CODE0+0FB0 %DEBUG-I-SOURCESCOPE, Source lines not available for 0\%PC Displaying source for 1\%PC 1518: UAR_STATUS = ( UAR$FIELD_DONE )(); ! Call UAR DBG> eval/addr UAR$FIELD_DONE 0000000000000000 DBG> type 1500:1520 module FDV$COMSUB 1500: !+ 1501: ! Field Completion UAR linkage 1502: ! Note ( Only use 1st UAR for now ) 1503: !- 1504: %if not FASTUAR %then 1505: if ( TXTADD = FDV$$FNDTXT( FLD[ FLD_R_TXTDEF ], 1506: FLD_K_S_FUAR1, 0 )) eqla 0 1507: then 1508: return( 1 ); ! No UAR - Return Success 1509: ! Set UAR String Addr 1510: TCA[ TCA_A_UAR_STR ] = FDV$$FNDTXT( FLD[ FLD_R_TXTDEF ], 1511: FLD_K_S_FUARD1, 0 ) + 1; 1512: UAR_ADDR = FDV$$FINDUAR( .TXTADDR + 1 ); 1513: UAR_STATUS = (.UAR_ADDR)(); ! Call UAR 1514: %else 1515: if UAR$FIELD_DONE eqla 0 1516: then 1517: return( 1 ); ! No UAR - Return Success 1518: UAR_STATUS = ( UAR$FIELD_DONE )(); ! Call UAR 1519: %fi DBG> show call module name routine name line rel PC abs PC LIBOTS OTS$REM_UL+00460 0000000000000FB0 FFFFFFFF82240FB0 FDV$COMSUB FDV$$VALID_FLD 1518 0000000000003880 00000000000F3220 FDV$GET FDV$$GET_VALFLD 784 0000000000000D00 00000000001085E0 FDV$GET FDV$$GET 620 0000000000000330 0000000000107C10 FDV$DISPCH ISOLATE 930 00000000000016D0 00000000001133B0 FDV$DISPCH FDV$$DISPATCH 633 00000000000006C0 00000000001123A0 PLI$DISPCH PLI$$DISPATCH 138 0000000000000130 000000000012DC20 PLI$ENTRYS TSSFDV$GET 68 0000000000004C60 000000000012B9E0 FDU$FEDPRC FDU$$PROC_MENU 1645 0000000000001A90 0000000000181F50 FDU$FEDPRC FDU$FED_MENU 1417 0000000000001300 00000000001817C0 FDU$FEDOPS FDU$FED_PROC 1269 0000000000000570 0000000000148480 FDU$CMDPRC FDU$$CMD_PROC_CTRL 1053 0000000000001160 0000000000147CC0 FDU$CMDPRC FDU$PROC_CREATE_CMD 678 00000000000002C0 0000000000146E20 CMU$TARGET_NODE CMU$TARGET_NODE_SETUP 2009 0000000000000CE0 00000000002235A0 FDU$EXEC FDU$CREATE_FORM 963 00000000000013B0 00000000001422F0 DCL 000000000009B950 000000007AE1B950 SYSTEM_PRIMITIVES_MIN AMAC$EMUL_CALL+00250 000000000019C4C0 FFFFFFFF8019C4C0 DCL 0000000000090EB0 000000007AE10EB0 SYSTEM_PRIMITIVES_MIN AMAC$EMUL_CALL+00250 000000000019C4C0 FFFFFFFF8019C4C0 DCL 000000000008FEB0 000000007AE0FEB0 EXCEPTION SYS$CLI+00150 FFFFFFFF8034FC40 FFFFFFFF8034FC40 CLI$DISPATCH+0150 0000000000089590 00000000000D9590 CMU$CLIHND CMU$PARSE_COMMAND 647 00000000000012C0 000000000020FFD0 CMU$CLIHND CMU$GET_CMD 452 00000000000006A0 000000000020F3B0 CMU$MAIN CMU$PROCESS_CMDSTM 1570 0000000000003840 00000000001C3940 CMU$MAIN CMU$START 689 0000000000001180 00000000001C1280 FDUSHR FDU$START 489 0000000000000530 0000000000140F10 FDU$MAIN FDU$MAIN 916 0000000000000F60 00000000001407B0 _AMAC$CODE AMAC$EMUL_CALL 394 0000000000000250 000000000013ED00 LIB$INITIALIZE LIB$INITIALIZE+00370 000000000021CA60 000000000026CA60 IMAGE_MANAGEMENT SYS$IMGSTA+00560 FFFFFFFF80B17520 FFFFFFFF80B17520 Debugging made it clear that the linkage address was incorrect for the UAR$FIELD_DONE routine. The fix selected was to correct the invalid reference to the routine UAR$FIELD_DONE in FDVCOMSUB.BLI from "external" to "external routine", to ensure that the linker generates correct linkage for the routine reference. On OpenVMS I64, a compiler must generate its own function descriptor to reference an external routine. The address of the generated function descriptor is used as the linkage address for the external routine. FORTRAN has only the EXTERNAL statement available as a standard language construct. Although it was originally intended only for external routine references, it is also often used for external data references, so it is required to work for both purposes. Thus, for OpenVMS I64, and for source languages other than FORTRAN, any incorrect reference to an external routine as though it were external data (or the reverse; see section 2.6.2) will not work and must be corrected. Such a correction is compatible with VAX and Alpha as well. 2.6.2 2004-08-30: CONVERR/NONPRICHA application failures; table TSS$GZ_NON_PRINTABLE_CHAR_TABLE improperly declared A CONVERR/NONPRICHA fatal error occurred on OpenVMS I64 when attempting to check an output form field value for non-printable characters. This problem caused many of the TDMS regression tests to fail. %TSS-F-CONVERR, data type conversion error -TSS-I-TRAOUTPUT, BUG421_RECORD.BUG421_RECORD.F1[1] of value "THIS IS LINE # 1 " output to F1[1] -TSS-I-TRAFIELD, BUG421_RECORD.BUG421_RECORD.F1[1] is length=80, dtype=37, class=11 at %X0059AE70 -TSS-I-TRAFIELD, F1[1] is length=80, dtype=14, class=1 at %X0059AED0 -TSS-F-NONPRICHA, field contains non-printable characters -CMU-I-SIGNAL_FROM, PC=0011DB20, PS=0000001B break on exception preceding TSS$REQMAP\TSS$$REQ_MAP_CONV_ERR\%LINE 1949+0CE 1949: SIGNAL( ! Signal the error. DBG> show call module name routine name line rel PC abs PC TSS$REQMAP TSS$$REQ_MAP_CONV_ERR 1949 00000000000045E0 000000000011DB20 TSS$REQMAP TSS$$REQ_MAP_ONE_ONE 1586 0000000000002F90 000000000011C4D0 TSS$REQMAP TSS$$REQ_MAP_MANY_MANY 1206 0000000000001F50 000000000011B490 TSS$REQMAP TSS$$REQ_MAP 602 0000000000000C60 000000000011A1A0 TSS$REQ TSS$$REQUEST_PHY 1425 0000000000002E80 00000000000E6060 BLI$CALLG 000000000000A160 0000000000072160 TSS$THD TSS$$THD_CALL 927 0000000000000E90 00000000000EB870 TSS$THD TSS$$THD_LOOP 836 0000000000000C30 00000000000EB610 BLI$CALLG 000000000000A160 0000000000072160 THD$COMMON_CODE THD$CALL_THREAD 1207 0000000000001650 000000000006AED0 THD$COMMON_CODE THD$START 1141 00000000000014A0 000000000006AD20 THD$COMMON_CODE THD$LAST_CHANCE 987 0000000000000F90 000000000006A810 THD$COMMON_CODE THD$KPS_START 934 0000000000000EE0 000000000006A760 SYSTEM_PRIMITIVES_MIN EXE$KP_START+00300 FFFFFFFF800916E0 FFFFFFFF800916E0 THD$KPS THD$SWITCH_STACK 539 00000000000001B0 00000000000661B0 THD$COMMON_CODE THD$RMS_DONE 2051 0000000000004D30 000000000006E5B0 PROCESS_MANAGEMENT EXE$AST_RETURN FFFFFFFF804D1870 FFFFFFFF804D1870 THD$COMMON_CODE THD$RESUME 1384 0000000000001F60 000000000006B7E0 TSS$THD TSS$$THD_CONTNUE 753 0000000000000560 00000000000EAF40 TSS$REQ TSS$$REQUEST 1019 00000000000014C0 00000000000E46A0 TSS$ENTRY TSS$$ENTRY_CALL 1900 0000000000003340 00000000000C6020 TSS$ENTRY TSS$$ENTRY 1507 0000000000002670 00000000000C5350 TSS$ENTRY TSS$REQUEST 2640 0000000000005F30 00000000000C8C10 BUG421 0000000000000510 0000000000020510 IMAGE_MANAGEMENT SYS$IMGSTA+00560 FFFFFFFF80B17520 FFFFFFFF80B17520 Debugging made it clear that the table array address provided to the SCANC operation was incorrect, and that the invalid table data caused SCANC to return a non-zero address value, even though all of the output characters were printable. The fix selected was to correct the invalid references to the table array TSS$GZ_NON_PRINTABLE_CHAR_TABLE in both TSSCPYSCR.BLI and TSSEXCL.BLI from "external routine" to "external", to ensure that the linker generates correct linkage for the data reference. This array is defined with a GLOBAL BIND in TSSDATA.BLI. It was already referenced correctly in TSSREQINS.BLI, TSSREQMAP.BLI, and TSSWBRK.BLI. However, the invalid references apparently prevailed without warning when the linker consolidated all of them. The address of a generated function descriptor apparently replaced the address of the table array for all of the references, whether valid or not. SCANC and other VAX BLISS built-ins are transparently implemented as macros in the STARLET library for Alpha and I64 BLISS. This is how the source listing looks: 1573 IF SCANC( ! If SCANC returns non-zero (namely 1574 ! the address of the byte that was 1575 ! non-printable), 1576 OUTPUT_DSC[DSC$W_LENGTH], 1577 ! Address of length of string. 1578 .OUTPUT_DSC[DSC$A_POINTER], 1579 ! Address of string. 1580 TSS$GZ_NON_PRINTABLE_CHAR_TABLE, 1581 ! Address of translation table. 1582 MASK ! Mask to compare with table entries. 1583 ) 1584 NEQ 0 ! Non-zero means a non-printable char. 1585 THEN ! then signal a dtype conv error. 1586 TSS$$REQ_MAP_CONV_ERR( ARGPTR(), %REF( TSS$_NONPRICHA ) ); Shown below is the BLISS source code as seen by the compiler after SCANC macro expansion. For clarity, the text has been formatted, and the "$SCANC_" prefix has been removed from the local variables. IF ( LOCAL LENA : WORD INITIAL(.(OUTPUT_DSC[0,0,16,0])<0,16,0>), ADDR : REF VECTOR[,BYTE] INITIAL(.OUTPUT_DSC[4,0,32,1]), TBLADDR : REF VECTOR[,BYTE] INITIAL(TSS$GZ_NON_PRINTABLE_CHAR_TABLE), MASKA : BYTE INITIAL(.(MASK)<0,8,0>), I; I = 0; WHILE (.I LEQ .LENA-1) DO BEGIN IF ((.MASKA AND .TBLADDR[.ADDR[.I]]) NEQ 0) THEN EXITLOOP; I = .I + 1; END; IF (.LENA EQL .I) THEN 0 ELSE ADDR[.I] ) NEQ 0 ! Non-zero means a non-printable char. THEN ! then signal a dtype conv error. TSS$$REQ_MAP_CONV_ERR( ARGPTR(), %REF( TSS$_NONPRICHA ) ); 2.6.3 2004-09-03: ACCVIO at PAG$AFK_AST line 1167 in TSS_21555; AFK AST delivery transfer problem as initially ported An ACCVIO fatal error occurred during AFK AST delivery: %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000013, PC=0000000000106BD0, PS=0000001B break on unhandled exception preceding TSS$PAGAFK\PAG$AFK_AST\%LINE 1167+20 1167: IF ( (.AFK[AFK$L_KEY_ID] EQL .KEY_ID) AND (.AFK[AFK$V_VALID]) ) DBG> e afk TSS$PAGAFK\PAG$AFK_AST\AFK: 0FFFFFFFF DBG> e AFK[AFK$L_KEY_ID] %DEBUG-E-NOACCESSR, no read access to address 0000000000000013 DBG> show call module name routine name line rel PC abs PC TSS$PAGAFK PAG$AFK_AST 1167 0000000000001400 0000000000106BD0 PROCESS_MANAGEMENT EXE$AST_RETURN FFFFFFFF804D1870 FFFFFFFF804D1870 PROCESS_MANAGEMENT SYS$HIBER+00350 FFFFFFFF80574260 FFFFFFFF80574260 TSS_21555 TSS_21555 84 0000000000000820 0000000000020820 IMAGE_MANAGEMENT SYS$IMGSTA+00560 FFFFFFFF80B17520 FFFFFFFF80B17520 The environment value provided by the transfer routine OTS$JUMP_TO_BPV to the target routine PAG$AFK_AST (in R9 using special linkage) was intended to be a pointer to the bound function descriptor at the beginning of the PAGCHN data structure, but it was not. This problem occurred because a pointer to the target function descriptor had been specified instead for the FDSC$Q_TARGET_ENVIR field of the bound function descriptor. The solution was to correctly specify a pointer to the bound function descriptor for its own FDSC$Q_TARGET_ENVIR field (as the desired context for PAG$AFK_AST), exactly as specified for its own FDSC$Q_OTS_PSEUDO_GP field (as indicated by the OpenVMS I64 Calling Standard document). Please refer to section 1.5.1 for further details. 2.6.4 2004-09-06: ACCVIO at TIO$OUT line 693 in TSS_21555; problem with "thread" context in exit handler %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000049C, PC=00000000000B7CF1, PS=0000001B break on unhandled exception preceding TIO$OUTPUT\TIO$OUT\%LINE 693+5F 693: .TIO_DISPTBL[ .FUNCTION_CODE*NUM_DEV_CODE + .TWA[TWA_U_DEV_CODE ]]); DBG> show call module name routine name line rel PC abs PC TIO$OUTPUT TIO$OUT 693 0000000000000301 00000000000B7CF1 TIO$OUTPUT TIO$TERMTERM 786 0000000000000B10 00000000000B8500 FDV$DISPCH FDV_EXIT_HANDLER 566 00000000000001A0 0000000000091EE0 SYSTEM_PRIMITIVES_MIN AMAC$EMUL_CALL +00250 FFFFFFFF8019C4C0 FFFFFFFF8019C4C0 IMAGE_MANAGEMENT EXIT_CALLBACK +00650 FFFFFFFF80B16A60 FFFFFFFF80B16A60 IMAGE_MANAGEMENT SYS$EXIT +00420 FFFFFFFF80B13B00 FFFFFFFF80B13B00 DEC$FORRTL DFOR$EXIT +00030 0000000000038430 FFFFFFFF82B38430 TSS_21555 TSS_21555 87 0000000000000880 0000000000020880 IMAGE_MANAGEMENT SYS$IMGSTA +00560 FFFFFFFF80B17520 FFFFFFFF80B17520 DBG> e/i @pc TIO$OUTPUT\TIO$OUT\%LINE 693+5F: ld1 r10 = [r10] DBG> e r10 TIO$OUTPUT\TIO$OUT\%LINE 688\%R10: 000000000000049C DBG> e twa TIO$OUTPUT\TIO$OUT\TWA: 00000164 DBG> type 684 module TIO$OUTPUT 684: TWA = TCA[TCA_R_TWA]; DBG> e tca TIO$OUTPUT\TIO$OUT\TCA: 00000000 FDV_EXIT_HANDLER was called as usual during image rundown, and attempted to reset the terminal attributes. Image exit may have already removed the THD "thread" context call frames. TSS$QIOW had inadvertently saved and restored a value of zero for the FDR_A_CUR_TCA field of the FDV$$R_ROOT global data structure. This caused the failure in TIO$OUT when it was next called. The solution was to modify TSS$QIOW in TSSQIOW.BLI to check the value of the saved context in HOLD_CTX, and to restore it only if non-zero. This preserves the context specified by the exit handler. This problem was first noted to occur reliably on OpenVMS I64. Then, five months later, it was noted to occur infrequently on OpenVMS Alpha V8.2 as well; see section 2.9.2. The appearance of this problem in conjunction with OpenVMS V8.x (both I64 and Alpha) is believed to result from some change in timing or sequence of events during image exit. 2.7 Corrections for I64 TDMS E8.2-20040920B After upgrading the OpenVMS I64 internal baselevel from XADH to XAHS on the system used to build I64 TDMS, re-linking the various images produced "%ILINK-I-DIFTYPE" messages, indicating that certain object modules were still incorrectly referencing certain external functions, although there had been no apparent resulting problems. 2.7.1 2004-09-20: %ILINK-I-DIFTYPE for function THD$KPS_START Module THD$KPS from source file THDKPS.MAR had incorrectly referenced the function THD$KPS_START (and others) with the .EXTRN directive. This was corrected (for OpenVMS I64 only) to use the .CALL_LINKAGE directive instead. 2.7.2 2004-09-20: %ILINK-I-DIFTYPE for function LIB$INITIALIZE Module TSS$MISC from source file TSSMISC.BLI, module FDV$MEMRES from source file FDVMEMRES.BLI, module FDU$MAIN from source file FDU.BLI, and module RDU$MAIN from source file RDU.BLI, had all incorrectly referenced the function LIB$INITIALIZE with the "external" statement. These were all corrected to use the "external routine" statement instead. 2.8 Corrections for I64 TDMS V8.2-20050131A 2.8.1 2005-01-11: Kit rebuilt due to incompatible change in linker output ACMS Engineering reported that the I64 TDMS E8.2-20040908A TSSSHR, FDU, and RDU images were all failing to run on OpenVMS I64 V8.2, with a %SYSTEM-F-NOLICENSE error. Further investigation showed that images from the kit that had been pre-linked on E8.2 did not fail to run. Only images re-linked on V8.2 during installation (by default options) were failing to run. The cause was attributed to an incompatible change in linker output between E8.2 and V8.2, causing the expected and actual validation checksums to differ. The solution chosen was to completely rebuild the kit from the sources on OpenVMS I64 V8.2, to establish validation checksums that are compatible with the new linker output format. 2.9 Corrections for TDMS V8.2-A20050228 (Alpha and I64) 2.9.1 2005-02-22: New TDMS$TOLERANT logical name A new customer in Finland who had previously been using Praxa TDMSE found that applications were failing frequently with %TSS-F-CONVERR when Alpha TDMS was used instead. This problem was caused by the presence of non-printable characters embedded within text fields to be displayed on TDMS forms. The solution chosen was to check for the logical name TDMS$TOLERANT whenever a non-printable character is detected in an output field. If this logical is defined, all non-printable characters within this form field are translated to blanks. The occurrence is not signaled, but is instead written to the trace log (if any) as an informational message (%TSS-I-BLANKED). Without the logical name, an embedded non-printable character terminates the request with failure status. Calling TSS$SIGNAL then produces text similar to the following example: %TSS-F-CONVERR, data type conversion error -TSS-I-TRAOUTPUT, BUG421_RECORD.BUG421_RECORD.F1[1] of value "THIS.IS LINE # 1 " output to F1[1] -TSS-I-TRFIELD, BUG421_RECORD.BUG421_RECORD.F1[1] is length=80, dtype=37, class=11 at %X0057CF00 -TSS-I-TRAFIELD, F1[1] is length=80, dtype=14, class=1 at %X0057CF60 -TSS-F-NONPRICHA, field contains non-printable characters With the logical name defined, the same occurrence does not terminate the request. The non-printable characters are translated to blanks. Text similar to the following example is immediately written to the trace log (if any): %TSS-I-BLANKED, non-printable field character(s) displayed as blank(s) -TSS-I-TRAOUTPUT, BUG421_RECORD.BUG421_RECORD.F1[1] of value "THIS IS LINE # 1 " output to F1[1] -TSS-I-TRAFIELD, BUG421_RECORD.BUG421_RECORD.F1[1] is length=80, dtype=37, class=11 at %X0057CF00 -TSS-I-TRAFIELD, F1[1] is length=80, dtype=14, class=1 at %X0057CF60 2.10 Corrections for TDMS V8.2-B20050228 (Alpha and I64) 2.10.1 2005-02-28: Maximum "threads" changed back to 4096 Regression testing (the OPN010 test) identified a problem with the V8.2-A20050228 kit. When merging the THDCOMMON.BLI source files from Alpha and I64, the maximum number of concurrent "threads" was inadvertently changed from 4096 to 100 for Alpha. This limitation could potentially have caused a problem (%TSS-F-BUGCHECK) in production, if an attempt had been made to support more than 100 terminals with a single ACMS server process. This limit was changed back to 4096. 2.10.2 2005-02-28: Now using common source code and build procedures The problem described in section 2.6.4 for I64 TDMS was later noted to occur infrequently during Alpha TDMS V1.9-20031201C regression testing on OpenVMS Alpha V8.2. The solution chosen was to provide rebuilt kits for both Alpha TDMS and I64 TDMS, using the same corrected I64 TDMS source code and consolidated build procedures. This problem is apparently new for OpenVMS V8.x. Users of Alpha TDMS V1.9-20031201C on OpenVMS Alpha versions prior to V8.2 are not required to upgrade to Alpha TDMS V8.2-B20050228 at this time. 2.11 Corrections for TDMS V2.0-C20060831 (Alpha and I64) 2.11.1 2006-08-31: In TDMS V2.0, I64_TDMS_DEV, ALPHA_TDMS_DEV, and VAX_TDMS_DEV was the full development kit license for I64, ALPHA, and VAX platforms respectively. Similarly the run time kit licenses were I64_TDMS_RTO, ALPHA_TDMS_RTO, and VAX_TDMS_RT. These licences are no longer valid. TDMS and TDMS-RT will be used as the license for full development and run time kits respectively, for all the platforms. 3 ________________________________________________________________________________ Restrictions The following sections describe restrictions in TDMS. 3.1 Incompatibility with Previous Versions Requests built with previous versions of RDU will continue to execute with the TDMS Version 1.7 or higher run-time system. However, requests built with RDU Version 1.7 or higher will not run under previous versions of TDMS. If distributed ACMS applications are used, requests built with RDU Version 1.7 or higher cannot be used until all the remote nodes are updated to Version 1.7 or higher of TDMS. 3.2 Command Line Editing Turned Off When TSS$OPEN is called, TDMS turns off command line editing. This allows TDMS to define the function keys F6 through F10 with the DEFINE KEY AS and PROGRAM KEY IS instructions. Command line editing is, therefore, unavailable within Datatrieve after a procedure is called that uses TDMS, unless you restore command line editing. You can restore command line editing with the FN$DCL("SET TERMINAL/LINE") Datatrieve command. See the Datatrieve documentation for more information on this command. TDMS restores command line editing when you call TSS$CLOSE. Therefore, command line editing is available within Datatrieve and at your terminal after you close your TDMS channel. However, if you end a TDMS session without calling TSS$CLOSE (for example, by pressing CTRL/Y), TDMS cannot restore command line editing. 3.3 Converting FMS Forms to TDMS Forms The /FORM_FILE qualifier to the FDU CREATE FORM command allows you to convert FMS forms to TDMS. You cannot convert FMS forms files that are larger than approximately 128 blocks to TDMS with the /FORM_FILE qualifier. If you attempt to convert an FMS form that is too large, you receive the following error messages: %FDU-E-NO_ENDPAK, Invalid input file, BFD end package not found. %FDU-E-NO_INBFD, Unable to set up Form Editor data structures %FDU-E-NOFRMCRE, Form FORMNAME not created You should not attempt to convert FMS forms that are larger than 128 blocks to TDMS. If you receive these messages, you may also receive the following message: %SYSTEM-F-ROPRAND, reserved operand fault at PC=00070C3F, PSL=03C00000 This message indicates that virtual memory has not been reset correctly after the attempt to convert a large FMS form. You may be able to issue a number of FDU commands before this message is displayed, or it may be displayed in response to the command you issue directly after the attempt to convert a large FMS form. To prevent the possibility of receiving the reserved operand fault message, exit from FDU immediately after you receive the messages indicating that your large form cannot be created. Then, re-enter FDU to perform any other tasks. 3.4 Terminal Hang in XOFF Mode If an image exits without first closing all its channels, the TDMS exit handler attempts to restore terminal characteristics and may hang if the terminal is in XOFF mode. If the image calls TSS$CLOSE before it exits, the exit handler does not hang. The ACMS Execution Controller and the Command Process use TDMS and, therefore, are affected by the way TDMS handles terminals in XOFF mode. Stop application operations ($ACMS /STOP APPLICATION) should not hang, but attempts to stop the ACMS terminal subsystem ($ACMS/STOP TERMINALS) may fail if users are logged in and a terminal is in XOFF mode. To prevent problems when stopping the terminal subsystem, cancel all users ($ACMS/CANCEL USER) before stopping the terminal subsystem. 3.5 Optional Parameter for TSS$DECL_AFK If you do not include the optional parameter key-astadr in the TSS$DECL_AFK call, you may get errors. Include the key-astadr parameter in this call as a workaround to prevent errors. 3.6 Clearing the Event Flag on Asynchronous TDMS Calls TDMS incorrectly assumes that event flags passed to TDMS asynchronous calls have already been cleared. Before passing the event flag parameter to a TDMS asynchronous call, you must clear the event flag using the $CLREF system service. 3.7 Optional Parameters for Asynchronous Calls If optional parameters are not included on the asynchronous programming calls, you may get errors. Supply the optional parameters as a workaround to prevent errors. 3.8 TDMS Exit Handler The first call to TSS$OPEN establishes a TDMS exit handler that cancels all subsequent TDMS input. OpenVMS invokes this exit handler when the program exits. If you declare an exit handler, and your exit handler is invoked after the TDMS handler, any request called from your exit handler does not complete properly. The solution is to declare your exit handler after the first call to TSS$OPEN. Then, your exit handler is called before the TDMS handler and any requests are completed properly. 3.9 Microcode Problem with VT100 Terminals A problem with the VT100 terminal causes the microcode to malfunction if a scrolled area immediately follows a double-size or double-wide line and the terminal is in jump scroll set-up mode. This malfunction causes random or incomplete movement of the scrolled area, disappearance of the cursor, nonsense character patterns on the screen, or a combination of these problems. If you define any double-size or double-wide lines while running FDU, the form editor forces the terminal into smooth scroll set-up mode to avoid this problem. However, TDMS does not make any test at run time when executing a request that uses a form with double-size or double-wide lines. This restriction is permanent. Do not define scrolled areas immediately adjacent to double-size or double-wide lines unless all VT100 terminals running the application are always set to smooth scroll mode. 3.10 RDU Return to DCL Level Ordinarily, when RDU (or any program) is already at its page maximum and it requests more memory, the OpenVMS system returns an error to the program. This error can be signalled by RDU, which displays a message indicating insufficient memory. However, if the error occurs when RDU attempts to expand its stack space, no error can be signalled because there is no stack space. Under these circumstances, the OpenVMS system may exit from RDU, returning you to the DCL level, or it may end the entire process, leaving the terminal logged out. RDU can do nothing to recover or display a message in either case. You can solve this problem by: o Having a system manager raise the VIRTUALPAGECNT system parameter (and, if necessary, the PGFLQUOTA for your user name) o Reducing the size of your request 3.11 Enqueue Limit Problem in Building Request Library Files When building request library files that contain a large number of requests, forms, or records, you may get the following message: CDD-F-LCKNOTGRA, lock not granted When this error occurs, RDU immediately exits and returns you to the DCL level. The message indicates that RDU attempted to use more locks on the CDD than the enqueue limit on the current process allows. The solution is to have your system manager raise the enqueue quota for your user name. The default for ENQLM quota is 20. Generally, TDMS requires an ENQLM of 40. If you raise your quota and still have the problem, try raising the quota to 100. If you need to raise the quota above 100 to make a BUILD LIBRARY command work, please submit an SPR (see Chapter 5). 3.12 TDMS Floating-Point Support TDMS does not have a form field data type that you can use for both input and output of floating-point record data. You can map such data for output to text fields (thus producing exponential notation). You can also map such data for input, but only from numeric form fields (in which case, the input data may have only the forms defined by the picture N or picture 9 data types). You can work around this restriction by doing floating-point input from a free-format text field to a record text field. Then, using either OpenVMS or language-specific conversion utilities, create a floating-point number in the target data item. 3.13 TDMS D-Format Floating-Point Problem The data conversion routines used by TDMS may provide only 7 digits of precision on a D-format floating-point conversion. Therefore, some values displayed at run time may be rounded. Note that rounding does not occur on input values. 3.14 Type-Ahead Buffer Overflowing When the type-ahead buffer for the terminal is full, TDMS may lose partial escape sequences, causing the remainder of the sequence to be used as input to a form field. You can set the TT$M_HOSTSYNC set mode characteristic for your terminal to prevent the type-ahead buffer from overflowing in one of the following two ways: o Enter the DCL command SET TERMINAL/HOSTSYNC. o Include the QIO function IO$_SETMODE in the host program. When the TT$M_HOSTSYNC is not set, CTRL/G (bell) is returned to inform you that the type-ahead buffer is full. If TT$M_HOSTSYNC is set, the terminal driver stops input by sending a CTRL/S to the terminal; the terminal responds by sending no more characters. The driver sends a CTRL/Q to restart transmission when the type-ahead buffer empties completely. See the discussion of the terminal type-ahead buffer or the SET TERMINAL DCL command in the OpenVMS documentation set for more information. 3.15 PASCAL and Parameter Passing Some TDMS routines require a variable number of parameters. For instance, you may need to pass any number of records (as few as zero, or as many as 252) to TSS$REQUEST, based on the requirements of the specific request. PASCAL checks the actual parameters against their formal declarations very closely. It can be difficult to declare TSS$REQUEST in a way that is valid for any call made to it. Each time you call TSS$REQUEST, you may pass a different number of records, or the records may have different types. You can use the [LIST] attribute to specify that the last formal parameter really represents a list; a variable number of actual parameters. You can also use the %REF foreign mechanism specifier with actual parameters to override formal parameter type checking. The following routine declaration and sample TSS$REQUEST calls illustrate the use of these features: [EXTERNAL] FUNCTION TSS$REQUEST (VAR channel : UNSIGNED; VAR library-id : UNSIGNED; %STDESCR request : string; VAR records : [LIST] integer) :UNSIGNED;EXTERN; . . . Status := TSS$REQUEST(channel, library, request, %ref record_1); Status := TSS$REQUEST(channel, library, request, %ref record_1, %ref record_2, %ref record_3); The RECORD_1, RECORD_2, and RECORD_3 actual parameters pass the addresses of records used in the requests being invoked. The %REF foreign mechanism specifier causes PASCAL to pass these actual parameters without verifying that they are declared in the routine declaration. PASCAL also does not verify that the actual parameters match their declared types. You must ensure that the parameter contains the type of data the called routine expects; in this case, an address. The routine declaration need not have declared the records parameter. The records parameter is declared to help document the purpose of the RECORD_1, RECORD_2 and RECORD_3 actual parameters. See the PASCAL documentation for more information on foreign mechanism specifiers. 3.16 TDMS Supported Terminals You may encounter the following known problems when you run TDMS on supported terminals: o PC 325, PC 350 In RDU, a request can set the Signal mode to either ring the bell or reverse the screen (that is, SIGNAL MODE IS BELL or REVERSE). If the Signal mode is set to reverse, then at run time the screen is reversed. However, the screen is also repainted twice during this signal to the operator. o DECmate II When a 132-column form is displayed followed by an 80-column form, the screen size is not always reset to its proper width. This problem does not affect how the application runs. 3.17 Calls to TDMS and Datatrieve Calls to TDMS routines should not be mixed with calls to callable Datatrieve that use the Datatrieve/TDMS interface within the same application. If an application must mix calls to TDMS and Datatrieve, be sure that you close the TDMS channel by calling TSS$CLOSE before you call Datatrieve to display a TDMS form (through the DISPLAY FORM statement, for example). Alternatively, you can open the TDMS channel after you call Datatrieve to display a TDMS form. 3.18 Accessing a CDD Node That Has an Associated Password TDMS provides different syntax than CDDL does for accessing a CDD node that has an associated password. The following examples show both the CDDL syntax and the TDMS equivalent: CDDL uses: DMU> LIST form-name(Password) TDMS uses: FDU>MODIFY FORM "form-path-name(Password)" RDU>MODIFY REQUEST "request-path-name(Password)" 3.19 Uncorrected Hardcopy Documentation Errors As mentioned in section 2.1.10, the hardcopy VAX TDMS Request and Programming Manual provides an incorrect RDB example in section 16.4.3.3 on page 16-24. As mentioned in section 2.1.11, the hardcopy VAX TDMS Reference Manual provides an incorrect example of the RDU SPAWN command in section 2.29A on page 2-79.3. These examples were both corrected in the online HTML documentation, on or before 2004-04-14. The corrections appeared section 2.1.10 of the VAX TDMS release notes. However, they were not provided in the available SDML source files, and they were never published in the hardcopy documentation. 3.20 Indexed fields restriction in FDU Using FDU, the assignment of video attributes to a selected set of indexed fields is not supported in this version of TDMS. Attempts to assign such attributes to this type of field will result in an error signalled to the terminal (ringing the terminal bell). A workaround for this restriction is to first create the fields as non-indexed, then assign video attributes. After that the fields may be changed to an indexed type. 3.21 Horizontally indexed field restriction in FDU LIST If a horizontally indexed field is contained within a scrolled region of a TDMS form, the output from a FDU LIST FORM command incompletely lists field attributes for horizontally indexed fields within a scrolled region. The FORM IMAGE section of the FDU LIST FORM output does not indicate all horizontal occurrences of the indexed field. The first occurrence of the horizontally indexed field on each line within the scrolled region is indicated. The horizontally indexed attribute is omitted in the FIELD DEFINITIONS section of the FDU LIST FORM output. The TDMS form and its fields have the correct and expected attributes although the form listing does not completely specify them. 3.22 Abnormal Exits [CONTROL/Y] from TDMS Applications Errors may result if a TDMS user abnormally exits from a TDMS application which has outstanding terminal I/O, and the new TDMS exit handler is invoked. The TDMS exit handler attempts to complete the terminal I/O until a valid TDMS terminator is received. This may in turn cause the request to be continued in an inconsistent state, which may result in errors being returned to the TDMS application. For example, if a TDMS user types "CONTROL/Y" and then "EXIT" to exit the TDMS application, and the logical "TSS$EXIT_CLEANUP" is defined to be true (or is not defined at all), the TDMS exit handler will be invoked. The user process will attempt to resume the TDMS request. An internal error may result if any request inconsistencies are detected, such as if asynchronous operations are not completed normally. Note that the terminal characteristics may not be reset to their original values if the TDMS exit handler is not invoked. 3.23 New default maximum number of created threads and default stack size for each created thread Starting with the acceptance field test version, Alpha TDMS has an AST-based threading package that is very similar to the one used by VAX TDMS, derived from the THD facility of the ACMS Alpha sources. This change has a number of potential advantages and drawbacks, compared to the previous experimental Pthreads package: Advantages: (1) TDMS remains fully compatible with ACMS. (2) Based on proven ACMS THD implementation. (3) Thread-enabled status and thread safety of applications and TDMS under true multithreading conditions are no longer pressing issues. (4) Simplifies TDMS debugging. Drawbacks: (1) TDMS execution is effectively serialized, as it was on VAX. Only one thread per process can execute at any given time. This may limit multi-user performance under some circumstances. (2) THD is a very limited, non-standard implementation of threading, first written in the early 1980's. (3) Linear scaling may not be fully attainable on OpenVMS Alpha, since the THD implementation used by both ACMS and TDMS is not likely to be updated for that platform. VAX TDMS allows a maximum of 1024 threads, with a maximum stack size of 64 KB for each thread. Alpha TDMS now specifies higher default values; a maximum of 4096 threads, with a default stack size of 128 KB for each thread. If smaller or larger values are required, the TSS$THD_SETUP routine can be called before any TDMS threads are created. TSS$THD_SETUP returns a success (odd) or failure (even) status, and is called with three input arguments: (1) Maximum number of threads; an optional read-only longword, passed by reference; the default value is 4096. (2) Default stack size in 512-byte pagelets; an optional read-only longword, passed by reference; the default value is 256. (3) The "throw-away" event flag number for threaded I/O; an optional read-only longword, passed by reference; the default value is 31. Each TSS$OPEN call creates one TDMS thread. The job pagefile quota (PGFLQUOTA) must be large enough to support the required virtual memory. The default values for TDMS threads now require a PGFLQUOTA of at least 1,050,000 pagelets, and enough pagefile space for all concurrent jobs that may require it. 3.24 Using TDMS with ACMS 3.24.1 ACMS logical names and ACMSGEN parameters Two logical names, translated by the ACMSEXC process, can be used to control the use of TDMS with ACMS: ACMS$LOCAL_TDMS_IN_AGENT, when set to "T", "t", or "1", forces all TDMS I/O requested by the application to execute within the ACMSCP process. ACMS$DEFAULT_MENU_FORMS_PRODUCT specifies the forms product to be used by the ACMSCP process. The choices are "TDMS" or "DECFORMS". The dynamic ACMSGEN parameter MAX_TTS_CP (default 20) controls the number of terminals allowed for each CP. It may need to be changed, either to accommodate more users, or to improve performance. ACMS limits the number of CP's on the system to a maximum of 127. 3.24.2 Use of multiple screen managers When using TDMS in the same application with screen management (e.g. SMG) routines and/or with other forms products (e.g. FMS or DECforms), TDMS is not notified and does not check whether any of these has changed the display state (e.g. screen width). This can cause incorrect display to the screen, for example, during a sequence of ACMS task calls or chained tasks that perform both TDMS and non-TDMS display I/O. ACMS user-written request procedures (URPs) can be used with the request interface (RI), providing greater display independence. TDMS should be used within URPs and application programs that call TSS$OPEN just before, and TSS$CLOSE just after, TSS$REQUEST call(s). REFRESH and REMOVE statements should be added to any DECforms form source (.IFDL) files. Use methods like these to ensure that the display state is always saved and restored, preventing conflicts with other display I/O. 3.24.3 CP's die if TSSSHR is present but license key is expired or missing ACMS attempts to activate and make use of the TSSSHR.EXE shareable image. Unfortunately, this will cause its CP's to terminate if any failure occurs, other than simply not finding the file. This includes a NOLICENSE error, which occurs when the appropriate TDMS license key either terminates (expires), or fails to load for any other reason. When this happens unexpectedly, the quickest way to get ACMS up and running again may be to rename or delete all "SYS$SHARE:TSSSHR.EXE;*" files. Another way is to issue the following DCL command, and add it to the system startup procedure: $ DEFINE/SYSTEM/EXEC TSSSHR _NL: If the ported TDMS software will no longer be needed on the system disk, use the DCL "PRODUCT REMOVE" command to completely remove it instead. If TDMS is still needed, please obtain, register, and load an appropriate license key for the system. Please refer to section 1.2.1 for further details. 3.25 TDMS software is limited to 32-bit addressing and call arguments The ported TDMS software is currently built with 32-bit compiler options. This helps to maintain near-total compatibility with VAX TDMS. It also defers or eliminates the extensive source code changes that would be required for full 64-bit operation. Hewlett-Packard Company and any successors or assignees reserve the right to determine whether to pursue a possible 64-bit version of TDMS. 3.26 Obtaining support for ported TDMS software TDMS software is ported to (and maintained on) OpenVMS Alpha and OpenVMS I64 only under contracted consulting services to specific customers. DIGITAL made an early decision not to release or support TDMS software as a Commercial Off-The-Shelf (COTS) product on new hardware platforms. Hewlett-Packard Company is not likely to reverse that decision. The Customer Support Centers and Software Engineering Groups specifically do not (and have no plans to) provide product support for customer use of Alpha TDMS or I64 TDMS. Please do not contact them for this purpose. The HP TDMS Porting Services Team is solely responsible for the support and maintenance of ported TDMS software, as provided under contract to each specific customer. Robert Sampson (e-mail: Robert.Sampson@hp.com) is currently assigned to deliver this consulting service. Please contact him directly for help. Use of terminal-based (often called "legacy") applications has declined, largely replaced by web browser-based user interfaces. Continued strong interest and support from remaining TDMS customers will drive any possible future TDMS development. 3.27 Required and recommended software versions The major software components related to Alpha TDMS and I64 TDMS are listed below. Kits should be installed in the order shown. Some software may require a license and/or PAK ("Product Authorization Key"). The versions listed are those used to build and/or test this release of Alpha TDMS and I64 TDMS, and/or the recommended versions for use with Alpha TDMS and I64 TDMS. TSSSHR = TDMS run-time shareable image FDU = TDMS form development utility RDU = TDMS request development utility Regres = regression tests Sample = sample applications C = are compiled using L = are linked using R = are run using Y = yes N = no K = kit installation option U = user option TSSSHR FDU RDU Regres Sample Software AXPVMS Version I64VMS Version C L R C L R C L R C L R C L R ============ =============== =============== ====== ====== ====== ====== ====== OpenVMS V8.2 V8.2 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Oracle Rdb T7.2 T7.2 Y N Y Y N Y Y N Y Y N Y Y N Y Oracle CDD/R T7.2 T7.2 Y Y Y Y Y Y Y Y Y Y N Y Y N Y BLISS-32 V1.11-004 V1.12-067 Y - - Y - - Y - - Y - - N - - MACRO-32 V4.1-20-3381U T1.0-97-50E9T Y - - Y - - Y - - Y - - N - - MACRO-64 V1.2-108 not used Y - - Y - - Y - - N - - N - - BASIC V1.5A V1.6 N - - N - - N - - Y - - Y - - DEC$BASRTL V01-028 V01-028 N N N N Y Y N Y Y Y Y Y Y Y Y C V6.5-001 S7.1-012 Y - - Y - - Y - - Y - - N - - DECC$SHR V8.2-00 V8.2-00 N N N N N N N N N N N N N N N Cobol V2.8-1380 V2.8-1380 N - - N - - N - - Y - - Y - - DEC$COBRTL V2.8-775 V2.8-775 N N N N N N N N N Y Y Y Y Y Y Fortran V7.6-4897-48EC7 T8.0-4407-50E5L N - - N - - N - - Y - - Y - - DEC$FORRTL V01-05.913 T01-01.003 N N N N N N N N N Y Y Y Y Y Y Pascal V5.9-95 T5.9-3 N - - N - - N - - Y - - N - - PAS$RTL V5.0-25 V5.0-24 N N N N N N N N N Y Y Y N N N DECwindows V1.5-041115 V1.5-041115 ACMS V4.5 V4.5 Datatrieve T7.3 T7.3 Kednos PL/I V4.4 not available Synergy/DBL unknown unknown 4 ________________________________________________________________________________ Known or Suspected Problems or Limitations This chapter contains a list of problems with TDMS software. 4.1 Incorrect error reporting of undeclared field in request file If an undeclared field is specified in a reverse field statement of a request file, then the field which proceeds the undeclared one will be incorrrectly reported as the one in error. This is purely a display problem and does not affect the internals of TDMS. Example: (Reverse field statement in request file) REVERSE FIELD field_a, undeclared_field; (Error reported during creation of request library) 010 field_a, 1 %RDU-E-ENOSUCHFIELD, no such field %RDU-E-NOMAPCRE, no mappings created 4.2 Incorrect Location Specified of File Installed on Your System In the TDMS Installation Guide, Appendix B, the location of the file TDMS019_FILES.DAT is given as: SYS$COMMON:[SYSEXE]TDMS019_FILES.DAT. The correct location for this file is: SYS$COMMON:[SYSMGR.VAXINFO$PRODUCTS]TDMS019_FILES.DAT. This error is corrected in the online HTML versions of the Installation Guide. 4.3 VAX H-float format is not fully supported by the OpenVMS Alpha and OpenVMS I64 language compilers Applications that make use of the VAX H-float format are likely to require recoding. If convenient, the IEEE X-float format should be used instead for better performance and standards compliance. Neither of these formats is necessarily expected to have a native implementation on modern hardware, but even an IEEE X-float software implementation is likely to be faster. Otherwise, consider making use of the robust and versatile input-output conversion facilities provided by Compaq Fortran. OpenVMS run-time library routines LIB$CVT_DX_DX and CVT$FTOF can also be used (from any language) to convert between H-float and other formats. Examples can be provided on request. 4.4 Available related OpenVMS solutions; former DIGITAL products, etc. Please advise the HP TDMS Porting Services Team of any other software you may need, and they will do their best to help you find it. The HP OpenVMS Frequently Asked Questions (FAQ) document has a chapter devoted to finding and using software: http://www.hp.com/go/openvms/faq The HP OpenVMS System Software page is another good place to start: 1) Visit the HP OpenVMS Systems home at: http://www.hp.com/go/openvms 2) Under the "HP OpenVMS Systems" heading on the left, follow the "HP OpenVMS software" link. The HP OpenVMS Systems Solutions and Applications page is yet another good place to start: 1) Visit the HP OpenVMS Systems home at: http://www.hp.com/go/openvms 2) Under the "HP OpenVMS Systems" heading on the left, follow the "HP OpenVMS solutions" link. 4.4.1 PL/I compiler Kednos Corporation (http://www.kednos.com) offers a PL/I compiler for OpenVMS Alpha. If you need a PL/I compiler for OpenVMS I64 before mid-2005, e-mail your requirements to "pli-sales@kednos.com" and indicate what other software you use with PL/I, such as Oracle Rdb. 4.4.2 DIBOL compiler, translator, support and programming services Synergex (http://www.synergex.com) offers a DIBOL derivative compiler (Synergy/DBL) for OpenVMS Alpha. Migration Specialties International (http://home.earthlink.net/~msi1) offers a DIBOL to C translator (CBL), as well as DIBOL support services. CSA Data Solutions (http://www.csadata.com) offers DIBOL programming services. 4.4.3 Oracle Rdb and CDD/Repository Oracle Corporation (http://www.oracle.com) offers the Rdb database and CDD/Repository products. 4.4.4 Freeware; BLISS, SDL, etc. Some OpenVMS utilities, such as BLISS compilers and Structure Definition Language (SDL), are provided as unsupported freeware. You can browse and download the HP OpenVMS Freeware at: http://www.hp.com/go/openvms/freeware 4.4.5 Software Partners Solution Index The HP Software Partners Solution Index is on the web: 1) Visit the HP "Large Enterprise Business" home at: http://www.hp.com/go/enterprise 2) Under the "Solutions" heading, follow the "Software partners" link. 4.4.6 Partner Products & Services Catalog The HP Partner Products & Services Catalog is on the web: 1) Visit the HP "Developer & Solution Partner Program" home at: http://www.hp.com/go/dspp 2) Under the "DSPP Partner Edge" heading on the left side, follow the "View partner information" link. 3) Under the "partner entries" heading, follow the "products & services catalog" link. 4.5 AST routines may require change for old OpenVMS Alpha versions Some application AST routines, especially those written in BASIC with five formal arguments (AST parameter, R0, R1, PC, and PSL), may require a change to specify only one formal argument (AST parameter) (or vice versa), in order to prevent a BASIC TOOFEWARG or TOOMANYARG exception (or other possible problems) on delivery. This issue exists only when your TDMS applications must run on multiple versions of OpenVMS Alpha which include any prior to V7.2-2. Please see section 2.2.5 for more information. 4.6 Floating values get truncated (not rounded) by default when converted to (packed or fixed) decimal formats This is the established standard practice on all OpenVMS platforms. It does not typically present any problem, unless a change in the floating-point precision causes a change in the truncated result. This is illustrated by the following example: $ CREATE CONVERSION.BAS $DECK DECLARE DECIMAL(4,3) D1, D2 D1 = -.010 D2 = .010 PRINT D1,D2 END $EOD $! $ BASIC CONVERSION $ LINK CONVERSION $ RUN CONVERSION -.009 .009 $! $ BASIC/REAL_SIZE=GFLOAT CONVERSION $ LINK CONVERSION $ RUN CONVERSION -.01 .01 $! Example: Converting value -.010 to float, then to decimal ========================================================== Floating-Point Representation Packed TDMS Fields ======================================= Decimal=========== # of Fraction Bits Actual Value Fields RJust Other ================== ==================== ====== ===== ===== 23; Nearest: -0.00999999977648258 VAX F-Float = D70ABD23 hex IEEE S-Float = BC23D70A hex (Single-Precision) 9D0000 -.009 -.009 Next: -0.0100000007078052 VAX F-Float = D70BBD23 hex IEEE S-Float = BC23D70B hex 52; Nearest: -0.0100000000000000002081668171172169 VAX D-Float = A3D73D70D70ABD23 hex VAX G-Float = 147B47AE7AE1BFA4 hex IEEE T-Float = BF847AE147AE147B hex (Double-Precision) 0D0100 -.010 -. 10 Previous: -0.00999999999999999847344334114040976 VAX D-Float = A3D63D70D70ABD23 hex VAX G-Float = 147A47AE7AE1BFA4 hex IEEE T-Float = BF847AE147AE147A hex 113; Nearest: -0.0100000000000000000000000000000000... VAX H-Float = 147B47AE7AE1AE14E147147A47AEBFFA hex IEEE X-Float = BFF847AE147AE147AE147AE147AE147B hex (Extended-Precision) 0D0100 -.010 -. 10 Previous: -0.0100000000000000000000000000000000... VAX H-Float = 147A47AE7AE1AE14E147147A47AEBFFA hex IEEE X-Float = BFF847AE147AE147AE147AE147AE147A hex The FMT005, FMT006, FMT007, FMT008, FMT009, and FMT010 TDMS regression tests are all written in BASIC. Changes of this type occurred when the /REAL_SIZE=GFLOAT option was specified. Although the /NOROUND_DECIMAL default option was in effect, the changed results appeared as though the non-default /ROUND_DECIMAL option had been specified. The FMT005, FMT006, FMT007, and FMT008 regression tests define records which include the fields F03, F04, F11, F12, F19, F20, F27, and F28. These fields specify "DATATYPE PACKED NUMERIC 4 DIGITS 3 FRACTIONS" in their CDD record definitions, or "DECIMAL(4,3)" in BASIC. The forms for these four regression tests contain fields with names that correspond to the record field names. The field picture "N.NNN" is used for the first four fields. The field picture "9.999" is used for the other four fields. The odd-numbered fields have the "right justified" attribute; the others do not. All of these fields have scale factor -3. The first four of these fields (F03, F04, F11, F12) are assigned the value -.010 decimal. Note that, under some circumstances, blanks are displayed in the place of leading zeros in the fraction of a TDMS form field. Please refer to section 4.9.3 for further details. The other four of these fields (F19, F20, F27, F28) are assigned the value .010 decimal. The FMT009 and FMT010 regression tests define records which include the fields F01, F02, F09, and F10. These fields specify "DATATYPE PACKED NUMERIC 3 DIGITS 2 FRACTIONS" in their CDD record definitions, or "DECIMAL(3,2)" in BASIC. The forms for these two regression tests contain fields with names that correspond to the record field names. The field picture "9.99" is used for all of these fields. All of these fields have the "fixed decimal" attribute. For FMT010 only, they also have the "zero fill" attribute. These four fields (F01, F02, F09, F10) are all assigned the value 0.04 decimal. The nearest VAX F-float representation of -.010 decimal is "D70ABD23" hex or -0.00999999977648258 decimal. This value gets truncated when converted to packed decimal format as "9D0000" hex in the record fields. This value is consistently displayed as "-.009" in all of the corresponding TDMS form fields. The exact VAX G-float representation of -.010 decimal is "147B47AE7AE1BFA4" hex or -0.0100000000000000 decimal. This value gets truncated when converted to packed decimal format as "0D0100" hex in the record fields. This value is displayed in the right-justified form fields as "-.010", and in the others as "-. 10". The nearest VAX F-float representation of .010 decimal is "D70A3D23" hex or 0.00999999977648258 decimal. This value gets truncated when converted to packed decimal format as "9C0000" hex in the record fields. This value is consistently displayed as " .009" in all of the corresponding TDMS form fields. The exact VAX G-float representation of .010 decimal is "147B47AE7AE13FA4" hex or 0.0100000000000000 decimal. This value gets truncated when converted to packed decimal format as "0C0100" hex in the record fields. This value is consistently displayed as " .010" in all of the corresponding TDMS form fields. The nearest VAX F-float representation of 0.04 decimal is "D70A3E23" hex or 0.0399999991059303 decimal. This value gets truncated when converted to packed decimal format as "03C00" hex in the record fields. This value is consistently displayed as "0.03" in all of the corresponding TDMS form fields. The exact VAX G-float representation of 0.04 decimal is "147B47AE7AE13FC4" hex or 0.0400000000000000 decimal. This value gets truncated when converted to packed decimal format as "04C00" hex in the record fields. This value is consistently displayed as "0.04" in all of the corresponding TDMS form fields. 4.7 Compiler command qualifiers can help with VAX source code compatibility These compiler command qualifiers may be helpful in the task of maintaining source code compatibility among VAX, Alpha, and I64. BASIC : /OLD=CDD/WARN=(ALL,NOINFO)/FLAG=DECL/REAL=SING BLISS : /SYNT=3 CC : /STAN=VAX/EXTE=COMM/SHAR/FLOA=G_FL COBOL : /COPY/RESE=NOXOPEN/FLOA=G_FL FORTRAN: /OLD_F77/FLOA=G_FL MACRO : /MIGR PASCAL : /FLOA=G_FL PLI : /FLOA=G_FL The FORTRAN/OLD_F77 qualifier is available and necessary only on OpenVMS Alpha, and only if the DICTIONARY statement is used. To help maximize the compatibility of OpenVMS I64 applications with VAX floating-point formats (at the expense of performance), /FLOAT=G_FLOAT or D_FLOAT can be specified as appropriate for CC, COBOL, FORTRAN, PASCAL, and PLI. On OpenVMS Alpha, the compiler defaults are typically the most appropriate. However, on OpenVMS I64, the compiler defaults are typically the IEEE formats, which may not be appropriate. 4.8 Compilers can "break" working VAX code by aligning or rearranging variables For the VAX BLISS compiler (as an example), OWN variables can be declared sequentially in the source code to allocate contiguous byte-aligned data structures in the same sequence. However, most programming languages do not specify that even sequence (much less contiguity) of declared variables in the source code is carried over to their allocation in memory. Instead, most programming languages provide safer, more portable methods that can be used to ensure that data structures are always allocated with the intended sequence and alignment (or mis-alignment) of fields. Most Alpha and I64 compilers align each declared variable on at least a longword boundary, unless instructed otherwise. The BLISS Language Manual (section 10.1.3) specifies that OWN variables are allocated in the same sequence as declared. However, address alignment padding bytes are added as needed by default for Alpha and I64. This can invalidate a data structure consisting of more than one variable that had been valid on VAX. Two bugs of this kind were identified and fixed in Alpha TDMS during field test. Please see sections 2.2.4 and 2.2.8 for details. ACMS (ADU) and TDMS (RDU) do not align CDD record definitions for workspaces or request records. Applications must take special care to match the layout of an ACMS workspace or TDMS request record. Using the same CDD record definition helps, yet cannot by itself always guarantee the same layout. When migrating a PASCAL application from VAX to Alpha or I64, for example, one must take particular care to ensure that no alignment bytes are added to a data type that is extracted by a %DICTIONARY directive, when ACMS (ADU) or TDMS (RDU) uses the same CDD record definition for a workspace or a request record that is shared with the application. The [ALIGN(VAX)] attribute should be placed before each TYPE section that contains such a %DICTIONARY directive. These declarations should be separated from others into one or more of their own TYPE sections. This ensures that shared storage will be given a compatible layout. Please see section 2.2.11 for a detailed example. 4.9 Performance and compatibility issues for ported applications 4.9.1 Alignment faults Compilers should ordinarily be allowed to align data in their own default (and often optimal) way. It is generally not a good idea to specify blanket data (mis-) alignment on the compile command line, due to potential performance impacts. Instead, alignment should be specified only as needed for specific data structures, using language constructs and/or compiler directives. The COBOL/NOALIGNMENT and PLI/NOALIGN defaults are possible exceptions to this rule; these two compilers pack their data by default for maximum VAX compatibility. On Alpha, alignment faults can have a significantly greater performance impact than on VAX. On I64, the impact of alignment faults may be as much as one hundred times greater than on Alpha. Natural alignment of data structures is best for performance on any platform. Data structures should be mis-aligned (or "packed") only as needed for compatibility or space savings. The performance impact should be evaluated, then either eliminated or minimized. Alignment faults can also be prevented by using language constructs, compiler directives, and/or compile command line qualifiers to generate defensive machine code that assumes that a specific run-time memory access will be unaligned. Just as with (mis-) alignment, specifying blanket unaligned access on the compile command line is generally neither necessary nor good for performance. Compile-time checking for potential alignment problems can be enabled with these compile command line qualifiers: BASIC /WARNINGS=ALIGNMENT ! disabled unless specified BLISS /CHECK=ALIGNMENT ! enabled by default CC/WARNINGS=ENABLE=ALIGNMENT ! enabled by default COBOL ! no option; default is /NOALIGNMENT FORTRAN /WARNINGS=ALIGNMENT ! enabled by default MACRO/MIGR /FLAG=ALIGNMENT ! enabled by default PASCAL /USAGE=PERFORMANCE ! disabled unless specified PLI ! no option; default is /NOALIGN Run-time reporting of alignment faults can be enabled, as the examples ALIGN_FAULT_DEMO.C and SET_ALIGN_REPORT.C (provided in SYS$EXAMPLES:) demonstrate. Under debugger control, the command "SET BREAK/UNALIGNED" triggers a breakpoint when an alignment fault occurs. 4.9.2 VAX floating-point formats on OpenVMS I64 and Alpha For performance reasons, the IEEE floating-point formats (S, T, and X) are the defaults for OpenVMS I64 compilers. If specified, VAX floating-point formats (F, D, and G) are implemented only by software conversion to and from IEEE formats, and only when loaded from and stored to memory. Regardless of the in-memory format specified to the compiler, a native OpenVMS I64 application performs all of its floating calculations on IEEE-format data, according to the IEEE rules currently in effect. For native applications running on OpenVMS I64, complete compatibility with VAX floating-point formats may not be easy to achieve. In many cases it is not even desireable, due to the performance penalty incurred. This is much more true for I64 than it is for Alpha, which provides direct support for most VAX floating-point formats (F, G, and D53, but not D56 and H) in its instruction set. To help maximize the compatibility of native OpenVMS I64 applications with VAX floating-point formats, specify /FLOAT=G_FLOAT with CC, COBOL, FORTRAN, and PLI. Specify /REAL_SIZE=SINGLE (VAX F-float) with BASIC; please refer to section 4.6 for further details. The default for most OpenVMS Alpha compilers is /FLOAT=G_FLOAT. If using VAX D float data, specify /FLOAT=D_FLOAT instead. You can specify /REAL_SIZE=DOUBLE (VAX D-float) with BASIC, but the increase in precision might affect the behavior. The MACRO and BLISS commands do not provide any /FLOAT option or equivalent. MACRO relies on VAX instruction set emulation and explicit operand format specifiers. BLISS provides little or no actual language support for floating-point data. For further information and guidelines on floating-point compatibility and performance, please check this help topic on OpenVMS I64 and Alpha: $ HELP CC/FLOAT An OpenVMS Alpha program or shareable image that has been migrated to OpenVMS I64 using the binary translator (AEST) performs all of its VAX floating calculations using AEST software emulation of Alpha instructions, according to the Alpha rules established by the Alpha compiler. An OpenVMS VAX program or shareable image that has been migrated to OpenVMS Alpha using VEST (then possibly to OpenVMS I64 using AEST) performs all of its VAX floating calculations using VEST software emulation of VAX (and possibly AEST software emulation of Alpha) instructions, according to the VAX rules established by the VAX compiler. 4.9.3 Leading blanks may be displayed after decimal point Packed decimal data may be displayed with one or more blank fill (or missing zero) characters, after the decimal point, and before the first displayed fraction digit, in a TDMS form field that does not have the "right justified" attribute; at least for a negative value with one or more leading zeros after the decimal point. This does appear to be a bit strange, yet it might be technically correct. If this presents a TDMS software compatibility problem, then please report it as specified in chapter 5. Please refer to section 4.6 for further details. 5 ________________________________________________________________________________ Guidelines for Submitting a Software Problem Report If you find a software error in any Alpha TDMS or I64 TDMS component, please submit a problem report to Robert Sampson (e-mail: Robert.Sampson@hp.com). The following are suggested guidelines for submitting a report: o Form Definition Utility (FDU) Any time you get a non-user software error or bugcheck from FDU, please include: - A statement of the problem - A CDD Data Management Utility (DMU) backup of the form - A softcopy of all error messages, including any traceback information for bugchecks - The exact sequence of functions issued that caused the problem if the error occurs in the form editor o Request Definition Utility (RDU) Any time you get a non-user software error or bugcheck from RDU, please include: - A statement of the problem. - A softcopy of the log files made by using the SET LOG command with the /LOG qualifier to get the necessary information. This item is especially important if the SPR is for the BUILD LIBRARY command and the requests referred to in the request library definition contain %ALL mappings. - A softcopy of all error messages, including any traceback information for bugchecks. - A DMU backup of the forms, records, and requests. o TDMS programming interface For the programming interface (the TDMS calls), internal software errors are reported to you by a return status code of TSS$_BUGCHECK or SS$_ACCVIO. Any time you get a bugcheck error from the TDMS program interface, please include: - A DMU backup of the forms, records, and requests /request library definitions - A single-request TDMS application that calls the request in error with the correct parameters and control field values set - An explanation of how to run the application - A trace log from your program that includes tracing the call that produced the error If you want to submit machine-readable information, please include all necessary files to compile and link your program and to build your request library. This means all program sources, request sources, record definition sources, a DMU backup of the form, and a command procedure (or instructions) on how to link the program.