System Software Library TACL Programming Guide Abstract This manual describes the Tandem Advanced Command Language (TACL) and provides information and examples for creating TACL programs. Part Number 107365 Edition Second Published Product Version Release ID Supported Releases December 1994 TACL D30 D30.00 This manual supports D30.00 and all subsequent releases until otherwise indicated in a new edition.
Document History Edition Part Number Product Version Earliest Supported Release Published First Update Second 085797 086700 107365 TACL C20 TACL D10 TACL D30 N/A N/A D30.00 November 1992 February 1993 December 1994 New editions incorporate any updates issued since the previous edition. A plus sign (+) after a release ID indicates that this manual describes function added to the base release, either by an interim product modification (IPM) or by a new product version on a .
New and Changed Information This is the second edition of the TACL Programming Guide . This edition documents the following new TACL features: A new built-in function, #SETCONFIGURATION, sets the TACL flags that can change the behavior of TACL for a specified TACL image or configure the currently running TACL process. A new built-in function, #XLOGON, implements the LOGON command. The LOGON command, #CHANGEUSER built-in function, and #XLOGON builtin function support the Safeguard authentication dialog.
New and Changed Information (This page left intentionally blank) iv 105919 Tandem Computers Incorporated
Contents About This Manual xi Notation Conventions Section 1 xv An Overview of TACL Running the Examples in This Manual 1-1 Style Conventions 1-2 Exceptions to the Style Conventions 1-3 Conventions Specific to This Manual 1-3 Section 2 Developing TACL Programs Choosing a Type of Variable 2-1 Defining Program Structure 2-2 Using Flow Control Functions 2-2 Nesting TACL Code 2-7 Saving Levels of Variables 2-8 Exiting From Programs 2-9 Processing Character Data 2-9 Line and Character 2-10 Global Edit
Contents Section 3 Developing TACL Routines Processing Arguments 3-1 How #ARGUMENT Works 3-3 Using #ARGUMENT 3-4 Examining the Contents of Arguments Parsing Arguments for a Caller 3-11 Returning Results 3-9 3-15 Calling a Routine Recursively Exiting From a Routine 3-16 3-17 Writing an Exception Handler 3-18 Types of Exception Handlers 3-19 Constructing an Exception Handler 3-19 Creating a Release Exception Handler 3-20 Creating a Keep Exception Handler 3-24 Combining Keep and Release Handlers 3-30
Contents Processing Completion Information 5-32 Processing NetBatch Jobs and Completion Codes Monitoring Job Status ENQUIRY 5-35 Section 6 5-32 Running TACL as a Server Running a TACL Process as a Server 6-1 Starting TACL as a Server Process 6-1 Sending Requests to a TACL Server 6-2 Directing Output From TACL 6-4 Running TACL Code as a Server 6-5 Constructing a TACL Server 6-5 Using TACL as a Pathway Server Section 7 6-6 Using Programmatic Interfaces Overview of SPI and EMS 7-1 Using SPI 7-4 Defini
Contents Index Figures viii Index–1 Figure 2-1. Performing Tasks Within a Loop Figure 2-2. Performing a Bubble Sort With Nested #LOOP Statements Figure 2-3. Deleting Files in a Subvolume 2-5 Figure 2-4. Processing Macro Arguments 2-8 Figure 2-5. Extracting a Volume Name from a Variable Figure 2-6. Retrieving Disk Names From DSAP Figure 2-7. Relationships Between System Timestamps and TACL Functions 2-20 Figure 2-8.
Contents Figure 3-16. Sample Command Shell Figure 3-17.
Contents Tables Table 2-1. x Built-In Functions That Edit Variables by Line 2-10 Table 2-2. Global Editing Commands Table 2-3. Data Manipulation Functions Table 2-4. Timestamp Conversion Functions Table 2-5. _DEBUGGER Command Syntax Table 3-1. Functions That Support Arguments Table 3-2. Functions That Support Exception Handlers Table 3-3.
About This Manual This manual describes the Tandem Advanced Command Language (TACL) and provides information and examples for creating TACL programs. Audience This manual is intended for users of TACL who are familiar with TACL commands and built-in functions and who want to create TACL programs. Organization This manual contains the following sections: Section 1, “An Overview of TACL,” contains an overview of TACL features and a description of the programming conventions used in examples.
About This Manual Related Reading To use this manual, you should be familiar with the syntax and structure of procedural variables (TEXT, MACRO, and ROUTINE), including basic programming concepts and terminology such as “pushing” and “popping” (creating and deleting) variables, the use of arguments, and so on. Elements of the TACL language are described in the TACL Reference Manual.
About This Manual Related Reading Figure 1 lists the recommended sequence for reading TACL related manuals. Figure 1.
About This Manual Related Reading (This page left intentionally blank) xiv 107365 Tandem Computers Incorporated
Notation Conventions General Syntax Notation UPPERCASE LETTERS The following list summarizes the notation conventions for syntax presentation in this manual. Uppercase letters indicate keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example: STATUS lowercase italic letters Lowercase italic letters indicate variable items that you supply. Items not enclosed in brackets are required.
Notation Conventions General Syntax Notation Ellipsis ... An ellipsis immediately following a pair of brackets or braces indicates that you can repeat the enclosed sequence of syntax items any number of times. For example: #PUSH variable [ [,] variable ] ... [ + | - ] {0|1|2|3|4|5|6|7|8|9}... An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times.
1 An Overview of TACL The Tandem Advanced Command Language (TACL) is the standard command interface to the Tandem NonStop kernel. In addition to providing full command interpreter facilities, TACL is a high-level programming language. As a programming language, the TACL product is most often used for managing systems and processes. You can, for example, use TACL to: Automate system startup and shutdown procedures.
An Overview of TACL Style Conventions You can add these statements to your TACLCSTM file if you use them frequently. In cases where TACL provides a built-in function that is similar to a command (such as PUSH and #PUSH), the examples in this manual use the built-in function. Built-in functions are the most basic unit of TACL, and they return results and provide easier programmatic access to error information. Error checking is as important in TACL programs as it is in programs written in other languages.
An Overview of TACL Style Conventions indented two spaces within the square brackets. Conditional text is indented two spaces past the labels. For example: [#CASE [errornumber] |0| #OUTPUT [filename] was purged |OTHERWISE| #OUTPUT [filename] could not be purged #OUTPUT Error [errornumber] ] Exceptions to the Style Conventions In a few situations, the preceding style conventions do not produce optimal results.
An Overview of TACL Style Conventions (This page left intentionally blank) 1–4 107365 Tandem Computers Incorporated
2 Developing TACL Programs This section describes topics that are common to all types of procedural variables. Topics include: Defining program structure Processing character data Accessing time information Accessing terminals Debugging TACL programs The TACL Reference Manual contains information about TACL statements, programs, and the TACL environment. This information is prerequisite to the topics in this and later sections.
Developing TACL Programs Defining Program Structure Defining Program Structure The following paragraphs describe topics that are related to the structure of TACL programs: Using flow control functions: #LOOP, #IF, and #CASE Nesting programs within other TACL programs Saving and restoring levels of variables Exiting from TACL programs Using Flow Control Functions The following examples show how #LOOP, #CASE, and #IF statements work.
Developing TACL Programs Defining Program Structure You can define a macro that increments a loop variable (passed as the argument); for example: [#DEF next MACRO |BODY| #SET %1% [#COMPUTE %1% + 1] ] Use the macro in Figure 2-2, bubble, with its nested #LOOP statements, to perform a bubble sort. A bubble sort compares numbers and switches their places until the numbers are stored in ascending order. To run bubble, load its file and supply the number of sort elements as an argument: bubble num Figure 2-2.
Developing TACL Programs Defining Program Structure Figure 2-2. Performing a Bubble Sort With Nested #LOOP Statements (Page 2 of 2) == Loop through all variable levels and display contents #SET element 1 [#LOOP |DO| #OUTPUT [stack.[element]] #SET element [#COMPUTE element + 1] |UNTIL| (element > %1%) ] #UNFRAME Bubble requests the specified number of elements and displays the results: 29> bubble Enter Next Enter Next Enter Next 1 5 43 30> 3 Number to be Sorted...1 Number to be Sorted...
Developing TACL Programs Defining Program Structure When you run checkfiles, the routine displays the following: Where do you want to start (default = beginning of subvol)? To start checking files in the middle of the subvolume, enter a text constant with the desired starting characters. Checkfiles then performs the following steps for each file past the specified starting point in the subvolume: 1. Checkfiles displays the file name and date of last alteration. 2.
Developing TACL Programs Defining Program Structure Figure 2-3. Deleting Files in a Subvolume (Page 2 of 2) [#IF [#MATCH Y* [#SHIFTSTRING/UP/[reply]]] |THEN| #SET resp [#PURGE [filenm]] [#CASE [resp] |0| #OUTPUT [filenm] purged |OTHERWISE| #OUTPUT [filenm] could not be purged #OUTPUT Error [resp] ] {end #CASE} ] {end #IF} |OTHERWISE| == Not an edit file; determine whether to purge it #OUTPUT Not an Edit file; nothing to show you.
Developing TACL Programs Defining Program Structure Nesting TACL Code To run another TACL program from within a TACL program, invoke the file name or variable name, as appropriate. Certain built-in functions can be used only within one type of program (macro or routine). To determine the use of such functions in a nested program, see individual function descriptions in the TACL Reference Manual.
Developing TACL Programs Defining Program Structure Use the macro in Figure 2-4, defaultvars, to assign data to a set of empty variables. The macro accepts a space-separated list of variables and nonempty values and calls itself repeatedly until all arguments are processed. To run this macro, load the file that contains the macro definition and then type: 12> defaultvars [variable constant [variable constant...] ] Figure 2-4.
Developing TACL Programs Processing Character Data The #FRAME built-in function creates a local environment for variables. The #UNFRAME command restores variables to the state they were in at the time of the last #FRAME operation. For more information about frames, see the TACL Reference Manual. Exiting From Programs TACL exits from a macro or text variable as soon as it encounters either of the following conditions: Successful completion of the code; TACL executes each line and exits when finished.
Developing TACL Programs Processing Character Data For additional information about #DELTA and STRUCT variables, see the TACL Reference Manual. For examples showing the use of STRUCT variables with SPI and EMS, see Section 7, “Using Programmatic Interfaces.” The following paragraphs describe how to use string manipulation functions and commands. Note Line and Character Built-In Functions Variable levels that contain TACL code contain special internal multicharacter representations of [, |, and ].
Developing TACL Programs Processing Character Data A character address specifies a particular character within a variable, counting from the first character, whose character address is 1. Each end-of-line character (except the last one in the variable) counts as one character. If a specified character address is greater than the number of characters in the variable, that address is considered to be equivalent to the address of the character that appears after the last character in the variable.
Developing TACL Programs Processing Character Data To find the character position of the first occurrence of the string “text,” starting at character position 1, enter: 14> #CHARFINDV sample 1 "text" #CHARFINDV sample 1 "text" expanded to: 62 15> Use the macro in Figure 2-5, volname, to extract a volume name from a variable named mylist.
Developing TACL Programs Processing Character Data Global Editing Commands Use the commands in Table 2-2 to perform editing operations on the entire contents of a variable or a range of lines within the variable. Table 2-2. Global Editing Commands Command VCHANGE VCOPY VDELETE VFIND VINSERT VLIST VMOVE Description Changes all occurrences of one string to another string in a range of consecutive lines in a variable. VCHANGE is not case-sensitive.
Developing TACL Programs Processing Character Data To display the contents of sample2, enter: 14> VLIST sample2 1 2 3 The name of this variable is "sample2." There are 37 characters in this line. This is the last line in the variable. To find all occurrences of the word “line” in sample2, enter: 15> VFIND sample2 "line" 2 3 There are 37 characters in this line. This is the last line in the variable.
Developing TACL Programs Processing Character Data Use the macro in Figure 2-6, volnames, to display the volume names on your system, using the VFIND global editing command. To run this macro, load the file and type volnames: 12> volnames The volume names are: $SYSTEM $DATA $DATA2 $DATA3 13> This macro uses the OUTV construct to retrieve process output. For more information about OUTV, see “Using INV and OUTV” in Section 5, “Initiating and Communicating With Processes.” Figure 2-6.
Developing TACL Programs Processing Character Data Additional Data Manipulation Capabilities Use the built-in functions and commands in Table 2-3 to perform other data manipulation tasks. A dash indicates that there is no equivalent function or command. Table 2-3.
Developing TACL Programs Accessing Time Data To obtain input from a terminal, you can use #INPUTV, #SET, VINSERT, or #APPEND. The following function calls wait for input and store the input into variable: #INPUTV variable prompt #SET variable [#INPUT prompt-text] #APPEND variable [#INPUT prompt-text] In addition, you can use #REQUESTER to read from a terminal. For additional information about these built-in functions and commands, see the TACL Reference Manual.
Developing TACL Programs Accessing Time Data Local timestamp, a three-word timestamp. This timestamp represents the number of centiseconds (.01 second) since 00:00 December 31, 1974. An example is: 45553140000 A local timestamp can represent one of the following three time zones: Local civil time (LCT): The time of day locally. This is in either standard time or daylight-saving time, depending on the area and the time of year. Local standard time (LST): The time of day expressed in standard time.
Developing TACL Programs Accessing Time Data Converting a Timestamp As noted previously, you can retrieve timestamps from the system in a three-word or four-word format. In addition, the #FILEINFO function returns timestamps in a threeword or four-word format, depending on the option you select. After you obtain the timestamp, you can include it in a function call, use it for calculations, or display it. Use the functions and commands in Table 2-4 to convert between time and date representations.
Developing TACL Programs Accessing Time Data Figure 2-7.
Developing TACL Programs Accessing Time Data Figure 2-8.
Developing TACL Programs Accessing Time Data Computing the Day of the Week Use the macro in Figure 2-9, dayofweek, to calculate the day of the week, as follows: 16> dayofweek Tuesday 17> Figure 2-9. Computing the Current Day ?SECTION dayofweek MACRO == Calculates the day of the week from the three word == TIMESTAMP, which starts at 00:00 31 December 1974 == (a Wednesday). #FRAME [#PUSH day^of^week elapsed^days elapsed^weeks ] == There are 8640000 hundredths of a second in a day.
Developing TACL Programs Accessing Time Data Converting Timestamps Into Different Formats The macro in Figure 2-10, getdates, converts the current date from a three-word timestamp to SQL format (yyyy-mm-dd), for use by report generators or other programs. This type of macro could be used to generate SQL reports. Figure 3-9 in Section 3, “Developing TACL Routines,” contains a modification of this example that shows how a nested routine can return dates as results. Figure 2-10.
Developing TACL Programs Accessing Terminals Accessing Terminals You can use TACL to read and write from a terminal. Sample operations include: Defining function keys Sending escape sequences to a terminal Changing the TACL prompt Implementing menus In addition, you can write programs that execute one or more commands that you use frequently. The Guardian User's Guide describes how to create command definitions; these definitions are typically alias or macro variables.
Developing TACL Programs Accessing Terminals Sending Escape Sequences to a Terminal The 6530 terminal and devices that emulate the 6530 terminal recognize a set of escape characters that allow you to control cursor position, set the size and video attributes of characters displayed on the screen, and perform other operations. Most escape sequences have the following format: escape-character number [number] The escape character is the 27th character in the ASCII character set.
Developing TACL Programs Accessing Terminals Figure 2-11. Sending Special Characters to a Screen (Page 2 of 2) == Clear the screen #OUTPUT [ascii:clr(0:1)] #OUTPUT The screen was just cleared.
Developing TACL Programs Accessing Terminals Use the routine in Figure 2-12, displayinfo, to list a screen full of lines and prompt the user to continue. To use this routine, load the associated file and enter: displayinfo This routine does not display an entire screen of text, but shows how the prompt works. Figure 2-12.
Developing TACL Programs Accessing Terminals Use the macro in Figure 2-13, lock, to lock a terminal until the user types the password. Figure 2-13.
Developing TACL Programs Accessing Terminals Changing the TACL Prompt The SETPROMPT command allows you to change the standard TACL prompt so that it includes the current volume or subvolume name. To make additional modifications, define a variable called _PROMPTER that contains the definition of the prompt. Within the _PROMPTER variable, set the #PROMPT built-in variable to the desired prompt text. To cause TACL to invoke _PROMPTER prior to displaying a prompt, set the #PREFIX built-in variable to -1.
Developing TACL Programs Accessing Terminals Implementing Menus You can use TACL to define menus. A menu displays a screen and allows users to press function keys to access information and utilities. Use the text variable in Figure 2-14, menu, to generate a menu. The user can press function keys to start applications and utilities. Note that the menu text could be displayed by individual #OUTPUT calls within the #LOOP function; setting displayvar to the display text avoids multiple #OUTPUT calls.
Developing TACL Programs Accessing Terminals Figure 2-14. Displaying a Menu (Page 2 of 2) [#LOOP |DO| #OUTPUTV displayvar SINK [#INPUT /FUNCTIONKEY fkey/ [prompt]] [#CASE [fkey] | F1 | SINK [psmail] | F2 | #INPUTV temp prompt1 TEDIT [temp] | F3 | #INPUTV temp prompt1 #SET temp2 #INPUTV temp2 prompt2 [#IF [#EMPTYV /BLANK/ temp2] |THEN| #SET temp2 $S.
Developing TACL Programs Debugging TACL Programs Debugging TACL The TACL debugger shows how TACL interprets code. It provides step-by-step Programs execution, examination of control flow, and examination and modification of variables. The debugger is a separate function, invoked by TACL upon request. For information about how to debug #DELTA code, see “#DELTA Built-In Function” in the TACL Reference Manual.
Developing TACL Programs Debugging TACL Programs To reenter the debugger after using STEP, set a breakpoint on a variable that will be invoked later in your program. Next, type RESUME to run your program until TACL encounters the breakpoint or finishes the program. Note that setting a variable (such as #SET x 123) is not an invocation of the variable; [x] is an invocation of the variable. To end a debugging session, clear all breakpoints and type RESUME.
Developing TACL Programs Debugging TACL Programs without accessibility to the #ARGUMENT built-in function, you would need to check that the argument is a valid file name. Figure 2-15.
Developing TACL Programs Debugging TACL Programs OTHERWISE ] -TRACE-6[#CASE 1 ^ -TRACE-6TEDIT [editfile] ^ -TRACEThe user issues a DISPLAY command to see the contents of the variable EDITFILE and sets a breakpoint on that variable: -6-DISPLAY editfile sect08 -7-BREAK editfile The RESUME command terminates the debug mode, and processing continues until the routine is ready to invoke EDITFILE, at which point the set breakpoint invokes _DEBUGGER again, which displays the word -BREAK- to show why it was invoke
Developing TACL Programs Debugging TACL Programs (This page left intentionally blank) 2–36 107365 Tandem Computers Incorporated
3 Developing TACL Routines TACL routines provide features that you cannot obtain from any other type of TACL variable.
Developing TACL Routines Processing Arguments To process the file-name argument from a macro: ?SECTION process_argm MACRO == This macro does not check argument type or validity. == Separate coding is required to validate the argument. #FRAME #PUSH fname == Store the first argument in fname.
Developing TACL Routines Processing Arguments Table 3-1 lists the built-in functions that support arguments to routines. Table 3-1. Functions That Support Arguments Function Description #ARGUMENT Allows you to define a list of argument types. Compares each argument against these types. If an argument matches a specified type, #ARGUMENT returns a number that indicates the position of the argument type in your list of types.
Developing TACL Routines Processing Arguments File names (FILENAME), DEFINE names and attribute names (DEFINENAME and ATTRIBUTENAME), process names (PROCESSNAME), system names (SYSTEMNAME), and user names (USER) Subsystem IDs (SUBSYSTEM) and text for SPI and EMS tokens (TOKEN) Some alternatives allow you to limit processing to syntax checking. For example, the FILENAME alternative looks for the name of an existing file.
Developing TACL Routines Processing Arguments To process several types of arguments entered in any order, use a #CASE statement. Use the routine in Figure 3-1 to process zero or more of the following: File attribute names (defined in ALL) Numbers Figure 3-1.
Developing TACL Routines Processing Arguments The following examples illustrate two ways to retrieve a number from a position within a line of text (as returned by FUP or other processes). First, you can use the #CHARGET function: #PUSH pfree line #SET line This is a test number: 53 #SET pfree [#CHARGET line 24 FOR 2] #OUTPUT [pfree] The preceding code retrieves two characters from line, but does not check that the two characters are numbers.
Developing TACL Routines Processing Arguments You could call this routine from your program: ?SECTION caller ROUTINE #FRAME == call getnumber with the starting position == and the line of text #PUSH pfree position line #SET line This is a test number: 53 #SET position 23 #SET pfree [getnumber [position] [line]] #OUTPUT [pfree] #UNFRAME The routine performs more checking than #CHARGET and is more flexible with the length of a space-separated number.
Developing TACL Routines Processing Arguments The following routine expects both a file name and a properly formatted variable name, but accepts them in either sequence. To run this routine, type the name of the file that contains this code: ?TACL ROUTINE #FRAME #PUSH fname vname [#CASE [#ARGUMENT /VALUE fname/ FILENAME VARIABLE /SYNTAX/] |1| #IF [#ARGUMENT /VALUE vname/ VARIABLE /SYNTAX/] |2| #SETV vname fname == fname contains the variable name; == move the variable name into vname.
Developing TACL Routines Processing Arguments Processing Arguments Recursively You can use the #ROUTINENAME built-in function to process arguments recursively. For more information, see “Calling a Routine Recursively,” later in this section. Examining the Contents of Arguments The following routines examine the contents of arguments. These routines return results; if you use the routines interactively, use #OUTPUT(V) to display results.
Developing TACL Routines Processing Arguments Figure 3-3. Returning a Set of Characters From a Variable ?SECTION substring ROUTINE #FRAME #PUSH bgn end var #IF #IF #IF #IF [#ARGUMENT/VALUE var/VARIABLE] [#ARGUMENT/VALUE bgn/NUMBER] [#ARGUMENT/VALUE end/NUMBER] [#ARGUMENT END] [#RESULT [#CHARGET [var] [bgn] TO [end]]] #UNFRAME Note This routine does not check to make sure that number2 is a greater number than number1. For more thorough argument validation, include that check.
Developing TACL Routines Processing Arguments Figure 3-5. Counting Characters in a Variable ?SECTION length ROUTINE #FRAME #PUSH var #IF [#ARGUMENT/VALUE var/VARIABLE] #IF [#ARGUMENT END] [#RESULT [#CHARCOUNT [var]]] #UNFRAME Use the routine in Figure 3-6, insert, to insert the contents of variable1 into variable2 at the specified position. The syntax is: insert variable1 variable2 number Figure 3-6.
Developing TACL Routines Processing Arguments The syntax for getargs is: getargs triplet [ triplet ]... where triplet contains three parts: REQUIRED type variable OPTIONAL REQUIRED or OPTIONAL specifies whether the corresponding argument is required or optional. { } Type is an #ARGUMENT alternative such as FILENAME. The specified type must not permit spaces. The KEYWORD alternative, for example, cannot be used because it requires the WORDLIST alternative, which allows spaces in its syntax.
Developing TACL Routines Processing Arguments Figure 3-7.
Developing TACL Routines Processing Arguments The following shows a sample invocation of call_getargs: 11> call_getargs data1, data2, 4 file1 = data1 file2 = data2 n1 = 4 12> Figure 3-8.
Developing TACL Routines Returning Results Returning Results Function results come from one or more #RESULT built-in functions within the routine. This is an important distinction between macros and routines: a macro invocation returns the expansion of the text of the macro; a routine returns only what the #RESULT function provides. Use the macro in Figure 3-9, report_shell, to calculate today’s date and the date thirty days ago and convert the dates to SQL format (yyyy-mm-dd).
Developing TACL Routines Calling a Routine Recursively Calling a Routine #The #ROUTINENAME built-in function returns the name of the currently active Recursively routine, which allows you to invoke a routine from within the routine. The function is similar to accessing %0% from a macro, but you cannot use #ROUTINENAME in a macro or %0% in a routine.
Developing TACL Routines Exiting From a Routine Use the routine in Figure 3-11, argrec, to process one or more file names, checking for syntax but not for file existence. File names can be separated by spaces or commas. After processing each file name, the routine scans ahead and skips over commas. It calls itself to process each additional file name. Figure 3-11.
Developing TACL Routines Writing an Exception Handler Writing an Exception Handler An exception is an event or condition that requires special handling. If, for example, a user presses the BREAK key or enters alphabetic data when a number is expected, an exception occurs. TACL cannot detect a modem disconnect, but can detect and process other exceptions, including ones you define.
Developing TACL Routines Writing an Exception Handler Types of Exception Handlers Exception handlers can be divided into two types, depending on how they return control: Release handlers that relinquish control to the calling procedure Keep handlers that retain control regardless of exceptions (usually for security purposes) A routine can contain both types of exception handlers. Constructing an Exception Handler Use the built-in functions in Table 3-2 to construct exception handlers. Table 3-2.
Developing TACL Routines Writing an Exception Handler Figure 3-12.
Developing TACL Routines Writing an Exception Handler If the user presses the BREAK key while the processing loop is running, TACL raises the _BREAK exception and reinvokes the routine. The #CASE function executes the _BREAK case, displays a message, and exits. If the user enters anything other than ADD or SUB, the #CASE in the loop raises _ERROR, and TACL reinvokes the routine; in this situation, the #CASE function takes the _ERROR path, displays a message, and exits.
Developing TACL Routines Writing an Exception Handler When you invoke command_processor, the output looks like this: 16> command_processor Enter cmd: add ADD Enter cmd: clr Invalid command TACL error occurred. 17> command_processor Enter cmd: BREAK key pressed. 18> Use the routine in Figure 3-14, purgefiles, to purge files based on file name templates. Purgefiles illustrates the use of #FILTER, #FILENAMES, and the TEMPLATES alternative for the #ARGUMENT built-in function.
Developing TACL Routines Writing an Exception Handler Figure 3-14.
Developing TACL Routines Writing an Exception Handler Figure 3-14.
Developing TACL Routines Writing an Exception Handler Note The examples in this subsection include an EXIT case for testing purposes, which allows you to exit the routines. To prohibit exits, delete the EXIT case from the #FILTER statement and from the exception handler and main loop. To invoke restricted_cmd_processor, load the file and enter: restricted_cmd_processor Figure 3-15.
Developing TACL Routines Writing an Exception Handler When you invoke restricted_cmd_processor, the output looks like this: 16> restricted_cmd_processor Enter cmd: add ADD Enter cmd: clr Invalid command TACL error occurred. Enter cmd: BREAK key pressed. Enter cmd: exit 17> By using the definitions in Figure 3-16, a user can start and stop an application. (In the example, there is no code to start an application; the code performs a delay sequence to simulate application activity.
Developing TACL Routines Writing an Exception Handler Figure 3-16.
Developing TACL Routines Writing an Exception Handler Figure 3-16. Sample Command Shell (Page 2 of 4) #INPUTV /UNTIL TACL/ cmd prompt [#IF ([#INPUTEOF]) |THEN| #RAISE EOF ] [#CASE [cmd] |WARMSTART| warmstart |COLDSTART| coldstart |SHUTDOWN| shutdown |EXIT| EXIT |OTHERWISE | #OUTPUT Invalid command ] |UNTIL| 0 = 1 ] == end #LOOP #UNFRAME ?SECTION display_initial_message TEXT #OUTPUT This interface is used to: #OUTPUT COLDSTART, WARMSTART, or SHUTDOWN the application.
Developing TACL Routines Writing an Exception Handler Figure 3-16.
Developing TACL Routines Writing an Exception Handler Figure 3-16. Sample Command Shell (Page 4 of 4) ?SECTION exit MACRO == EXIT the exception handler [#IF condition = 1 |THEN| #OUTPUT Can not EXIT without resolving the error. #OUTPUT Must WARMSTART, COLDSTART, or SHUTDOWN. #OUTPUT |ELSE| #OUTPUT Exiting restrictive command shell. #RAISE EXIT ] ?SECTION cleanup MACRO == delete variables from prev.
Developing TACL Routines Writing an Exception Handler For this example, the keep handler terminates if you enter an EXIT command. Usually, a keep handler does not provide an exit mechanism. Figure 3-17. Using Nested Keep and Release Handlers (Page 1 of 2) ?SECTION restricted_caller ROUTINE [#CASE [#EXCEPTION] |_CALL| #FRAME #PUSH cmd exceptionlist #SET exceptionlist _BREAK _ERROR EXIT |_BREAK| #OUTPUT BREAK key pressed. |_ERROR| #OUTPUT TACL error occurred.
Developing TACL Routines Writing an Exception Handler Figure 3-17.
4 Accessing Files The #REQUESTER built-in function allows you to open a file, process, or device so that you can send messages or records to it or read messages or records from it. This section describes how to use #REQUESTER to access files. For information about the use of #REQUESTER with processes, see “Using $RECEIVE” in Section 5, “Initiating and Communicating With Processes.
Accessing Files Requesting Waited Reads Table 4-1 lists functions related to #REQUESTER operation. Table 4-1. Functions Used With #REQUESTER Requesting Waited Reads Function Description #APPEND, #APPENDV #EXTRACT, #EXTRACTV Adds lines to a variable. Retrieves lines from a variable.
Accessing Files Requesting Waited Reads Use the routine in Figure 4-1, waited_read, to perform waited reads from the file specified in the first argument in the invocation and display the records on the terminal. To invoke this routine, load the file and type: waited_read filename The routine stops when it detects an error or end-of-file. Figure 4-1.
Accessing Files Requesting Nowaited Reads Requesting Nowaited To open a file for nowaited read operations, issue a #REQUESTER call and omit the Reads WAIT option; for example, the following statement opens FILE1 and initializes error_var, read_var, and prompt_var: #SET rslt [#REQUESTER READ file1 error_var read_var prompt_var] Note It is very important to check the results of the open operation; otherwise, you will not know if the open request received an error.
Accessing Files Requesting Nowaited Reads This routine uses #VARIABLEINFO/VARIABLE/ to return a variable name to the #CASE statement. #VARIABLEINFO/VARIABLE/ returns the name of a variable without the level number so that it will match one of the labels. The #WAIT built-in function, when used alone, returns the variable name with the level number. Figure 4-2.
Accessing Files Requesting Waited Writes Requesting Waited To open a file for waited write operations, issue a #REQUESTER call and include the Writes WAIT option. The following statement opens FILE1 and initializes error_var and write_var. If FILE1 does not exist, TACL creates an Edit file: #SET rslt [#REQUESTER /WAIT/ WRITE file1 error_var write_var] Note It is very important to check the results of the open operation. Otherwise, you will not know if the open request received an error.
Accessing Files Requesting Waited Writes Use the routine in Figure 4-3, waited_write, to perform waited writes to the file specified as the first argument in the invocation. If the file already contains data, this routine appends the new data to the end of the file. To invoke this routine , load the file and type: waited_write filename The #INPUT call in Figure 4-3 reads a line from the TACL IN file. Figure 4-3.
Accessing Files Requesting Nowaited Writes Requesting Nowaited To open a file for nowaited write operations, issue a #REQUESTER call and omit the Writes WAIT option. The following statement opens FILE1 and initializes error_var and write_var. If FILE1 does not exist, TACL creates an Edit file: #SET rslt [#REQUESTER WRITE file1 error_var write_var] Note It is very important to check the results of the open operation. Otherwise, you will not know if the open request received an error.
Accessing Files Requesting Nowaited Writes Use the routine in Figure 4-4, nowaited_write, to perform nowaited writes to the file specified in the first argument in the invocation. If the file already contains data, this routine appends the new data to the end of the file. To invoke this routine, load the file and type: nowaited_write filename Figure 4-4.
Accessing Files Copying Records Between Files Copying Records Use the routine in Figure 4-5, copy, to read records from one file and write them to Between Files another file. The source file is specified as the first argument; the destination file is specified as the second argument; both files must exist.
Accessing Files Copying Records Between Files Figure 4-5. Copying Records From One File to Another File (Page 2 of 2) [#IF open_err = 0 |THEN| #OUTPUT [dest] opened successfully |ELSE| #OUTPUT [dest] not open; error [write_err] SINK [#REQUESTER CLOSE read_var] == close source #RETURN ] == Initiate read and write operations. #SET read_err 0 == initialize read_err [#LOOP |DO| == Start the read. #APPEND prompt_var READIT == Wait for read_var or read_err to change.
Accessing Files Comparing Files Comparing Files Use the routine in Figure 4-6, fcomp, to perform a line-for-line comparison of two files. A mismatch does not resynchronize the two files. Fcomp reads a record from each of the two files and then calls #COMPAREV to compare the records. The maximum line length for an edit file is 239 bytes; fcomp uses this value as a maximum line length for the input records.
Accessing Files Comparing Files f2 is an ending field range (optional). result is a file that will contain the results of the comparison (optional). Figure 4-6. Comparing Two Files (Page 1 of 3) ?SECTION fcomp ROUTINE #FRAME == Define a character array; the maximum line length is 239 == characters. #DEF char_array STRUCT BEGIN CHAR column(1:239); END; == Use the character array to define two STRUCTs that contain == character arrays. Fcomp uses these STRUCTS to compare == lines of data.
Accessing Files Comparing Files Figure 4-6. Comparing Two Files (Page 2 of 3) == If a result file was specified, use it for output. == Otherwise, use the default OUT file. [#IF NOT [#EMPTYV results] |THEN| #PUSH #OUT #SET #OUT [results] ] == Display the user's request. #OUTPUT #OUTPUT *---------------------------------------------------* #OUTPUT Files compared: [file1],[file2] -- Field:<[f1]:[f2]> #OUTPUT *---------------------------------------------------* == Open the files.
Accessing Files Comparing Files Figure 4-6. Comparing Two Files (Page 3 of 3) == If the first read was successful, read a line from the == second file. [#IF file1_err <= 1 |THEN| #SET file2_prompt *start* #EXTRACTV file2_var line2 == If the second read was successful, perform the == comparison. [#IF NOT file2_err |THEN| == If the two lines do not match, display them.
Accessing Files Listing a File Listing a File Use the macro in Figure 4-7, tacllist, to format, paginate, and print TACL program files. This macro calls #REQUESTER to read the TACL file, copies the TACL file to a disk file designated as the OUT file in TFORM format, and then calls TFORM to format and print the file. Tacllist displays the following: A listing banner with the TACL file date and the current date. The contents of the file, including line numbers and page numbers.
Accessing Files Listing a File Figure 4-7.
Accessing Files Listing a File Figure 4-7.
Accessing Files Listing a File Figure 4-7. Listing a File (Page 4 of 5) == The following variables keep track of the line number, == page number, and number of lines already written to == a page (for calculation of automatic page break). #SET line_num 1 #SET page_num 1 #SET lines_out 0 #SET match_string \NEW #OUTPUT \STYLE FORM WIDTH 132 CHARS get_dates output_banner == Start the read operation; place the record into line.
Accessing Files Listing a File Figure 4-7. Listing a File (Page 5 of 5) [#IF err_inp <> 1 |THEN| == Error 1 is EOF (OK) #OUTPUT Error [err_inp]: Opening/reading file & [file:input(0:33)] ] #SET err_inp [#REQUESTER/WAIT/CLOSE rec_inp] #POP #OUT [#IF [#FILEINFO/CODE/ [file:output(0:33)]] = 101 |THEN| TFORM/IN [file:output(0:33)], OUT [printer], NOWAIT/ ] ] == end of #IF [err_inp] <> 0 |ELSE| == Error in input parameters #OUTPUT #OUTPUT ERROR: Missing input parameter.
5 Initiating and Communicating With Processes TACL provides several ways to initiate, control, and handle the results of processes, whether they are application programs, utilities, or other TACL processes. For example, you can: Run a program and wait to process TACL commands until the program is finished running. Run a program and continue to process TACL commands while the program is running. Start a utility, such as FUP, and send it a list of commands.
Initiating and Communicating With Processes Using RUN and #NEWPROCESS Options Communicating with a process through $RECEIVE, using #REQUESTER, #APPEND(V), and #EXTRACT(V). This method uses the following type of communication: OPEN WRITEREAD Process such as a device TACL REPLY CLOSE Processing completion information You can use the Define Process (DP) facility (not part of TACL) to communicate with processes if your system has ViewPoint software. See “Using DefineProcess,” later in this section.
Initiating and Communicating With Processes Using RUN and #NEWPROCESS Options Sending Information at Initiation Time You can supply IN and OUT files for processes that accept input from an IN file and write to an OUT file. This mechanism does not allow you to evaluate the results of each request and make decisions before the next request; it does, however, provide a way to send a set of requests to a process.
Initiating and Communicating With Processes Communicating With a Process TACL stores the values of parameters assigned by the PARAM command and sends these values to processes that request parameter values when the processes are started. Processes that request the parameter values interpret the values. CLEAR PARAM param-name clears a specific parameter value; CLEAR ALL PARAM clears all parameter values. TACL clears all parameter values when you use the LOGOFF command.
Initiating and Communicating With Processes Communicating With a Process 3. Send a command. 4. Wait for output from the process (a WRITE operation). 5. Based on the reply, decide upon the next action and either go back to Step 2 or continue to Step 6. 6. When finished, send an exit message to the process. The following facilities support this type of operation.
Initiating and Communicating With Processes Using the INLINE Facility Using the INLINE Facility The INLINE facility allows you to incorporate command stream processing into your TACL program. The syntax closely resembles interactive syntax. The INLINE facility provides the flexibility of an interactive interface; you can read process output, examine it, and make decisions about further commands. The INLINE facility allows you to switch output variables during the operation of your TACL program.
Initiating and Communicating With Processes Using the INLINE Facility To retrieve the current settings of the INLINE variables, expand the variables (using square brackets) or use the ENV command. The default value for #INLINEPREFIX is NULL. Generating Input To define the inline prefix, use the #INLINEPREFIX built-in variable or the INLPREFIX command. The following command sets the prefix to +: #SET #INLINEPREFIX + When TACL passes a prefixed line to a process, it first removes the prefix and the space.
Initiating and Communicating With Processes Using the INLINE Facility Figure 5-1.
Initiating and Communicating With Processes Using the INLINE Facility Processing and Displaying Messages The commands and variables in Table 5-3 control the display of process input and output and the capture of process output. To retrieve the setting of a built-in variable, expand the variable or use the associated command. You can set these values at any time while communicating with an INLINE process. Table 5-3.
Initiating and Communicating With Processes Using the INLINE Facility Use the routine in Figure 5-3, inline_fup_log, to interact with FUP and send output to a variable, log, for FUP output. The routine displays the entire output variable at the end. The routine accepts two file name arguments and retrieves information about each file. To use this routine, load the associated file and enter: inline_fup_log file1 file2 Figure 5-3.
Initiating and Communicating With Processes Using the INLINE Facility To control the output displayed by TACL, use the INLOUT command. To inhibit terminal output from the INLINE_FUP_LOG routine in Figure 5-3, add an #INLINEOUT call as shown in Figure 5-4. The syntax is: inline_fup_log2 file1 file2 Figure 5-4.
Initiating and Communicating With Processes Using the INLINE Facility The macro displays the PERUSE banner and spooled jobs; it then deletes the jobs and exits. Figure 5-5.
Initiating and Communicating With Processes Using the INLINE Facility The following code stops an INLINE process as part of the _BREAK portion of an exception handler: |_BREAK| #OUTPUT BREAK was pressed...terminating processing #PUSH x #SET x [#INLINEPROCESS] == get the INLINE process name [#IF NOT [#EMPTYV x] |THEN| #INLINEEOF ] #POP x #RESET FRAMES #RETURN Limitations of the INLINE Facility Not all processes can interface with the INLINE facility.
Initiating and Communicating With Processes Using INV and OUTV Using INV and OUTV The INV and OUTV options for the RUN command and the #NEWPROCESS built-in function allow you to use variables in place of IN and OUT files. To use INV or OUTV, your TACL process must be a named process. You cannot use IN and INV together for the same process; nor can you use OUT and OUTV together.
Initiating and Communicating With Processes Using INV and OUTV Table 5-4 lists the functions and options that support communication through INV and OUTV. You can request waited or nowaited communication. Table 5-4. Functions and Options Used With INV and OUTV TACL Command or Function Description RUN or #NEWPROCESS with INV and OUTV variables specified #APPEND(V) to INV variable #EXTRACT(V) from OUTV variable #WAIT Starts a process.
Initiating and Communicating With Processes Using INV and OUTV Generating Commands Because data transfer occurs through variables, be careful when moving data to and from the variables. For example, when a process is running in the nowait mode, it is possible to attempt an operation before the preceding operation has finished. Caution Data can be unexpectedly lost or duplicated during data transfer. To avoid lost or duplicated data, follow these guidelines. Use #APPEND or #APPENDV to manage IN variables.
Initiating and Communicating With Processes Using INV and OUTV Use the macro in Figure 5-7, fupin, to communicate with FUP using OUTV and a static INV. Figure 5-7. Communicating With FUP Using INV and OUTV ?SECTION fupin MACRO #FRAME PUSH in_variable PUSH out_variable == Create an IN variable == Create an OUT variable == Place a FUP command into the IN variable #SET in_variable INFO STEIN.
Initiating and Communicating With Processes Using INV and OUTV Use the macro in Figure 5-8, fup2, to modify a FUP operation so that user requests and FUP responses are recorded in a log file. The syntax is: fup2 fup-command where fup-command is a valid FUP command. The macro logs the request, the time of the request, and the FUP output to a file called LOGFILE. The macro displays the contents of LOGFILE before exiting. Figure 5-8.
Initiating and Communicating With Processes Using INV and OUTV Use the macro in Figure 5-9, show_spooler_jobs, to interact with the PERUSE utility and display a list of jobs without PERUSE banner lines. To use this macro, load the associated file and enter: show_spooler_jobs Figure 5-9.
Initiating and Communicating With Processes Using INV and OUTV Stopping a Process That uses INV and OUTV A process that uses INV and OUTV remains in existence until one of the following conditions occurs: The originating process sends an exit message to the process. The exit message can be defined by the process (such as EXIT for FUP). Some processes accept an end-of-file indicator as a termination request.
Initiating and Communicating With Processes Using $RECEIVE Using $RECEIVE To establish your TACL program as a requester process, follow these steps: 1. If the process does not already exist, start the process as appropriate. 2. To open the process, issue a #REQUESTER READ call. 3. To send a message, append data to the prompt variable. Unlike communication to a disk file (described in Section 4, “Accessing Files”), TACL issues a WRITEREAD operation and sends the prompt data to the process or device.
Initiating and Communicating With Processes Using $RECEIVE For nowaited communication, TACL sends the WRITEREAD and continues executing code. Each time you append a line to prompt_var, the TACL process reads a record from $T1 and appends it to read_var. To open a running process and specify nowaited communication, issue a #REQUESTER READ call without the WAIT option.
Initiating and Communicating With Processes Using $RECEIVE Figure 5-10. Sending Messages to a Terminal (Page 2 of 3) |_BREAK| #OUTPUT Send Terminated - Break Pressed #UNFRAME #RETURN ] {End CASE} [#DEF L25 STRUCT == Set address to line 25 BEGIN BYTE BYTE (0:1) VALUE 27 111 ; CHAR CHAR (0:1) REDEFINES BYTE ; END; ] [#DEF output_help_text TEXT |BODY| #OUTPUT/COLUMN 1/ This routine sends a message to line 25 & of a terminal.
Initiating and Communicating With Processes Using $RECEIVE Figure 5-10. Sending Messages to a Terminal (Page 3 of 3) |OTHERWISE| == The user did not supply a device name. Display help == text. output_help_text #UNFRAME #RETURN ] == end of outer #CASE == Obtain the current time == Note: the underscores act as placeholders for unwanted == text.
Initiating and Communicating With Processes Using $RECEIVE Testing Server Programs You can use TACL to test server programs. One way to do this is to perform the following steps: 1. Define a request STRUCT and a reply STRUCT. 2. Verify that the server process is running. 3. Open the server using #REQUESTER with the READ option. 4. Loop and prompt for request type; use #CASE enclosures to issue specific test requests.
Initiating and Communicating With Processes Using $RECEIVE Figure 5-11.
Initiating and Communicating With Processes Using $RECEIVE Figure 5-11. Creating CMON Messages (Page 3 of 4) STRUCT run_info REDEFINES replytext; BEGIN FNAME progname; INT priority; INT processor; END; END; ?SECTION talk_to_cmon ROUTINE == This routine accepts the names of two STRUCTs as its == arguments. The first has been set by the caller to the == message to send to CMON and the second is set by this == routine to the response from CMON.
Initiating and Communicating With Processes Using $RECEIVE Figure 5-11.
Initiating and Communicating With Processes Using #SERVER Stopping a Process That Communicates Using $RECEIVE Your ability to stop this type of process depends on how the process started and your access capabilities. The process might stop if one of the following occurs: The process finishes its work and stops its own execution. The originating process terminates. The originating process sends an end-of-file or other end signal (for example, exit for FUP).
Initiating and Communicating With Processes Using #SERVER Sending Commands When your TACL program has a server path, other processes can open it and issue WRITEREAD operations. TACL receives a prompt; your TACL process can then write to the other process. This code is exactly the same as that used with #REQUESTER in “Using $RECEIVE,” earlier in this section. Use the macro in Figure 5-12, serv, to communicate with a FUP process.
Initiating and Communicating With Processes Using Define Process Limitations on the Use of #SERVER TACL supports only one active READ at a time from each server path. If more than one process sends a READ or WRITEREAD to a server path, TACL process the first such request that arrives and returns a file system error 28 to each of the other processes. For additional limitations, see the TACL Reference Manual.
Initiating and Communicating With Processes Processing NetBatch Jobs and Completion Codes Processing Depending on how you run a process and how the process handles termination, TACL Completion can access several types of completion information: Information TACL supports a STATUS option that stores an indication of why the process terminated. The possible indications are STOP, ABEND, CPU (CPU failure), and NET (network failure). If the process specifies a completion code, you can access the completion code.
Initiating and Communicating With Processes Processing NetBatch Jobs and Completion Codes If you incur a syntax error while trying to start a process, TACL sets MESSAGECODE to 0, COMPLETIONCODE to 4, and TERMINATIONINFO to 0. If a NEWPROCESS failure occurs while you are trying to start a process, TACL sets MESSAGECODE to 0, COMPLETIONCODE to 4, and TERMINATIONINFO to the NEWPROCESS error code. If you successfully start a process, TACL sets MESSAGECODE to 0, COMPLETIONCODE to 0, and TERMINATIONINFO to 0.
Initiating and Communicating With Processes Processing NetBatch Jobs and Completion Codes Figure 5-13. Checking Completion Codes (Page 2 of 2) == Check the completion code; if an error occurred, display == it and exit [#IF [:_COMPLETION:COMPLETIONCODE] <> 0 |THEN| #OUTPUT *** Error during preprocessing #OUTPUT Completion code = [:_COMPLETION:COMPLETIONCODE] #UNFRAME #RETURN ] == Compile and bind with COBOL85, again as a waited process PARAM BINSERV $SYSTEM.SYSTEM.BINSERV PARAM SYMSERV $SYSTEM.SYSTEM.
Initiating and Communicating With Processes Monitoring Job Status: ENQUIRY Monitoring Job Status: ENQUIRY Note The ENQUIRY facility allows you to acquire the last 22 lines written to the OUT file of a TACL process; it provides the same functionality as the NetBatch-Plus ENQUIRY screen. To access this information, you open the TACL process and send it an enquiry message (-22). TACL replies with the lines of text from its OUT buffer.
Initiating and Communicating With Processes Monitoring Job Status: ENQUIRY To run this routine, load the associated file and enter: enquiry TACL-process-name Figure 5-14.
Initiating and Communicating With Processes Monitoring Job Status: ENQUIRY Figure 5-14.
Initiating and Communicating With Processes Monitoring Job Status: ENQUIRY (This page left intentionally blank) 5–38 107365 Tandem Computers Incorporated
6 Running TACL as a Server Section 5, “Initiating and Communicating With Processes,” described how to generate requests and communicate with processes from within a TACL program. This section discusses a different perspective: how to provide access to a TACL process from other processes. There are two types of TACL servers: A generic TACL process that processes TACL commands and built-in functions such as WHO, ENV, CREATE, and #TIMESTAMP and returns results.
Running TACL as a Sever Running a TACL Process as a Server When operating as a server, TACL starts up, logs on under its process accessor ID, and processes input in the usual way. Sending Requests to a TACL Server A requesting TACL process sends requests as described in Section 5, “Initiating and Communicating With Processes.” Table 6-1 lists commands used to communicate with a server. Table 6-1.
Running TACL as a Server Running a TACL Process as a Server Figure 6-1.
Running TACL as a Sever Running a TACL Process as a Server Special Actions of the #INPUT(V) Built-In Function When TACL acts as a server, it can process statements from $RECEIVE or statements coded within the TACL process. Action of the #INPUT(V) built-in function depends on the origin of the #INPUT(V) call: When a server TACL process executes an #INPUT(V) built-in function as part of its own code, it reads from $RECEIVE, executes the text in that message, and replies with the results.
Running TACL as a Server Running TACL Code as a Server Running TACL Code To provide TACL code for use by a TACL server process, you must provide a link to a as a Server TACL process that is running your code. There are several ways to accomplish this, including: ASSIGN the TACLCSTM file to a TACL macro or routine that contains the code. Include access to the code from your TACLCSTM file. (When you start a TACL process, the process accesses your TACLCSTM file.
Running TACL as a Sever Using TACL as a Pathway Server Using TACL as a The code in this subsection creates a Pathway environment that includes one TCP and Pathway Server one TACL server.
Running TACL as a Server Using TACL as a Pathway Server Use the code in Figure 6-2 as a sample Pathway server. This file is known as TACLIN in the Pathway configuration file; if you use a different file name, modify the configuration file. Figure 6-2.
Running TACL as a Sever Using TACL as a Pathway Server Figure 6-2.
Running TACL as a Server Using TACL as a Pathway Server Figure 6-3 contains the Screen COBOL source code for the requester. This requester displays a screen and waits until the user presses the F1 key to send a request to TACL or SF16 to exit the program. If the user sends a request, the requester displays the response from TACL and waits until the user presses the F1 key to clear the message. The requester then prompts for input again.
Running TACL as a Sever Using TACL as a Pathway Server Figure 6-3. Screen COBOL Code That Accesses a TACL Server (Page 2 of 2) Procedure Division. 0-DEBUT. Display Base FRAME Perform 1-LOOP Until EXI Stop Run. 1-LOOP. Accept FRAME Until F1 Escape SF16 If Termination-Status = 1 * Then Send TOTACL To "TACL" Reply Code 0 Yields REPCOD TACL Display RESPONSE Accept Escape F1 Reset RESPONSE Clear Input Else Move 1 To FEOJ. * End-If The following commands start the Pathway environment.
Running TACL as a Server Using TACL as a Pathway Server The commands in Figure 6-4 configure the sample Pathway environment. This file is used as input when you start the Pathway environment. Note that the server program file is $SYSTEM.SYS01.TACL and the commands assign the TACLCSTM file to the TACLIN file. This example uses $DATA for the volume and TEST for subvolume; modify these entries to reflect appropriate volume and subvolume names on your system. Figure 6-4.
Running TACL as a Sever Using TACL as a Pathway Server To run this application, type the following: 12> O PWYOBEY (Pathway displays startup information here) 13> PATHCOM $TST =RUN TEST-TACL (Pathway displays the application screen. When finished, press SF16 instead of entering a request.) =SHUTDOWN, WAIT TCP TCP-1, STOPPED =EXIT 14> Press F1 after each response to return to input mode.
7 Using Programmatic Interfaces Previous sections have described how to send textual commands to processes and retrieve textual results.
Using Programmatic Interfaces Overview of SPI and EMS request for action.) EMS allows you to monitor the status of system and application components. EMS messages are a type of SPI message; to communicate with EMS, you use SPI and EMS procedures. The following diagram shows a sample flow of EMS messages from subsystems to management applications. An application can also retrieve messages without involvement of distributor processes.
Using Programmatic Interfaces Overview of SPI and EMS The buffer transports the tokens to and from the target subsystem. The following is a simplified diagram of an SPI message. Again, each token contains a token code and a token value: Header Data Portion Token Token Token ••• ••• SSID Command # Obj-Type # and so on 324 7 The ZSPI-TKN-COMMAND code and others listed previously are defined in files provided by Tandem (stored in ZSPIDEF and ZSPISEGF subvolumes).
Using Programmatic Interfaces Using SPI Using SPI The Subsystem Programmatic Interface (SPI) allows you to store tokenized commands in buffers, send them to Tandem subsystems (such as Pathway), and receive a buffer containing tokenized replies. TACL uses standard SPI type names and supports standard SPI data types. Before sending or receiving an SPI message, you must: Know the subsystem ID for the desired subsystem. Know the names of individual tokens of interest.
Using Programmatic Interfaces Using SPI TACL interacts with other processes as a server (through $RECEIVE) and as a requester (through the use of the #REQUESTER, #APPEND(V), and #EXTRACT(V) built-in functions). When using $RECEIVE, the IN and OUT files do not automatically provide an SPI interface, but can be made into an SPI interface by using an #INPUTV and #REPLYV loop protected by an exception handler. Defining an SPI Buffer SPI works with binary values.
Using Programmatic Interfaces Using SPI TANDEM.EMS.0 and TANDEM.43.1245 are examples of valid subsystem IDs for Tandem subsystems. The following considerations apply to the use of subsystem IDs in TACL: The null subsystem ID (all binary zeroes) is expressed as 0.0.0 in TACL. TACL performs automatic conversion between text and the internal format used by SPI for subsystem IDs. Your TACL function must specify the subsystem ID for each subsystem with which your application communicates.
Using Programmatic Interfaces Using SPI Table 7-2. SPI Token Data Types (Page 2 of 2) Token Data Type Name Value Type and Range ZSPI^TDT^SSCTL ZSPI^TDT^SSID 0 to 255 Subsystem owner, period, subsystem number, period, and version number. Must be put into, or obtained from, a STRUCT. Definition of the STRUCT provides rules for conversion between internal and external formats. Any valid subvolume name; missing fields are not defaulted.
Using Programmatic Interfaces Using SPI Token Codes In TACL, a token code is an integer, a numeric variable, or a two-word STRUCT. Token code definitions, as generated by DDL, are included in the TACL versions of the SPI and subsystem definition files.
Using Programmatic Interfaces Using SPI If the data type of a token is any other than those already listed, the token value is represented by a space-separated list m/n items, where m is the actual length of the token and n is the basic length of the token data type. If the actual token length is not evenly divisible by the basic data-type length, the last bytes cannot be set or seen. TACL shows each item in its usual external representation.
Using Programmatic Interfaces Using SPI Use the routine in Figure 7-2, dumplog, to retrieve the name of the current EMS log file using SPI. The example then calls EMSDIST to read the current log and display the message on the home terminal. To invoke this routine, load the associated file and enter: dumplog [time] Figure 7-2.
Using Programmatic Interfaces Using SPI Figure 7-2. Displaying the EMS Log (Page 2 of 2) == Send the request (the open was waited, so we do not need == to wait for the variable to become empty.) #APPENDV request spi_buf == Retrieve the results #EXTRACTV reply spi_buf [#IF NOT [#EMPTYV io_err] |THEN| #OUTPUT *** Error [io_err] sending to $0.#ZSPI #UNFRAME #RETURN ] == Close SPI #SET err [#REQUESTER CLOSE request] [#IF err |THEN| #OUTPUT *** Error [err] closing $0.
Using Programmatic Interfaces Using EMS The following session shows sample output: 17>dumplog 16:50 92-05-28 16:51:22 \SYS.003,000 TANDEM.MSGSYS.C20 000104 Receive Queue for CPU 3, PIN 50 Greater Than 10 LCBs 92-05-28 17:00:34 \SYS.004,013 TANDEM.EMS.C20 000165 LDEV 0056 CU %120 CSS SUBDEVICE ERROR, CIU SUBDEV #000003 F, M=%043200 STATUS %000005 To generate a request for EMS, see the following subsection, “Using EMS.
Using Programmatic Interfaces Using EMS You can find the necessary definitions in the ZSPIDEF subvolume; load them from within your TACL code or create and attach segment files (in the ZEMSSEGF subvolume) that contain the information. Follow these steps to generate an EMS event: Generating an EMS Event 1. Define a message buffer (#DEF) 2. Initialize the buffer (#EMSINIT) 3.
Using Programmatic Interfaces Using EMS Figure 7-3.
Using Programmatic Interfaces Using EMS Figure 7-3. Generating an EMS Event (Page 3 of 3) == Main logic ================================================== #SET collector $0 #SET action_id 0 == Open the Collector for WRITEREADs; $0 expects a WRITEREAD #SET evt_error [#REQUESTER /WAIT/ READ [collector] & req_error req_read req_prompt] == If open fails, display an error message. Otherwise send == an event message.
Using Programmatic Interfaces Using EMS (This page left intentionally blank) 7–16 107365 Tandem Computers Incorporated
8 Example of a System Management Program The use of TACL for system management purposes combines several tasks: Starting, stopping, and monitoring processes Communicating with processes Acting on responses Generating commands Handling errors and other exceptions This section contains an example of a system management program that checks the status of several system elements.
Example of a System Management Program Monitoring System Operation Figure 8-1.
Example of a System Management Program Monitoring System Operation Figure 8-1.
Example of a System Management Program Monitoring System Operation Figure 8-1. Monitoring System Status (Page 3 of 12) == For CPU status, -1 = up and 0 = down [#IF cpustatus |THEN| #OUTPUT [type] Processor [cpucounter] is up. |ELSE| #OUTPUT [Tcr][type] Processor [cpucounter] & is down.
Example of a System Management Program Monitoring System Operation Figure 8-1.
Example of a System Management Program Monitoring System Operation Figure 8-1. Monitoring System Status (Page 5 of 12) [#LOOP |WHILE| NOT [#EMPTYV dsapout2] |DO| #EXTRACTV dsapout2 line == data line #SET disk [#CHARGET line 1 FOR 8] == disk name #SET fragments [#CHARGET line 45 FOR 4] == fragment count [#IF fragments > [maxfragments] |THEN| #OUTPUT/hold/[Tcr][disk] #OUTPUT /COLUMN 13/ has [fragments] fragments.
Example of a System Management Program Monitoring System Operation Figure 8-1. Monitoring System Status (Page 6 of 12) ] == end def #OUTPUT == == == == == == --------------------------------------------------------Report on databases. (Insert database files that you want to monitor.) The format is: filename AcceptableIndexlevelNumber Example: LVL $SYSTEM.SYSTEM.
Example of a System Management Program Monitoring System Operation Figure 8-1. Monitoring System Status (Page 7 of 12) [#IF NOT deverror |THEN| #OUTPUT #OUTPUT All Spooler devices OK.
Example of a System Management Program Monitoring System Operation Figure 8-1. Monitoring System Status (Page 8 of 12) == Get the percent full for TMF audit trail files #OUTPUT [#LOOP |DO| #SET file [#FILENAMES/MAXIMUM 1, PREVIOUS [file]/$*.AUDIT.
Example of a System Management Program Monitoring System Operation Figure 8-1. Monitoring System Status (Page 9 of 12) [#IF NOT [#CHARFINDV scanline 6 "?"] |THEN| [#IF NOT [#CHARFINDV scanline 8 "-P"] AND NOT [#CHARFINDV scanline 8 "-M "] AND [#CHARFINDV scanline 18 " *"] |THEN| #OUTPUT [#CHARGET scanline 6 FOR 10] using & backup path.
Example of a System Management Program Monitoring System Operation Figure 8-1.
Example of a System Management Program Monitoring System Operation Figure 8-1. Monitoring System Status (Page 11 of 12) == --------------------------------------------------------== Check the status of other devices == --------------------------------------------------------#PUSH puplistdev scanline state device otherdevs #OUTPUT Checking status of other devices ...
Example of a System Management Program Monitoring System Operation Figure 8-1.
Example of a System Management Program Monitoring System Operation (This page left intentionally blank) 8–14 107365 Tandem Computers Incorporated
9 Syntax Summary The syntax diagrams summarized in this appendix are divided into five categories: The command interpreter set of commands and functions, supplied with TACL in the directory :UTILS:TACL The built-in functions and variables that constitute the TACL programming language The specialized forms of the #DEF function used to create and redefine structured variables (STRUCT declarations) The specialized forms of the #SET function used to assign values to TACL built-in variables The commands of the #
Syntax Summary :UTILS:TACL Commands and Functions CLEAR ALL ALL ASSIGN ALL PARAM ASSIGN logical-unit PARAM param-name COLUMNIZE list COMMENT [ comment-text ] _COMPAREV string-1 string-2 COMPUTE expression _CONTIME_TO_TEXT contime-list _CONTIME_TO_TEXT_DATE contime-list _CONTIME_TO_TEXT_TIME contime-list COPYDUMP [ / run-option [ , run-option ] … / ] source-file , dest-file COPYVAR variable-level-in variable-level-out CREATE file-name [ , extent-size ] CREATESEG file-name DEBUG [ [\node-
Syntax Summary :UTILS:TACL Commands and Functions FILES [ / OUT list-file / ] [ subvol-template [ [,] subvol-template ] … ] FILETOVAR file-name variable-level HELP HISTORY [ num ] HOME [ directory-name ] INFO [ / OUT list-file / ] DEFINE define-name-list [, DETAIL ] INITTERM INLECHO { OFF | ON } INLEOF INLOUT { OFF | ON } INLPREFIX [ prefix ] INLTO [ variable-level ] JOIN variable-level KEEP [ / LIST / ] num variable [ variable ] … KEYS LIGHTS [ / run-option [, run-option ] ...
Syntax Summary :UTILS:TACL Commands and Functions PAUSE [ [\node-name.]{$process-name | cpu,pin } ] PMSEARCH subvol-spec [ [,] subvol-spec ] … PMSG { ON | OFF } POP variable [ [,] variable ] … PPD [ / OUT list-file / ] [ [\node-name.
Syntax Summary :UTILS:TACL Commands and Functions SHOW [ / OUT list-file / ] DEFINE [ attribute-name | * ] SINK [ text ] STATUS [ / OUT list-file / ] [ range ] [ , condition ] … [ , DETAIL ] [ , STOP ] STOP [ [\node-name.]{$process-name | cpu,pin } ] SUSPEND [ [\node-name.]{$process-name | cpu,pin } ] SWITCH SYSTEM [ \node-name ] SYSTIMES [\node-name.
Syntax Summary Built-In Functions and Variables Built-In Functions and Variables ! num -num text ? num -num text The following summarizes the syntax of the built-in functions and variables used for programming in TACL: #ABEND [ / option [ , option ] … / ] [ [\node-name.]{$process-name | cpu,pin } [ text ] ] #ABORTTRANSACTION #ACTIVATEPROCESS [ [\node-name.]{$process-name | cpu,pin} ] #ADDDSTTRANSITION low-gmt high-gmt offset #ALTERPRIORITY [ [\node-name.
Syntax Summary Built-In Functions and Variables #CHARFIND [ / EXACT / ] variable-level char-addr text #CHARFINDR [ / EXACT / ] variable-level char-addr text #CHARFINDRV [ / EXACT / ] variable-level char-addr string #CHARFINDV [ / EXACT / ] string-1 char-addr string-2 TO˚char-addr-2 ] [ FOR˚char-count #CHARGETV var-1 var-2 char-addr-1 TO˚char-addr-2 ] [ FOR˚char-count #CHARGET variable-level char-addr-1 #CHARINS string char-addr text #CHARINSV variable-level char-addr string #COLDLOADTACL #COMPAREV string
Syntax Summary Built-In Functions and Variables #DEFINEDELETE define-name #DEFINEDELETEALL #DEFINEINFO define-name #DEFINEMODE #DEFINENAMES define-template #DEFINENEXTNAME [ define-name ] #DEFINEREADATTR _ cursor˚˚mode { define-name }{ attribute-name } #DEFINERESTORE [ / option [ , option ] … / ] buffer #DEFINERESTOREWORK #DEFINESAVE [ / WORK / ] define-name buffer #DEFINESAVEWORK #DEFINESETATTR attribute-name [ attribute-value ] #DEFINESETLIKE define-name #DEFINEVALIDATEWORK #DELAY csecs #DELTA [ / COMM
Syntax Summary Built-In Functions and Variables #ENDTRANSACTION #EOF variable-level #ERRORNUMBERS #ERRORTEXT / option [ option ] … / #EXCEPTION #EXIT #EXTRACT variable-level #EXTRACTV from-variable-level to-variable-level #FILEGETLOCKINFO [ / option / ] fvname control lockdesc participants #FILEINFO / option [ , option ] … / file-name #FILENAMES [ / option [ , option ] … / ] [ file-name-template ] #FILTER [ exception [ exception ] … ] #FRAME #GETCONFIGURATION / option [ , option ] … / #GETPROCESSSTATE [
Syntax Summary Built-In Functions and Variables #INPUTEOF #INPUTV [ / option [ , option ] … / ] variable-level prompt-string #INSPECT #INTERACTIVE [ / CURRENT / ] #INTERPRETJULIANDAYNO julian-day-num #INTERPRETTIMESTAMP four-word-timestamp #INTERPRETTRANSID transid #JULIANTIMESTAMP [ type [ tuid-request ] ] #KEEP num variable #KEYS #LINEADDR variable-level char-addr #LINEBREAK variable-level line-addr char-offset #LINECOUNT variable-level #LINEDEL variable-level line-addr-1 line-count TO line-addr-2 ] [
Syntax Summary Built-In Functions and Variables #MOM #MORE #MYGMOM #MYPID #MYSYSTEM #MYTERM #NEWPROCESS program-file [ / option [, option ]… / ] [ param-set ] #NEXTFILENAME [ file-name ] #OPENINFO / option [ , option ] / { file-name | device-name } tag #OUT #OUTFORMAT #OUTPUT [ / option [ , option ] … / ] [ text ] #OUTPUTV [ / option [ , option ] … / ] string #PARAM [ param-name ] #PAUSE [ [\node-name.
Syntax Summary Built-In Functions and Variables #RENAME old-file-name new-file-name #REPLY [ text ] #REPLYPREFIX #REPLYV string #REQUESTER [ / option [ , option ] / ] CLOSE variable-level READ file-name˚error-var˚read-var˚prompt-var WRITE file-name˚error-var˚write-var #RESET option [ option ] … #REST #RESULT [ text ] #RETURN #ROUTINENAME #SEGMENT [ / USED / ] #SEGMENTCONVERT / FORMAT { a | b } / old-file-name new-file-name #SEGMENTINFO / option [ , option ] / [ segment-id ] #SEGMENTVERSION fi
Syntax Summary Built-In Functions and Variables #SORT [ / option / ] [ text ] #SPIFORMATCLOSE #SSGET [ / option [ , option ] … / ] buffer-var get-op #SSGETV [ / option [ , option ] … / ] buffer-var get-op result-var #SSINIT [ / TYPE 0 / ] buffer-var ssid command [ / type-0-option [ , type-0-option ] … / ] #SSMOVE [ / option [ , option ] … / ] source-var dest-var token-id #SSNULL token-map struct #SSPUT [ / option [ , option ] … / ] buffer-var token-id [ token-value [ token-value ] … ] #SSPUTV [ / option [
Syntax Summary Built-In Functions and Variables #WAIT variable-level [ variable-level ] … #WAKEUP #WIDTH 9–14 107365 Tandem Computers Incorporated
Syntax Summary STRUCT Declarations STRUCT Declarations The following summarizes the forms of the #DEF function used to create and redefine structured variables: #DEF variable STRUCT BEGIN declaration [ declaration ] … END ; LIKE structure-identifier ; { } type identifier [ VALUE initial-value ] ; type identifier ( lower-bound : upper-bound ) [ VALUE initial-value ] ; STRUCT identifier [ ( lower-bound : upper-bound ) ] ; BEGIN declaration [ declaration ] … END ; LIKE structure-identifier ; { } FILLER
Syntax Summary #SET Summary #SET Summary The following summarizes the syntax of the #SET function when it is used to assign values to built-in variables. SET VARIABLE commands used for the same purpose have the same syntax.
Syntax Summary #DELTA Command Summary #SET #WAKEUP num #SET #WIDTH num #DELTA Command Table 9-1 summarizes the syntax of the #DELTA character processor commands. Summary Table 9-1.
Syntax Summary #DELTA Command Summary Table 9-1. #DELTA Commands (Page 2 of 2) 9–18 Command Description xP y,xP Qvar$ xStext$ x:Stext$ xT y,xT @Tvar$ :Ttext$ xUvar$ y,xUvar$ xV x:V xXvar$ y,xXvar$ xY Z \ x\ ^\ ? :? ' , $ .
Appendix A Supplemental Information for D-Series Systems The D-series operating system supports expanded numbers of processes and devices.
Supplemental Information for D-Series Systems Communicating With a $CMON Process New process identifiers. The range of values for process identification numbers (PINs) has been expanded. The D-series process file name, a variable-length string, replaces the C-series process file name. The process handle is a new ten-word value that replaces the C-series four-word process identifier. TACL supports a new field type for STRUCT variables, called PHANDLE. New system procedures.
Supplemental Information for D-Series Systems Processing Completion Information The ALTERPRIORITY message is defined as follows: STRUCT altpri^msg; BEGIN INT msgcode; INT userid; INT cipri; INT INT INT ciinfile [0:11]; cioutfile [0:11]; crtpid [0:3]; INT INT INT END; progname [0:11]; priority; phandle [0:9]; == == == == == == == == -56 user altering the priority command interpreter initial priority command interpreter IN file command interpreter OUT file process identifier of target process == progra
Supplemental Information for D-Series Systems Processing Completion Information TACLSEGF (supplied by Tandem) defines :_COMPLETION^PROCDEATH as follows: [#DEF :_completion^procdeath STRUCT BEGIN INT z^msgnumber; STRUCT z^base REDEFINES z^msgnumber; BEGIN CHAR byte(0:1); END; PHANDLE z^process handle; INT4 z^cputime; INT z^jobin; INT z^completion^code; INT z^termination^code; INT z^killer^craid; REDEFINES z^termination^code; SSID z^subsystem; PHANDLE z^killer; INT z^termtext^len; STRUCT z^procname; BEGIN IN
Supplemental Information for D-Series Systems Communicating With Programmatic Interfaces You can access the process name as follows: PUSH proc^offset proc^len proc^lwa procname SET VARIABLE proc^len & [:_completion^procdeath:z^procname:zlen] [#IF proc^len > 0 |THEN| SET VARIABLE proc^offset & [:_completion^procdeath:z^procname:zoffset] SET VARIABLE proc^lwa [#compute proc^offset+proc^len-1] SET VARIABLE procname & [:_completion^procdeath:z^procname^:byte([proc^offset]:& [proc^lwa])] ] You can access the te
Supplemental Information for D-Series Systems Communicating With Programmatic Interfaces ten integers, each ranging from 0 to 65535. A null process handle consists of ten integers, each of which has the value 65535. A new built-in function, #CONVERTPHANDLE, converts process file identifiers to process handles and process handles back to process descriptors. A new built-in function, #SPIFORMATCLOSE, closes the template file defined in =_EMS_TEMPLATES so that you can open a new template file.
Glossary access mode. A file attribute that determines what operations you can perform on the file, like reading and writing. alias. An alternative name for a given function. ancestor. The process that is notified when a named process or process pair is deleted. The ancestor is usually the process that created the named process or process pair. argument. A parameter that you specify when you invoke a macro or routine. array data item.
Glossary completion code. A value used to return information about a process to its ancestor process when the process is deleted. This value is returned in the process deletion message, system message -101. condition code. A status returned by some file-system procedure calls to indicate whether the call was successful. A condition-code-greater-than (CCG) indicates a warning, a condition-code-less-than (CCL) indicates an error, and a condition-codeequal (=) indicates successful execution.
Glossary enclosure. A unit composed of one or more labels, such as |THEN| or |DO|, and the text associated with each label. Enclosures are found only in the TACL built-in functions #DEF, #IF, #CASE, and #LOOP, which are enclosed in brackets to provide boundaries for their enclosures. TACL defers execution of text that is associated with labels until it determines the correct label to use. Enscribe. A database record management system. exception.
Glossary file system. A set of operating system procedures and data structures that provides for communication between a process and a file, which can be a disk file, a device other than a disk, or another process. FILLER byte. A portion of a STRUCT that is used only to maintain the alignment of adjacent STRUCT items. frame. A local environment managed by the #FRAME, #UNFRAME, and #RESET built-in functions. fully qualified file name. The complete name of a file, including the node name.
Glossary job ancestor. A process that is notified when a process that is part of a job is deleted. The job ancestor of a process is the process that created the job to which the process belongs. Julian timestamp. The number of microseconds since midnight January 1, 4713 B.C. at the Greenwich meridian. LCT. See local civil time. LDEV. See logical device. level. One element of the set of values stored in a stack and known as a variable. local civil time (LCT).
Glossary node. A system of one or more processor modules. Typically, a node is linked with other nodes to form a network. node name. The portion of a file name that identifies the system through which the file can be accessed. nonretryable error. An error condition returned by the file system that cannot be recovered by retrying the operation even after operator intervention. Contrast with retryable error. NonStop SQL.
Glossary process access ID (PAID). A user ID used to determine whether a process can make requests to the system; for example, to open a file, stop another process, and so on. The process access ID is usually the same as the creator access ID, but it can be different; the owner of the corresponding object file can set the object file security such that it runs with a process access ID equal to the user ID of the file owner, rather than the creator of the process. Contrast with creator access ID.
Glossary request. A message formatted and sent to a server by a requester. Requests also include status messages such as CPU up and CPU down messages, which are placed on the intended recipient’s process message queue ($RECEIVE file) by the operating system. Contrast with reply. requester. A process that initiates interprocess communication by sending a request to another process. Contrast with server. response. See reply. retryable error.
Glossary subvolume. A group of files stored on disk. These files all have the same subvolume name, but each has a different file ID. A subvolume name consist of one to eight alphanumeric characters, the first of which must be alphabetic. An example of a subvolume name is $DATA.INFO. An example of a file name in this subvolume is $DATA.INFO.RESULTS. swapping. The process of copying information between physical memory and disk storage. system process.
Glossary user process. A process whose primary purpose is to solve a user’s problem. A user process is not essential to the availability of a processor module and is created only when the user explicitly creates it. Contrast with system process. variable. A named quantity that can assume any of a given set of values. variable level. A portion of a variable that can be individually addressed.
Index A Accessing structured data Address, character 2-11 ALIAS variables 2-24 Argrec example 3-17 Arguments alternatives (such as NUMBER and STRING) 3-3 parsing for a caller 3-11 processing a space-separated list 3-8 processing file names 3-7 processing variables 3-8 to routines 3-1 ASSIGN command 5-3 ATTRIBUTENAME argument alternative 3-3 B BREAK, for debugging 2-32 Bubble example 2-3 Built-in functions for data manipulation 2-16 for EMS 7-12 for string manipulation 2-10 #APPEND 2-3, 2-17, 4-2, 5-1, 5-5,
Index Built-in functions (continued) #EMSADDSUBJECT(V) 7-12 #EMSGET(V) 7-12 #EMSINIT(V) 7-12 #EMSTEXT(V) 7-12 #EOF 5-16, 5-19 #ERRORTEXT 3-22, 3-27 #EXCEPTION 3-19, 3-24, 3-27, 3-32 #EXTRACT 2-15, 4-2, 5-1, 5-5, 5-16 #EXTRACT(V) 7-3 #EXTRACTV 2-28, 4-11, 5-31, 5-37 #FILEINFO 2-5, 2-34, 4-16, 8-4, 8-8 #FILENAMES 8-8 #FILTER 3-22, 3-25, 3-32 #FRAME 2-3, 2-8, 5-4 #IF 2-4, 2-8 #INFORMAT 2-23 #INLINEECHO 5-7 #INLINEEOF 5-7 #INLINEOUT 5-9, 5-11 #INLINEPREFIX 5-7 #INLINETO 5-9 #INPUT 2-17, 3-22, 3-32 #INPUT(V) 7-
Index Built-in functions (continued) #PROCESSINFO 8-3 #PROCESSORSTATUS 8-3 #PROCESSORTYPE 8-3 #PROMPT 2-29 #PURGE 2-5, 4-16 #PUSH 2-3, 2-8 #RAISE 3-29, 3-32 #REPLYPREFIX 6-5, 6-8 #REPLYV 6-5, 7-5 #REQUESTER 2-17, 4-2, 5-1, 5-5, 5-21, 5-25, 5-37, 6-2, 7-3, 7-15 #RESET 3-17, 3-21, 3-27, 3-32 #RESET FRAMES 2-8 #REST 3-5, 3-16 #RESULT 3-8, 3-15 #RETURN 3-17 #ROUTINENAME 2-7, 3-9, 3-16 #SERVER 5-1, 5-31, 6-5, 7-3 #SET 2-3, 2-16 #SETMANY 2-23, 3-27 #SHIFTSTRING 2-5, 3-16, 4-16, 6-2 #SSGET(V) 7-5 #SSINIT 7-5 #SSN
Index C Caller example 3-16 Call_getargs example 3-11 Character address 2-11 CHARACTERS argument alternative 3-3, 3-6 Checkfiles example 2-4 Ckup example 8-1 CLOSEPAREN argument alternative 3-3 CMON process 5-25 COMMA argument alternative 3-3, 3-12 Commands for debugging TACL programs 2-32 ASSIGN 5-3 FILETOVAR 2-16 for data manipulation 2-16 for global editing 2-13 INLPREFIX 5-7 PARAM 5-3 RUN 5-2, 6-1 SETPROMPT 2-29 SINK 2-30 SYSTEM 2-29 TIME 8-13 VCHANGE 2-14 VDELETE 5-19 VFIND 2-14 VINSERT 2-13 VLIST 2-1
Index D Data types 2-17 determining 3-5 Date, textual 2-17 Dayofweek example 2-22 Debugging sample session 2-33 _DEBUGGER 2-32/35 Defaultvars example 2-8 DEFINE 5-4 Define Process (DP) facility 5-31 Display example 2-25 Displayinfo example 2-27 Distributed System Management See DSM DSM and TACL 7-1 Dumplog example 7-10 E Editing commands 2-13 Editing variables 2-11 Emptyspool example 5-11 EMS and TACL 7-1/15 calling EMSDIST 7-12 flags 7-13 generating an event 7-13 log, displaying contents of 7-10 Enquiry e
Index Examples (continued) caller 3-16 checkfiles 2-4 ckup 8-1 command_processor 3-21 copier 2-2 copy 4-10 dayofweek 2-22 defaultvars 2-8 display 2-25 displayinfo 2-27 dumplog 7-10 emptyspool 5-11 enquiry 5-35 fcomp 4-12 fup2 5-18 fupin 5-17 getdates 2-23 inline_fup 5-7 inline_fup_log 5-10 inline_fup_log2 5-11 lock 2-28 menu 2-30 monitoring a system 8-1 nowaited_read 4-4 nowaited_write 4-9 Pathway 6-6 purgefiles 3-22 report_shell 3-15 restricted_caller 3-30 restricted_cmd_processor 3-24 restrictive_command
Index Examples (continued) TACL as a Pathway server 6-6 taclevent 7-13 tacllist 4-16 tedsave 2-33 volname 2-12 volnames 2-15 waited_read 4-3 waited_write 4-7 Exception handlers description of elements of 3-19 keep type 3-24 release type 3-20 types 3-19 Exception handlers, description of 3-18 Exception, definition of 3-18 EXCLUSION option for #REQUESTER built-in function 4-2 F Fcomp example 4-12 FILENAME argument alternative 3-3 Files opening 4-1 reading from 4-2/5 writing to 4-6/9 FILETOVAR command 2-16 Fu
Index I IN file 5-1, 5-3 setting to $RECEIVE 6-3 INLINE facility description of 5-1, 5-6/13 handling _BREAK exception 5-13 INLINE run option 5-6 limitations 5-13 stopping processes 5-13 Inline_fup example 5-7 Inline_fup_log example 5-10 Inline_fup_log2 example 5-11 INLPREFIX command 5-7 INV option limitations 5-20 INV option (RUN and NEWPROCESS), NEWPROCESS) INV variable 5-1 J Julian day number 2-17 Julian timestamp 2-17 K KEYWORD argument alternative 3-3 L Local civil time (LCT) 2-17 Local daylight time (
Index O OPENPAREN argument alternative 3-3 OTHERWISE alternative for ARGUMENT built-in function OTHERWISE argument alternative 3-6 OUT file 5-1, 5-3 reading from 5-35 saving 2-8 setting to $RECEIVE 6-4 OUTV option limitations 5-20 OUTV option (RUN and NEWPROCESS), NEWPROCESS) OUTV run option 2-15 P PARAM command 5-3 Pathway example 6-6 Process handles A-5 Processes initiating and communicating with 5-1 initiating and communicating with' 5-37 stopping 5-20 PROCESSNAME argument alternative 3-3 Programs debug
Index Routines exception handlers combining types 3-30 keep type 3-24 release type 3-20 “keep” type 3-19 “release” type 3-19 exception handlers for 3-18, 3-32 exiting 3-17 overview 2-1 RUN command 5-2, 6-1 INV option 5-14 OUTV option 5-14 Run options INLINE 5-6 STATUS 5-16 Runsrv example 6-3 S Same_ssid example 7-9 Script example 5-8 Send example 5-22 Serv example 5-30 Server programs testing 5-25 Server, TACL as a 6-1/12 SETPROMPT Command 2-29 Show_spooler_jobs example 5-19 SINK command 2-30 SLASH argumen
Index STATUS option (RUN and NEWPROCESS) STATUS option (RUN) 5-16 STATUS variable 5-20 STRING argument alternative 3-3 String manipulation, built-in functions for 2-10 Strio example 5-25 STRUCT variable description of 2-9 specifying escape sequences for terminals 2-25 using with D-series software A-5 STRUCT variables using with SPI 7-5 Structures accessing structured data 5-25 examples 5-25 SUBSYSTEM argument alternative 3-3 Subsystem ID 7-5 Subsystem Programmatic Interface See SPI Syntax summary built-in
Index Templates example 3-22 Terminals sending escape sequences to 2-25 TIME command 8-13 Timestamps 2-17 TOKEN argument alternative 3-3 Token code 7-3 Token code (SPI) 7-8 Token map (SPI) 7-8 U USER argument alternative 3-3 V Variable levels, using 2-3 variable INV 5-1 OUTV 5-1 :_COMPLETION 5-32 VARIABLE argument alternative 3-8 Variables creating modifying 2-9 types 2-1 Variables, editing 2-11 VCHANGE command 2-14 VDELETE command 5-19 VFIND command 2-14 VINSERT command 2-13 VLIST command 2-14 Volname exa
Index WORDLIST argument alternative 3-5 Writing to a file nowaited 4-8 waited 4-6 Z ZSPIDEF files 7-4, 7-5 ZSPISEGF files 7-4 Special characters #built-in funcion See Built-in functions #built-in variable See Built-in variables $CMON 5-25, A-2 $RECEIVE 5-1, 5-5, 7-3 and TACL as a server 6-1 using for process communication 5-21/29 %0%, using to call a macro recursively 2-7 :_COMPLETION’ variable; 5-32 _COMPAREV command 2-5 _COMPLETION^PROCDEATH variable A-3 _CONTIME_TO_TEXT_DATE command 8-3 _DEBUGGER comman
