SLAC Controls Software -- bug: Chapter 2

Go to bottom of page

2.1 BASIC ARCHITECTURE . . . . . . . . . . . . . . . . 2-1

2.2 HARDWARE CONFIGURATIONS . . . . . . . . . . . . . 2-3

2.2.1 SCP_TERM . . . . . . . . . . . . . . . . . . . . 2-4

2.2.2 SCP_DISP . . . . . . . . . . . . . . . . . . . . 2-4

2.2.3 SCP_IO . . . . . . . . . . . . . . . . . . . . . 2-4

2.3 TERMINAL USAGE . . . . . . . . . . . . . . . . . . 2-5

2.3.1 COWRITE . . . . . . . . . . . . . . . . . . . . 2-5

2.3.2 DLOG Utilities . . . . . . . . . . . . . . . . . 2-6

2.3.2.1 Summary Of New DLOG Utilities . . . . . . . . 2-7

2.3.2.2 DLOG Examples . . . . . . . . . . . . . . . . 2-9

2.3.2.3 DLOG Utility Arguments . . . . . . . . . . . 2-13

2.3.2.3.1 `prompt' Argument . . . . . . . . . . . . 2-13

2.3.2.3.2 `type' Argument: . . . . . . . . . . . . . 2-14

2.3.2.3.3 `size' Argument . . . . . . . . . . . . . 2-15

2.3.2.3.4 `value' Argument . . . . . . . . . . . . . 2-16

2.3.2.3.5 `default' Argument . . . . . . . . . . . . 2-17

2.3.2.3.6 `current' Argument . . . . . . . . . . . . 2-17

2.3.2.3.7 `min'/`max' Arguments . . . . . . . . . . 2-18

2.3.2.3.8 `query_default'/`query_value' Arguments . 2-19

2.3.2.3.9 `item' Argument . . . . . . . . . . . . . 2-19

2.3.2.3.10 General Note . . . . . . . . . . . . . . . 2-20

2.3.2.4 The Parse Buffer . . . . . . . . . . . . . . 2-20

2.4 LOGICAL NAME ROUTINES . . . . . . . . . . . . . 2-21

2.4.1 LIST_VAR4 . . . . . . . . . . . . . . . . . . 2-22

2.4.2 LIST_VAR8 . . . . . . . . . . . . . . . . . . 2-22

2.4.3 LIST_DISP . . . . . . . . . . . . . . . . . . 2-22

2.4.4 LIST_CALL . . . . . . . . . . . . . . . . . . 2-23

2.4.5 LIST_GROUP . . . . . . . . . . . . . . . . . . 2-23

2.4.6 GROUP_SCHED . . . . . . . . . . . . . . . . . 2-23

2.4.7 Service Routines . . . . . . . . . . . . . . . 2-24

2.4.7.1 LIST_PUT . . . . . . . . . . . . . . . . . . 2-24

2.4.7.2 LIST_GET . . . . . . . . . . . . . . . . . . 2-25 CHAPTER 2 APPLICATIONS STRUCTURES

2.1 BASIC ARCHITECTURE General applications are coded in the SLC Control Program (SCP). In this scheme, there are as many copies of SCP executing as there are active control consoles. The standard console (COW) is a standardized set of hardware and software including touch panel and display screens. SCP will also execute using a small COW (ie a CALF) which is physically a standard terminal: see the section on Cursor Addressed Limited Facility. The functions performed by PARANOIA, FEEDBACK, and DBEX are handled by unique processes and shared by the various SCP's. The SCP thus handles only one user, and there is no requirement that all SCP's be identical. The single user software is conceptually and actually much simpler than a multi-user version would be, and development is made possible by the co-existence of several versions of SCP. It must be noted, of course, that there is only one SLC, and so care must be taken in controlling hardware. Essentially all Facilities and applications code is structured into two classes of subroutines referred to as 'actions' and 'displays'. A 'display' is a subroutine which generates information to be conveyed to an operator by a COW. Usually these routines generate graphics

APPLICATIONS STRUCTURES Page 2-2 displays using the UNIFIED GRAPHICS package; they may also generate certain line printer and terminal displays. 'Displays' are always called by the Display Executive subroutine DEXEC. They are made known to the SCP during initialization by a call to a Logical Name routine. An 'action' is a routine which may exercise an actual control function or gather and process data either for a display or the database. A suitable collection of actions constitutes a GROUP. One member of the GROUP is usually a driver for the other actions, and is identified to the SCP by a call to a Logical Name routine. The distinguishing feature of a GROUP is that it may be scheduled for execution in various periodic modes. After any GROUP is executed the SCP will call DEXEC to generate any requested displays. The GROUP structure allows various functions to be executed periodically; e.g. the BPMO display may be regenerated regularly by scheduling the GROUP which acquires data from the SLC. Then DEXEC can call the actual BPMO display, and the system will translate the graphics buffers and transmit them to the COW. Communication between the application code and the Panel Description Code is facilitated by the SCP Logical Name routines. (These services are completely independent from the VMS LOGICAL NAME services). These routines allow data to be moved from the panel, and allow the panel to manipulate groups and subroutines that have been identified to the Logical Name service. This structure is deliberately limited; the Panel Description is NOT a programming language. It is believed that the set of constructs defined here constitute a base that is broad enough to comfortably support the SCP, and limited enough to ensure a unified structure that is understandable and debuggable by the

APPLICATIONS STRUCTURES Page 2-3 enlightened user. The Host software for each Facility is pre-linked into a module (a VMS shareable image) which may then be linked with other such modules into a version of the SCP. Each Facility module contains an initialization routine, a GROUP driver if appropriate, and all 'display' and 'action' routines for that Facility. These modules are then declared to the VMS operating system by means of the VMS Install utility, so that the code and fixed data sections may be shared by all active consoles. The sharing of code significantly reduces the load on the Host machine when multiple consoles are active. The pre-linking of each Facility into a module makes minor revisions transparent to the user and major revisions uniform across the system.

2.2 HARDWARE CONFIGURATIONS The SCP may be run on a variety of hardware configurations. It consists of a terminal, a touch panel device, a display device, an input/output device, and a messages device. These logical devices may share physical devices and have graphics or color capability. The basic configuration is an ASCII terminal running the program with the display and touch panel interface handled by a micro on SLCNET, this is known as a COW. The basic CALF has only one physical device, which may or may not support graphics, and may be an Ann Arbor, VT100, or any device with VT100 emulation. It is typically monochrome. The SCP may also run on an Amiga running a special emulator. This provides both graphics and color capability. Finally, any XWindows device supprts the SCP.

APPLICATIONS STRUCTURES Page 2-4 All this makes various combinations of devices available for the program. The use of the utility routines provided will simplify the interface. However, there are also routines that will return the characteristics of each of the logical devices. Most of them return the information as a bitmapped longword which can be decoded with the parameters in SCP_DEVICES_PARM.

2.2.1 SCP_TERM TYPE = SCP_TERM() Returns the characteristics of the terminal device.

2.2.2 SCP_DISP TYPE = SCP_DISP() or TYPE = SCP_DISP(N) Returns the characteristics of the currently selected display device, or for the indicated display device.

2.2.3 SCP_IO TYPE = SCP_IO

APPLICATIONS STRUCTURES Page 2-5 Returns the characteristics of the input/output device.

2.3 TERMINAL USAGE A natural consequence of the SCP design is that the SCP will execute interactively on a terminal (as opposed to batch). This terminal will be used to receive messages from the SCP and other processes, and to conduct dialogs that are unsuited for touch panel communication. (The word terminal is used loosely here. It is planned that the COW will echo terminal messages on the bottom of the touch panel screen. Also, auxilliary keyboards may be attached in close proximity to the touch panel). Several utility routines are provided for communication between the SCP and the terminal. These routines recognize whether the SCP is running on a COW or a CALF and format output to the terminal appropriately.

2.3.1 COWRITE CALL COWRITE(BRDCST,MESSAGE,COLOR,DEST_SCPID) is used to write the character variable MESSAGE. If the I*4 flag BRDCST=0, then MESSAGE will appear on ALL terminals that are running a SCP. If BRDCST=1, MESSAGE will be written only on the terminal which is running the SCP. If BRDCST=2, the message will be sent only to the SCP specified in the optional DEST_SCPID argument. COLOR is an optional 8-byte character argument which may be set to any of the standard Unified Graphics colors. Translation to an appropriate

APPLICATIONS STRUCTURES Page 2-6 graphics rendition will be made for display on the Ann Arbor. There is also a function called cowrite_c() that is better suited to being called from C. See ref_iobsic:cowrite_c.c for details.

2.3.2 DLOG Utilities The DLOG utilities are general-purpose utilities that allow the user to be prompted for data of a particular type. The file ref_c_inc:dlog.h supports use of the DLOG utilities. (The DLOG utilities all start with the prefix DLOG_). These DLOG utilities have the following features: o User input is automatically converted to the caller-specified numeric or text format. o Three text formats are supported: blank-padded, null-terminated, and descriptor. o A default value can be specified by the caller in most cases, which is the value returned if the user enters . o A current value can be specified by the caller in most cases, that is formatted into the prompt string. o Automatic reprompting if user enters an invalid value.

APPLICATIONS STRUCTURES Page 2-7 o The caller can specify a small set of choices from which the user must choose. o C and FORTRAN interfaces. dialog*() and query*() are still supported but are implemented using the new DLOG utilities. Using dialog*() or query*() in new code is discouraged. If you would have ...and your code is in ...else if your code called... in C, now you should is in FORTRAN, now call... you should call... ----------------- ----------------------- --------------------- dialog() or DLOG_text() DLOG_text_for() dialog_blink() query() or DLOG_query() DLOG_query_for() query_blink()

2.3.2.1 Summary Of New DLOG Utilities - To prompt for... ...from C, call: ...from FORTRAN, call: -------------------------- ----------------- ---------------------- a value of a certain type DLOG_text() DLOG_text_for() a yes/no question DLOG_query() DLOG_query_for() a value of a certain type, DLOG_range() DLOG_range_for()

APPLICATIONS STRUCTURES Page 2-8 within certain limits a value of a certain type, DLOG_list() DLOG_list_for() that must be one of several supplied choices a value of a certain type, DLOG_password() DLOG_password_for() where the typing is hidden and button-macro recording is suppressed Only a few examples are shown below. Rather than including a long list of examples here, many more examples of DLOG utility calls are located in ref_iobsic:dlog_examples.c (C calls) and ref_iobsic:dlog_examples_for.for (FORTRAN calls). These examples can be actually be executed by going to the DLOG Examples Panel, located off of the Development panel. All the new DLOG utilities, as well as the old dialog*() and query*() utilities, blink the last button pushed, if there was a last button pushed (some standalones prompt the user and don't have panel buttons). (There are no longer any _blink() functions for this purpose; dialog_blink() and query_blink() are still supported, but their use is discouraged). The DLOG utilities return a successful status if and only if a valid user input was written to the value argument.

APPLICATIONS STRUCTURES Page 2-9 The DLOG utilities return an unsuccessful status if and only if a valid user input was not written to the value argument. This could mean an internal failure in the utility, or a control-c by the user. (However, if the user control-c's, the DLOG utility will return the bad status OP_ABORT).

2.3.2.2 DLOG Examples - These are only a few examples of DLOG calls from C. Many more examples of DLOG utility calls are located in ref_iobsic:dlog_examples.c (C calls) and ref_iobsic:dlog_examples_for.for (FORTRAN calls). This is an example of prompting the user to answer a YES/NO question, with a default of NO. BOOL query_value_e ; status = DLOG_query ( "Do you REALLY want to do this?" , DLOG_QUERY_NO , /* default value (optional; */ /* if NULL , defaults to NO */ &query_value_e ) ; /* user input */ if ( OP_ABORT == status ) strcpy ( buffer_c , "User hit control-c." ); else if ( !SUCCESS(status) ) strcpy ( buffer_c , "Failure in DLOG function."); else if ( TRUE_T == query_value_e )

APPLICATIONS STRUCTURES Page 2-10 strcpy ( buffer_c , "User entered value was: YES" ) ; else strcpy ( buffer_c , "User entered value was: NO" ) ; cowrite_c ( CWR_LOCAL , buffer_c , NULL , NULL ) ; This is an example of prompting the user to enter a comment. Note that the type argument ends in _LINE, which assures that all of what the user types in will be returned in value_c. charu * deflt_c = "Because I felt like it!" ; charu * current_c = "Just because!" ; charu value_c[40]; status = DLOG_text ( "Who are you and why are you doing this?", DLOG_TYPE_N_LINE , /* type */ sizeof( value_c ) , /* size of 'value_c' */ deflt_c , /* default value (optional) */ current_c , /* current value (optional) */ value_c ); /* user input. */ if ( OP_ABORT == status ) strcpy ( buffer_c , "User hit control-c." ); else if ( !SUCCESS(status )) strcpy ( buffer_c , "Failure in DLOG function."); else strcpy ( buffer_c , "User entered value was: " ) , sprintf ( &buffer_c[ strlen ( buffer_c ) ] , "%s" , value_c );

APPLICATIONS STRUCTURES Page 2-11 cowrite_c ( CWR_LOCAL , buffer_c , NULL , NULL ) ; This is an example of prompting the user to enter a floating-point number. float deflt = 3.14 ; float current = 2.71 ; float value ; status = DLOG_text ( "Enter new voltage:" , DLOG_TYPE_R , /* type */ sizeof( value ) , /* size */ &deflt , /* default value (optional) */ ¤t , /* current value (optional) */ &value ) ; /* user input. */ if ( OP_ABORT == status ) strcpy ( buffer_c , "User hit control-c." ); else if ( !SUCCESS(status )) strcpy ( buffer_c , "Failure in DLOG function."); else strcpy ( buffer_c , "User entered value was: " ) , sprintf ( &buffer_c[ strlen ( buffer_c ) ] , "%5f" , value ) ; cowrite_c ( CWR_LOCAL , buffer_c , NULL , NULL ) ;

APPLICATIONS STRUCTURES Page 2-12 This is an example of prompting the user to choose one of four possible choices. charu * deflt_c = "OFF" ; charu * current_c = "ON" ; charu * item_ac[] = { "OFF" , "SAMPLE" , "COMPUTE" , "ON" } ; int4 c_item ; charu value_c[9] ; c_item = sizeof( item_ac ) / sizeof( item_ac[0] ) ; status = DLOG_list ( "Please choose a new state:" , DLOG_TYPE_N , /* type */ sizeof( value_c ) , /* size */ deflt_c , /* default value (optional) */ current_c , /* current value (optional) */ c_item , /* number of choices */ item_ac , /* array of choices */ value_c ); /* user input. */ if ( OP_ABORT == status ) strcpy ( buffer_c , "User hit control-c." ); else if ( !SUCCESS(status )) strcpy ( buffer_c , "Failure in DLOG function."); else strcpy ( buffer_c , "User entered value was: " ) , sprintf ( &buffer_c[ strlen ( buffer_c ) ] , "%s" , value_c ); cowrite_c ( CWR_LOCAL , buffer_c , NULL , NULL ) ;

APPLICATIONS STRUCTURES Page 2-13

2.3.2.3 DLOG Utility Arguments - Even though there many different kinds of DLOG utilities, some of the arguments represent the same concept for different utilities. For instance, all arguments that start with the word `prompt' are input arguments that are formatted into the dialog box as a prompt string. The `prompt' argument will act the same for the DLOG_text() utility as it does for the DLOG_list() utility. Rather than repeat comments pertaining to the `prompt' argument for each prototype, just a short comment is made in the prototype and a longer comment here. The same method has been used for other common argument names in the prototypes in this file.

2.3.2.3.1 `prompt' Argument - An argument starting with the word `prompt' is an input argument. The string provided is used to prompt the user. Several lines can be specified in the `prompt' argument. This is done by including newline characters ('\n' in C; CHAR(10) in FORTRAN) in the prompt. The prompt will be split into separate lines at the newline characters before it is shown to the user. If any lines are still too long, they will be divided further (on blanks, if possible).

APPLICATIONS STRUCTURES Page 2-14 On xwindows platforms, all the lines in the caller-supplied prompt are used in the dialog box. On non-windows platforms, all lines except the last are outputted to the message area of the screen. The last is written to the prompt area. Bear in mind that on terminal CALFs (SCP T, SCP C, SCP G, etc.) there are only 3 lines in the message area, so prompts should be well under 4 lines in length, or contain all critical information in the last 4 lines, to be compatible with all SCP types.

2.3.2.3.2 `type' Argument: - An argument starting with the word `type' is an input argument. The value specifies the data type of other arguments. In C, the `type' argument is of type DLOG_type_te (see below). For instance, if DLOG_TYPE_R is specified as the `type' argument, the DLOG utility will prompt the user until a valid floating-point number is entered, and the value written to the `value' argument will also be a floating-point number. Another example: if DLOG_TYPE_Z is specified as the `type' argument, the DLOG utility will prompt the user until a valid hexadecimal integer number is entered. The value written to the `value' argument will be an integer. The values allowed for the `type' argument to a DLOG utility come in two flavors: "Line" and "Token".

APPLICATIONS STRUCTURES Page 2-15 Line types are mostly used when prompting for things like comments, reasons, or titles. Token types are mostly used for things like numeric data, primaries, micros, units, secondaries, channels, components, states, etc. Line types, such as DLOG_TYPE_N_LINE, end in the word "_LINE". They indicate that everything that the user entered in response to the prompt should be returned to the caller in the specified format. "Token" types, such as DLOG_TYPE_R and DLOG_TYPE_Z, do not end in the word "_LINE". They indicate that the only the first "token" entered by the user should be returned to the caller. The remainder of the user's input is stored in what is known as the parse buffer. The next call to a DLOG utility looks in the parse buffer; if it is not empty, it uses the contents of the parse buffer AS IF IT WERE user input; if it is found to be valid input, the user is NOT PROMPTED, and the caller of the DLOG utility gets the next token that was obtained from the parse buffer. How are tokens separated? All most users need to know is that tokens are separated by blanks, commas, or equals signs, except inside matching quotes. Note that this means that if a token-flavored type is specified, embedded blanks, commas, and equals signs won't work in user input, unless enclosed in quote marks. (For the exact rules on token-parsing, see ref_iobsic:pars.c).

2.3.2.3.3 `size' Argument -

APPLICATIONS STRUCTURES Page 2-16 An argument starting with the word `size' is an input argument. The value should specify the size of the `value' argument (see below) in bytes. This informs the DLOG utility how many bytes of data it can write to the `value' argument. In most cases, sizeof() the `value' argument (in C) or SIZEOF() (in FORTRAN) should be used as the `size' argument. Other arguments may have to match the size specified by the `size' argument such as the `default' and `current' arguments (see below).

2.3.2.3.4 `value' Argument - An argument starting with the word `value' is an output argument. The data written to this argument represents the user's input. This argument must be the address of at least as many bytes of memory as are specified by the `size' argument. If the DLOG utility returns a successful status, the user entered a valid value that was successfully written to the `value' argument specified by the caller. The DLOG utility writes the user's input in the format specified by the `type' argument. For example, if the caller specifies a `type' argument of DLOG_TYPE_R, and a `size' argument of "sizeof(float)", the DLOG utility will write a float to the `value' argument if the user enters a valid floating point number.

APPLICATIONS STRUCTURES Page 2-17 Another example: if the caller specifies a `type' argument of DLOG_TYPE_R, and a `size' argument of "sizeof(double)", the DLOG utility will write a double to the `value' argument if the user enters a valid floating point number.

2.3.2.3.5 `default' Argument - An argument starting with the word `default' is an optional input argument. This argument (if supplied) must be the address of a value of a type specified by the `type' argument, and size specified by the `size' argument. If supplied, the default will be added to the prompt that the user sees as "(default = [xxxxx])", where xxxxx is the ascii form of the default. If the user enters a carriage-return () as input, the supplied default will be written to the `value' argument, just as if the user had entered it.

2.3.2.3.6 `current' Argument - An argument starting with the word `current' is an optional input argument.

APPLICATIONS STRUCTURES Page 2-18 This argument (if supplied) must be the address of a value of a type specified by the `type' argument, and size specified by the `size' argument. If supplied, the current value will be added to the prompt that the user sees as "(current = xxxxx)", where xxxxx is the ascii form of the current value. The intended use for the `current' argument is to let applications tell the user the current value of something they are about to change, before they change it.

2.3.2.3.7 `min'/`max' Arguments - An argument starting with the words `min' or `max' is an optional input argument. Either of these arguments (if supplied) must be the address of a value of a type specified by the `type' argument, and size specified by the `size' argument. If supplied, the current value will be added to the prompt that the user sees as "(min = xxxxx)" or "(max = xxxxx)", where xxxxx is the ascii form of the value. The user's input will not be considered valid unless it falls between the minimum and maximum values. Values equal to the min or max values will be considered valid.

APPLICATIONS STRUCTURES Page 2-19 `min' and `max' arguments do not both need to be supplied. Only the DLOG_range*() functions use `min'/`max' arguments.

2.3.2.3.8 `query_default'/`query_value' Arguments - These arguments are only used by the DLOG_query*() functions. See the function header for DLOG_query() in ref_iobsic:dlog_query.c for more information.

2.3.2.3.9 `item' Argument - An argument starting with the word `item' is an input argument. This argument must be the address of an array of values of a type specified by the `type' argument, and size specified by the `size' argument (exceptions: DLOG_TYPE_N, DLOG_TYPE_N_LINE, DLOG_TYPE_C, DLOG_TYPE_C_LINE). On x platforms, the values are formatted into the dialog so that the user can double-click on an item, or type an item in manually. On non-x platforms, the values are added to the prompt like this: "(choices = aaa,bbb,ccc)". The user's input will not be considered valid unless it matches exactly one of the choices in the `item' argument. If the user enters a valid choice, the choice is copied from the `item' argument to the `value' argument.

APPLICATIONS STRUCTURES Page 2-20 These arguments are only used by the DLOG_list*() functions. See the function header for DLOG_list() in ref_iobsic:dlog_query.c for more information.

2.3.2.3.10 General Note - When calling a DLOG utility, the same variable can be specified for any combination of the value, default, current, min, and max arguments. For example, one could call DLOG_text, specifying a type of DLOG_TYPE_R and the value &my_float (where my_float is declared as a float) for the default, current, and value arguments (if desired).

2.3.2.4 The Parse Buffer - The prompting facilities on the SLC control system support something known as a 'parse buffer'. This parse buffer has two primary purposes: supporting button macro playback, and supporting "type-ahead". (Type-ahead allows the user to enter data for several consecutive prompts all at once in the first prompt issued. Many facilities in the control system rely on it. One example is applications that allow the user to type in primary, micro, and unit in response to a prompt for a primary; the primary is used to fulfill the first prompt, and the micro and unit fulfill the second and third prompts without the

APPLICATIONS STRUCTURES Page 2-21 user being reprompted). Users of DLOG utilities need to be aware of the parse buffer in two main areas First, if the user enters data that is found to be invalid (such as "hi there!" in response to a prompt for a floating-point number) the DLOG facility clears the parse buffer by calling pars_reset() and reprompts the user. (This is usually required because it is likely that if the item that the user entered was invalid, any additional items that the user typed-ahead are probably incorrect or invalid also. (In addition, clearing the parse buffer gives users a chance to intervene if a button macro is playing back)). Second, in some specialized situations, applications want to make sure that they do not leave garbage in the parse buffer, or want to force a prompt even though the parse buffer may not be empty. Calling parse_reset() will clear the parse buffer in these situations. Note that automatic data entry during button-macro playback will not work if pars_reset() is called before a DLOG utility.

2.4 LOGICAL NAME ROUTINES A consistent set of routines to reference variables, subroutines, groups, and displays by logical names has been developed. They are basically to allow symbolic reference to these entities from the panel description code.

APPLICATIONS STRUCTURES Page 2-22 o LOG_NAME is a character variable of length less than or equal to 8. o LOC4 is a 4 byte variable. o LOC8 is an 8 byte variable. o EXT_SUBR is the name of a subroutine that has been declared EXTERNAL. The subroutine must have no arguments. When any subroutine is declared to the logical name subroutines, it is called with a parameter ACNTRL(1) set to -1 for initialization. This parameter is in a common block found in the include file ACNTRL. Note that the LOG_NAME's must be unique across all calls to the logical name routines. The returned values of these functions are defined in the include file DBDEF.

2.4.1 LIST_VAR4 ISS=LIST_VAR4(LOC4,LOG_NAME) associates a 4 byte variable with a logical name.

2.4.2 LIST_VAR8 ISS=LIST_VAR8(LOC8,LOG_NAME) associates an 8 byte variable with a logical name.

2.4.3 LIST_DISP

APPLICATIONS STRUCTURES Page 2-23 ISS=LIST_DISP(EXT_SUBR,LOG_NAME,GRP_BITS) associates a display generating subroutine with a logical name. It also defines the set of groups for which this display will be generated. GRP_BITS is a bit map of the relevant GRP_BIT's . See LIST_GROUP.

2.4.4 LIST_CALL ISS=LIST_CALL(EXT_SUBR,LOG_NAME) associates any subroutine with a logical name so that it may be 'called' from the panel description code.

2.4.5 LIST_GROUP ISS=LIST_GROUP(EXT_SUBR,LOG_NAME,GRP_BIT) associates a group driver subroutine with a logical name. The LOG_NAME may be used to schedule the group. GRP_BIT is an I*4 argument returned by LIST_GROUP, containing a unique bit for each defined group. These bits should be appropriately combined to form the GRP_BITS argument into LIST_DISP.

2.4.6 GROUP_SCHED ISS=GROUP_SCHED(LOG_NAME,MODE,INTERVAL) is used to control the scheduling of groups. o LOG_NAME may be the (character) name of any group previously declared by a call to LIST_GROUP, or it may be the string SELF to perform scheduling operations on itself.

APPLICATIONS STRUCTURES Page 2-24 o MODE may be any of the following character strings: OFF Stop any cyclical scheduling of the specified group. NOW Schedule the specified group ASAP but only once. LATER Schedule the specified group INTERVAL from now. CYCLE Schedule the specified group INTERVAL from now and every INTERVAL seconds thereafter. o INTERVAL is a R*4 number of seconds for the delay. INTERVAL is optional and defaults to 1 second if not coded. Note that INTERVAL is ignored for MODE's OFF and NOW.

2.4.7 Service Routines The logical name facility is serviced by two routines which are not intended for the normal user. They are defined here for completeness.

2.4.7.1 LIST_PUT - ISS=LIST_PUT(INT_NAME,DATA) o INT_NAME is a 8 byte integer which must be left adjusted and right padded with blanks to correspond to a LOG_NAME. o DATA is an integer array of 4 or 8 bytes.

APPLICATIONS STRUCTURES Page 2-25 LIST_PUT searches the local name tables to find the LOG_NAME corresponding to INT_NAME. Then, if the LOG_NAME was defined from the routine: o LIST_VAR4 - The first 4 bytes of DATA are transferred into LOC4. o LIST_VAR8 - The first 8 bytes of DATA are transferred into LOC8. o LIST_DISP - The display subroutine will be loaded into the DEXEC tables. DATA is ignored. o LIST_CALL - The subroutine will be called. DATA is ignored. o LIST_GROUP - The Group is scheduled for one-shot execution. DATA is ignored.

2.4.7.2 LIST_GET - ISS=LIST_GET(INT_NAME,DATA) searches the local name tables to find the LOG_NAME corresponding to INT_NAME. Then, if the LOG_NAME was defined from the routine: o LIST_VAR4 - The value in LOC4 is copied into the first 4 bytes of DATA. o LIST_VAR8 - The value in LOC8 is copied into the first 8 bytes of DATA.

APPLICATIONS STRUCTURES Page 2-26 o LIST_CALL - The address of the subroutine will be copied into the first 4 bytes of DATA. o LIST_GET does nothing if the LOG_NAME was defined by one of the other routines

Go to top of page

Contact (until Aug. 15, 1996): Jeffrey Miller
Owner: Bob Sass

Converted from VAX Runoff output using doc2webset.pl