OASIS-CC VERSION V02.05.14(2) RELEASE NOTES TABLE OF CONTENTS 1 Compatibility And Requirements Information 2 OASIS-CC Installation Procedure 2.1 Solaris Version 2.2 HP_UX version 3 Upgrading V02.05.14(1.x) Applications to V02.05.14(2) 4 Major New Features Or Code fixes 4.1 Timed Command Processing (crn 583) 4.2 Data Server Implentation (crn 586) 4.3 Building The Decomposition Tree Before Establishing Connection (crn 601) 4.4 Utility Task Xterm Window Naming Convention 4.5 Pseudo Xmitter Writing To File Only 5 Change Requests Closed With This Release 6 Main Known Problems And Limitations 6.1 Filename Length Limitation 6.2 Limited thruput while using a generic communication protocol with a TDM frame (crn 259) 6.3 Badly formatted internet address hangs OASIS-CC (crn 258) 6.4 CEV may fail if CEV_TIMEOUT is greater than 86400.0 seconds (crn 358) 6.5 Initialization problem with keyed binary bridge (crn 359) 6.6 Apparent memory leak in graph presentation type (crn 337) 6.7 Ask window problem (crn 486) 6.8 Running awb remotely with the SOLARIS version (crn 378) 6.9 OASIS-CC not compiling procedures (crn 409, tbd) 6.10 Size limitation for command log and command window (crn 508) 6.11 Incorrect time reported in message log (crn 512) 6.12 res2rfg TAE utility may crash on *_.res resource files (crn 525) 6.13 Leak when displaying panel with DDOs (crn 529) 6.14 Use caution when using remote displays 6.15 OASIS-CC never told when crash occur on a remote X server (crn 529) 6.16 Remote Display issues in HP_UX version (crn 529) 6.17 Exiting a loop with repeat count via a "GOTO" statement (crn 516) 6.18 Duplicate subfield reference in command request not reported (crn 528) 6.19 Problem running awb under hp_ux 10.20 (crn 610) 7 Anomaly Or Enhancement Request Reporting 8 Documentation Set Status 9 Upgrades To The Spectrometer Application Appendix A: HIGH LEVEL LANGUAGE PROCESSING OF "TIMED" COMMANDS Appendix B: oasis_data_server.h Appendix C: CHANGE IN LATEST_DATA RECORD LAYOUT Appendix D: MEASURED PERFORMANCES OASIS-CC VERSION V02.05.14(2) RELEASE NOTES 12/05/96 Updated 1/6/97 for SunAda 3.0 Compilation (crn 572) These release notes describe version V02.05.14(2) (SparcStation and HP 9000/700 series) of OASIS-CC. .A copy of these notes can be found in $ODIST/release_notes/oasis_v2.0514_2. A copy of the notes from previous releases, including patches, can also be found in the $ODIST/release_notes directory. 1 Compatibility And Requirements Information --------------------------------------------- This release of OASIS-CC has been tested on SparcStation 2, 10, and 20 (see below for compatibility with UltraSparc). This release of OASIS-CC has also been tested on a HP 715/100 running HP_UX 9.05 and on a HP 712/80 running HP_UX 10.x. There are 2 different versions: A SOLARIS version which requires: X X11R5 from SUN MOTIF 1.2 from SUN (Motif Developer's Kit) TAE+ 5.3c for SOLARIS (available from Century Computing for a non-NASA project, from GSFC for a NASA project) A HP_UX 9.x and 10.x version which requires: X X11R5 MOTIF 1.2 TAE+ 5.3b for HP (available from Century Computing for a non-NASA project, from GSFC for a NASA project) Notes concerning the SOLARIS version: (1) It requires a C compiler (OASIS-CC was tested using the Sun C SparCompiler. The make_oasis_app.sh utility requires the Sun C SparCompiler. This utility needs to be updated for use with other compilers such as the GNU C compiler); (2) Release 14 for SOLARIS requires TAE+ 5.3c. It is not compatible with TAE+ 5.3l; Notes concerning the HP_UX distribution: (1) It requires a C compiler (OASIS-CC was tested using the HP_UX C compiler (cc). The make_oasis_app.sh utility requires the HP_UX C compiler. This utility needs to be updated for use with other compilers such as the GNU C compiler); How much memory you need depends on the application. Our experience is that 32 Mbytes is a minimum. Disk space requirements are about 40 Mbytes for the Solaris distribution and 50 Mbytes for the HP_UX distribution. Notes on license requirements ----------------------------- TAE+ A TAE+ license is not required for every workstation that the executable image of OASIS-CC runs on. TAE+ needs only to be licensed for the workstation(s) used to develop TAE+ interfaces and to create the executable image. In other words, a TAE+ license is required for each workstation that is used to run the workbench and link the executable image. OASIS-CC A separate license is required for each workstation used to run OASIS-CC. 2 OASIS-CC Installation Procedure ---------------------------------- 2.1 SOLARIS Version ------------------- Installing from the distribution tape ------------------------------------- Refer to the Unix OASIS-CC V02.05.12 Installation Guide for instructions on how to install the OASIS-CC software from the tar tape. Sites that require the ability to maintain applications running under previous releases must install V02.05.14(2) in a new directory. ******************************************************************************* * We recommend that you run OASIS-CC in the SOLARIS RT (realtime) scheduling * * class rather than the SOLARIS TS (time-sharing) scheduling class. * ******************************************************************************* ******************************************************************************* * Note that the SOLARIS distribution expects /usr/ccs/bin to be placed before * * /usr/ucb in $path. This is because OASIS-CC needs to be linked with the * * SOLARIS linker, not with the SunOs 4.1 compatibility linker * ******************************************************************************* * ***************************************************************************** * The SOLARIS version of OASIS-CC now expects that the environment variable * * LD_LIBARY_PATH to be defined with the path to the X and the Motif libraries.* * For example on LASP uses the following definition: * * setenv MOTIFHOME /opt/SUNWmotif * * setenv OPENWINHOME /usr/openwin * * setenv LD_LIBRARY_PATH $MOTIFHOME/lib:$OPENWINHOME/lib * ******************************************************************************* * ***************************************************************************** * The SOLARIS version of OASIS-CC expects the X11 include files to be in * * /usr/include/X11. If this is not the case, create a symbolic link from the * * directory containing the X11 include files * * (usually /usr/openwin/include/X11) to /usr/include/X11. * * ***************************************************************************** 2.3 HP_UX version ----------------- Installing from the distribution tape ------------------------------------- The installation procedure for the HP 9000/700 version is the same as for the SPARC version with the additional steps listed below. Refer to the Unix OASIS-CC V02.05.12 Installation Guide for instructions on how to install the OASIS-CC software from the tar tape. Additional steps to be done for the HP_UX version: After installing the release distribution you need to: (1) Define ODIST (2) cd $ODIST/nosrc_objs (3) execute the make_ldas.sh script This will create 2 files (lda1 and lda2) that are needed to link OASIS-CC on your machine. ******************************************************************************* * We recommend that you run OASIS-CC with a realtime priority rather than * * with a time share priority. (see rtprio(1) in the man pages) * ******************************************************************************* * ***************************************************************************** * The HP_UX version of OASIS-CC expects the environment variable * * LPATH to be defined with the path to the X and the Motif libraries. * * For example on our development system we use the following definition: * * setenv LPATH /usr/lib/Motif1.2:/usr/lib/X11R5:/usr/lib:/lib * ******************************************************************************* * ***************************************************************************** * The HP_UX version of OASIS-CC expects the X11 include files to be in * * /usr/include/X11R5. If this is not the case, create a symbolic link from * * the directory containing the X11 include files to /usr/include/X11R5. * * ***************************************************************************** * ***************************************************************************** * The HP_UX version of OASIS-CC expects the Motif include files to be in * * /usr/include/Motif1.2. If this is not the case, create a symbolic link from * * the directory containing the Motif include files to /usr/include/Motif1.2 * * ***************************************************************************** 3 Upgrading Applications to V02.05.14(2) ---------------------------------------- Applications running under OASIS-CC V02.05.14(1.x) are not compatible with V02.05.14(2) and need to be upgraded. Upgrading from V02.05.14(1.1) or V02.05.14(1.2) or V02.05.14(1.3) ----------------------------------------------------------------- Because of crn 583 (support for "timed" command) a new parser needs to be installed and two stubbed routines need to be inserted in libOasisUser.a (see 4.3 below) (1) copy the new parser files: cp $ODIST/common_distrib/utilities/parser_int.dat $OASIS_PARSER/. cp $ODIST/common_distrib/utilities/parser.dat $OASIS_PARSER/. (2) update $OASIS_USER_CODE/libOasisUser.a as two new routines need to be provided In addition, to support the Data Server concept (crn 596, see 4.4 below) a new field has been added to the LATEST_DATA table just after the field ROUTE_TO_BRIDGE. This new field is named ROUTE_TO_DATA_SERVER. It is a SYSTEM-controlled field that can take the value of NEVER (default), ALWAYS or ON_CHANGE. This makes an application running 14(1.x) incompatible with this release. A script file is provided in $ODIST/bin to update the LATEST_DATA table (file $OASIS_DATABASE/latest_data.dat) to the new format. To upgrade from 14(1.x) to the release: (1) Log in the application account intended for application development. This account should be populated with the files of the application you want to upgrade from. (2) Set up all the environment variable and make sure that ODIST points to the new release distribution (3) Execute the upgrade script by typing $ODIST/bin/14_1to14_2.csh Upgrading from V02.05.14(2.alpha) --------------------------------- Because of the compiler changes you need to reload the parser table. After having initialized your OASIS-CC application environement variables enter: convert_table To support the Data Server concept (crn 596, see 4.4 below) a new field has been added to the LATEST_DATA table just after the field ROUTE_TO_BRIDGE. This new field is named ROUTE_TO_DATA_SERVER. It is a SYSTEM-controlled field that can take the value of NEVER (default), ALWAYS or ON_CHANGE. This makes an application running 14(2.alpha) incompatible with this release. A script file is provided in $ODIST/bin to update the LATEST_DATA table (file $OASIS_DATABASE/latest_data.dat) to the new format. To upgrade from 14(2.alpha) to the release: (1) Log in the application account intended for application development. This account should be populated with the files of the application you want to upgrade from. (2) Set up all the environment variable and make sure that ODIST points to the new release distribution (3) Execute the upgrade script by typing $ODIST/bin/14_1to14_2.csh Upgrading from V02.05.14(1 xfer test release) -------------------------------------------- Because of crn 583 (support for "timed" command) a new parser needs to be installed and two stubbed routines need to be inserted in libOasisUser.a (see 4.3 below) (1) copy the new parser files: cp $ODIST/common_distrib/utilities/parser_int.dat $OASIS_PARSER/. cp $ODIST/common_distrib/utilities/parser.dat $OASIS_PARSER/. (2) update $OASIS_USER_CODE/libOasisUser.a as two new routines need to be provided 4 Major New Features Or Code Fixes ----------------------------------- The following new features and major code fixes are included in this release. New features and code fixes have associated Change Request Numbers (CRNs) that provide a means of tracking changes to the OASIS-CC code. CRNs are generated by LASP and the general OASIS-CC user community. The pertinent CRNs are shown for each enhancement or correction included in this new version of OASIS-CC. 4.1 Timed Command Processing (crn 583) -------------------------------------- The parser has been modified to allow a local variable of the type "clock time" to be used as argument of "timed" command UNTIL parameter. These are valid statements: hold set telemetry rate to 8 until /-08:00:00.1 declare variable $t = /-08:00:00.1 hold set telemetry rate to 8 until $t message simulator hold until /-06:56:00.0 declare variable $t = /-06:56:00.0 message simulator hold until $t The command subsystem code calls two new routines that are to be provided by the application developer. The first routine (Oasis_CUntilCmd) is called whenever a "timed" command is requested, just before the command subfields are "packed" into the command bit pattern. This routine can be used to insert in the command bit pattern the command time information. The second routine (Oasis_CUntilMessage) is called after a "delayed" command message is built. This routine can be used to insert in the command bit pattern the message time information. For example cstol> hold turn on telemetry until $t ; Oasis_CUntilCmd is called before ; the command is built cstol> message simulator hold until $t cstol> turn on telemetry cstol> send message ; Oasis_CUntilMessage is called after ; the message has been built See appendix A for a in-depth description of the Oasis_CUntilCmd and Oasis_CuntilMessage procedures. 4.2 Data Server Implentation (crn 586) -------------------------------------- Concept ------- The purpose of the Data Server implementation in OASIS-CC is two folds: (1) Provide a data transfer mechanism that is more efficient that the Bridge subsystem. (2) Provide a mechanism by which OASIS can distribute data on-demand from client processes. In this implementation OASIS-CC acts as a server process that accepts connection and data request from client processes. The client processes request data in the form of data set that are pre-defined in OASIS-CC via the BRIDGE_DEFINITIONS table. Interface Specification ----------------------- The interface is specified in $ODIST/include/oasis_data_server.h (see appendix B for a listing of this file). Client to Data Server -------------------- After a client process has connected to the OASIS-CC Data Server it can send three types of message to OASIS-CC: ADD_GROUP, REMOVE_GROUP and DISCONNECT. ADD_GROUP is used to request the transmission of specific data set (see paragraph 4 on how data set are defined in OASIS-CC). A client process can request more than one data set at a time. REMOVE_GROUP is used the request the removal of a specific data set from the data transmitted by OASIS-CC to the client process DISCONNECT is used by the client process to warn OASIS-CC that it is disconnecting (If the client disconnect without telling OASIS-CC it still Ok, as OASIS-CC catches the corresponding signal. However it is cleaner to have the client tell OASIS-CC). The messages from a client to OASIS-CC have the same format: an 32-bit opcode (1 means ADD_GROUP, 2 REMOVE_GROUP and 3 DISCONNECT) and a 16-character field (the name of the group to be added or removed. In the DISCONNECT message this field is ignored). Data Server to Client --------------------- The data transmitted by OASIS-CC to a client process consists in a stream of 2 32-bit field. The first field is a tag field that identifies the measurement that is transmitted. It is the hashkey value derived from the measurement external_element and item names and used in OASIS-CC as a key to measurement LATEST_DATA table record. The utility COMPUTE_HASHKEY can be used to compute a measurement tag from its external_element and item names. The second field is either the measurement DN or EU value. It is the responsibility of the client process to keep track of the type (and unit if an EU value is sent) of each one of the measurements it has requested. From time to time OASIS-CC sends to the client processes data in which the tag is set to zero. These are end-of-frame (or end-of-packet) markers. Data between two end-of-frame (or end-of-packet) markers was collected from the same frame (or packet). Starting and Terminating the Data Server ---------------------------------------- The Data Server is controlled using the switch statement. It is started by the statement SWITCH ON DATA_SERVER It is terminated by the statement SWITCH OFF DATA_SERVER When "switched on" the Data Server accepts connection and request messages from up to 5 client processes. When "switched off" it disconnects from all the connected client processes and hibernates until "switched on" again. Note 1: The Data Server stream does not need to be defined in the STREAMS table. Its name (DATA_SERVER) implies the stream. Therefore the name DATA_SERVER should not be used to define a stream. Note 2: The code looks for a socket number in the LATEST_DATA record: External_Element : DATA_SERVER Item_Name : SOCKET_ADDRESS Dn_low : socket number to use for the data xfer If this LATEST_DATA record is not present the value 5010 is used. Defining a Data Set -------------------- Data grouping is done using the BRIDGE_DEFINITIONS table. Assume that a client sends an ADD_GROUP request to OASIS for the group names "XFER". OASIS searches the BRIGDE_DEFINITIONS table for all the records that have NAME = XFER. These records define the dataset to transfered to the client. The DATA_TYPE field for each records define the type of data that will be transfered. Currently only DN_DATA or EU_DATA are supported. The UNITS field IS NOT taken into account. If EU_DATA is requested what is send the EU value of the measurement in the unit defined in the LATEST_DATA table record of the measurement. Current Limitations and Future Extensions ----------------------------------------- - A client cannot request at the same time the DN and the EU value of a measurement. - Currently the visibility into the status of the Data Server is very limited. A "show data_server status" statement should be implemented. - There is an hardcoded limit (5) as to how many client processes can be connected at the same time with the Data Server. - Currently the code does not protect a user from checkpointing LATEST_DATA while the field ROUTE_TO_DATA_SERVER is not set to NEVER. - When data is super-commutated, the last measurement appears to be transmitted first. 4.3 Building The Decomposition Tree Before Establishing Connection (crn 601) ---------------------------------------------------------------------------- In previous releases in the IP protocol the connection to the client of (or server to) OASIS-CC was done before the decomposition tree was built. This caused problem for applications with a large decomposition tree and where the client of (or server to) OASIS-CC starts sending data as soon as the the connection is done. In this release the user can select when the decomposition tree is build: before or after the connection. The user's choice in passed to OASIS-CC via the latest_data entry "stream_name" MODE. Dn value of "stream_name" MODE Action 0 OASIS-CC is client Decomp. tree after connection 1 OASIS-CC is server Decomp. tree after connection 2 OASIS-CC is client Decomp. tree before connection 3 OASIS-CC is server Decomp. tree before conenction 4.4 Utility Task Xterm Window Naming Convention ----------------------------------------------- The contents of the TASK_NAME field in the UTILITY_TASKS record is now used as label to the XTERM window opened when the RUN directive is executed. 4.5 Pseudo Xmitter Writing To File Only --------------------------------------- A new transmitter task has been developed that only records to a file the command message (or the data routed to it from a receiver task). The STREAMS table setup for this transmitter task is: field value STREAM_NAME name of the stream PROCESSOR EXTCOMM_SUBSYSTEM DIRECTION FORWARD_STREAM PROTOCOL TEST_4 FRAME_LENGTH max length (in bits) of the buffers passed to the stream The name of the file to which the data will be written is expected in a CHARACTER_STRING global variable named EXTERNAL_ELEMENT name of the stream ITEM_NAME FILENAME If this global varaible does not exist (or the name is blanked) the transmitter task uses the default filename of "test_4.data". 5 Change Requests Closed With This Release -------------------------------------------- crn # Title Comment 294 OASIS can block all CSTOL statement execution when it is an IP server. 538 Reference to non-existing local variable kills OASIS. 555 same as 294. 572 Problem running OASIS on Ultra Sparc machine 583 Implementation of HOLD/UNTIL clause. see 4.1 586 New fast xfer mechanism. see 4.2 588 same as 538. 589 Snap fails when presentation type is "label" and string is blanked. 601 IP protocol allows for connection after the decomp tree see 4.3 is build. 602 Floating point exception when parsing number (hp_ux only) 603 Monitors with initial value = 0 not routed to bridge when route_to_bridge = "on_change". 606 Non-recoverable "system error" when procedure called with non-existing parameter 607 Change to utlity task xterm window naming convention. see 4.4 608 Pseudo xmitter writing to file only see 4.5 6 Main Known Problems And Limitations --------------------------------------- 6.1 Filename Length Limitation ------------------------------ In OASIS-CC filenames can be up to 128 characters long. In the SOLARIS and the SunOS versions, the length of the pathname (not the length of the environment variable that translates into the pathname) is included in the filename length. In some case, the 128 character limit can be reached. A way around this limitation is to softlink the directories to directories with shorter names and define the environment variables relative to the new directories. 6.2 Limited thruput while using a generic communication protocol with a TDM --------------------------------------------------------------------------- frame (crn 259) -------------- The current implementation of the generic communication protocol provides the user with some flexibility in controlling the load put on the host machine by the data acquisition if the data comes as packets. Ideally, it would be nice to choose the time_out and frame_length parameters (in the streams table record describing the primary stream) such as frame_length/time_out >> bit rate. If the stream is packetized the only requirement on the frame_length is that it has to be greater than the largest of the packets. The larger the frame_length, the greater the time_out value can be and therefore the lower the load on the machine. Currently in the case of a TDM frame, the frame_length has to be equal to the length of the frame, which limits the possible values for the time_out parameter. 6.3 Badly formatted internet address hangs OASIS-CC (crn 258) ------------------------------------------------------------ Putting a badly formatted internet address (such as "/128.32.33.34" instead of "128.32.33.34") in the data_line field of the links table for streams that use the IP protocol causes OASIS-CC to hang. 6.4 CEV may fail if CEV_TIMEOUT is greater than 86400.0 seconds (crn 358) ------------------------------------------------------------------------ When CEV_TIMEOUT is set to a value greater than 86400.0 seconds, a command may immediatly fail CEV, as if the CEV_TIMEOUT was set to 0.0. This is due to a SunAda compiler problem. 6.5 Initialization problem with keyed binary bridge (crn 359) -------------------------------------------------------------- The problem occurs under the following conditions: (a) The bridge is a binary keyed bridge; (b) The "w" values in the TB[w] format don't follow the format rules (i.e "w" defaults to 32 for eu_data and to 96 for time_data, "w" is rounded to the nearest 8 bits and "w" is limited to 128 * 8 for character strings; and (c) non-key items are not recieved before the triggering key item is recieved. Then OASIS-CC may report an error in the "write_line" routine and it is possible that some of the first records are not correctly formatted. This problem can be avoided by using "w" values that follow the rules listed above. 6.6 Apparent memory leak in graph presentation type (crn 337) -------------------------------------------------------------- The graph presentation type gives the appearence of a memory leak. This is because it was designed to update very rapidly without concerns for memory deallocation except at certain times. This may need to be reconsidered in the future. For now, it is necessary to know when memory is cleaned up in order to avoid the problem of memory continuing to be allocated. If you have a continuously updating graph, it will only have memory cleaned up when: 1) The panel is deleted. (not hidden). 2) A non-visible point is plotted and the graph is set to "jump" to the new point ("dojump" resource is TRUE). 3) The graph item is redrawn due to some change in its appearance. This may be anything including a title change, font change, color change, or anything which would require the items to be rearranged in the graph. 4) The graph area is redrawn by a user scrolling with scrollbars. Notice that continuously updating graphs which take long period of time before a non-visible point is plotted (the end of the graph is reached) will continuously allocate memory without ever deallocating it. 6.7 Ask window problem (crn 486) --------------------------------- This is a non fatal problem which is caused by rapid succession of ask windows. Undelayed back to back ASK windows result in the following type of error message in the window from which OASIS-CC was started: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 38 (X_QueryPointer) Major opcode of failed request: 0 Resource id in failed request: 0x200820 (e.g) Serial number of failed request:43641 6.8 Running awb remotely with the SOLARIS version (crn 378) ------------------------------------------------------------ You cannot run the awb code delivered with OASIS-CC from a remote workstation if you set the DISPLAY environmental variable using the full node name (such as setenv DISPLAY mirza.colorado.edu:0.0). You need to set DISPLAY using the internet address instead (such as setenv DISPLAY 128.138.137.20:0.). This problem concerns the SOLARIS verion only. 6.9 OASIS-CC not compiling procedures (crn 409, tbd) ----------------------------------------------------- When OASIS-CC compiles a procedure, it creates some temporary files in $OASIS_TMP. Those files are deleted (except for the files generated by the special clps) when OASIS-CC terminates via a CSTOL OFF. The files created by the special clps are not deleted. If OASIS is not terminated via a CSTOL OFF no files are deleted. This can cause problem if and when OASIS-CC (in the same environment) is run with different privileges as it may not have the permission to overwrite the files left by a previous session. 6.10 Size limitation for command log and command window (crn 508) ---------------------------------------------------------------- When a command with many subfields is used, the message generated when the command is built can be truncated (because of the limitation of the message size in the event message log). The same problem exists with the ASCII text displayed in the command window. 6.11 Incorrect time reported in message log (crn 512) ----------------------------------------------------- Due to a bug in the runtime delivered with the Ada compiler, the time reported in the event log of an OASIS-CC application started before midnight the Saturday before the last Sunday of April (!) is off by one hour after midnight (i.e, the time goes from 23:59:59 to 01:00:00). This problem affects all version of OASIS-CC. 6.12 res2rfg TAE utility may crash on *_.res resource files (crn 525) -------------------------------------------------------------------- The res2rfg utility crashes when it encounters a string larger than 132 characters. For example this can occur when using the Cstolq macro in awb. A workaround this problem is to use the '\' continuation character to end a line before it reaches a dangerous length. 6.13 Leak when displaying panel with DDOs (crn 529) --------------------------------------------------- There is a leak (which has been traced to Motif and to the Interview code used by TAE) when a panel with a DDO is displayed. This leak has been discovered in the Solaris version. It probably exists in all versions of OASIS-CC. 6.14 Use caution when using remote displays ------------------------------------------- Testing remote displays has shown that problems can occur in a heterogenious environment. For example we found problems when displaying panels with presentation types that have text input from the HP_UX version of OASIS-CC to an X11R4 server running the X MIT code or to a X11R5 server running the X Bluestone code or the X Sun code. Therefore users should carefully test their usage of remote displays before running in an operational environment. 6.15 OASIS-CC never told when crash occur on a remote X server (crn 529) ----------------------------------------------------------------------- Assume that OASIS-CC is displaying on a remote X server and that the workstation on which the remote X server runs crashes. OASIS-CC is made aware of the crash only after a period of time that may be rather long. OASIS-CC itself does not crash, but all X activities (input and output) are stopped until OASIS-CC is made aware of the crash. Same thing happens if the ethernet connection to the remote X server is severed. Note that this is a different situation from the X server being terminated on the remote workstation. 6.16 Remote Display issues in HP_UX version (crn 529) ----------------------------------------------------- Terminating an X server on which OASIS-CC is displaying can cause OASIS-CC to crash. 6.17 Exiting a loop with repeat count via a "GOTO" statement (crn 516) ------------------------------------------------------------------------ If a loop with repeat count is not exited via either the "end loop" or an "escape" statement, the loop counter is not re-initiliazed when loop is re-entered at the "loop" statement. 6.18 Duplicate subfield reference in command request not reported (crn 528) -------------------------------------------------------------------------- Assume the following statement: set telemetry with format 1, format 2 No errors or warnings are printed by Oasis to caution the user that the same subfield is referenced twice in the command request statement. Oasis uses the last value (2 in the example) for the subfield. 6.19 Problem running awb under hp_ux 10.20 (crn 610) ---------------------------------------------------- Some users have reported that when they are running awb under hp_ux 10.20 it does not respond to mouse click. The distribution contains a version of awb linked with archive library that seems to work. The executable is name awb_static. 7 Anomaly Or Enhancement Request Reporting -------------------------------------------- The mechanism previously used with the VMS version since 1988 to report OASIS-CC anomalies or to suggest enhancements to the OASIS-CC functionality has been extended to the SunOS version. The report generated using this mechanism can be sent to the OASIS project office by electronic mail (the preferred way) or by regular mail. Each report is assigned a Change Request Number (CRN) and is acknowledged to the originator. The CRN can be used to track progress on the report. To report an anomaly enter: $ODIST/bin/report.csh 8 Documentation Set Status ---------------------------- none. 9 Upgrades To The Spectrometer Application -------------------------------------------- none. Appendix A: HIGH LEVEL LANGUAGE PROCESSING OF "TIMED" COMMANDS DEVELOPMENT OF THE USER PROVIDED CODE When linking an application, OASIS-CC expects the user code to be placed the $OASIS_USER_CODE/libOasisUser.a archive library. This is the same archive library in which OASIS-CC expects the user equation code. As for the equation code the script $ODIST/bin/equation_Imakefile.csh can be used to create a makefile to maintain the user code. OASIS-CC is distributed with an archive library that provides stubbed routines. Source code for the stubbed routines can be found in $ODIST/common_distrib/objects (the file oasis_cmd_stub.c contains stubs for Oasis_CUntilCmd, Oasis_CUntilMessage in addition to stubs for Oasis_CCmd, Oasis_CCmdMessage and Oasis_CLoadMessage). The equation toolbox is described in the release notes for v02.05.10 (Appendix B) and v02.05.11 (Appendix C). Command buffer access routines supported in earlier versions are described in the release notes for v020514(1) (Appendix B). ROUTINES DESCRIPTION Routines name Purpose Oasis_CUntilCmd Insert time information in the command buffer before the command is buffered in a command message buffer, prior to packing the command subfields (if any) into the command bit pattern. Oasis_CUntilMessage Insert time information in the command message buffer before it is passed to the communication subsystem for transmission. MANUAL PAGES FOR THE ROUTINES NAME Oasis_CUntilCmd SYNOPSIS #include #include int Oasis_UntilCmd(command_descriptor_ptr, until_descriptor_ptr) COMMAND_DESCRP_PTR command_descriptor_ptr; UNTIL_DESCRP_PTR until_descriptor_ptr; DESCRIPTION This routine is called before the command is built. 'command_descriptor_ptr' is a pointer to a command_descriptor structure defined as: typedef struct command_descriptor { char *reference_element; /* top most external element in element hierarchy */ char *external_element; /* external_element */ char *command_name; /* name of the command */ short command_type; /* command type */ void *command_ptr; /* pointer to the command buffer */ int command_size; /* actual command size in bits */ /* set by oasis, updated by the user code */ int max_command_size; /* max # of bits allocated by oasis for the command */ } COMMAND_DESCRP, *COMMAND_DESCRP_PTR; 'until_descriptor_ptr' is a pointer to until_descriptor structure defined as: typedef struct until_descriptor { int year; /* year 1900 - 2099 */ int month; /* month 1 - 12 */ int day; /* day of month 1 - 31 */ float second; /* second of day */ } UNTIL_DESCRP, *UNTIL_DESCRP_PTR; Before calling Oasis_CUntilCmd, OASIS-CC loads the structure with values derived from the contents of the "UNTIL" parameter. Before calling Oasis_CUntilCmd, OASIS-CC loads 'reference_element', 'external_element', 'command_type' and 'command_name' with values extracted from the commands table and the element_hierarchies table. 'command_type' should be set to CMD_TIMED. 'command_ptr' points to a buffer containing the command bit-pattern. In this buffer 'command_size' bits have been loaded by OASIS-CC. The buffer contents can be modified by the user code that should update 'command_size' to reflect the new size of the command. The size of the buffer allocated by OASIS-CC for the command is 'max_command_size' bits. The function should return CMD_SUCCESS if successful. Note that the 'char' components of the command_descriptor structure are in uppercase. NAME Oasis_CUntilMessage SYNOPSIS #include #include int Oasis_CUntilMessage(message_descriptor_ptr, until_descriptor_ptr) MESSAGE_DESCRP_PTR message_descriptor_ptr; UNTIL_DESCRP_PTR until_descriptor_ptr; DESCRIPTION Oasis_CUntilMessage is called after a command message has been built. 'message_descriptor_ptr' is a pointer to message_descriptor structure defined as: typedef struct message_descriptor { char *external_element; /* external_element */ int max_message_size; /* max # of bits of the message allocated by oasis*/ int header_size; /* size if the header in bit */ int trailer_size; /* size of the trailer in bit */ short message_type; /* message type */ void *message_ptr; /* pointer to message buffer */ int message_size; /* actual # of bits of the message */ /* set by oasis, updated by user code */ } MESSAGE_DESCRP, *MESSAGE_DESCRP_PTR; 'until_descriptor_ptr' is a pointer to until_descriptor structure defined as: typedef struct until_descriptor { int year; /* year 1900 - 2099 */ int month; /* month 1 - 12 */ int day; /* day of month 1 - 31 */ float second; /* second of day */ } UNTIL_DESCRP, *UNTIL_DESCRP_PTR; Before calling Oasis_CUntilMessage, OASIS-CC loads the structure with values derived from the contents of the "UNTIL" parameter. Before calling Oasis_CUntilMessage, OASIS-CC loads 'external_element', 'header_size' and 'trailer_size' with values extracted from the command_messages table. 'message_type' should be set to MGS_DELAYED. 'message_ptr' points to a buffer containing the message bit-pattern: the message header followed the command(s) and terminated by the message trailer. In the buffer 'message_size' bits have been loaded by OASIS-CC. The buffer contents can be modified by the user code that should update 'message_size' to reflect the new size of the message. The size of the buffer allocated by OASIS-CC for the message is 'max_message_size' bits. The function should return CMD_SUCCESS if successful. Note that the 'char' components of the message_descriptor structure are in uppercase. Appendix B: oasis_data_server.h /* Copyright 1986, 1992 by the Regents of the University of Colorado */ /* History : */ /* Original: developed by aj per crn 586 2/96 */ /* Purpose : */ /* Define constants and structures for data distribution by OASIS */ #ifndef __OASIS_DATA_SERVER_H__ #define __OASIS_DATA_SERVER_H__ /* client request definition */ #define OASIS_ADD_GROUP 1 #define OASIS_REMOVE_GROUP 2 #define OASIS_DISCONNECT 3 #define OASIS_VERSION_0 0 typedef struct client_request { int version; /* version number */ int request_type; /* client request */ char group_name[16]; /* requested data set name - 16 character */ } typedef struct server_data { /* for version 0 */ int hashkey; /* data tag */ int data; /* data value int or float */ } #endif /* __OASIS_DATA_SERVER_H__ */ Appendix C: CHANGE IN LATEST_DATA RECORD LAYOUT With this release, the layout of the LATEST_DATA table has been modified. A new field (ROUTE_TO_DATA_SERVER) has been added after the ROUTE_TO_BRIDGE field. ROUTE_TO_DATA_SERVER This internal OASIS-CC system flag indicates if the value is to be forwarded the the data_server subsystem. NON_KEY Protection class : SYSTEM Data type : ROUTING_CODE Default value : NEVER Appendix D: THRUPUT PERFORMANCES OASIS-CC thruput was measured under the following conditions: Computer : Sparcstation 10, 128 Mbyte, running SOLARIS 2.3 Ultra Sparc 1 , 196 Mbyte, running SOLARIS 2.5 OASIS-CC : - Release of v02.05.14(2). Compiled with run-time checks ON - Application set up to decompose 128 measurements per packet. Measurements are converted to engineering unit using the analog conversion table and are limit checked. - Protocol used is Ip - OASIS-CC verifies the sync pattern of each packet Simulator: - Packet size set to 128 bytes - Running on a remote workstation SparcStation 10/40 measured measured # measurements # measurements # measur. measured packet bit decomposed changing xfered % of cpu rate rate per second per second per second 32/s 32kbps 4096 3968 0 38% 16/s 16 kbps 2048 1984 0 16% 16/s 16 kbps 2048 1984 1904 33% UltraSparc 1/140 measured measured # measurements # measurements # measur. measured packet bit decomposed changing xfered % of cpu rate rate per second per second per second 32/s 32kbps 4096 3968 0 11% 32/s 32kbps 4096 3968 3908 20% EOS TC LOAD SIMULATION We have added to our test suite a new load test. This test is a simulation of the expected Test Conductor (TC) wokstation load during the EOS/am spacecraft I&T. TEST CONDITIONS --------------- Input ----- - 5 packetized streams - 2 16kb packets, one packet/sec each 32.0 kbp/sec (each stream has 64 different packet ids) - 5 1kb packets, one packet/sec each 5.0 kbp/sec - 1 ascii message stream at 3 messages/s (with burst of 50 messages/sec) 1.9 kbp/sec ---- 38.9 kbp/sec Processing ---------- - Number of measurements extracted 1,109/sec - Number of measurements changing (in telemetry) 113/sec - Number of equations firing 110/sec - Number of display 2 with 75 items each (refresh rate of 2 sec) - Number of measurements bridged or xfered 200/sec - Latest_Data and Limits tables 2/hour checkpointing frequency - Run directive frequency 2/hour - Switch recording file frequency 2/hour - Clear and display frequency of one of the 10/hour 75 items display - Snap frequency 10/hour - Trigger activation ~1/hour (burst of 5 commands) - Commanding rate 2 commands/sec - All events are logged - Event messages are displayed (including the messages from the ascii message stream) - Cstol procedure lines in user clp are displayed - Cstol procedure running in the user clp with $$step_interval = 0.25 - One measurement out-of-limit per second (with burst of 110 measurements going out-of-limit in the same packet for time to time) - Procedures running in 5 sub clps Sizing ------ Decomposition : 70,406 records Latest_Data : 5,226 records Equations : 600 records (600 equations coded in C) Limits : 600 records Analog_Conversions: 1,106 records Note that the test was run mainly from committed database tables. The set up procedure was "only" 1,200 lines long. Test environment ---------------- UltraSparc 1/140 with 196 Mbytes of memory, running Solaris 2.5 OASIS-CC release 14(2) and HP 712/80 with 64 Mbytes of memory, running HP_UX 9.05 OASIS-CC alpha release 14(2) TEST RESULTS ------------ Cpu usage Ultra Sparc 1 (test duration: 5 hours) With no data bridged : <9% With data bridged to file : 11% With data xfered via the data server : 9% HP 712/80 (test duration: 24 hours) With no data bridged : 24% With data bridged fo file : 36% WIth data xfered via the data server : 27%