DEComni_MMS_for_Digital_UNIX________________________ Release Notes March 1998 This document contains the release notes for DEComni MMS for Digital UNIX Version 3.1 software and documentation. Please read this document before using the product and consult it before reporting problems to Digital. Revision/Update Information: This is a new document for the current release. Software Version: DEComni MMS Version 3.1 Digital Equipment Corporation Maynard, Massachusetts ________________________________________________________________ March 1998 © Digital Equipment Corporation 1998. All Rights Reserved. Possession, use, or copying of the software described in this documentation is authorized only pursuant to a valid written license from DIGITAL or an authorized sublicensor. Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. The postpaid Reader's Comments forms at the end of this document request your critical evaluation to assist in preparing future documentation. The following are trademarks of Digital Equipment Corporation: Alpha AXP, BASEstar, DEC, DECmessageQ, DECnet, DECnet-DOS, DECosap, DEComni, DIGITAL, DIGITAL UNIX, FMS, LN03, MicroVAX, NAS, OpenVMS, OpenVMS Alpha, PATHWORKS, PDAS, Rdb/VMS, ReGIS, ThinWire, TK, ULTRIX, VAX, VAXcluster, VAX COBOL, VAX FORTRAN, VAX Pascal, VAX RMS, VMS/ULTRIX Connection, VT, and the DIGITAL logo. The following are third-party trademarks: Excel is a registered trademark of Microsoft Corporation. IBM is a registered trademark of IBM Corp. INGRES is a trademark of Ingres Corp. LOTUS 1-2-3 is a registered trademark of Lotus Development Corp. MS, Microsoft, and MS-DOS are registered trademarks of Microsoft Corporation. Network File System and NFS are trademarks of Sun Microsystems, Inc. ORACLE is a trademark of Oracle Corp. PostScript is a registered trademark of Adobe Systems Incorporated. SINEC AP, SINEC H1, SICOMP, Simatic, SINEC, SINUMERIK and SIROTEC are registered trademarks of Siemens, AG. UNIX is a registered trademark licensed exclusively by X /Open Company Ltd. Windows, Windows NT and Windows 95 are trademarks of Microsoft Corporation. Wonderware InTouch is a registered trademark of Wonderware Corporation. X/Open is a registered trademark of the X/Open Company Limited This document was prepared using VAX DOCUMENT, Version 2.1. _________________________________________________________________ Contents Preface................................................... v 1 Installation Information 1.1 DEComni API...................................... 1-1 2 New Features and Modified Functionality 2.1 Operating System Support......................... 2-1 2.2 Debug and Trace Messages......................... 2-1 2.3 libmms.so Image Id............................... 2-2 2.4 MMS Archive Library No Longer Distributed........ 2-2 2.5 Dynamic Loading of DASes......................... 2-2 2.6 Named Variable Lists and Events.................. 2-2 2.7 Compiling and Linking Your Application........... 2-2 2.8 Looking Up a Value............................... 2-3 2.9 Printing a Value................................. 2-3 2.10 Deleting a Value................................. 2-3 3 Restrictions 3.1 Named Variable Lists and Alternate Access........ 3-1 3.2 OSI Addressing................................... 3-1 3.3 Interoperability................................. 3-1 3.4 Object Names..................................... 3-2 3.5 Segmented Services............................... 3-2 3.6 D_FLOAT.......................................... 3-2 3.7 Inconsistencies in the Monitor Type Attribute of a PI............................................. 3-2 3.8 Alternate Access with a Structure................ 3-3 iii 4 Known Problems 4.1 Cancel Request................................... 4-1 4.2 Unsolicited Error Indications.................... 4-1 4.3 Connection Establishment......................... 4-1 4.4 Reusing Internally-Created VMDs.................. 4-2 4.5 Negotiated_vmd_struct and incoming_vmd_struct Data............................................. 4-2 4.6 Nesting Level and Parameter CBB Not Checked...... 4-2 4.7 Calls to omni_connect and omni_listen............ 4-2 4.8 RFC1006 Support.................................. 4-3 4.9 Association Scope Variable Support............... 4-3 4.10 Simultaneous Conclude Handling Problem........... 4-3 4.11 omni_listen Appears to Hang...................... 4-3 iv _________________________________________________________________ Preface DEComni MMS Documentation Set DEComni MMS for Digital UNIX Version 3.1 provides the following documentation: o DEComni MMS for Digital UNIX Installation Guide o DEComni API and DEComni MMS User Guide v 1 _________________________________________________________________ Installation Information 1.1 DEComni API DEComni API and DEComni MMS are separate products. You must install DEComni API Version 3.1 before you can install DEComni MMS. Installation Information 1-1 2 _________________________________________________________________ New Features and Modified Functionality This section describes the new features and modified functionality for DEComni MMS Version 3.1. 2.1 Operating System Support DEComni MMS Version 3.1 may run with DIGITAL UNIX V3.2x or V4.0x. 2.2 Debug and Trace Messages DEComni MMS Version 3.1 may print debug and trace information messages. You can get messages from different functional components of DEComni MMS by defining the following environment variables: o OMNI_MMSCORE_DEBUG_ENABLED o OMNI_DT_DEBUG_ENABLED o OMNI_ED_DEBUG_ENABLED o OMNI_EXC_DEBUG_ENABLED These variables enable respectively messages from: core functions activated by requests to MMS services, Data Transport operations, Encode and Decode operations for PDUs, exception and error conditions. DEComni MMS prints messages to stdout or to the file whose name is provided by the environment variable OMNI_MMS_LOG_ FILE . Example: setenv OMNI_DT_DEBUG_ENABLED 1 setenv OMNI_MMS_LOG_FILE my_mms_log.txt New Features and Modified Functionality 2-1 New Features and Modified Functionality 2.3 libmms.so Image Id 2.3 libmms.so Image Id A libmms.so library now contains a symbol prefixed by ALE_image_id that provides the version identifier for the library itself. This symbol can be displayed via the UNIX nm utility and can be used to identify patched and special libraries. Example: nm /usr/shlib/libmms.so | grep ALE_image_id ALE_image_id_31_000_980315 | 0004396972122304 | T | 0000000000000008 2.4 MMS Archive Library No Longer Distributed Starting with Version 3.1, the MMS archive library libmms.a is no longer distributed. 2.5 Dynamic Loading of DASes DEComni API Version 3.1 allows DEComni MMS to be integrated dynamically. DEComni API provides a new registration utility for Version 3.1 integrators: omni_registry. This utility allows DEComni MMS to register itself under DEComni API by specifying its shareable image. Using the information found in the registry database, DEComni API Version 3.1 can locate and load the MMS shareable image dynamically during its initialization phase. 2.6 Named Variable Lists and Events DEComni MMS supports two additional objects: Named Variable Lists and Event Enrollments. For further information, refer to the DEComni API and DEComni MMS User Guide. 2.7 Compiling and Linking Your Application DEComni API Version 3.1 will be the last DEComni API version to support omni_server. With DEComni API Version 3.1, a new facility is provided for linking applications: the "collapsed" approach. In the "collapsed" approach, a DEComni API application is linked to the shareable "libomniapi.so" so that the omni_server process is no longer required. 2-2 New Features and Modified Functionality New Features and Modified Functionality 2.7 Compiling and Linking Your Application To build your executable program, use the commands listed below. Using the omni_server: cc -o myprog myprog.c -lomniclt -lc_r -lmach -lbsd Using the "collapsed" shareable (without omni_server): cc -o myprog myprog.c -lomniapi -lods -lpthreads -lc_r -lmach -lbsd There are some rules that you must follow in order to migrate a V2.x application to a Version 3.1 application in case you want to link the Version 3.1 "collapsed" shareable. Please refer to DEComni API and DEComni MMS User Guide for information about how to write an application that can link with the "collapsed" shareable. 2.8 Looking Up a Value The new API call omni_lookup_value allows MMS users to look at the value associated to a write indication before providing positive acknowledgement (omni_get_value) or negative acknowledgement (omni_reject) of the value. 2.9 Printing a Value The new API call omni_print_value allows MMS users to print the value of a buffer associated to a DEComni API variable. 2.10 Deleting a Value The new API call omni_delete_definitions allows MMS users to delete a previously-defined (omni_define) object and its descendent. New Features and Modified Functionality 2-3 3 _________________________________________________________________ Restrictions 3.1 Named Variable Lists and Alternate Access At present, no support is available for alternate access in conjunction with Named Variable Lists. No provision is made for connecting an alternate access specification to a variable that is part of a Named Variable List, as allowed by the MMS protocol. 3.2 OSI Addressing All ODS records for VMDs used in calls to omni_listen must have a unique TSAP. In the example that follows, the address of VMD_A is: PSAP1.SSAP1.TSAP1 The address of VMD_B is: PSAP1.SSAP2.TSAP1 If you use both VMD_A and VMD_B as the VMD in omni_listen, an error occurs on the second call to omni_listen, because both VMD_A and VMD_B have the same TSAP. 3.3 Interoperability When establishing an OSI transport connection, the Digital side will request the following transport parameters: Alternate Transport Class Implementation ID Preferred TPDU size If a third party transport provider has difficulty negotiating these parameters, you may experience interoperabilty problems. Restrictions 3-1 Restrictions 3.4 Object Names 3.4 Object Names DEComni MMS does not verify whether an object, i.e. a named variable, contains valid MMS ID characters. The user must take care to define objects within the character set from a-z, A-Z, 0-9, the underscore (_), and the dollar sign ($). The name must also start with an alphabetic character. 3.5 Segmented Services During segmented services, such as upload and download, DEComni MMS does not free the allocated data until the entire operation is complete. In addition, it does not perform other operations, such as omni_put_value or omni_get_value, on the same connection. 3.6 D_FLOAT DEComni MMS Version 3.1 does not support D_FLOAT variables. 3.7 Inconsistencies in the Monitor Type Attribute of a PI It appears that the omni_c_attr_monitor attribute is used inconsistently. In defining a PI, a user can specify one of three values to the omni_c_attr_monitor attribute: omni_c_pimnt_not_present, omni_c_pimnt_permanent, and omni_c_pimnt_current. Its type is omni_l_pi_monitor. However, if a user requests a omni_get_remote_attributes on a PI, then tries to retrieve the omni_c_attr_monitor attribute, a simple boolean value is returned: TRUE or FALSE. This is due to the level of detail returned by MMS. When defining a PI, you can specify whether you want to activate or disactivate monitoring. If you choose to activate the monitoring facility, you can also request MMS to activate it permanently or for the duration of the current connection only. However, after an omni_get_remote_attributes operation on a PI, the only information returned concerns whether monitoring is on or off. It is not possible to provide the same level of detail associated with the omni_c_pi_monitor type. For this reason, MMS uses the omni_c_boolean type. 3-2 Restrictions Restrictions 3.8 Alternate Access with a Structure 3.8 Alternate Access with a Structure If the alternate access specifies a single component of a structure, DEComni MMS incorrectly formats a request with listOfAccessResult that refers to the structure type. Restrictions 3-3 4 _________________________________________________________________ Known Problems 4.1 Cancel Request DEComni MMS does not support Cancel Request. 4.2 Unsolicited Error Indications If a DEComni MMS application receives a reject PDU, the DEComni MMS core attempts to match the reject's invoke id with an outstanding request. If it cannot find a match, or an invoke id was not sent with the reject, the user receives an indication of type 0. 4.3 Connection Establishment Note the following: o There is a defect in the processing of Associate Indication/Initiate Request with proposed syntax. If the proposed syntax of an Associate Indication does not contain MMS/BER as a valid concrete syntax pair, DEComni MMS may not reject the request. o The Presentation Context Index (PCI) is not validated for inbound requests and confirmations. If the peer decides to use a PCI value other than the one proposed /accepted, DEComni MMS cannot detect the error. o DEComni MMS currently accepts all proposed syntax pairs on an Initiate Request. In normal circumstances, DEComni MMS should only accept MMS/BER. Known Problems 4-1 Known Problems 4.4 Reusing Internally-Created VMDs 4.4 Reusing Internally-Created VMDs If the translate flag of an omni_listen call is NON-ZERO and no matching VMD is available, DEComni MMS creates a VMD internally upon receipt of an Initiate indication. This VMD remains in memory until the application exits. Once the association terminates or aborts, the VMD becomes available for reuse when subsequent Initiate indications from the same peer are received. This may potentially cause some confusion if the application routinely adds object definitions to this VMD after a connection is established, given that these added object definitions will persist after association conclusion. 4.5 Negotiated_vmd_struct and incoming_vmd_struct Data The output parameters "negotiated_vmd_struct" of omni_connect and "incoming_vmd_struct" of omni_listen contain the fields omni_t_vmd_syntax and omni_t_vmd_ap_title. At present, DEComni MMS does not fill in either of these fields; omni_t_vmd_syntax is an obsolete field and omni_t_vmd_ap_title is not currently used. 4.6 Nesting Level and Parameter CBB Not Checked At present, DEComni MMS does not check the nesting level or parameter CBB negotiation result from connection establishment before sending service requests. It does not check nesting level before sending a structure or array, nor does it check Param CBB for STR1 or STR2 support. 4.7 Calls to omni_connect and omni_listen If the corresponding ODS entry for a VMD is not present during an omni_connect call, the following error is returned: %OMNI-E-BADHANDLE, The Value of the Handle Parameter is Invalid This is incorrect. The error returned should be: %OMNI-E-BADHANDLE, Directory Service access failure 4-2 Known Problems Known Problems 4.8 RFC1006 Support 4.8 RFC1006 Support RFC1006 (MMS over TCP/IP) is not supported. 4.9 Association Scope Variable Support Association scope variables are not supported. 4.10 Simultaneous Conclude Handling Problem DEComni MMS is unable to handle simultaneous conclude request conditions. If the DEComni MMS application and the partner request a conclude at the same time, DEComni MMS enters a loop of continuous rejects. 4.11 omni_listen Appears to Hang A DEComni MMS process which calls omni_listen and receives only a transport connection request and no presentation details from a remote system appears to hang and prevent subsequent connection requests from being answered. This situation may arise if one or more remote systems request a connection and there is only one omni_listen_ a call pending. One of the remote systems fails to send its presentation details and therefore does not complete its connection request; in this case, the omni_listen_a call enters the "in use" state and all further connection requests are automatically rejected. The "in use" state remains until either: o The remote connection is disrupted o The remote connection finally sends its presentation details, or o The DEComni MMS application is stopped. The above situation is a normal consequence where only one omni_listen_a call is pending and a remote device fails to complete its MMS connection request cycle (it is an MMS implementation problem associated with the remote system). To overcome this problem, you should post multiple calls to omni_listen_a, equal to or greater than the number of remote connections, thus allowing the remaining connection requests to be processed and not blocked. Known Problems 4-3 Known Problems 4.11 omni_listen Appears to Hang ________________________ Note ________________________ At present, the OSAK layers of DECnet OSI do not implement a timeout when a remote system fails to complete its connection request by sending its presentation details within the required time. If this feature is implemented in DECnet OSI, DEComni MMS will take advantage of the feature in a later release. ______________________________________________________ 4-4 Known Problems