XENTIS Documentation -- Release Notes
XENTIS 5.0 -- Released 2005
XENTIS V5.0 Release Notes This document contains information about using XENTIS V5.0 and highlights features that are available in V5.0 that were not available in versions prior to V5.0. A. INSTALLATION AND GENERAL INFORMATION. 1. If you have a previous version of XENTIS already installed and you never installed an interim version, we recommend that you copy the release notes of these previous versions from saveset F on your release tape and review them. The following DCL command should retrieve these release notes and place them in your current directory: BACKUP/LOG in_dev:XENTIS050.F/SELECT=[*...]*.REL*/SAVE_SET [] where 'in_dev' is your tape drive or cd drive. 2. Multiple versions of XENTIS may be installed and active at the same time. Please see section below for more information. 3. On VAX systems XENTIS V5.0 requires OpenVMS V6.1 or later. On Alpha systems XENTIS V5.0 requires OpenVMS V6.2 or later. It is also important to install all the BASIC RTL patches available from HP. Without these patches, XENTIS will abort under certain circumstances. 4. Beginning with V4.2, CALLABLE XENTIS is a feature that is available only upon request from your vendor. It is no longer available in the standard release. CALLABLE XENTIS provides the ability for a 3GL program to call XENTIS (except /Dictionary and /Edit) in the context of the same process or image. XENTIS can still be executed in the context of a subprocess. Using XENTIS in a subprocess is not considered CALLABLE XENTIS. 5. If you are upgrading from V4.2 or later, please execute the XENTIS_UPGRADE.COM procedure found in XENTIS50$COMFILES:. This purpose of this procedure is to inform the installer of the names of the various XENTIS text files that have been modified by this site in the previous version. The best example here would be the setup file XENTISSET.DAT, but other text files are also sometimes modified. 6. To support CDD on Alpha systems, the installation procedure will automatically link 3 images that access CDD. This link during install is not needed on Vax systems. To force the install procedure to link these three images for either Vax or Alpha systems, then define the XENTIS_LINK_YES to translate to Y prior t installing XETNIS. For example: $ DEFINE XENTIS_LINK_YES Y 7. If you are using XENTIS with the Oracle, Sybase, Ingres or Progress relational database, then you will need to relink XENTIS to support these databases. The following commands will perform this: a. Copy the object libraries from your tape or disk. For Vax: $ BACKUP/LOG dev:[dir]XENTIS050.G/SAVE/SEL=[*...]*.*; [] For Alpha: $ BACKUP/LOG dev:[dir]XENTIS050.H/SAVE/SEL=[*...]*.*; [] b. Relink XENTIS $ SET DEFAULT XENTIS50$PROGRAM: $ @XENTIS50$COMFILES:XENLINK.COM dev:[dir] where dev:[dir] is the location of the object libraries c. Restart XENTIS $ @XENTIS50$COMFILES:XENTIS_SHUTDOWN.COM $ @SYS$MANAGER:XENTIS50_START.COM $ PURGE XENTIS50$PROGRAM:*.* Make sure your database server is started prior to executing these commands. You will need the SYSNAM and the CMKRNL privileges to perform this procedure. This section does not apply if the relational database you use is Oracle Rdb, formerly Digital Rdb. 8. For those sites that make extensive use of Compiled Command Files (XCC), there is a DCL command procedure that will compile all XENTIS Command Files (XCF) found in a particular directory into Compiled Command Files. The name of this procedure is XENTIS_RECOMPILE_COMMAND.COM and can be found in the XENTISnn$REPORT$DATA directory. A review of the comments inside this procedure will document how it works. B. INSTALLING AND USING TWO DIFFERENT VERSIONS AT THE SAME TIME Beginning with version 4.3 XENTIS allows two or more different versions to be installed and active at the same time. This is accomplished by including the version number, in this case 50, with the logicals used by XENTIS and including the version number in many executable files. The information in this section describes how this is accomplished and what the customer needs to do to insure smooth operation of two or more versions at the same time. 1. All XENTIS logicals that previously began with XENTIS, now begin with XENTISnn, where 'nn' is the version number. Please note that symbols such as XENTIS$DICT and XENTIS$PASSWD have not changed. These symbols are unique to your process and do not need to be changed. 2. All XENTIS executable files that may get installed with the INSTALL utility now have the version number appended to the filename. This is because the INSTALL utility does not allow two or more files with the same name to be installed at the same time. Customers that have a limited user count license, or those that have a Progress database interface license must either install XENTIS executables with the SYSLCK privilege or must give each user the SYSLCK privilege. (The XENTIS startup procedure automatically examines the XENTIS license for these two conditions and installs the executables if appropriate.) Please note that due to a bug in Rdb, the XENTIS executables should not be installed if the Rdb interface is to be used. 3. None of the control files or data files that XENTIS uses have had their names modified for this purpose. The lone exception to this rule is the startup file that is executed during system startup. Its name is now XENTISnn_START.COM, found in the SYS$MANAGER directory, where 'nn' is the version number. 4. XENTIS version 5.0 may be installed and started, while a previous version is active and running. It may not be installed while another installation of V5.0 is active and started. The V5.0 installation procedure detects this condition and will halt its processing. 5. During system startup, the various versions of XENTIS should be started in order with the oldest version first and the newest version last. When shutting down XENTIS, it is best if the reverse order is followed; the latest version first. 6. Existing batch command files present a unique problem. Many or most batch command files created prior to version 4.3 contain a line in them similar to "RUN XENTIS$PROGRAM:XRP". Under the old scheme of filenames and logicals, this would always execute the current version of XENTIS. Under the new scheme of filename and logicals, this would execute a version of XENTIS that was previously installed. If it is desired for pre V4.3 batch command files to use version 5.0, then perform the following steps. a. Copy XRP50.EXE to XRP.EXE in the same directory. b. Define a logical as: DEFINE XENTIS$PROGRAM XENTIS50$PROGRAM Beginning with batch command files created under version 4.3 or later, you can control which version of XENTIS is used. This is done with the XEN_VER DCL symbol. To use version 4.3, set XEN_VER to "43"; to use version 5.0, set XEN_VER to "50"; etc. This symbol can be set in a user login file or the system login file, SYS$MANAGER:SYLOGIN.COM. If this symbol is not set, the current version will be used. 7. To remove an older version of XENTIS from your system, execute the XENTIS_SHUTDOWN.COM procedure for all versions in the order of most recent version first. (XENTIS_SHUTDOWN.COM was introduced in version 4.2.) Next, delete all the files from the older version. Next deassign the PKMSSHR logical. Next, execute the XENTIS startup files, found in SYS$MANAGER, in the order of most recent version last. C. NEW FEATURES 1. /Report and /Report modules (/File, /Word, /Model, /Update). a. The debug feature has been enhanced. The user can now specify a starting point when most debug messages will be output. The starting point is the number of primary file records processed. This can dramatically reduce the number of debug messages produced. This feature does not affect the "F", meaning File, debug messages. The ability to use this feature is controlled by the XENTISnn_DEBUG_DELAY logical. For example to have debug messages displayed only beginning with the 60th primary file record, the user would enter the following at DCL prior to running XENTIS: $DEFINE XENTIS50_DEBUG_DELAY 60 Until the 60th record is processed, only File (F) debug messages will be displayed, if these messages are requested. b. XENTIS now supports the scaling of packed decimal data described in a Maxcim ECB data dictionary. Turning on or off this capability is controlled by the new MAXCIM-PACKED-SCALE setup parameter. The default value of this parameter is N, meaning the feature is turned off, for compatibility with prior versions. c. Support for reading XML data has been added. The ability to read XML data is specified by entries in the XENTIS data dictionary. See below section for more information. d. Writing an XML formatted text file is now supported by the XENTIS/Model feature. A new model control files, XML.DAT, is used to provide this ability. This control file will not work with older versions of XENTIS, as the FORMAT paramter with a value of XML is allowed only with XENTIS version 5.0 or later. The user can make changes to this control file but only if they change the following parameters: LINE-PREFIX, LINE-POSTFIX, LEADING-BLANKS, TRAILING-BLANKS, and DEFAULT_OUTPUT. The LINE-PREFIX and LINE-POSTFIX control the tags used to indicate the start and end of a record. 2. Reading XML Formatted Data XENTIS supports reading XML formatted data from two different types of sources, a text file and an web server using a TCP/IP connection. a. Support for XML data where the source is a text file is now supported. This is done by entering an "X" at the "Record Format" prompt in the Add File function of the "Edit a Dictionary" menu item. The "Record" tag in the XML data file must match the generic file name entered. There must also exist a field name in the data dictionary under the specified generic file name for each data field that is to be processed from the XML data file. The field types for these fields are limited to the following types: T, STR, YN, GN, TDA, MDY, DMY, and PRD. This means that only character data is allowed in an XML file. For example, if a generic file of XMLRECORD is defined with fields CUSTNAME and CUSTID, then a sample of the XML file would look like: <XMLRECORD> <CUSTNAME>Acme Electric</CUSTNAME> <CUSTID>200</CUSTID> </XMLRECORD> <XMLRECORD> <CUSTNAME>Smith Tools</CUSTNAME> <CUSTID>221</CUSTID> </XMLRECORD> b. Support for XML data where the source is a data stream from a web server is now supported. This is done by entering a "W" at the "Record Format" prompt in the Add File function of the "Edit a Dictionary" menu item. The "Record" tag in the XML data stream must match the generic file name entered. When this feature is used, the user should enter the URL path name of the data source in the "Actual Filename" field. For example, if the data is found in "customers.xml" on the bellevue.acmelectric.com" node, the "Actual Filename" description would be: http://bellevue.acmelectric.com/customers.xml This property value must begin with "http://" to avoid file name syntax validation errors upon entry in the data dictionary. If the URL entered at the Actual Filename prompt is too long, then you may continue the entry in the URL1 through URL6 prompts. Trailing blanks in these entries will be ignored. Note, these prompts are new for version 5.0. One of the uses of this feature will be to have a CGI script executed on the web server that returns data in XML format to XENTIS. The URL may also contain placeholders that can be used to pass run time data to a CGI script. These placeholders are of the form ~P-n~, where "n" is a digit from 0 through 8. A example of a URL with placeholders might be: http://test.myweb.com/test.cgi?state=~P-1~&zip=~P-2~ If placeholders are used in a URL and the associated generic file is specified as a primary file, then the "Key to access", "First record to read" and "Last record to read" prompts are replaced with a sequence of "Parameter Literal (P-n) for Primary File" prompts. Only text literals are allowed to be entered. If placeholders are used in a URL and the associated generic file is specified as an auxilliary file, then the "Key number to access...by" and "Field n to build key" prompts are replaced with a sequence of "Parameter Value (P-n) for ... File" prompts. Text literals and fields from a prior file are allowed to be entered. Placeholder zero (0) is a special case. The VMS username will be substituted if placeholder zero is used. When used an an auxilliary file, XENTIS will treat the XML data stream as an indexed file. This means that XENTIS can join multiple HTTP server XML streams together. In the XENTIS processing logic, instead of performing an indexed file read, XENTIS will open a new connection to the HTTP server and issue a new request for an XML data stream. If the URL is defined correctly, placeholders are used correctly, and the end user correctly specifies paramters, this can result in an elegant solution to retrieving data from dissimilar data sources. If it is done incorrectly, it can result in a massive amount of unrelated data. In the case of structured XML data, XENTIS supports qualified tags. In the below example: <Record> <CompanyName>Acme Electric</CompanyName> <Contact>John Jones</Contact> <SupportExpires>30-JUN-2004</SupportExpires> <Address> <Shipto> <City>Seattle </City> <Zip>98101</Zip> </Shipto> <Billto> <City>Tacoma </City> <Zip>98402</Zip> </Billto> </Address> </Record> The City and Zip tags are qualified by the Shipto and Billto tags. To make sure that the City tag within Shipto is processed independently from the City tag within Billto, and likewise for the Zip tags, you should create your data dictionary fields using the following names: SHIPTO$CITY or ADDRESS$SHIPTO$CITY SHIPTO$ZIP or ADDRESS$SHIPTO$ZIP BILLTO$CITY or ADDRESS$BILLTO$CITY BILLTO$ZIP or ADDRESS$BILLTO$ZIP c. Other notes about the XML data include: . Only character data is supported in the XML file. This is why only some data types are allowed. Verification of data type restriction is performed at the time a report is run, not at the time the data dictionary is edited. . The XML parser used does not support the optional end tag of "/>" . Only one occurence of a field within a record is supported. . Fields within a record may be in any order. . If a fields occurs more than once in a record, the last value encountered will be used. . Fields that are not defined in the data dictionary are ignored. . Records found in the XML file, other than the one that matches the generic file name in the data dictionary will be ignored. . Fields defined in the data dictionary, but not found in the XML data will be set to spaces. . Pointer files cannot be created. d. The new setup file parameters for use with XML data are: . NET-DEVICE. This should have a value of "UCX$DEVICE". . NET-PROTOCOL. This controls the text string that prefixes the URL passed to the web HTTP server. . NET-PORT. This controls the TCP/IP port number to use. It is usually set to a value of 80. . NET-METHOD. This parameter should be set to "G". . NET-INCL-HOST. This controls whether or not the host name is included in the URL passed to the HTTP server. It can have a value of Y or N. . NET-INCL-PROTOCOL. This controls wheter or not the protocol is included in the URL passed to the HTTP server. It can have a value of Y or N. . NET-TIMEOUT. This controls the number of seconds XENTIS will wait for a response from the HTTP server. Reduce this value when testing new CGI scripts. . NET-READSIZE. This controls the number of bytes read in each request from the HTTP server. . NET-REQ-XML-HEAD. This controls whether or not the XML header, "<?xml", is required. D. KNOWN PROBLEMS AND RESTRICTIONS XENTIS has several known problems and restrictions. Some of these are known bugs in the XENTIS software, some are known bugs in other software that XENTIS uses, such as Rdb, while others are limitations placed upon XENTIS by the operating system. 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 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. Under most circumstances this restriction is not a problem. However, should this limitation be reached, it is possible to avoid the limitation by restricting the record size of certain files. This is accomplished as the following example illustrates. $ DEFINE RECSIZE_LIMIT_SALESHIS 12000 If the above DCL command is entered, then XENTIS will limit the SALESHIS file to 12000 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 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 will display the filename as the user entered the filename and the name of the file that was actually opened by the software. 7. The DROP-PRIV setup file parameter has no effect with MAXCIM V4 or later files. This is to conform to the MAXCIM security mechanism. 8. 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) 9. 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. 10. 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. 11. The COBOL to XENTIS dictionary transfer does not support sequence numbers in columns 73 through 80. Sequence numbers are typically used in older punched card source files. If you have sequence numbers, you must remove them. In addition sequence numbers in character positions 1 through 6 are not allowed. If they exist you must remove them. Using a 'Box Cut' with the TPU/EVE text editor is an easy way to accomplish this removal. 12. The Rdb interface converts Rdb VARCHAR fields to CHAR fields. This means that VARCHAR fields will have spaces appended to the end of the field to fill out the field to its maximum size allowed. If a VARCHAR field is used in an index, which is usually not wise, and two or more tables are joined using the /NOSQL qualifier, then you will probably have to specify a sub-field as your 'field to build key' field. For example: if the desired index to file B is using datatype VARCHAR(5) but only two of the five characters are really being used, then you should use only the first two characters of the input field from file A. 13. When displaying the output of a report to the screen, there is a limit of the number of lines available. If a detail contains more than the limit, then one or more printed lines may scroll off the top of the screen. 14. The FMTNM function does not support the blank-when-zero feature of print masks, designated by the ampersand character, the trailing DB if negative feature, the trailing CR if negative feature, or the surrounding parenthesis if negative feature. 15. The minimum version of Ingres that is supported is version 6.3. This allows XENTIS to support groupids of the Knowledge Management Extension to Ingres. 16. The Rdb interface does not support the catalog and schema features of Rdb V4.1 and later. When XENTIS/Report attaches to a multischema database it specifies that the multischema capability will be turned off for the duration of the attachment. If a multischema database is used, then the RDB-USE-ATTACH setup parameter must be set to Y. 17. When entering a CDD pathname and you do not want CDD$DEFAULT applied, be sure to start the pathname with _CDD$TOP rather than CDD$TOP. In other words, start the pathname with an underscore character. 18. XENTIS/File does not work when the output file is an Rdb table and the table contains computed_by fields, or virtual fields. 19. Calculation expressions may not include the vertical bar character (|). If you need a vertical bar character, the following calculation expression will yield one: BAR;1 = CHR(124.) 20. Due to a bug in Rdb, the Rdb interface for XENTIS does not work if XENTIS is installed with privileges. If you have a limited user license key, give all XENTIS users the SYSLCK privilege and define the XENTIS50_PRIV_LIST to NOINSTALL before executing the XENTIS startup procedure (SYS$MANAGER:XENTIS50_START.COM). 21. The minimum supported version of Rdb is version 4.0 on Vax systems and 6.0 on Alpha AXP systems. 22. The minimum supported version of Oracle is version 8.0. To use Oracle8 contact your XENTIS vendor as a relink is required. 23. The only supported versions of Progress are 6.2N and 6.2L on VAX systems and 6.2N on Alpha systems. 24. The Info File Creation program does not work with Rdb V4.0, but it does work with later versions of Rdb. 25. XENTIS version 4.3 and later cannot coexist with version 4.2 on Alpha systems. Version 4.2 was a temporary version and uses translated images. Remove version 4.2 from your Alpha computer system. 26. The CENTURY-ADJUST setup parameter when used with foreign dates, also known as user written dates, is applied only after a valid date is retured from the customer maintained foreign date routine. Once a valid date is returned, if the year, when ignoring the century, is less than the value of the CENTURY-ADJUST parameter, and the year is less than 2000, then XENTIS will add a century to the date. One effect of this is that since the foreign date routine cannot return a date of 29-Feb-1900, a resulting date cannot be 29-Feb-2000. Once again, it is the responsibility of the customer maintained foreign date routine (XENTISnn_USER_PACK) to return a valid date. E. PROBLEMS FIXED IN XENTIS V5.0. 1. The Filename Info File Creation utility did not work. The workaround was to use the version 4.7 copy of the utility. This utility is found in the XENTIS System Utilities Menu. The purpose of this utility is to improve the speed of displaying file names in the Info (middle) Window of XENTIS/Report when the user has a large data dictionary. It does this by scanning the data dictionary and placing all filenames into a separate special file. If this special file exists, XENTIS/Report retrieves file names from the special file instead of the data dictionary. Changes to the data dictionary are not reflected in this file. This problem was introduced in version 4.8 and has been corrected. 2. Under some circumstances XENTIS/Edit did not correctly write the Change Date or the Add date to the data file, if those properties were defined in the data dictionary. It was writing garbage. This problem was introduced in version 4.8 and has been corrected. 3. In XENTIS/Edit, if a default data dictionary was not defined the user would not be able to enter a data dictionary name. This problem was introduced in version 4.8 and has been corrected. 4. In XENTIS/Report if a report was defined to place report data into a title line and the output of the report was directed to the user's terminal and that terminal was a CRT, or a PC running terminal emulation software, then the the title lines were not updated to reflect the change in data. This problem was introduced in version 4.3 and has been fixed. 5. In XENTIS/Report, the sizes of certain memory areas cleared by the ERASE command were recalculated due to changes in versions 4.5 through 4.8.
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.