XENTIS Documentation -- Release Notes XENTIS 4.1 XENTIS V4.1 Release Notes This document contains information about using XENTIS V4.1 and highlights features that are available in V4.1 that were not available in previous versions. A. INSTALLATION AND GENERAL INFORMATION. 1. XENTIS V4.1 uses the VMSINSTAL utility to install XENTIS. XENTIS can be installed on any disk or in any directory provided certain XENTIS files do not already exist in that directory. 2. Release notes and new features are included on the tape. Installation instructions are sent separately. 3. XENTIS operates on systems with VAX/VMS V5.0 or later. It will not operate on earlier versions of VMS. 4. The installation procedure has changed significantly from version 3.5 and before. The default installation places XENTIS into four different subdirectories. These subdirectories are: [XENTIS41.DATA], [XENTIS41.IMAGES], [XENTIS41.DEMO], and [XENTIS41.INSTALL]. The last directory is optional if disk space is tight. [XEN41.DATA] contains the data files and DCL command files used by XENTIS. [XENTIS41.IMAGES] contains the executable images. [XENTIS41.DEMO] contains the demonstration files. [XENTIS41.INSTALL] contains files that are needed to relink XENTIS. 5. XENTIS may need to be relinked for various reasons. For example: Your company acquires a database package that XENTIS supports and subsequently licenses the XENTIS interface to that database. XENTIS must be relinked to make the interface operational. Another example: You wish to use the foreign data type feature. This feature allows XENTIS to support data types that are not normally supported. One of the steps needed to implement a foreign data type is relinking XENTIS. When upgrading various system software or Digital supplied layered products, it is not normal to have to relink XENTIS. If you need to relink XENTIS, then the XENLINK.COM procedure in the 'Install' files directory will perform the link. The comments at the top of this procedure should give you adequate instructions on how to relink. Typically all you need to do is to enter: $ SET DEFAULT dev:[XENTIS41.INSTALL] $ @XENLINK $ RENAME *.EXE dev:[XENTIS41.IMAGES] where 'dev:' is the disk device where XENTIS is located. If XENTIS is installed with the INSTALL utility, then the installed images will have to be REMOVEd and ADDed with the INSTALL utility after relinking. Using the Progress database or using a limited user license requires that XENTIS be installed with the INSTALL utility. 6. After installation, XENTIS V4.1 must be enabled with the LKMS License Key Management System. Instructions for installing the license key are included in the XENTIS V4.1 Installation Guide. For each site, the license key determines which XENTIS modules are licensed and on which CPU's they are licensed to run. If you have already installed a license key for XENTIS then you do not need to install it again. The license key used with V3.6 and V4.0 will work with V4.1. 7. XENTIS V4.1 uses a start-up DCL command file named SYS$COMMON:[SYSMGR]XENTIS_START.COM. This file must be executed whenever your computer system is started. You may choose to insert a line in your system start-up procedure to ensure this is accomplished. SYS$COMMON:[SYSMGR]XENTIS_START.COM references the file SYS$SPECIFIC:[SYSMGR]PKMS_XENTIS_START.COM, a DCL command file that is the start-up file for the license key system, references a file that makes sure certain shareable images that belong to Rdb, CDD, or DBMS are installed, inspects the license key and installs the XENTIS images with SYSLCK if a limited user count license is present, and defines a system-wide logical called XENTIS$COMFILES. XENTIS$COMFILES points to the disk and directory where a file called XENTISLOGICALS.COM is located. XENTISLOGICALS.COM is referenced by XENTIS.COM and XENTIS1.COM, and contains the definition of the logicals XENTIS uses during execution. The use of XENTISLOGICALS.COM benefits you by allowing you to redefine XENTIS$COMFILES and the logicals in XENTISLOGICALS.COM instead of having to copy and change XENTIS.COM or XENTIS1.COM. 8. In addition to the original XENTIS menu system, XENTIS V4.1 includes the improved menu system introduced with version 3.6. MAXCIM users that link XENTIS into the MAXCIM menu can utilize the improved menu system by either: a. Renaming XENTIS.COM to XENTIS0.COM, and XENTIS1.COM to XENTIS.COM, or b. Creating a new XENTIS.COM file that has the following line: $ @FIS$NCA50$DATA:XENTIS1.COM This technique allows MAXCIM users to not be required to relink MAXCIM. 9. Granting privileges to XENTIS images with the VMS INSTALL utility will also require using the INSTALL utility on certain system shareable images. The system resources required to perform this operation are very minimal and will have almost no impact on your system. If Sybase is loaded on your system, be sure that the SYB_DBSHR logical is created in the System table using Executive mode. You may also need to install this image using the VMS INSTALL utility. If XENTIS is relinked, be sure to remove and add the XENTIS images with the INSTALL utility. 10. Licenses that restrict the concurrent number of users will require the XENTIS images to be installed with the SYSLCK privilege. This process is done automatically by the XENTIS_START.COM procedure found in the SYS$MANAGER: directory. If XENTIS is relinked, be sure to remove and add the XENTIS images with the INSTALL utility. 11. Installing XENTIS images with /SHARE qualifier to the VMS INSTALL utility will require both global sections and global pages. The number of global sections and global pages required depends upon the number of databases that XENTIS was linked with, and varies from site to site. Most sites will need 3 to 6 global sections and 2000 to 2500 global pages to install XRP.EXE with /SHARE. Most sites that want to install images to be shared need only to install the XRP.EXE image. If you wish to install XENTIS images without the /SHARE qualifier then the resources required are very minimal and every site should already have enough resources. If XENTIS is relinked, be sure to remove and add the XENTIS images with the INSTALL utility. 12. It is recommended that the XRPSCM.EXE and XDCRE.EXE images be restricted such that only highly privileged individuals be allowed to execute these images. We suggest that VMS ACL's be used to control which users can access these programs. XRPSCM.EXE is the program that compiles the system setup file. XDCRE.EXE is the program that creates a new empty data dictionary. B. UPGRADING FROM PREVIOUS VERSIONS OF XENTIS TO XENTIS V4.1. The XENTIS installation procedure does not do anything different if you have a previous version of XENTIS loaded on your system. Upgrading from the previous version is essentially the same as installing a new license except for a few manual procedures listed below. 1. A new license key is not needed unless you are also upgrading from VMS version 4.x. In this case you may need a new license key. 2. If you are upgrading to XENTIS V4.1 at the same time you are upgrading from VMS V4.x to VMS V5.x, then you may need to get a new license key from your vendor. New license keys are not needed if the values returned by F$GETSYI("CPU") and F$GETSYI("HW_MODEL") are equal. New license keys will not be needed for certain older systems such as, but not limited to, VAX 11/700 series and MicroVax II systems. 3. Compiled command files created in previous versions of XENTIS must be recreated using XENTIS V4.1. Please note that the need for compile command files is less in V4.1 than in prior versions, because V4.1 processes .XCF files faster and compile command files are no longer required for run-time-only licenses. 4. Pointer files created in previous versions of XENTIS must be recreated using XENTIS V4.1. 5. Standard (uncompiled) command files (full or partial) created in any 3.X version of XENTIS or version V4.x can be used with XENTIS V4.1. 6. Standard command files (full or partial) created with FIS or XENTIS V2.X must be converted. Contact your vendor for assistance. 7. If you are using foreign data types, then the packing/unpacking routines must be incorporated into the XUUSER_PACK routine. This process is as follows: a. Insert custom code into the XUUSER_PACK.BAS routine as supplied on the distribution tape, or create your own XUUSER_PACK routine written in your favorite language using the same parameters found in the XUUSER_PACK.BAS routine. b. Compile XUUSER_PACK and place it into the XULIBR.OLB library. c. Relink XENTIS according to the instructions above. d. The internal date format that is passed to and from the XUUSER_PACK routine has changed slightly to support time. If your foreign date does not support time, then no changes are necessary to your routine. If you wish to support time, then you will need to follow the directions found in the sample XUUSER_PACK.BAS routine. 8. If you are using callable XENTIS, any program that calls XRPTOP, then that program will have to be relinked. Be sure to include the XUNAME module from the XENTIS.OLB library in your link command, i.e. XENTIS.OLB/INCLUDE=XUNAME In addition, the following object libraries need to be specified in the following order (append /LIB): XRPLIB.OLB XULIBR.OLB XSADABAS.OLB XSDAS.OLB XSDBMS.OLB If DBMS is not on the system XSINGRES.OLB XSORACLE.OLB XSPROGRESS.OLB XSRDB.OLB If Rdb is not on the system XSRDBSQL.OLB If Rdb is not on the system XSSYBASE.OLB PKMS.OLB 9. If you are using Ingres, Rdb, or Sybase and you are upgrading from XENTIS V3.4 through XENTIS V3.6, then you may want to utilize the XRPDBCONV program, to convert .XCF files that were created prior to V4.0 to take advantage of the improved relational database interfaces. See the V4.0 release notes for more information. 10. The organization of the standard menus have been changed from version 3.6 and prior. If you use DCL .COM files that reference menu items by their number, then those .COM files will need to be upgraded to utilize V4.1. 11. If generic files in your XENTIS/Dictionary data dictionary were created prior to XENTIS V3.0, or were created by using the dictionary load utility where the input file was not created by XENTIS, then you may need to run the XDFIX_PREFIX program. See below for more information. 12. The organization of the system setup file has changed slightly. All parameters that were added from V3.3 through V3.6 have been moved from the front of the file into the balance of the file. Some new categories have been created and some parameters have been move around to reflect the new categories. Setup parameter values that were changed from the default in previous versions should be changed in V4.1 also. The V4.1 installation procedure will leave several files in the data directory; XENTISSET.V36_ORIGINAL, XENTISSET.V40_ORIGINAL, and XENTISSET.V41_ORIGINAL. These files are the original copies of the system setup files, as they were shipped, for their respective versions. It is recommended that any changes to the system setup parameter file be made as additions to the end of the file. If the setup file compiling program encounters two parameters with the same name, the last one it finds will be the one used. 13. Temporary dictionaries in V4.1 are compatible with temporary dictionaries created in V4.0. However, they are not guaranteed to be compatible in future versions. Temporary dictionaries are considered to be internal data structures and are subject to change from version to version. Some future version of XENTIS may require you to regenerate any temporary dictionaries you are using. C. DOCUMENTATION. 1. Documentation for V4.1 has been reworked. The format and style has changed slightly from the V4.0 documentation, and there have been numerous corrections and additions. 2. The tutorial has also been reworked to take advantage of the improved keystrokes available in V4.1 3. Keyboard templates for DEC LK201 and DEC LK401 keyboards are available. One copy of each template is included with each license. Additional keyboard templates can be ordered from your vendor. 4. Minor corrections have been made to the Quick Reference Card for V4.1. 5. Documentation regarding the specifications of Model Control Files and Pointer files should not be construed to be a commitment that future versions of XENTIS will support the exact same specifications. The specifications of Model Control Files and Pointer files are subject to change in any future version. Should you have developed a Model Control File that supports a spreadsheet or word processing package not currently supplied, please inform your vendor so that it can be supplied in the next version. D. NEW FEATURES. 1. /Report and /Report modules (/File, /Word, /Model, /Update). a. XENTIS V4.1 now supports the Progress relational database management system. Some notes pertaining to this database interface include: . The Progress interface in not compatible with the Ingres interface due to duplicate routines used by Progress and Ingres. . XENTIS/Update is not supported for Progress. . XENTIS uses the HLI SQL access to the database. This means sites using this feature must have an HLI license. . The XRP.EXE, XRPNEW.EXE, and XRPLOAD_INFO.EXE images must be installed with the SYSLCK privilege, or the user must have the SYSLCK privilege. This is an HLI requirement. The XENTIS startup procedure, SYS$MANAGER:XENTIS_START, will install the images with the SYSLCK privilege. . They may also need GROUP or WORLD privileges, depending upon the security of the database. . Character fields will be one byte larger than what is defined in the Progress database. Progress HLI insists on adding an extra byte for every text field retrieved. . XENTIS does not support all the editing characteristics allowed by Progress in its Format string (XENTIS calls this a print mask). XENTIS attempts to approximate the format used by Progress. . Date fields will use the standard XENTIS date format while printing. Progress users may want to use the VMS Date Formatting Logicals. . Progress views are not yet supported. . Fields using data type 'Recid' are not supported. . Formats for Logical data type fields are not supported. This means that Logicals will print their internal values which are 0 and 1. XENTIS will treat these fields as byte integers. . The TEXT-IS-STRING setup file parameter will be automatically set to N when using Progress. . The number of fields per file is limited to 500. . Array fields are supported. . Multi-database reporting will work only if all Progress tables are specified consecutively beginning with the primary table. To access a progress database then user should enter 'PROGRESS:dev:[dir]dbname.ext' at the Dictionary prompt, where dev:[dir]dbname.ext is the name of the Progress database. At the Password prompt the user should enter 'username/password' where username is the Progress username and password is the Progress password. b. XENTIS V4.1 uses significantly less CPU than prior versions. This improvement exists in almost all phases of producing a report. On average, the dialogue phase uses about 25% less CPU than prior versions. The selection phase and the print phase may use anywhere from 10% less CPU to 50% less CPU. Performance gains will not be as great on systems that support the full VAX architecture, such as the VAX 11/7xx systems and the VAX 8000 systems, but they will still be significant. c. XENTIS now supports the ability to call a user written routine. This user written routine will be called at certain specific points in the selection phase ( after selecting... and before sorting...) of the report generation process. The data passed to this user written routine includes: . The places in the selection phase logic that it is being called from. . The number of input files being processed. . The names of the files being processed. . The record sizes of each of the files being processed. . The needed data dictionary information on each data file being processed. . The record buffer of each file being processed. The places in the selection phase where the user written routine will be called from are: . Initialization. . Termination. . Immediately before record selection logic is processed, even if there is no selection logic present. . Immediately before passing the record to the sort or print routines. . Immediately after every input file is read. This grants the user full access to the report's data file buffers at various critical points during the generation of the report. The user written routine is implemented as a shareable image that is dynamically linked to XENTIS while XENTIS is executing. This dynamic linking will occur only if the XENTISSHR3GL logical is defined and translates to the shareable image containing the user written routine. The entry point of the user written routine must be named XRP3GL. The user written routine must always pass back a status code indicating success or failure. If a failure code is returned during initialization, then XENTIS will not call the user written routine again for the duration of the current report. Two sample user written routines are supplied, one written in BASIC and one written in C. These sample routines are functionally identical and demonstrate how to access the data passed to the user written routine. Additional documentation on how to write a user written routine is located in the sample routines. Due to the potential security risks, this feature requires the new setup file parameter ALLOW-3GL to be set to Y. The default value of this parameter is shipped as N. Please review the system documentation on the LIB$FIND_IMAGE_SYMBOL for additional technical documentation. d. Compiled command files are now stored in a compressed format. This new compressed format will occupy 10% to 20% of the disk space used by compiled command files from previous versions. Compiled command files also now contain a copy of the setup file that was used when the compiled command file was created. This provides greater assurance the report will run as intended. e. A checksum is now written to XCF files. This lifts the restriction that Run-Time-Only licensees can only execute compiled command files. This means Run-Time-Only licensees may execute .XCF files that were created on a development system with version 4.1 or later, provided the .XCF file has not changed. The checksum does not include lines in the .XCF file that are comment-only lines. This allows developers of .XCF files to add comments to their .XCF files. f. The FIND command in display mode, invoked by pressing the FIND key or the F keys, will now always assume a wildcard find; the first character being a *. Entering the leading * is now optional. Additionally, the next FIND key will use the previous find as its default search string. g. The LIST SELECT command will now display a sequence number on the left side of the screen for each selection expression listed. h. There are two new setup parameters designed to help prevent new users from running reports that are too large. These parameters are READ-LIMIT and SELECT-LIMIT. READ-LIMIT will limit the number of records read from the primary file. SELECT-LIMIT will limit the number of record groups that are selected. The user may not exceed the limits specified in the setup file, regardless of what is entered at the "Number of records to select/read" prompt. A value of zero indicates that there is to be no limit. The value shipped with V4.1 is 0. i. The value of the setup file parameter TEXT-IS-STRING has been changed from N to Y. This means that all TEXT fields will behave as if they are STRING fields. TEXT fields have null characters removed from them during processing, while STRING fields are processed unchanged. This results in a performance gain. If you have data fields that contain null characters and you want those null characters removed during report processing, then the TEXT-IS-STRING parameter should be set to N. j. A sequence number has been added to the "Model Field" prompt in XENTIS/Model. k. A setup file parameter has been added to control the presence of the dialogue in a batch log file when a XENTIS command file (.XCF) is passed to XENTIS. This parameter is named BATCH-DIALOGUE. If its value is Y, then the report definition dialogue will appear in batch log files. If it is N, then the dialogue will not appear. The value shipped with V4.1 is Y. l. XENTIS/Model now supports a GOTO MODEL-n command. This will cause XENTIS to goto the chosen model field. m. XENTIS/Word now supports a GOTO WORD-n command. This will cause XENTIS to goto the chosen word field. n. When in display mode the key sequence will cause XENTIS to advance to the next field. This key sequence is supported only in the FIELD Section, the CLT Section, the BREAK Section, the MODEL Section, and the WORD Section. The GOTO NEXT command, new in V4.1, performs the same action. The F17 function key will also perform the same action. o. A DUMP command is now supported in XENTIS/Report and XENTIS/Creport at the first "Field name/number/literal" prompt. This command will scan all files chosen and create a default report format using each field in each file. For example, if you have chosen 3 files with 15, 20, and 25 fields respectively, then the DUMP command will design a report that uses all 60 fields. Each field will use the default heading and print mask retrieved from the data dictionary. The DUMP command will automatically shift the report to use the next print line whenever a field would exceed the right margin, either 80 or 132 columns. The DUMP command will stop when it attempts to use a print line that exceeds the MAX-ROW setup parameter in /Report or the DFLT-PAGE-SIZE parameter in /Creport. The DUMP command requires the report to not have any reporting fields already defined for the report. If you have some reporting fields defined, then use the DELETE command to remove them. p. A new command, XCOMMENT, has been added. This command will accept a comment from the user and enter it into a .XCF file when a .XCF file is created. For example, entering "XCOMMENT my comment" will place " my comment" as a comment into the .XCF file that will be created. Any LIST command will display the current comments. There is no method to delete comments once they are entered. Up to 100 comments may be entered. q. The INSERT and DELETE commands are now supported in the MODEL, WORD, and the SELECTION Sections of the dialogue. r. There are five new setup file parameters designed to control the info window in display mode. These parameters are named DISPLAY-FREQ, DISPLAY-HEAD, DISPLAY-MASK, DISPLAY-ACCUM, and DISPLAY-YESNO. They control whether or not print frequencies, heading justifications, print masks, accumulated levels, and simple yes/no responses are displayed in the info window at the appropriate prompt. The allowable values are Y and N. The values shipped with V4.1 are Y. s. There are four new display mode commands: MINIMIZE, MAXIMIZE, RULERUP, and RULERDOWN. The MINIMIZE command will shrink the top window to its smallest size. The MAXIMIZE command will enlarge the top window to its largest size. The RULERUP command will move the middle ruler up one line. The RULERDOWN command will move the middle ruler down one line. The F19 and F20 function keys will perform the same operations. t. The default value displayed in the dialogue window will now be modified every time the highlighter in the info window is moved with the arrow keys, provided the FIND-DEFAULT setup parameter is set to Y. This feature does not take effect on those prompts where the user is to enter an expression such as calculation and selection expressions. u. The available model control files will now be displayed in the info window. v. The DIR and LIST commands will now reenter display mode upon completion, provided they were executed from display mode. The LIST command will also display the product name and current version. w. Index or Key Names for ISAM files are now fully supported. This is useful for SQL database reports that do not use the SQL-JOIN feature, for RMS files that have key names, and for Adabas files. The XENTIS dialogue now accepts a key name in the Key Section. If the USE-KEY-NAME setup parameter, new with V4.1, is set to Y, then the Key Section of the dialogue will use key names in its defaults, and key names will be written to XCF files. Regardless of the value of this setup parameter, both key names or key numbers will be accepted in the dialogue. It is recommended that key names be used rather than key numbers for SQL databases that utilize the multiple dictionary feature or set the SQL-JOIN parameter to N. x. Error messages will no longer have CTRL/O appended to them when executing in batch. CTRL/O turns off the line drawing character set on terminals. y. XENTIS now uses four fewer logical unit numbers than were used in previous versions. Logical unit numbers are allocated and deallocated using the LIB$GET_LUN and LIB$FREE_LUN library routines. This is beneficial to those sites using callable XENTIS and user written callable routines. z. Print masks for numeric fields will now accept text. You must have at least one '#' character in your mask. If extra text is found in a numeric print mask, you may not use some of the special formatting for negative numbers such as trailing DB, trailing CR, and surrounding parentheses. aa. There is a new setup parameter called AUTO-ERASE that modifies the behavior of the terminal input routine when operating in display mode. If the value of this parameter is Y, then entering any character in the first position of the field will cause the rest of the field to be erased. bb. The function keys, F6-F20, along the top of a DEC LK201 and DEC LK401 keyboard, are now defined for certain operations during the definition of a report. The standard definitions of these keys, with and without the PF1 key pressed first, are: Key No PF1 One PF1 ---- -------- -------- F6 \ QUIT F7 WIDE NARROW F8 NORECALC RECALC F9 DELETE INSERT F10 LIST DIR F11 NODISPLAY DISPLAY F12 F13 F14 F15 HELP HELP HELP F16 DO GOTO CMDFILE F17 GOTO NEXT GOTO SELECT F18 GOTO EXECUTE GOTO FUNCTION F19 RULERDOWN RULERUP F20 MAXIMIZE MINIMIZE These keys are defined in the XENTIS_KEYDEFS.COM file. You can take advantage of this feature in V4.0 by referencing this procedure in your LOGIN.COM file, with the exception of the RULERUP, RULERDOWN, MINIMIZE, MAXIMIZE, and GOTO NEXT commands. cc. Sybase users may now specify a table from a database other than the default database without having to use the multiple dictionary syntax (appending /DICT=xxx/PASS=yyy to the table name). The table name is specified in the format that Sybase supports in its native tools: dbname.owner.table. dd. There is a new command, SQLWHERE, that is supported for the purpose of allowing a user to enter a WHERE clause for SQL based databases. The SQLWHERE command may be entered at any prompt. The syntax of this command is: SQLWHERE sql_where_statement where sql_where_statement is any SQL WHERE statement that is valid for tables being referenced. The value of this command will be appended to the WHERE clause generated by XENTIS. XENTIS will not perform any syntax validation on the SQLWHERE statement entered by the user. A maximum of 256 characters may be entered. Proper use of this feature can reduce the number of records returned by the database engine to XENTIS. An example might be: SQLWHERE A.NAME LIKE 'AJAX%' OR A.NAME LIKE 'ACME%' To view the resulting SQL statement that XENTIS generates, define the SQL$DEBUG logical to have a value of Y. ee. Data record caching is now supported. This feature can be used by setting a setup parameter or by entering a qualifier at the "Key number to access filename by" prompt. Wise use of caching can improve performance. By appending /CACHE=n to the "Key number to access filename by" prompt, where n is the size of the cache in records, you will be implementing data record caching. Specifying a cache size of zero will disable caching for that file. If /CACHE=n is not appended, then default data caching will occur according to the setup file. To provided good support for caching, there are two setup file parameters to control it. The parameter CACHE-LIMIT is the largest size that a cache for any one file may use. The parameter DFLT-CACHE is the size of the cache that will be used if the user does not specify the /CACHE=n qualifier. CACHE-LIMIT may not exceed 100. Specifying a cache limit of zero will disable caching. Specifying a default cache of zero will require each report to specify a cache size. The default cache value as specified in shipped setup file is zero. Caching is not implemented for XENTIS/Update, for files using VAX DBMS, for SQL based databases, nor on the target files that have a one-to-many relationship. Specifying a cache value in these situations will be ignored. ff. There is a new setup file parameter that controls whether transactions for SQL databases are READ-ONLY transactions or READ-WRITE transactions. The name of this setup file parameter is SQL-READ-ONLY. The allowable values are Y and N. If the value is Y, then a READ-ONLY transaction will be used, otherwise a READ-WRITE transaction will be used. The value of this parameter is shipped as Y. This parameter has no affect if the database is Sybase. gg. There are several new functions supported in calculation expressions. These functions and a brief description are as follows: CHR() Function - converts a number to an ASCII character. It accepts one numeric argument and returns a one byte string whose ASCII value is equal to the numeric argument. For example: ABC;1 = CHR(65) will yield an "A". ASC() Function - converts the first byte of a character string to a number. It is the inverse of the CHR() function. It accepts one string argument and returns a number. For example: ABC = ASC("A") will yield 65. FMTNM() function - Converts a number to a string according to a print mask. The first argument is a number to be formatted. The second argument is a string that contains a XENTIS numeric print mask. It returns a string containing the formatted number. For example: ABC;7 = FMTNM(1.23,"###.###") will yield " 1.230". FMTST() function - Converts a string to a string according to a print mask. It is identical to FMTNM except that the first argument is a string. For example: ABC;14 = FMTST("2063430447","(###) ###-####") will yield "(206) 343-0447". FMTDT() function - Converts a date to a string according to a print mask. It is identical to FMTNM except that the first argument is a date. For example: ABC;15 = FMTDT(16-DEC-1989, "Date is: ######") will yield "Date is: 16-DEC". LOWER() function - Converts a string to lowercase. It accepts a string argument and returns a string. For example: ABC;10 = LOWER("AbcDefGhiJ") will yield "abcdefghij". TIEXT() function - Extracts the time portion of a date that contains time. The extracted value is the number of seconds since midnight. It accepts one date argument and returns a number. For example: ABC = TIEXT(CURDATETIME) will yield 7446 ( (2 * 60 * 60) + (4 * 60) + 6 ) where CURDATETIME is "10-NOV-1992 02:04:06" TICVT() function - Converts an ASCII time to the number of seconds since midnight. It accepts one string argument and returns a number. The string argument must be in a time format acceptable to VMS. For example: ABC = TICVT("02:04:06") will yield 7446. DAEXT() function - Extracts the date portion of a date field resulting in the number of days since 17-Nov-1858. It accepts one date argument and returns a number. For example: ABC = DAEXT(CURDATE) will yield 48936 where CURDATE is 10-NOV-1992. DACVT() function - Converts an ASCII date to the number of days since 17-Nov-1858. It accepts one string argument and returns a number. For example: ABC = DACVT("10-NOV-1992") will yield 48936. DABLD() function - Builds a date from days since 17-Nov-1858 and number of seconds since midnight. It accepts two numeric arguments; the first is the number of days since 17-Nov-1858, and the second is the number of seconds since midnight. The result of the function is a date. For example: NEWDATE = DABLD(48936.,7446.) will yield 10-NOV-1992 02:04:06. DYOWK() function - Converts a date field into a number representing the day of the week. The result will be from one through seven where one is Monday and seven is Sunday. For example: DAY = DYOWK(19-OCT-1992) will yield a 1. SOUND() function - Converts a text field to a 4 character text field according the the soundex algorithm. The soundex algorithm is designed to produce similar output for similar sounding words. The SQL Services for Rdb documentation describes the algorithm. USERT() function - Converts a text field to a text field according to a 3GL user written routine. Additional information may be found elsewhere in this document. USERN() function - Converts a numeric field to a numeric field according to a 3GL user written routine. Additional information may be found elsewhere in this document. USERD() function - Converts a date field to a date field according to a 3GL user written routine. Additional information may be found elsewhere in this document. hh. User controlled attributes may now be specified for particular columns in XENTIS/Report. To support this feature, the format of the bottom window in display mode has been modified slightly and the 'Heading Justify' prompt has been modified to accommodate attributes. Attributes are specified by appending /ATTR=attr-name to your heading justification response, where attr-name is the name of the desired attribute. The attribute entered will be validated with the attributes file. The name of the attribute and the function that it performs are under control of the system manager. Attributes are defined in the XENTIS_ATTRIBUTES.DAT file. Each attribute has a name, an attribute-on sequence of characters, and an attribute-off sequence of characters. The format of the attributes file is documented in the file. The attributes file is a standard text file that can be edited with any standard text editor. Do not print this file because it contains escape sequences that may not be liked by your printer. The name of the attributes file is controlled by the new ATTR-FILE setup file parameter. If you choose a different name for the setup file, then to avoid confusion with model control files, do not use a DAT extension unless you include XENTIS in your filename. The XENTIS/Model function will assume any .DAT file in XENTIS$REPORT$DATA that does not include XENTIS or MENU in its name is a model control file. If a column, or report field, has an attribute associated with it, the attribute-on sequence will be printed immediately prior to printing of the field, and the attribute-off sequence will be printed immediately after printing of the field. This allows the user, with the help of the system manager, to do such things as putting the printer into BOLD mode, UNDERLINE mode, BARCODE mode, etc. Attributes may not be associated with a word-wrapped field. XENTIS assumes that the attribute-on sequence and the attribute-off sequence do not take up any space in the output, or that the attribute-on-off sequences are actually commands to the printing device rather than data that will be printed. This means that attributes do not affect where a field may be placed on the report. Attributes do not take effect when output is to a terminal or a printer that it attached to a terminal. It is also important to realize that should you use an attribute to change the size of a print font, or something similar to that effect, the output may become misaligned, due to the fact that XENTIS has no knowledge of fonts. ii. User controlled attributes may also be specified on any of the three report titles. This is done by appending /ATTR=attribute_name at the end of the title, where attribute_name is the name of the desired attribute. jj. There are two new setup parameters called HEADING-UNDERLINE and TOTAL-OVERLINE. They may have values of Y or N. The default value as shipped is N. If HEADING-UNDERLINE is set to Y, then XENTIS/Report will print dashes under column headings rather than a blank line. Heading underline has no effect if the output is to your terminal. If TOTAL-OVERLINE is set to Y, then XENTIS/Report will print dashes above any accumulated fields. kk. The DBKEY scope for Rdb databases in now explicitly set to ATTACH rather than using the default value. ll. User written functions are now supported in the CALCULATION section. There are three classes of user written functions: text, numeric, and date. Each function class uses two parameters. The first parameter is the name of the user written function, expressed as a string literal. The second parameter is the value to be passed to the user written function. The data class of the second parameter must match the class of the function. Using the XENTIS function USERT indicates that the user written function will be a Text function; USERN indicates that the user written function will be a Numeric function; and USERD indicates that the user written function will be a Date function. Example calculation expressions using this feature are: NEWTEXT;40 = USERT( "CAPITALIZE", COMPANY_NAME ) NEWNUMBER = USERN( "EVENODD", ANY_NUMBER ) NEWDATE = USERD( "LASTYEAR", ANY_DATE ) User written functions may be written in any 3GL language. Instructions on how to write a user written function are found in the sample user written functions provided on the release tape. Sample routines are supplied, and written in the BASIC and C programming languages. The name of the sample user written function is XENTIS_USER_FUNCTION, and it can be found in the XENTIS data directory, usually [XENTIS41.DATA]. Please review the system documentation on the LIB$FIND_IMAGE_SYMBOL for additional technical documentation. mm. The LIST command will now accept an optional filename. This will cause the output of the LIST command to be put into a disk file rather than be displayed on the user's terminal. An example would be: LIST ALL MYDISK:[MYDIR]MYFILE.LIS The output of the LIST command would be place into the file MYDISK:[MYDIR]MYFILE.LIS. Any errors while opening the output file will result in the output being placed on the user's terminal. The LIST command has also been enhanced to allow for a topic of SETUP. The LIST SETUP command will display the current contents of all setup parameters. nn. A performance problem involving the interface to VAX DBMS and CDD-Plus has been resolved. The performance problem exists within CDD-Plus. The general solution is to read CDD-Plus only once for each subschema in the database. The technical solution involves writing a special .XDB32F file into the same directory where the DBMS root file is located. This is automatically done the first time each subschema belonging to the root file is accessed. There will be a separate .XDB32F file for each subschema. Because of this design, the first XENTIS/Report user of the VAX DBMS interface should have the appropriate privilege to create this file and to retrieve subschema information from CDD-Plus. It is also important to keep this .XDB32F file in sync with the database. Therefore, if any subschema in the database changes, then the DBA should integrate the database into the CDD-Plus, delete the appropriate .XDB32F file, and execute XENTIS/Report so that a new .XDB32F file will be created that will reflect the modified subschema. We recommend that appropriate ACL's be placed on the .XDB32F files to control which users can read this file. oo. When filenames and tables are being retrieved from the data dictionary, a message will now be displayed to indicate that this action is being taken. This message is displayed because some dictionaries have a lot of data or some databases are slow to return this information. This is also an indication that the INFO_FILE is not being used. pp. When HELP HELP is entered or when the TOPICS choice is selected from the HELP items, a message will be displayed indicating that HELP topics are being retrieved. This message is displayed because it can take a long time to retrieve all of the help topics. qq. An undocumented logical, designed specifically for technical support assistance, will write a significant amount of internal technical specifications to a newly created XCF file. To utilize this feature set the XENTIS$SUPPORT logical to Y. rr. The value of the setup file parameter DFLT-WRITE-CMD as it is shipped has been changed from N to Y. This is done so on the belief that when most reports are defined it is desirable to save them for future use. ss. Error messages have been improved when a calculation error occurs, such as a divide by zero error. The error message will include information that will allow the user to identify the record(s) causing the error. tt. Hashed indexes are now recognized by XENTIS. They may be used when SQL-JOIN is set to N provided only a full key is specified in the key section of the dialogue and N is responded to the 'Does this key have multiple records' prompt. To avoid breaking any existing .XCF file, hashed indexes will appear at the end of the index list and will have '_HASH' appended to their name. uu. There are two new setup file parameters that control the description used for grand total lines. GT-DESC-1 is used if it will fit on the grand total line. If GT-DESC-1 will not fit on the grand total line, then GT-DESC-2 will be used. If GT-DESC-2 will not fit, then no description will be included on the grand total line. 2. /File a. There is now a new setup parameter that controls the default value for the "Create New Sequential File" prompt. The name of this parameter is DFLT-NEW-SEQ. The allowable values are Y, N, and H. The value shipped with V4.1 is N. b. XENTIS/FILE now supports the GENERATE-REPORT setup file parameter similar to its function in XENTIS/Report. If this parameter has a value of Y when creating a new sequential file, and no records are selected, XENTIS/File will create the new sequential file and leave it empty. If the value of this parameter is N, then XENTIS/file will not create a new sequential file. c. A new response value is now allowed at the "Accumulate" prompt for numeric fields. The value X is added to the allowable values of Y, N, and R. The X value behaves just like the R, for running totals, except that the running total will not be reset at a break, when performing summary output. d. If a data file has an Add-Date defined for it, XENTIS and MAXCIM ECB dictionaries only, then XENTIS will now include a time value if the date data type chosen for the Add-Date supports time. 3. /Dictionary a. The "Create a new empty data dictionary" utility will yield a slightly better RMS design than in previous versions. b. Default print masks are now allowed for text data types. c. The "Pttrn Match" field attribute is no longer used. Loading existing dictionary dump files will ignore this field attribute. This feature was never implemented. Its current space in the data dictionary is now used by print masks that are longer than 16 characters. This will cause a minor problem if someone has entered anything in the "Pttrn Match' field attribute when defining data prior to version 4.1. The symptom will be extraneous characters at the end of the default print mask. The solution to this problem is to correct the default print mask. d. Longer print masks may now be entered. Print masks may be up to 48 characters. e. A response of Q is now allowed at the "Add, Change, Delete, List, Rename, Exit" menu and at the "File, Field, Table, Password, View, Exit" menu. A response of Q will cause the program to exit. f. Print masks for numeric fields will now accept text. You must have at least one # character in your mask. g. The "Create a new empty datafile" utility will now prompt the user for changes and duplicates for each key defined in the file. This utility has also changed the name of the temporary FDL file that it uses and this name will now be displayed if the temporary FDL file is not deleted. h. The maximum size of a validation table has been increased to 500 bytes. The maximum number of entries allowed has been increased to 250. i. The terminology displayed on the screen in the 'Dump' and 'Load' dictionary utilities has been slightly modified. The term 'Sequential' has been replaced with 'Text' and the term 'Unload' has been replace with 'Dump'. These two utilities also now use a default file extension of .DMP if no extension is specified. j. The CDD to XENTIS dictionary transfer has been enhanced to accept a file containing COBOL record description. This enhancement results in an additional prompt prior to the 'Pathname to transfer' prompt. The additional prompt is 'Transfer type CDD or COBOL'. The valid responses are CDD or COBOL. If the response is COBOL, then the Pathname prompt is modified to 'Filename to transfer'. This enhancement also supports the ability to transfer multiple COBOL record layouts from a single COBOL source file. When this occurs, the program will return to the 'Include structure level fields' prompt when it encounters the next record. Some restrictions include: . Only VAX Cobol from DEC is supported. . Only two levels of occurs are supported. . 66, 77, and 88 levels are not supported. . The program stop processing if it encounters the phrase WORKING-STORAGE SECTION, LINKAGE SECTION, REPORT SECTION, COMMUNICATION SECTION, or PROCEDURE DIVISION. . The VALUE IS clause is not supported. . The SYNCHRONIZED clause is not supported. . The JUSTIFIED clause is not supported. . FILLER fields will have a field generated using the name of FILLER-n where n is a sequence number. 4. /Edit a. XENTIS/Edit will now display text data according to the print mask found in the data dictionary. It is important to note that when adding data to a file, the default value for text fields, at the time the text field is being entered, will not include any extra characters from the print mask, nor should the user enter any of these extra characters. For example, if a phone number is a text field with a print mask of (###) ###-####, the user should not enter the parentheses, the space, or the dash characters. 5. General Enhancements a. XENTIS now supports the time portion of date data type fields that allow time. These data types include: VMS Date (DA), Text Date (TDA), Sybase Date (SDA), Ingres Date (IDA), the new MDY data type, the new DMY data type, and user defined date data types. The smallest measurement of time supported is a full second; fractions of seconds are not supported and will be ignored. To print the time portion of a date field, extend the print mask to 20 # characters. Previous versions of XENTIS would remove time portion of any datetime field, (VMS Date, Ingres Date, Sybase Date). To maintain compatability with previous versions, there is a new setup file parameter called IGNORE-TIME. If this parameter is set to Y, then XENTIS will remove the time portion of any datatype field. If it is set to N it will not remove it. So that existing reports will not be broken by V4.1, the value of this parameter is shipped as Y. This parameter is not used by XENTIS/Edit. To remove time from a datetime field without this parameter set to Y use the DABLD and the DAEXT functions in a calculation as follows: NEWDATE = DABLD( DAEXT( OLDDATETIME ), 0. ) Please note that the literals TODAY, TOMORROW, and YESTERDAY are VMS datetime literals. Their current VMS definition is for midnight of the specified day. A calculation is necessary to specify a date literal that includes time. For example, to create a datetime literal using the value of 15-OCT-1992 12:14:16, create the following calculation: CALC1 = DABLD(DACVT("15-OCT-1992"),TICVT("12:14:15")) This is necessary because the standard VMS datetime syntax includes a space between the date portion and the time portion. The XENTIS parser sees the space and thinks that it has reached the end of the literal. b. The audit trail feature used in /Edit and /Update has been enhanced. Reliability has been improved and the format of the audit trail record has changed. The format of the audit trail record is now: DATA FIELD LENGTH DATA TYPE -------------------- ------ --------- Receiver Name 12 Text Generic Filename 32 Text Message Type 1 Text (A, C, or D) Current Date-Time 8 VMS Date VMS Terminal Name 12 Text VMS Username 12 Text VMS Node Name 6 Text VMS Process Id 8 Text Date Prior Change 8 VMS Date RFA 6 RFA Record Length 2 Word Record Image 1 n Record Image Record Image 2 n Record Image The Terminal Name field has been expanded from 6 bytes to 12 bytes. The Username, Node Name, and Process ID fields are new in XENTIS V4.1. c. The output filename prompt in the Audit Trail Manager program has been lengthened to allow long filenames to be entered. In addition, the process name of the audit trail process has been modified. The process name now begins with 'aud' rather than 'AUD'. This will allow you to verify that the correct version of the audit trail is executing. d. XENTIS now supports 3 additional date data types. The abbreviation for these data types are MDY, DMY, and RDR. All three data types are fully supported in all modules of XENTIS including XENTIS/Edit. When defining these data types in XENTIS/Dictionary you should use the MDY, DMY, and RDR codes. MDY is a 6, 8, 12, or 14 character date data type where the first 2 characters indicate the month, the second 2 characters indicate the day of the month, and the next 2 or 4 characters indicate the year. All characters must be numeric characters from 0 through 9. When writing to a file, the null date will be written as "000000" or "00000000". Many users have been using the foreign data type feature or the Dn functions to support this date data type. Using these features is no longer necessary and will degrade performance. When the year segment is two characters, XENTIS will assume years 1900 though 1999 will be used. When the length is 12 or 14 characters, time is included in the field. With 12 characters only hours and minutes are included, but with 14 characters seconds is also included. In this case the data might be represented by a MMDDYYYYHHMMSS layout. DMY is identical to MDY except that the month and day segments of the date are switched around. RDR is a date that is identical to the RDA (RSTS/E Date) data type except that the two bytes are reversed. e. The TDA data type has been expanded to accept a length of 6, 12, or 14 characters. When this data type is 6 characters, the year segment is shorted from 4 characters to 2 characters. Two character years in TDA data types will assume years from 1900 through 1999. When the data type is 12 characters, a 2 character hour field and a 2 character minute field is added. When the data type is 14 characters, a 2 character seconds field is added to the 12 character TDA field. When the TDA field is 14 characters the format of the data might be represented by a YYYYMMDDHHMMSS layout. f. There is a new menu entry that allows a user to submit an existing report to batch. If the report contains either prompted literals or command file Substitution, then the user will be prompted for the appropriate data before the job is submitted to batch. g. The XENTIS Tutorial should now work with XENTIS/Dictionary even if XENTIS/Dictionary is not licensed. h. When selecting 'Run an existing report' or 'Modify an existing report' from the menu, the initial screen that is displayed is no longer blank. The appearance of the screen has been enhanced, and the prompt has been enhanced. i. Error messages have been improved if an error occurs when a new default data dictionary is specified. E. KNOWN PROBLEMS AND RESTRICTIONS. 1. Print frequency U (for Unique) and the setup parameter ACCUM-IF-UNIQUE may not always work when multiple primary files are being used. This is because two records in different primary files may have the same record pointer (RFA in RMS files). After sorting, these two records may get sorted next to each other. As a result, XENTIS thinks they are the same record, because they have the same RFA. 2. If the user enters a prompted literal, then backs up and makes a correction to the prompted literal, the user may be prompted for the first literal even though it is no longer part of the report. This happens because literals that were entered and then changed during the report definition, remain in the internal literal pool. This problem will automatically disappear when the report definition is saved and the report is reexecuted after exiting. 3. A problem may occur with XENTIS Dictionaries created prior to XENTIS V3.1. In some cases the prefix entry in the file record was not created correctly. Due to enhancements made to the processing of prefixes, the incorrect data stored in such prefixes may cause reports or /Edit to work incorrectly. This problem is resolved by running "Edit a Data Dictionary" from the XENTIS/Dictionary menu and selecting "Change" "File" followed by changing the prefix value from spaces to null. Running the program XDFIX_PREFIX found the the images directory will also correct this problem. 4. The sizes of all records from all input files, plus calculations, sort records, and literals, cannot exceed 32767 bytes. 5. /Update does not allow the same data file to be used twice, unless those files are used only to perform selection and/or calculations. This means that you cannot modify a field or delete a record if that field or record is located in a file that is used two or more times in a single /Update run. This restriction is placed due to problems involving record locking, rereading records by RFA, and RMS not being able to keep track of where the next record is located. This restriction may cause certain existing XENTIS command files to no longer work; receiving the error message "Same physical file update not allowed". These XENTIS command files may not have been working correctly. The solution to this problem is to perform this operation in two passes; the first being a SELECT function where the desired records are selected and their pointers are saved into a pointer file, followed by a REUPDATE where the selected records are read after retrieving their pointers from the pointer file. This restriction was effective with V3.6 of XENTIS. 6. When using VAX DBMS with XENTIS, if the same file is specified twice, XENTIS may under some circumstances enter an endless loop while under other circumstances it will not retrieve all desired records. An example of this occurs in the sample PARTS database linking the EMPLOYEE to DIVISION to EMPLOYEE using the MANAGES set and then the CONSISTS_OF set. This problem also occurs if a 3GL program is written using embedded DML statements. It is suspected that this may be a problem with VAX DBMS rather than XENTIS. 7. When using a MAXCIM ECB data dictionary, only one version of a data file is allowed. Specifying a version other than the most current version will be ignored. Using the ACTUAL/GENERIC syntax does not get around this restriction. The LIST FILES command displays the filename as the user entered the filename, which will be different from the file that will be used if a version other than the most current version is entered by the user. 8. When using multiple dictionary reporting with DBMS when DBMS is not your default data dictionary, then a subschema should be specified only on your first DBMS file. It will be rejected on subsequent DBMS files. For example: Third file? EMPLOYEE/DBTEST.DBM$SUBSCHEMAS.PERSONNEL/DICT=DBMS Fourth file? DIVISION/DICT=DBMS 9. When using DBMS under certain circumstances, the user may encounter the error: "Error opening data \ \ -- %RMS-E-ACT, file activity precludes operation". When this error occurs, enter an ERASE command and start the report definition again. 10. The REDISPLAY command does not always work correctly when DBMS is used, the output is to the users terminal, and when there is no requested sort. 11. The DROP-PRIV setup file parameter has no effect with MAXCIM V4 or later files. This is to conform to the MAXCIM security mechanism. 12. The Rdb interface of XENTIS does not work if XENTIS is linked to both the DAS file structure and to Rdb's SQL. If both are desired, then two images must be linked. Contact customer support for more information. 13. Calculations on totals should not use more than one occurrence of the same data field in the same report. An easy work around is to specify a calculation such as: AMOUNT3 = AMOUNT(3) 14. There is no support in the software for descending keys. They may, however, work under certain limited circumstances where the ascending/descending nature of the key is not used. 15. Entering a print mask using dual leading dollar signs or dual leading asterisks without including a trailing minus sign is accepted. Printing negative data will thus erroneously print as if it were positive, with no error indicated. 16. Due to duplicate routine names used by Progress and Ingres, XENTIS will not work with both Progress and Ingres. If a cpu has both Progress or Ingres installed one of the following steps must be take prior to linking XENTIS or installing XENTIS: . The Ingres software must be shut down and its system logicals removed (II_FRAMELIB, II_COMPATLIB, and II_LIBQLIB). . The Progress software must be shut down and its system logical removed (PROLOAD). Either of these steps will cause XENTIS to not see the particular database and will therefore link in stub routines. Specifying ING, PRO, or INGPRO for a third parameter to the XENLINK.COM procedure will instruct XENLINK to excluded the specified database. Read the XENLINK.COM procedure for more information. F. PROBLEMS FIXED IN XENTIS V4.1. Listed below are some of the problems that have been fixed in version 4.1. This list is not intended to be a complete list. However, it does list many of the bugs that were reported by customers and all bugs that may materially affect processing. 1. If a compiled command file was used and the output was directed to the printer port on the user's terminal, subsequent executions of the compiled command file would result in the output being placed in a file called PRINTERPORT.LIS. 2. The wrong help message was displayed at the "Press return to exit" prompt. 3. If a user setup file was locked by another process, XENTIS/Report would abort. 4. The BROWSE function from the menu would assume all output files had a filetype (extension) of '.LIS'. BROWSE will now use the filetype specified in the setup file parameter DFLT-OUTPUT. It also assumed that your file was in your current default directory. It will now use the default directory specified in the setup file. 5. Under certain circumstances attempts to modify a calculation when using /MODEL or /FILE may result in an inability to complete the calculation section. 6. REUPDATE could select the wrong number of records when using a MAXCIM V3 dictionary if the number of records previously selected were less than the number of fields in the file being updated. 7. XENTIS/Update with a MAXCIM ECB dictionary did not process the external reference checks correctly when there were 2 or more external reference checks for the file being updated. This is applicable to MAXCIM version 4 or later. 8. Including a !~~PROMPT command in an .XCF file without any definition commands (!~~D) for command file substitution would cause an abort. It will now ignore the !~~PROMPT command. 9. Secondary input files that were relative where the join field from a previous file had a length that was not controlled by the data type (i.e. zoned decimal vs. integer ) would not read the correct record from the relative file. 10. The help message for the "Enter calc expression" prompt was accidently merged with the help message for the "Do you wish to have calculations" prompt. 11. Numeric prompted literals could not be changed. 12. Header records in relative files that contained header records were not processed correctly. 13. Simple calculations assignments of the nature "NEWDATE = OLDDATE" for date datatypes would work only if OLDATE was a VMS DATE data type. 14. Responding to B at the execute prompt when your default dictionary was an Rdb database would not create a correct DCL .COM file. 15. Compiled command files would contain and enforce the file version number of pointer files. 16. The processing status message would appear in the output if the output was to a printer port. 17. A data file with nine keys could not be included in a view when defining a view in XENTIS/Dictionary. 18. Rdb users are no longer required to have the ACCUM-IF-UNIQUE setup parameter set to N for accumulation to work. 19. XCF files would not be created correctly when the default dictionary is CDD and CDD$DEFAULT is defined in such a way that the first node of the translation is in turn another logical. 20. XCF files would not be created correctly if a prompted literal was used for either the "First key to read" or "Last key to read" prompt, and the data type of the key was a VMS Date, and the prompted literal data class was D. 21. XENTIS/Update would abort when trying to write to the log file if the user did not have write privileges to his default directory. 22. Attempts to GOTO past the calculation section when calculations existed, and at least one calculation could not be expanded from from field numbers to field names would result in the user having to press Return many times in response to warning messages. 23. If the output report file was on another node in the network and the output disk on the target node had a name that did not exist on the local node, then XENTIS would not accept the output file name. 24. Invalid dates in XENTIS/Edit would return the current date rather than inform the user of an error. 25. Conditional calculations where the result was a string whose value was not set in a previous calculation would result in printing nulls rather than spaces if the setup parameter TEXT-IS-STRING was set to Y. 26. XENTIS/File required both read and write access to all fields in the output file in XENTIS V4.0. 27. Calculations in XENTIS/Update would under certain circumstances yield strange results when a VAL or ABS function was also used. 28. Entering more than 20 SET commands would cause an abort. 29. A GOTO SELECT-99 command would cause an erroneous error message. 30. A problem regarding replacing missing records with zeros/nulls when the source key to read was spaces and no records had yet been read from the auxiliary data file has been corrected. 31. XENTIS/Report failed to enter display mode if a command file was passed to it when the START-IN-DISPLAY parameter was set to Y and the START-IN-DISPLAY-CMD parameter was set to N. It will now enter display mode when it has finished processing the command file. 32. Using print frequency H would sometime cause those field with the H print frequency to print twice. This usually happened when a break and a new page occurred at the same time. 33. The XENTIS/Report dialogue did not recognize when a partial field was being used as a break field for the purpose of generating a default break description. 34. A misleading error message would be displayed when XENTIS received the error message 'Global page table is full' from the operating system. It was displaying 'Not a BASIC error'. 35. The XENTIS/Dictionary utilities now gets it input from SYS$INPUT rather than SYS$COMMAND. This allows DCL command files to use dictionary utilities. 36. XENTIS will now reference its images by explicitly using a filetype (extension) of '.EXE;'. This insures that the image activator will execute the image file with the highest version number rather than possibly executing another version of the image that is installed with the INSTALL utility; even if that other version can not be found with a DIR command. (Files don't really get deleted until they are deinstalled.) 37. Summary output using XENTIS/File where the output file contained more that 150 fields would fail in V4.0. This has been fixed. 38. The word wrap feature did not work correctly when combined with print frequency F. 39. When creating a DCL .COM file by responding with C at the "Execute" prompt in /Report, the dictionary file specified in the resulting .COM will no longer include a version number. 40. Random aborts of XENTIS/Edit with 'Memory Management' or 'Access Violation' errors has been fixed.

GrayMatter Home | XENTIS Home | Download Software | XENTIS Technical Support | Contacting GrayMatter | XENTIS News

Comments? Send us your feedback.	www.graysoft.com
	© Copyright 2020 GrayMatter Software Corp. All rights reserved.