______________________________________________ TDMS Release Notes Original Document Order Number: AA-M062I-TE This manual contains the release notes for Alpha TDMS. OPERATING SYSTEM: OpenVMS Alpha V7.2-2 or later SOFTWARE VERSION: Alpha TDMS Version 1.9B Final Acceptance Field Test Updated February 7th 2002 __________________________________________________________ The information in this document is subject to change without notice and should not be construed as a commitment by Compaq Computer Corporation. Compaq Computer Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is proprietary to, and embodies the confidential technology of, Compaq Computer Corporation. Possession, use, or copying of this software and media is authorized only pursuant to a valid written licensing or contractual agreement with Compaq. Compaq has never released Alpha TDMS as a software product, nor has it completed any extensive general field test. Support can be obtained only under the specific terms of a valid written contract with Compaq. No responsibility is assumed for the use or reliability of software or equipment that is not supplied by Compaq Computer Corporation. Compaq Computer Corporation makes no representations that the interconnection of its products 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 customers. Compaq 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. VAX TDMS) by a warranty, support agreement, or Software Product Description, or as may be provided for any software (e.g. Alpha TDMS) under a contract. Compaq may, at its option, agree to meet the terms of specific acceptance criteria. Compaq 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. © Digital Equipment Corporation 1983, 1987, 1988, 1989, 1998. © 2002 Compaq Computer Corporation, its successors and assignees. All Rights Reserved. The following are trademarks of Compaq Computer Corporation: DECscheduler, DECmessageQ, DECnet, DECtrace, OpenVMS, Alpha, AlphaServer, AlphaStation, VAX, VAXcluster, VAXmail, VMS, DIGITAL, and the DIGITAL and Compaq logos. All other trademarks and registered trademarks are the property of their 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 Alpha TDMS 1.3.1 Optional optimized shareable image provided 1.3.2 TDMS$ALLOW_SIGNAL_FROM_MSGS enables "-CMU-I-SIGNAL_FROM" messages 2 Errors 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 Documentation Corrections 2.2 Corrections for Field Test of Alpha TDMS 2.2.1 Problems reported by field test customers 2.2.2 TDMS development regression tests 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 Documentation Error 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.25 Alpha TDMS is currently limited to 32-bit addressing and call arguments 3.26 Alpha TDMS support 4 Known or Suspected Problems or Limitations for Field Test 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 language compilers 4.4 Some old OpenVMS VAX products not available from Compaq for the OpenVMS Alpha platform 4.5 AST routines may require change for Alpha 4.6 Field test unresolved problems 4.6.1 Problems reported by field test customers 4.6.2 TDMS development regression tests 4.7 Datatrieve does not display TDMS forms on OpenVMS Alpha 4.8 Compiler command qualifiers can help with VAX source code compatibility 4.9 Alpha compilers can "break" working VAX code by aligning or rearranging variables 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) Version 1.9B. It describes changes made to the software 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 is compatible so far with all current and supported versions of OpenVMS VAX, although it is a retired product. Alpha TDMS is being provided only as a migration service under contract, and not as a software product. It should be used only with OpenVMS Alpha V7.2-2 and later. Structure This manual is divided into five chapters: Chapter 1 Contains information on new features and also contains information on previous features and technical changes in TDMS. Chapter 2 Contains information describing the TDMS errors 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 The 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. (The DCL prompt on your system may be different.) References to Products This manual may refer to Compaq 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 Alpha TDMS does not require a TDMS license. This is because no suitable license has ever been issued. Alpha TDMS does not require a CDD-PLUS license. This is because Oracle Corporation does not use it. The CDD Repository product from Oracle must be installed before installing TDMS. TDMS Version 1.9 supports the License Management Facility (LMF) required for running TDMS on OpenVMS VAX V5.0 or later. LMF is the software license management tool on the OpenVMS operating system. LMF includes the License Management Utility (LICENSE), and the command procedure VMSLICENSE.COM, used to register, manage, and track software licenses online. To use TDMS on these OpenVMS versions, you must be registered in the LICENSE database. To register the license, you must have a Product Authorization Key (PAK) containing the information necessary for the registration. The PAK is obtained along with the TDMS Version 1.9 kit. The registered license must then be activated to make it known to the system. If you do not have the necessary information or are otherwise unable to complete the registration of the PAK, you can continue with the installation, but you will not be able to run TDMS Version 1.9 until the registration process has been completed. For more information on registration through the LMF, see the TDMS Installation Guide. For complete information on using LMF, see the manual on the License Management Utility in the OpenVMS documentation set. 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" cause 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 Alpha TDMS 1.3.1 Optional optimized shareable image provided Starting with the final field test update of February 1st 2002, 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. Excessive TDMS CPU time should first be 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 final field test update of February 7th 2002, 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 2 ________________________________________________________________ Errors Corrected This chapter describes corrections in TDMS after Version 1.7 for errors that were in previous versions of TDMS. 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: DEFAULT FIELD %ALL, BLINK FIELD %ALL, REVERSE FIELD %ALL, BOLD 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 During the layout phase in FDU it was previously possible to initiate selection and type a space followed by GOLD T (or GOLD D). This resulted in an access violation. This has been corrected. The 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. The 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. The FDU no longer access violates or loops. The new behavior is for the 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 leapyear calculation algorithm was incorrect. Thus, some February 29 dates may have been accepted for non-leapyears. 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 do not contain 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 Documentation Corrections 1. Page 16-24 of the TDMS Request and Programming Manual contains 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 is initialized, but not used. The example should 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 is used with the TDMS syntax %INCLUDE shown at the top of the same page (16-24), the RDB precompile fails. The failure occurs because %INCLUDE is performed at compile-time. At precompile-time, the record is not known to the application. 2. Page 2-79.3 of the TDMS Reference Manual contains the following incorrect example: RDU>SPAWN FDU LIST FORM TEST_FORM/OUTPUT=TEST_FORM.LIST/NOWAIT The example is incorrect because the /NOWAIT qualifier is in the wrong position. Also, another /OUTPUT qualifier is needed to direct the output from the SPAWN command. The corrected example follows: RDU>SPAWN/NOWAIT/OUTPUT=SUB_PROCESS.LOG FDU LIST FORM TEST_FORM/OUTPUT=TEST_FORM.LIST These examples will be corrected in the next version of the documentation. 2.2 Corrections for Field Test of Alpha TDMS 2.2.1 Problems reported by field test customers [A] Could not install Alpha TDMS kit; no TDMS or CDD-PLUS license: Thank you for quickly bringing these license issues to my attention. I had obtained a TDMS license that was issued for Compaq internal use only. The same license worked on both VAX and Alpha. I had made the incorrect assumption that the TDMS licenses issued to customers would also work on both VAX and Alpha. I had also incorrectly assumed that Oracle still issues and requires a CDD-PLUS license. The installation procedure no longer requires a TDMS license, since the only TDMS licenses ever issued to customers work only on VAX. The installation procedure no longer requires a CDD-PLUS license, since Oracle neither issues nor requires it. The Alpha TDMS and Oracle CDD Repository software also do not perform run-time checking for these licenses. This change was completed on 2001-10-29. [B] Field validators were not working: 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, long, and quad) specifies a range pair (minimum and maximum value). Their components were 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. This change was completed on 2001-11-13. [C] ACMS/ENTER and ACMS/DEBUG would hang with TDMS present: 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 December 3rd 2001, 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. This change was completed on 2001-12-03. [D] Last double-wide or double-size form line was shown normal-size: 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 (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. This change was completed on 2001-12-04. [E] VARYING STRING record field caused application failure: 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. This gets interpreted 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 the fields. However, note that the generated declaration does not specify the "PACKED" keyword for array fields. Each VARYING STRING array element of the NODE_ADDR field is a word-counted string (.ASCIW) aggregate, requiring nine bytes without alignment, or ten bytes with alignment. 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 TYPE section that contains 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. This fix was suggested on 2002-01-14. [F] SYS$LIBRARY:ACMSREQ.RLB was missing on Alpha: ACMS deliberately does not provide TDMS support files on Alpha. 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 acceptance field test update of January 11th 2002, the development kit provides this file. Starting with the final field test update of January 25th 2002, the run-time-only kit 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. This change was completed on 2002-01-25. 2.2.2 TDMS development regression tests [A] ACCVIO in ARY014, DEF_KEY1, MOD03: 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 might have interpreted the meaning of the negative loop increment on line 612 in a way that matched the programmer's intent. However, the Alpha BLISS compiler performed 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 were both one, and the step value was negative one. The loop would have had 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. It caused serious memory corruption 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 This change was completed on 2001-10-12. [B] ACCVIO in TSS_21555: This ACCVIO occurred during AFK (application function key) AST (asynchronous system trap) delivery. The virtual address was the same as the PC: 0x0414BB4000550140. This address was obviously not valid. A 64-bit P2 address does not make sense for 32-bit Alpha TDMS. This was a programming error in my initial attempt to implement AFK ASTs on Alpha. I tried to provide PAGCHN context to the AST routine by placing a copy of its procedure descriptor at the start of the PAGCHN data structure. However, in order to make this scheme work, copies of the entire linkage section for the TSSSHR image would have to be made, and the pointers would have to be relocated. Too much virtual memory would be used. The solution was to implement a bound procedure descriptor for each PAGCHN, and a short transfer routine written in Macro-64. The names and attributes of code psects were specified so that the linker places the transfer routine code segment immediately before that of the AST routine. This eliminates the need for two instructions; a load and a jump. The transfer routine furnishes the PAGCHN address (the bound procedure descriptor address from register R27) to the AST routine as the sixth actual argument in register R21, and fills in the low byte of the argument information register R25 with the value six. The result is an efficient implementation of AFK ASTs for the Alpha calling standard. This change was completed on 2001-10-24. [C] TOOFEWARG in CAN002, CAN003, CAN006, CAN010, CAN011, CPY002, OPN007, KNL002, SAV010, WML003: Under OpenVMS Alpha V7.2-1, the above BASIC programs would fail during most of the test runs with: %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 the AST routines in separate source files. I chose to fix the problem differently, 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 and OpenVMS Alpha V7.2-2 or V7.3, 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 This change was completed on 2001-11-21. [D] TSS$OPEN failure in OPN002, OPN010: 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. This change was completed on 2001-11-21. [E] CONVERR in TSSCNL: 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. My 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 This change was completed on 2002-01-03. [F] Blank date fields in DAT002: 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 my programming error. 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. My 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. My 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() */ This change was completed on 2002-01-08. 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 language-specific or OpenVMS 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 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 Datatrieve on OpenVMS Alpha is unable to display TDMS forms at all. The following restriction applies to VAX TDMS. Calls to TDMS routines and calls to callable DATATRIEVE that use the DATATRIEVE/TDMS interface should not be mixed in 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 Documentation Error Page 2-79.3 of the TDMS Reference Manual contains the following incorrect example: RDU>SPAWN FDU LIST FORM TEST_FORM/OUTPUT=TEST_FORM.LIST/NOWAIT The example is incorrect because the /NOWAIT qualifier is in the wrong position. Also, another /OUTPUT qualifier is 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 will be corrected in the next version of the 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 TDMS$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 now 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 Pthreads package: Advantages: (1) TDMS can now be used with ACMS on Alpha. (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 debugging during field test. Drawbacks: (1) TDMS execution is now 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 attained on current and future Alpha and IPF (EV8 multi-threading) platforms, unless both ACMS and TDMS THD packages are updated. 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 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.25 Alpha TDMS is currently limited to 32-bit addressing and call arguments Alpha TDMS 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. Compaq and its successors and assignees reserve the right to determine whether to pursue a possible 64-bit version of TDMS, based on their own perceptions of demand and profitability. 3.26 Alpha TDMS support TDMS is being ported to (and maintained on) Alpha only under contracted consulting services to specific customers. The decision not to release or support Alpha TDMS as a Commercial Off-The-Shelf (COTS) product was made years ago. Compaq and its successors are not likely to reverse that decision. The Customer Support Centers and Software Engineering Groups (and their successors) specifically do not (and have no plans to) provide product support for customer use of Alpha TDMS. Please do not contact them for this purpose. Compaq Professional Services, a.k.a. Compaq Federal LLC (or any successor) is solely responsible for the support and maintenance of the Alpha TDMS software, as provided under contract to each specific customer. Robert J. Sampson (e-mail: Robert.Sampson@compaq.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. 4 ________________________________________________________________ Known or Suspected Problems or Limitations for Field Test This chapter contains a list of the known problems with the field test version 1.9B of Alpha TDMS. 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. 4.3 VAX H-float format is not fully supported by the OpenVMS Alpha language compilers Applications that make use of the VAX H-float format may require recoding. If convenient, the IEEE X-float format should be used instead for better performance. Although neither format is implemented in Alpha hardware, the IEEE X-float implementation is faster because it is better assisted by Alpha instructions. 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 Some old OpenVMS VAX products not available from Compaq for the OpenVMS Alpha platform A PL/I compiler is available from KEDNOS. A DIBOL (DBL) compiler is available from Synergex. The Rdb database and CDD Repository products are available from Oracle Corporation. Some of the old DIGITAL products may reside on old distribution CDs. However, Compaq can neither recommend nor support their use. Legitimate and working licenses may not be available for them. Some OpenVMS utilities, such as BLISS compilers and Structure Definition Language (SDL), are provided as unsupported freeware. Please advise Compaq of any software you may need, and we will do our best to help you find it. 4.5 AST routines may require change for Alpha 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. Please see section 2.2.2 [C] for more information. 4.6 Field test unresolved problems 4.6.1 Problems reported by field test customers (none outstanding at this time) 4.6.2 TDMS development regression tests [A] DTR001: Test fails with "%FDV-E-IOL, Error opening form library". On Alpha, Datatrieve is unable to display TDMS forms. 4.7 Datatrieve does not display TDMS forms on OpenVMS Alpha On Alpha, the Datatrieve installation procedure provides support for displaying FMS forms, but not TDMS forms. My attempts to build Datatrieve on Alpha to support TDMS forms have met with failure. If there is any indication of customer demand, Compaq may decide to pursue getting this feature added to Datatrieve on Alpha in the future. 4.8 Compiler command qualifiers can help with VAX source code compatibility The following compiler command qualifiers can help with the task of maintaining source code compatibility between VAX and Alpha. BASIC : /OLD=CDD/WARN=(ALL,NOINFO)/FLAG=DECL BLISS : /SYNT=3 CC : /REEN=MULT/STAN=VAX/EXTE=COMM/SHAR COBOL : /COPY/RESE=NOXOPEN FORTRAN: /OLD_F77/REEN=THRE/RECU MACRO : /MIGR PASCAL : (none known) PLI : (none known) 4.9 Alpha compilers can "break" working VAX code by aligning or rearranging variables For the VAX BLISS compiler (as an example), it happens that variables can be declared sequentially in the source code to allocate contiguous 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 compilers align each declared variable on at least a longword boundary, unless instructed otherwise. The Alpha BLISS compiler appears to preserve sequence. However, it does insert alignment padding bytes. This is likely to invalidate data structures that had been valid on VAX. Two bugs of this kind were identified and fixed in Alpha TDMS during field test. Please see section 2.2.1 [B] and [D] for details. 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 and minimized. 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, 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.1 [E] for a detailed example. 5 ________________________________________________________________ Guidelines for Submitting a Software Problem Report If you find a software error in any Alpha TDMS component, please submit a software problem report directly to Robert J. Sampson (e-mail: Robert.Sampson@compaq.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.