OASIS-CC VERSION V02.05.12 RELEASE NOTES TABLE OF CONTENTS 1 Compatibility Information 2 OASIS-CC Installation Procedure 3 Upgrading V02.05.11 to V02.05.12 4 Major New Features Or Code fixes 4.1 Snap Of Undisplayed TAE+ Panels (crn 395, OSCAR 66) 4.2 Access To Previous Command Subfield Values From Cstol (crn 435, OSCAR 69) 4.3 Checkpointing Latest_Data Causes A Priority Inversion (crn 463) 4.4 Building The Decomposition Trees Outside Of OASIS-CC (crn 466) 4.5 Remote Display Of The Event Message Windows (crn 469, OSCAR 65) 4.6 Association Of Global Data With Out-Of-Limits Counters (crn 470, OSCAR 50) 4.7 Control of the "Awaiting data" messages (crn 471, OSCAR 70) 4.8 Forcing an ASCII_CHAR_x receiver to wait for sub clp (crn 472, OSCAR 71) 4.9 Handling Less Than 32 Bit Long Signed Integer (crn 474) 4.10 Lowered Receiver Priority When Retrieving Data (crn 475) 4.11 Modification To The CEV Functionality (crn 480, OSCAR 72) 4.12 Display Code Improved (crn 478 and crn 482) 4.13 Additional EU Units and Parser Table Size Increased (crn 485) 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 Clearing a panel with a selection list presentation type with a scrolling bar can cause OASIS-CC to crash (crn 252) 6.5 When an IP server stream is switched on, OASIS-CC keyboard or procedure input processing can become locked (crn 294) 6.6 Double precision floating point printout may be incorrect (crn 320) 6.7 Highlighted item on a selection list is unchoosable (crn 265) 6.8 S11W implementation not available in the SOLARIS version 6.9 CEV may fail if CEV_TIMEOUT is greater than 86400.0 seconds (crn 358) 6.10 Initialization problem with keyed binary bridge (crn 359) 6.11 Apparent memory leak in graph presentation type (crn 337) 6.12 Displayed Data Incorrect (crn 349 and crn 476) 6.13 Remote Display issues in SunOs versions 6.14 Memory leak when displaying in SunOs versions 6.15 Ask window problem (crn 486) 6.16 Equation always started when measurement is out-of-limits (crn 452) 7 Anomaly Or Enhancement Request Reporting 8 Documentation Set Status 9 Upgrades To The Spectrometer Application Appendix A: DATABASE TABLE UPDATES Appendix B: CSTOL LANGUAGE UPDATES Appendix C: USING CEV WITH SERIAL DIGITAL COMMANDS Appendix D: THRUPUT MEASUREMENTS AND LOAD SIMULATION Appendix E: DISPLAYING SYSTEM TIME Appendix F: MEMORY UTILIZATION WHILE COMPILING LARGE PROCEDURES Appendix G: SYNC PATTERN, BLOCK ID, ETC ... (REVISITED) OASIS-CC VERSION V02.05.12 RELEASE NOTES Nov 7, 1994 These release notes describe version V02.05.12 and V02.05.12.ball of OASIS-CC. A copy of these notes can be found in $ODIST/release_notes/oasis_v2.0512. A copy of the notes from previous releases can also be found in the $ODIST/release_notes directory. This release comes in 3 flavors: a SunOs 4.1.x version using TAE+ 5.2, a Sunos 4.1.x version using TAE+ 5.3 and a SOLARIS 2.3 version using TAE+ 5.3. 1 Compatibility Information ----------------------------- This release of OASIS-CC has been tested or run under the following conditions: Sparcstation IPC, LX and 2 SunOS 4.1.3 X MIT X11R4 with fixes 1 to 18 MOTIF 1.1.4 TAE+ 5.2 and 5.3 Sparcstation 2 and 10 SOLARIS 2.3 X X11R5 from SUN MOTIF 1.2 from SUN (Motif Developer's Kit) TAE+ 5.3 for SOLARIS Note that for the SunOs distribution: (1) The Ada distributions require SunAda 1.1; (2) All the distributions require the MOTIF developer's kit; (3) OASIS-CC cannot be linked with shareable libraries. For example, OASIS-CC needs the libXm.a motif library. It cannot be linked with the libXm.so motif library; Note that for the SOLARIS distribution: (1) The Ada distributions require SunAda 2.0; (2) The C distribution 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 OASIS-CC Installation Procedure ---------------------------------- SunOs Distributions ------------------- 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.12 in a new directory. Note that the SunOs distribution is quite large because $ODIST/bin contains all of the dump_database and the load_database executables since V02.05.04. This is done to allow users running an old release to convert to this release. If these utilities are not needed, the following files can be deleted from $ODIST/bin: dump_database_v020508 dump_database_v020509 dump_database_v020510 load_database_v020509 load_database_v020510 load_database_v020511 SOLARIS Distributions --------------------- 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.12 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. * * ***************************************************************************** 3 Upgrading V02.05.11 Applications to V02.05.12 ------------------------------------------------ There are changes in the OASIS-CC V02.05.12 code that makes it incompatible with applications running version V02.05.11. The changes are: (1) the parser has been upgraded (see Appendix B); (2) some database tables have changed (see Appendix A). Also this release uses a new environment variable called OASIS_DECOMP_TREE. This variable should point to the directory where OASIS-CC will find the decomposition trees saved by the new save_decomposition_tree utility (see paragraph 4.4). Sites that require the ability to maintain version V02.05.11 or earlier release applications will need new accounts for their associated V02.05.12 applications. The paragraph "Creating OASIS-CC Accounts" in the Unix OASIS-CC Installation Guide provides details on the requirements for application accounts. The OASIS-CC Application Environment Reference Manual describes how to create the appropriate application environment. The minimum set of files that users need to transfer from existing applications to the areas for developing applications with the new release are: OASIS Database files OASIS Procedure files OASIS Macro files TAE+ resource and graphics files The distribution tape contains a command procedure (v0205011to12.csh) that will make V02.05.11 application compatible with V02.05.12. To upgrade to V02.05.12, perform the following: (1) Log in the application account intended for V02.05.12 development. This account should be populated with V02.05.11 files (the minimum set is listed above). (2) Set up all the environment variables (including OASIS_DECOMP_TREE). Make sure that ODIST points to the OASIS-CC V02.05.12 distribution and that TAE points to the TAE+ distribution. (3) Execute the OASIS-CC upgrade by typing: $ODIST/bin/v0205011to12.csh (5) Re-create your application. ******************************************************************************* * NOTE: Because of a limitation to the load_database and dump_database * * utilities, the v0205011to12.csh script truncates the following fields * * to 80 characters: * * * * commands.fixed_pattern * * ascii_command_values.default_substring_value * ******************************************************************************* To update from a version prior to V02.05.11, you must first upgrade to V02.05.11. Refer to the release notes in $ODIST/release_notes. ******************************************************************************* * NOTE: If you are updating from the alpha release of v020512, you only need * * to copy the new parser table. This can be done by executing: * * cp $ODIST/common_distrib/starter/parser/* $OASIS_PARSER * * Of course, you should re-create your application. * ******************************************************************************* 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 Snap Of Undisplayed TAE+ Panels (crn 395, OSCAR 66) ------------------------------------------------------- Starting with this release, OASIS-CC provides two mechanisms to "snap" a display page. As in previous OASIS-CC releases the user can create an image of a display page in the TAE+ resource file format. This snap capability requires the display page to be displayed. In addition, the user can now create a printable approximate image of a display page. This new snap capability does not require the display page to be displayed. Because the image of the page is created in a printable format that can be output on 80-characters wide line printer, this new functionality has several restrictions: - The only objects processed are output objects. No buttons, radio buttons, panel lines, scroll bars, text lists, or edit pages, etc., are included in the ASCII file. If a panel has no output variables, an error is reported and no file is created. - A limited number of output object presentation types and of TAE+ types are recognized: "label", "dynamic text" and "text display" for the presentation types and "string", "real" and "integer" for TAE+ types. However, when TAE+ real or integer types are used, the formatting of the value is not controlled by OASIS-CC. The snap utility does not know what kind of formatting TAE does and will format the value using the display_definitions record contents (i.e., as if the TAE+ type was string). - The ASCII page size is limited to 80 columns by 80 rows at this time. An attempt is made to fit all objects onto the page. All objects that fall below or are "squeezed" further than 80 rows are truncated. The following is a list of things that make a panel a good one to snap. This list simply limits the amount of shifting around done by the placement algorithm and ensures value integrity. - uses the OASIS default pixel size - reasonably wide (max ~ 600 pixels) but larger in height (max ~ 1000 pixels) - only includes 'label' and 'dynamic' as output objects - those output objects are controlled by OASIS (i.e. all 'label' or 'dynamic' objects are of type STRING) - includes a "reasonable" number of objects in X-direction (5 - 7) - all objects are aligned to the pixel (i.e. use the Action Workbench "Align" for all items) To support the new snap functionality, the SNAP directive has been modified (see Appendix B). Both forms of the snap function create files in $OASIS_SNAP under the name of fyy_mmm_dd_hh_mn_ss.page-name.res (for the resource file version) or fyy_mmm_dd_hh_mn_ss.page-name (for the printable file version). 4.2 Access To Previous Command Subfield Values From Cstol (crn 435, OSCAR 69) ----------------------------------------------------------------------------- This release provides the capability to copy the value inserted in a command subfield into a global variable when the command is sent. This feature allows the Command Execution Verification (CEV) functionality to be used with non-discrete commands (i.e., commands with one or more subfield) as explained in Appendix C. The association between a command subfield and a global variable is defined by two new fields in the ascii_command_values table (for ascii commands) or in the command_values table (for binary commands). The first field (called LATEST_DATA_LINK) indicates if the subfield value needs to be copied back to a global variable (value is TO) or not (value is NONE). The second field (called ITEM_NAME_LINK) defines the item name of the global variable in which the subfield value is copied back. Its external_element name is the name of the external_element associated with the command. A subfield value is copied back into a global variable according to the following rules: (a) If the command is an ascii command, the character string that makes the subfield value is copied. Note that in latest_data a character string is limited to 128 characters, whereas a subfield is limited to 256 characters, so the subfield value may be truncated when it is copied. (b) If the command is a binary command and the MAPPING_FORMAT field is set to INTEGER, the integer value (converted from the long_float format used to store the subfield value) is copied. (c) If the command is a binary command and the MAPPING_FORMAT field is set to either IEEE_FLOAT or IEEE_LONG_FLOAT, the float value (converted from the long_float format used to store the subfield value) is copied, using a unit of DN. If an overflow occurs during the conversion, the value is not copied. 4.3 Checkpointing Latest_Data Causes A Priority Inversion (crn 463) ------------------------------------------------------------------- While testing under "heavy" load conditions, it was found that checkpointing latest_data was, from time to time, causing a priority inversion where the high priority receiver tasks could be blocked for an unbounded amount of time by lower priority tasks. The code has been changed to make sure that the time during which this problem occurs is bounded. A portion of duration of the priority inversion is caused by the opening of the checkpoint file. For this reason, we recommend that checkpoint files be opened locally (i.e. on the workstation running OASIS-CC) rather than remotely (on a server workstation). 4.4 Building The Decomposition Trees Outside Of OASIS-CC (crn 466) ----------------------------------------------------------------- For applications with a large decomposition table, "switching on" a stream can take a long time. Also, the decomposition table, which is only used during the "switch on", takes a large amount of memory. This release of OASIS-CC comes with a new utility called save_decomposition_tree that can be used to build and save the decomposition tree outside of OASIS-CC in a series of files. At runtime when "switching on" a stream, these files can be read by OASIS-CC, bypassing the decomposition table. This is much faster and uses less memory. The save_decomposition_tree utility reads the streams table and the decomposition table and creates in $OASIS_DECOMP_TREE one file for the primary stream (the file is called stream-name.TREE) and one file for each of the secondary streams (each file is called stream-name.secomdary-stream-name.TREE). Example output from the save_decomposition_tree utility follows: atika% save_decomposition_tree Save_Decomposition_Tree utility SOLARIS version v020512 Enter the primary stream_name tlm1 Building the decomposition tree for stream TLM1 <== THIS STEP MAY BE Processing primary stream TLM1 VERY LONG Processing secondary stream TLM1_SEC_1 Processing secondary stream TLM1_SEC_10 Processing secondary stream TLM1_SEC_11 Processing secondary stream TLM1_SEC_12 Processing secondary stream TLM1_SEC_13 Processing secondary stream TLM_SEC_14 Processing secondary stream TLM1_SEC_15 Processing secondary stream TLM1_SEC_16 Processing secondary stream TLM1_SEC_17 Processing secondary stream TLM1_SEC_18 Processing secondary stream TLM1_SEC_19 Processing secondary stream TLM1_SEC_2 Processing secondary stream TLM1_SEC_20 Processing secondary stream TLM1_SEC_21 Processing secondary stream TLM1_SEC_22 Processing secondary stream TLM1_SEC_23 Processing secondary stream TLM1_SEC_24 ..... All done... The decomposition records that describe the primary stream's decomposition tree and its secondary streams' decomposition tree can then be removed from the decomposition table. The receivers for the IP, IP_1, ASYNC_CHAR and ASYNC_CHAR_1 (and VME for 12.ball) protocols are able to start from the saved decomposition tree files rather than from the decomposition table. To force a receiver to use the saved decomposition tree files, set the secondary_offset field in the primary stream record to 0. ****************************************************************************** * NOTE: The format of the files generated by the save_decomposition_tree * * utility depends on (1) the decomposition table layout and (2) the compiler * * used to generate the OASIS-CC code. Therefore, these files may have to * * be re-generated when a new version of OASIS-CC is released. * ****************************************************************************** 4.5 Remote Display Of The Event Message Windows (crn 469, OSCAR 65) -------------------------------------------------------------------- Event message windows (i.e., windows of the page_kind of FOR_MESSAGE) can now be displayed on remote workstations or X-11 terminals. This works the same way as displaying remote TAE+ panels. This capability can be used to remotely display the execution of a procedure. This can be accomplished by displaying on the remote workstation a message window with a "+LP_U" discriminator. This works well as long as the procedure execution rate is not too fast. If the procedure executes too fast, the display of the procedure lines on the remote workstation can get behind. 4.6 Association Of Global Data With Out-Of-Limits Counters (crn 470, OSCAR 50) ------------------------------------------------------------------------------ OASIS-CC now provides the capabilty to (1) group measurements together for the purpose of counting out-of-limits occurences and (2) automatically increment or decrement a counter associated with a group of measurements when a measurement in the group goes from within limits (or not checked) to out-of-limits (green or good state to yellow or red or bad state) or from out-of-limits (yellow or red or bad state to green or good state) to within limits (or not checked) respectively. The association of a measurement with a group is done via a new field in the latest_data table called SUBSYSTEM_NAME (see Appendix A). The external element name of the counter associated with a group is taken from SUBSYSTEM_NAME. The item name is $$OUT_OF_LIMITS. The "$$" in front of the item name is here to prevent an application from resetting the counters from CSTOL (The counters can be reset from an Ada or a C equation. Of course, this should be avoided). If an application needs access to a counter from CSTOL, it should do it by copying the counter value into another global variable via an equation. It is the responsibility of the user to set up the counters in latest_data. 4.7 Control of the "Awaiting data" messages (crn 471, OSCAR 70) --------------------------------------------------------------- The frequency at which the "Awaiting data" messages are output by OASIS-CC can now be controlled on a stream basis for the following protocols: IP, IP_1, ASYNC_CHAR, ASYNC_CHAR_1, ASCII_CHAR_IP and ASCII_CHAR_RS232. This control is done via a latest_data table record defined as follows: EXTERNAL_ELEMENT => Name of the stream ITEM_NAME => AWAITING_MSG_FRE DATA_CLASS => NUMERIC DN_LOW => Requested time (in second) between two messages when no data is received. If this record is not present, the delay between messages is set to 30 seconds. If the value is set to 0, messages are never printed. 4.8 Forcing an ASCII_CHAR_x receiver to wait for sub clp (crn 472, OSCAR 71) ---------------------------------------------------------------------------- ASCII_CHAR_IP or a ASCII_CHAR_RS232 receivers are often used to route CSTOL statements from a remote node to a sub clp. If, when the receiver tries to route a new CSTOL statement, the sub clp is busy (for example executing the CSTOL statement that was previously routed) the receiver drops the CSTOL statement to go back to its data acquisition task. The CSTOL statement is then lost. This can cause problem when CSTOL statements burst. This OASIS-CC release allows the user to force the receiver to wait for a specifiable maximum amount of time for the sub clp to accept the new CSTOL statement before dropping it. This new feature is controlled by a record in the latest_data table. EXTERNAL_ELEMENT => name of the stream ITEM_NAME => ROUTE_TIME_OUT DATA_CLASS => NUMERIC DN_LOW => maximum amount of time the receiver can wait (in milliseconds). Note that under SunOs the clock resolution is about 20 milliseconds. Under Solaris it is about 30 milliseconds. If the record is not present, the value is set to 0 milliseconds. Notes: (1) The easiest way to use this new feature is not to try to find the right value for "route_time_out", but to set the value large enough to (a) allow for the longest cstol statement execution and more; and (b) recover fast enough from an hanged sub clp. (2) The assumptions are that (a) cstol statements are never burst at such a rate that the system buffer overflows with incoming statements while the receiver task waits for a sub clp; and (2) over a long period of time the rate of processing of cstol statements is greater than the production rate of cstol statements. In other words, the implementation uses the buffer provided by the system to smooth out cstol statement bursts. 4.9 Handling Less Than 32 Bit Long Signed Integer (crn 474) ----------------------------------------------------------- With this release, users can declare 8-bit or 16-bit DN numbers to be signed numbers. When this happens, OASIS-CC takes the sign of the extracted value into account when it loads the value in the latest_data table. (see Appendix A) 4.10 Lowered Receiver Priority When Retrieving Data (crn 475) ------------------------------------------------------------- Retrieving data from a file recorded by a receiver task is done by the same receiver task. In previous versions of OASIS-CC, each receiver task was assigned a high scheduling priority, regardless of the function accomplished by the task (data acquisition or data retrieval). This is normal for data acquisition as it is a realtime activity. But this can cause problems when retrieving data if the programmed interval between two reads of the raw data file (i.e., the "delta" of the "retrieve stream-name from filename every delta" statement) is too short. In that case, the part of OASIS-CC that does the data processing may not have enough time to process the data generated by a read before it is preempted by the next read. Data is then constanstly queued in OASIS-CC, waiting to be processed. After a short period of time, memory becomes exhausted and OASIS-CC terminates. To avoid this problem, in this release of OASIS-CC, when a receiver task retrieves data, its scheduling priority is lowered below the priority of the data processing code. This allows a small delta to used without risking the problem explained above. This fix applies only to the IP, IP_1, ASYNC_CHAR and ASYNC_CHAR_1 (and VME for 12.ball) protocols. 4.11 Modification To The CEV Functionality (crn 480, OSCAR 72) -------------------------------------------------------------- Two modifications affect the way Command Execution Verification (CEV) works in OASIS-CC. (a) In addition to doing CEV by comparing an expected value to a telemetred DN measurement value, CEV can now be done by comparing an expected state to a telemetred STATE. This can be useful when a STATE may correspond to several DN values. To support this new functionality, a new field has been added to the commands table (CEV_STATE). If this field is defined (i.e., is not all ascii spaces) it is used instead of the CEV_VALUE field. (b) The way CEV_MASK is used has been changed. It is used to compute the expected verification value. The formula is: expected verification value = (current telemetred value AND (NOT cev_mask)) OR cev_value where cev_value is the contents of the CEV_VALUE field, cev_mask is the contents of the CEV_MASK field and "current telemetred value" is the raw value (at the time the command is sent) of the measurement defined by the CEV_EXTERNAL_ELEMENT and CEV_ITEM_NAME fields. With this new scheme, CEV_MASK defines the bits that are affected by the command, while CEV_VALUE represents the value those bits should take. This scheme allows the system to verify that the bits that are supposed to change do change and the the bits that are not affected by the command do not change. Entering the CEV_VALUE, when it is used to represent the value that the bits defined by the CEV_MASK should take, can be tricky as the CEV_VALUE is not entered as a bit pattern but as a 32-bit integer value. In a CSTOL query statement this can be accomplished using the hexadecimal notation (i.e., cev_value = X#ffff). 4.12 Display Code Improved (crn 478 and crn 482) ------------------------------------------------ The display code has been improved in two ways. First the time to bring up a TAE+ panel has been reduced. The gain is very noticable with large panels when the display_definitions table contains a lot of records. Second, it takes fewer cpu cycles to update fields of the data type "string" and of the presentation category "text". 4.13 Additional EU Units and Parser Table Size Increased (crn 485) ------------------------------------------------------------------ The size of the parser table has been increased to accomodate additional user-defined command verbs. At several customers' request, several engineering units have been added. Following is the list of the new mnemonics and the units they are intended to stand for: DBH : db-hertz GHZ : gigahertz OZI : ounce-inch RS2 : radians per second^2 WK : Week AM2 : amp-meter^2 APC : amps per count CNT : counts CPA : counts per amp DS2 : degrees per second^2 GPC : gauss per count G2 : gauss^2 HZ2 : hertz^2 JM2 : joules per meter^2 N : newtons NMS : newton-meter-seconds NM2 : newtons per meter^2 RDS : radian seconds RPC : radians per count R2S : radians^2 per second^2 T2 : tesla^2 5 Change Requests Closed With This Release -------------------------------------------- Change Requests Number crn # Title Comment 395 Snap of undisplayed panel see above 4.1 435 Access to previous command subfield values from cstol see above 4.2 456 Extraction of telemetred subcomm_id value can be incorrect 457 oasis_equations.h file incorrect if proto functions are used 458 Memory leak while displaying a panel 460 Crn 432 not correctly implemented 461 Cev not always working when the cev measurement changes rapidly 462 Ascii bridge incorrect when Dn data value is large 463 Checkpointing latest_data forces a priority inversion see above 4.3 464 Deadlock situtation while sending commands with Cev enabled 465 Lowered receiver priority when buidling the decomposition tree 466 Building the decomposition tree outside of OASIS-CC see above 4.4 467 report.csh not working in release 11 468 Switching on a large stream results in memory size increase 469 Remote display of event message windows see above 4.5 470 Association of global data with out-of-limits counters see above 4.6 471 Control of the "awaiting data" messages see above 4.7 472 Forcing a ASCII_CHAR_x receiver to wait for sub clp see above 4.8 473 Unable to switch on/off a substream when primary is a bus stream 474 Handling less than 32 bits long signed integer see above 4.9 475 Lowered receiver priority when retrieving data see above 4.10 478 Bringing up a TAE+ panel is now much faster see above 4.12 479 Limits error message threshold value can be incorrect 480 Modification to CEV functionallity see above 4.11 481 5:00 am gremlin fixed (affected SOLARIS version only) 482 Display code improved see above 4.12 484 More memory leaks 485 Parser table size increased and Additional EU units see above 4.13 Crn 444 and 459 concerning documentation have been closed. In addition 455, 477 and 483 have been closed with no action taken. 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 Clearing a panel with a selection list presentation type with a ------------------------------------------------------------------- scrolling bar can cause OASIS-CC to crash (crn 252) -------------------------------------------------- When clearing a panel with a selection list presentation type with a scrolling bar, seven error messages ("Warning: Cannot find callback list in XtRemoveAllCallbacks") are output in the startup window. Our analysis of the problem is that it may cause OASIS-CC to crash. A workaround is to hide the panel rather than clear it. NOTE THAT THIS IS FIXED IN THE SOLARIS VERSION. 6.5 When an IP server stream is switched on, OASIS-CC keyboard or ----------------------------------------------------------------- procedure input processing can become locked (crn 294) ------------------------------------------------------ When a server stream is started using the IP protocol, the task handling the stream first waits for a client process to connect. It is only after a connection has been established with a client process that task is able to execute processing directives, such as route or record. 6.6 Double precision floating point printout may be incorrect (crn 320) ----------------------------------------------------------------------- When a local variable whose value is lower than 1.0e-99 is written or displayed the output is incorrect. For example 1.0e-100 appears as 1.0e-90, 1.0e-101 appears as 1.0e-91. This problem has been traced to a compiler problem and can be reproduced outside the OASIS-CC code. While the printed value is incorrect, the internal representation of the value seems to be correct. THIS PROBLEM OCCURS ONLY IN THE SUNOS VERSION. 6.7 Highlighted item on a selection list is unchoosable (crn 265) ----------------------------------------------------------------- When a selection list panel comes up with an highlighted item, the item cannot be directly selected. NOTE THAT THIS IS FIXED IN THE SOLARIS VERSION. 6.8 S11W implementation not available in the SOLARIS version ------------------------------------------------------------ Because of driver problems the s11w code is not functional in the SOLARIS version. 6.9 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.10 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.11 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.12 Displayed Data Incorrect (crn 349 and crn 476) ---------------------------------------------------- If the same measurement is displayed more than one time on the same TAE+ panel or on different TAE+ panels, but under a different unit (such as v and mv), the displayed values are incorrect. 6.13 Remote Display issues in SunOs versions -------------------------------------------- If, after you have displayed one or more panels on a remote X-11 terminal, the X-11 server is killed on the remote terminal OASIS-CC crashes even if all the TAE+ panels have been cleared from the remote X-11 terminal before the X-11 server is killed. This is not an OASIS-CC problem. 6.14 Memory leak when displaying in SunOs versions -------------------------------------------------- There is a memory leak in the SunOs versions, when a "display" CSTOL statement is executed. This leak has been estimated to be about 1280 bytes. However tests seem to indicate that it may be larger. The leak is in the Xm 1.1.4 motif library and affects only the SunOs versions. 6.15 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.16 Equation always started when measurement is out-of-limits (crn 452) ------------------------------------------------------------------------ If a measurement that "triggers" an equation is out-of-limits, the equation is started even when the measurement value is not changing. A similar problem exists with "print-on-change" for a measurement that is out-of-limits. Every measurement value is printed, even it does not change. 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 ---------------------------- New versions of the following OASIS-CC documents are delivered with v020512: OASIS-CC System Manager's Guide - November 1994 OASIS-CC Cstol Reference Manual - November 1994 OASIS-CC Database Guide - November 1994 OASIS-CC Application Environment Reference Manual - November 1994 OASIS-CC Generic Communications Guide - November 1994 OASIS-CC Quick Reference Manual - November 1994 OASIS-CC Installation Guide - November 1994 In each of these documents, a revision number and the month/year of printing are included in the page headers. A revision history is provided with each of the documents (except the Installation Guide). The history details which release a given chapter is consistent with and for which release it was last updated, along with brief notes summarizing the changes. Revision 0 has been given to the chapters that required no updates for V020511 and V020512. Each chapter that includes new information (for V020511 or V020512) is revision 1. The following documents are those remaining in the OASIS-CC - related suite provided by LASP that required no updates. Action Workbench User's Guide - June 1993 Graph Presentation Type Supplement - Presentation Types Reference Manual - TAE+ Version 5.2 - March 1993 Graph Presentation Type Supplement - User Interface Developer's Guide - TAE+ Version 5.2 - March 1993 Spectrometer Data Generator Reference Manual - March 1993 9 Upgrades To The Spectrometer Application -------------------------------------------- The spectrometer application has two new features: high level language equations, and a demonstration of the transfer of command subfields into the Latest_Data table. Two new fields to the Command_Values database table allow a link to an item in Latest_Data. LATEST_DATA_LINK and ITEM_NAME_LINK specify an item whose external_element is identical to the Command_Values external_- element in Latest_Data. Regardless of whether the command issues, with or without success, the Latest_Data item stores the command subfield, providing a record of the requested value. Currently, there are three options for LATEST_DATA_LINK: to, from, and none. Of the three, 'from' is not implemented. This field indicates the direction of transfer for the command subfield. ITEM_NAME_LINK is simply the item_name of the Latest_Data item. For the spectrometer application, a new Latest_Data item called TELEMETRY TARGET_SPEED reflects the command subfield "to" for the "set telemetry rate" command. To demonstrate the use of higher level language equations, a C equation called "check_speed."" performs the comparison of TELEMETRY TARGET_SPEED to the telemetered TELEMETRY SPEED. Also provided in the documentation is the equivalent Ada equation. If the TELEMETRY TARGET_SPEED is equal to the TELEMETRY SPEED, the equation sets the state of the Latest_Data item TLM_SPEED VERIFY to "TRUE." As a means of demonstrating a practical use of the new feature, the application implements Command Execution Verification on TLM_SPEED VERIFY to confirm the change in the telemetered item. Additionally, once TLM_SPEED VERIFY changes to "TRUE," another C equation, "reset_speed_chk.c," resets the value to "FALSE" to ensure that CEV waits for new comparisons. Appendix A: DATABASE TABLE UPDATES The following database tables have been modified: ASCII_COMMAND_VALUES COMMAND_VALUES COMMANDS DECOMPOSITION LATEST_DATA ********************* ASCII_COMMAND_VALUES Two new fields have been added betwen MIN_VALUE and DESCRIPTION. LATEST_DATA_LINK This field indicates if the subfield value is to be copied back to a global data (TO) or is to be taken from a global data (FROM) or has no link with a global data (NONE). Note that FROM is currently not implemented. NON KEY Protection class : DB_MANAGER Data type : LINK_TO_LATEST_DATA Default value : NONE ITEM_NAME_LINK If LATEST_DATA_LINK is not NONE, then this field gives the item_name of the global variable attached to the subfield (the external_element name is the external_element of the command). NON KEY Protection class : DB_MANAGER Data type : NAME_TYPE Default value : ********************* COMMAND_VALUES Two new fields have been added between IS_DISCRETE and DESCRIPTION. LATEST_DATA_LINK This field indicates if the subfield value is to be copied back to a global data (TO) or is to be taken from a global data (FROM) or has no link with a global data (NONE). Note that FROM is currently not implemented. NON KEY Protection class : DB_MANAGER Data type : LINK_TO_LATEST_DATA Default value : NONE ITEM_NAME_LINK If LATEST_DATA_LINK is not NONE, then this field gives the item_name of the global variable attached to the subfield (the external_element name is the external_element of the command). NON KEY Protection class : DB_MANAGER Data type : NAME_TYPE Default value : ********************* COMMANDS A new field has been added between CEV_MASK and CEV_TIMEOUT. CEV_STATE The state value the measurement named by CEV_EXTERNAL_ELEMENT and CEV_ITEM_NAME should have after the command has executed. This value is taken into account if it is not all ascii space. NON KEY Protection class : DB_MANAGER Data type : NAME_TYPE Default value : ********************* DECOMPOSITION A new field has been added between EU_UNITS and FLOATING_POINT_KIND. DN_KIND Indicates if the dn value is to be treated as unsigned (UNSIGNED) or signed value. If the value is signed it also indicates the negative format used (TWO_COMPLEMENT or ONE_COMPLEMENT). Note that ONE_COMPLEMENT is not currently supported. NON KEY Protection class : DB_MANAGER Data type : DN_TYPE Default value : UNSIGNED ********************* LATEST_DATA A new field has been added between ROUTE_TO_BRIDGE and EU_UNITS. SUBSYSTEM_NAME Indicates the name of the subsystem with which the measurement is associated for the purpose of counting out-of-limits alarms. NON KEY Protection class : PROTECTED Data type : NAME_TYPE Default value : Appendix B: CSTOL LANGUAGE UPDATES The SNAP directive has been upgraded. SNAP SNAP saves the current contents of the named display page Format SNAP page-name SNAP page-name RESOURCE Arguments page-name (identifier): The display page to snap Notes SNAP page-name creates a printable approximate image of the page. This form of the SNAP directive works on displayed or non-displayed pages. It creates a file named Fyy_mmm_dd_hh_mn_ss.page-name in the $OASIS_SNAP directory. SNAP page-name RESOURCE creates a files in TAE+ resource format. The Action Workbench (AWB) can be used to display the page offline. This form of the SNAP directive works only if the page is displayed. It creates a file named Fyy_mmm_dd_mn_ss.page-name.res in the $OASIS_SNAP directory. SNAP page-name RESOURCE corresponds to the SNAP page-name in the previous OASIS-CC releases. Appendix C: USING CEV WITH SERIAL DIGITAL COMMANDS As described in paragraph 4.2, applications can now store the values used in command subfields in the latest_data table. This new capability can be used to do command execution verification (CEV) of serial digital commands. The spectrometer application has an example of CEV done with a serial digital command. This note describes the principles behind CEV of serial digital commands and its limitations. 1 - CEV with serial digital commands Doing CEV with serial digital commands involve several steps: a - You need to define a pseudo measurement that will be used to verify the command. For example this pseudo measurement can take two values: TRUE (which implies that the command has verified) or FALSE (which implies that the command has not verified). The initial value of the pseudo variable needs to be FALSE. b - You need to define a high-level language equation that is started by the pseudo measurement. What this equation does is reset the value of the pseudo measurement to FALSE after the pseudo measurement has gone from FALSE to TRUE. c - You need to define a high-level language equation that is started by one or more measurements in the telemetry. What this equation does is compare these telemetred measurements with the copy of the command subfield values. When the equation algorithm finds that the command has verified, it sets the pseudo measurement to TRUE. This forces the CEV software to declare that the command has verified. It also starts the equation defined in b above, that resets the pseudo measurement to FALSE. 2 - Limitations There are at least two limitations. a - Unexpected Event Detection (UED) cannot be used, as the speudo measurement changes value (from TRUE to FALSE) after the command has been verified. b - The method described above assumes that the second equation (the one started by the telemetry) is run. This will not happens if the triggering measurements values are not changing, for example when the spacecraft is already in the commanded state. This can be avoided by associating the command with a pre-check procedure that changes another pseudo measurement value and starting the second equation on this pseudo measurement changes, as well as on changes of the telemetred measurements referred to in c above. This method of verifying command is the result of numerous electronic mail exchanges between LASP and Stephen Walters at the Santa Barbara Research Center (SBRC). Appendix D: THRUPUT MEASUREMENTS AND LOAD SIMULATION THRUPUT MEASUREMENTS OASIS-CC thruput was measured under the following conditions: Computer : Sparcstation 10, 128 Mbyte of main memory OS : SOLARIS 2.3 OASIS-CC : - Release of v02.05.12. 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 In the measured % of cpu, three numbers are given. The first one is computed using the ps command. The second and the third one are the %cpu for user and idle as reported by the vmstat command. measured measured # measurements # measurements Limits measured packet bit decomposed changing status % of cpu rate rate per second per second 16/s 16kbps 0 n/a n/a 1 << 16/s 16kbps 2048 0 n/a 1 << 16/s 16kbps 2048 1984 off 16,16,82 16/s 16kbps 2048 1984 on 16,17,82 24/s 24kbps 0 n/a n/a 1 << 24/s 24kbps 3072 0 n/a 5, 5,94 24/s 24kbps 3072 240 on 5, 6,93 24/s 24kbps 3072 480 on 10,10,88 24/s 24kbps 3072 1200 on 25,24,74 24/s 24kbps 3072 2400 on 30,31,68 32/s 32kbps 0 n/a n/a 1 << 32/s 32kbps 4096 0 n/a 14,13,85 32/s 32kbps 4096 320 on 14,14,85 32/s 32kbps 4096 640 on 15,16,82 32/s 32kbps 4096 1600 on 32,34,64 32/s 32kbps 4096 3200 on 45,47,47 For all measurement, the primary stream was set up with a frame_length of 4096 and a time_out of 0.05 Computer : Sparcstation 2, 32 Mbyte of main memory OS : SunOs 4.1.3 OASIS-CC : - Release of v02.05.12. 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 In the measured % of cpu, three numbers are given. The first one is computed using the ps command. The second and the third one are the %cpu for user and idle as reported by the vmstat command. measured measured # measurements # measurements Limits measured packet bit decomposed changing status % of cpu rate rate per second per second 16/s 16kbps 0 n/a n/a 1 << 16/s 16kbps 2048 0 n/a 21,20,77 16/s 16kbps 2048 1984 off 45,45,54 16/s 16kbps 2048 1984 on 53,53,45 24/s 24kbps 0 n/a n/a 1 << 24/s 24kbps 3072 0 n/a 30,30,68 24/s 24kbps 3072 240 on 34,35,64 24/s 24kbps 3072 480 on 39,39,60 24/s 24kbps 3072 1200 on 50,50,49 32/s 32kbps 0 n/a n/a 1 << 32/s 32kbps 4096 0 n/a 42,41,58 32/s 32kbps 4096 320 on 45,45,54 32/s 32kbps 4096 640 on 50,50,48 For all measurement, the primary stream was set up with a frame_length of 4096 and a time_out of 0.05. 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 200 - 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 ---------------- SparcStation 10 with 128 Mbytes of memory, running Solaris 2.3 OASIS-CC release 12: TEST RESULTS ------------ Cpu usage The total %cpu used by OASIS-CC and the X11 server was constant during an uninterrupted 3 days test at 38-40%. Memory usage OASIS-CC showed an average process size increase of about 225 Kbytes/day. Appendix E: DISPLAYING SYSTEM TIME OASIS-CC cannot directly display the system time. However this can be done indirectly by starting a C equation that accesses the system time, formats it and loads the formatted string into a global variable. The following code has been implemented as part of the Bench Checkout Unit (BCU) of the MOPITT instrument. It is reprinted by permission of SED Systems and COM DEV Atlantic. It was authored by Curtis Osiowy and Siu Chan of SED Systems. The BCU application runs a CSTOL procedure in a sub clp, that changes a global variable value every second. In turn, this variable starts a C equation that updates another global variable with the formatted system time. This last variable value can then be displayed. ;//U tdsp_set_time CSTOL procedure ;//U proc tdsp_set_time let $$log_input = no goto CALL ; ************************************************************************* ; * ; * PROJECT: Bench Checkout Unit ; * DEVELOPER: SED SYSTEMS INC., SASKATOON, CANADA ; * PACKAGE NAME: TDSP ; * UNIT NAME: tdsp_set_time ; * FILENAME: tdsp_set_time.prc ; * VERSION: 1.1 ; * DATE: 7/17/94 ; * ; ************************************************************************* ; * ; * REVISION HISTORY ; * ---------------- ; * ; * REV. DATE PROGRAMMER DESCRIPTION ; * ; * 1.1 17/07/94 CJO Initial Release. ; * ; ************************************************************************* ;//* ;//P a. Purpose ;//P ;//P The purpose will be to update the TAE+ time display on the master ;//P panel every second. This procedure will be run in the background ;//P on a sub-clp. ;//P ;//I b. Unit Parameters ;//I ;//I None. ;//I ;//S c. Shared Data Accessed ;//S ;//S None. ;//S ;//* d. Design Description ;//* CALL: ;//* UNIT tdsp_set_time ;//* LOOP let mop tdsp_tae_time = 0.0 dn wait ::1.0 let mop tdsp_tae_time = 1.0 dn END LOOP ;//* ;//* RETURN ;//* end proc /************************************************************************** * * PROJECT: Bench Checkout Unit * DEVELOPER: SED SYSTEMS INC., SASKATOON, CANADA * PACKAGE NAME: TDSP * UNIT NAME: tdsp_new_time * FILENAME: tdsp_new_time.c * VERSION: 1.1 * DATE: 7/18/94 * ************************************************************************** * * REVISION HISTORY * ---------------- * * REV. DATE PROGRAMMER DESCRIPTION * * 1.1 17/07/94 SHC Initial Release. * **************************************************************************/ #include #include #include #include #define MOP_TDSP_DATE_TIME 650604180 #define TMLG_C_MSG 1374071855 /*U tdsp_new_time /*/ void tdsp_new_time(lock_id, equation_result) db_lock lock_id; result_list equation_result; { /*P a. Purpose /*P /*P This procedure gets the system time and format it into a string and /*P update the corresponding OASIS latest data record. /*/ /*I b. Unit Parameters /*I /*I NAME TYPE USE DESCRIPTION /*I /*I lock_id db_lock in ID used by OASIS for the /*I access of latest_data table. /*I equation_result result_list out List of the global data that /*I need to be updated in the /*I latest_data table. /*/ /*S c. Shared Data Accessed /*S /*S NAME ACCESS TYPE /*S /*S MOP_TDSP DATE_TIME write /*S TMLG C_MSG write /*/ /** d. Design Description /** /** UNIT tdsp_new_time /*/ time_t tloc; /* time in seconds since Jan 1, 1970 */ time_t status; /* function call return status */ char *str_ptr1, *str_ptr2; /* pointer to character string */ /** Get system time [time] /*/ status = time(&tloc); /** IF call return success /*/ if ( status != -1 ) /** THEN /*/ { /* call successful */ /** Get the time in string format and strip the new line character at the /** end of the string. [ctime][strtok] /*/ str_ptr1 = ctime(&tloc); str_ptr2 = strtok(str_ptr1, "\n"); /** Update the OASIS latest data record with the new time string. /** [Oasis_CSetString] /*/ Oasis_CSetString(str_ptr2, MOP_TDSP_DATE_TIME, equation_result); } /* call successful */ /** ELSE /*/ else { /* call failed */ /** Write an error message to OASIS latest data record tmlg c_msg. /** [Oasis_CSetString] /*/ Oasis_CSetString("Cannot get system time.", TMLG_C_MSG, equation_result); } /* call failed */ /** END IF /*/ } Appendix F: MEMORY UTILIZATION WHILE COMPILING LARGE PROCEDURES A frequently asked question is : "what is the impact of compiling a large procedure on OASIS-CC?". The answer depends on if the procedure is a "one shot" procedure (i.e., a procedure which is used only once during an OASIS-CC session) or if the procedure is a permanent procedure (i.e., a procedure that can potentially be used many times during an OASIS-CC session and is constantly running). A good example of the former is a setup procedures used to update or load an application database. An example of the latter would be a procedure that sequences activities. 1 - One shot procedure Large "one shot" procedure should be avoided at all costs. From the overall OASIS-CC performances point of view, it is a lot better to execute the sequence start small_proc1 decompile small_proc1 start small_proc2 decompile small_proc3 start small_proc4 decompile small_proc4 start small_proc5 decompile small_proc5 start small_proc6 decompile small_proc6 start small_proc7 decompile small_proc7 start small_proc8 decompile small_proc8 than to execute start large_proc ; where large_proc is functionnaly decompile large_proc ; equivalent to the sequential execution of ; of small_proc1 to small_proc8 The first method uses far less memory, as a great part of the memory freed by the decompile statement can be reused by another procedure. Because the first method allocates and deallocates less memory, the possibility of memory fragmentation (which slows down OASIS-CC and/or forces OASIS-CC to use more virtual memory) is reduced. Note that tests have shown that this release of OASIS-CC is less likely to have its thruput diminished after the decompilation of a large procedure than previous releases. The first method is also faster than the second method, as it reuses memory already allocated by OASIS-CC. In any case, when an application is operational, it should start from committed database tables. Then set up procedures should only be used to update the database tables. Following is a quantative description of the difference between a large procedure and several small procedures. This test was conducted with a 57,000 lines procedure used to load the decomposition table of an OASIS-CC application. The procedure was then decomposed in 18 smaller procedures. The test compares: (1) the compilation time of the large procedure vs the compilation/decompilation time of all 18 procedures; and (2) the size of the OASIS-CC executable after the large procedure compilation vs its size after the compilation/decompilation of all 18 procedures. The test was conducted on a 128 Mbytes Sparc 10/30 workstation. The starting process size was 21.5 Mbytes. Large procedure vs 18 small procedures Compilation time 102 s 86 s Process size 56.2 Mbytes 22.8 Mbytes 2 - Permanent procedure It does not really matter if this type of procedure is large or small. The memory that the procedure object code uses is frozen as long as the procedure is compiled and therefore cannot be the cause of any memory fragmentation. Appendix G: SYNC PATTERN, BLOCK ID, ETC ... (REVISITED) Bit patterns are used to specify the following fields in the four database tables: Table name Field name COMMANDS FIXED_PATTERN CEV_MASK COMMAND_MESSAGES HEADER_PATTERN TRAILER_PATTERN DECOMPOSITION BLOCK_ID_VALUE STREAMS ID_VALUE SYNC_PATTERN 1 - SPECIFYING A BIT PATTERN FIELD VALUE ---------------------------------------- In general, these fields are expressed using a hexadecimal representation. The first hexadecimal character represents the most significant four bits of the first byte of the pattern, the second hexadecimal represents the least significant four bits of the first byte of the pattern, and so on. Examples: Let's assume that a stream has a 8-bit ID_VALUE on a byte boundary whose pattern reads 11110111, then F7 is entered in the database. Let's assume that a stream has a 7-bit ID_VALUE starting on a byte boundary whose pattern reads 1111011, then F6 (i.e, 11110110) should be entered in the database. 2 - EXCEPTIONS TO THE RULE -------------------------- 2 - 1 BLOCK_ID_VALUE AND CEV_VALUE ---------------------------------- For the field BLOCK_ID_VALUE and the CEV_VALUE there is one additional rule - The field has to be entered as if the trailing part of a 32 bit wide field. For example, the BLOCK_ID_VALUE 1 is expressed as "00000001" instead of "1", F1 as "000000F1" instead of "F1" and B8F1 as "0000B8F1" instead of "B8F1". 2 - 2 SYNC_PATTERN ------------------ As far as the SYNC_PATTERN field is concerned, the IP and ASYNC_CHAR protocols also expect that in each byte the bits to be also reversed. The IP_1 and ASYNC_CHAR_1 protocols do not. For example for the SYNC_PATTERN field, "FAF320" is expressed as "5FCF04" if the protocol is IP or ASYNC_CHAR.