Westi

<body topmargin=0 leftmargin=0 marginheight=0 marginwidth=0> <table cellpadding=0 cellspacing=0 border=0><tr> <td valign="top" colspan=2 height=110 BGCOLOR="#660000" TEXT="#F7F7FF" bgproperties="fixed" background="04900840dvldxa.png"> <div> <B>RJM Systems, Inc.</B><FONT SIZE="1" COLOR="#FFFFCC" FACE="Arial" ><B>     |     </B></FONT><FONT SIZE="3" COLOR="#FFFFCC" FACE="Arial" ><A HREF="index.htm" TARGET="_top" TITLE="RJM Systems, Inc."><U><B>home</B></U></A></FONT></div> <div> <A HREF="id20.htm" TARGET="_top" TITLE="SourceBank/VM"><U><B>SourceBank/VM</B></U></A><B>   |   </B><A HREF="id21.htm" TARGET="_top" TITLE="Scepter"><U><B>Scepter</B></U></A><B>   |   </B><A HREF="id24.htm" TARGET="_top" TITLE="Visual Aids"><U><B>Visual Aids</B></U></A><B>   |   </B><B>Westi</B></div> <div> </div> </td> </tr><tr> <td valign="top" width=125 BGCOLOR="#AAAAAA" TEXT="#080000" background="04311c00euxmic.png"> <bR> </td> <td valign="top" height=370 BGCOLOR="#FFFBF0" TEXT="#080000"> <div> Westi</div> <bR> <div> <B>SYSTEM DESCRIPTION</B>.</div> <bR> <div> The RJM Systems Teleprocessing Interface (WESTI) is a comprehensive teleprocessing monitor designed to operate with IBM 9370, 43xx, 30xx, 370, ESA 9000 or compatible computers running a VSE/AF, VSE/SP, VSE/ESA or replacement environment. The system eases installation of terminal networks by providing the functions required by any on-line system.</div> <bR> <div> The design intent of the WESTI System is to provide a variety of common functions that can be easily tailored and combined to meet the specific needs of an individual installation (the resulting monitor contains only the code necessary to support a particular environment). By eliminating the need to become involved in the design and coding of monitor routines, user efforts are devoted to writing and testing application programs, thus reducing the time needed to get the system on-line and productive.</div> <bR> <div> The system consists of a generative monitor (assembled from supplied macros and selected relocatable modules), external macros and/or calls used in writing application programs, utility programs used to format system work files and to prepare display formats, the necessary control applications, and the supporting documentation.</div> <bR> <div> Functionally, the WESTI System nucleus possesses many attributes that are normally associated with an operating system supervisor. Central to monitor operation is the dispatcher task whose job is the scheduling of all activity within the system. The primary purpose of the dispatcher is to allocate time among the various system and user tasks and relinquish control to the operating system supervisor only when there are no dispatchable tasks. Network management, terminal-to-application device assignment, application program scheduling, resource allocation, and memory management are included as part of the basic monitor code. The monitor also provides the means of accomplishing  terminal input-output operations. Optionally, the monitor can contain a multi- entry interface for the file access methods DAM, SAM, ISAM, PSAM and VSAM, and many of the popular database management systems (DBMS). Application programs may also reference files and/or databases using techniques similar to those employed by batch partition programs. In situations where asynchronous access to special user routines is desired, the monitor contains a method to provide this type of support by employing the Multi-tasking Facility of the VSE Supervisor. See the section 'Program Description WOUDE  Function' for more details on this technique.</div> <bR> <div> Few restrictions are placed on the content of user application programs, in that they may be written in the Assembler, COBOL, PL/1, and/or RPG/II programming languages and access any type of file or database. They are therefore compatible with any file organization access method, and/or database management system. The monitor also contains a means of breaking large application programs into smaller segments where it is required to conserve memory space. A communications linkage between all segments is provided as a part of this segmentation process. The linkage between an application program and the monitor is such that an application may be run <U>multi-entry</U> (handle many terminals simultaneously), <U>single-entry</U> (handle only one terminal at a time) or <U>single-entry-multi-copy</U> (the monitor provides each terminal its own dynamically created copy of an application), depending on user need or preference. In addition, applications may be memory resident or may share a common execution area and be rolled in/out as required.</div> <bR> <div> New applications and terminals are added to an operational system in modular fashion with little impact on all previous programs. New terminals and applications are added simply by re-assembling the monitor program and re-linking the system. Since a prime design feature of the monitor is that any terminal should be able to access any application and any application should be able to service any number of terminals, new terminals and applications will automatically have access to the entire system.</div> <div> Security tests based on terminal type, name, and/or password are provided as an integral part of the supplied System Menu Control Application. Furthermore, this application is easily altered to include the unique security requirements of a particular installation. Additionally, security tests can be provided on an application by application basis by employing user written security checks and the monitor supplied SIGNOFF Function to deny  access.</div> <bR> <bR> <div>   <B>Data Base and File Interface </B>.</div> <bR> <div> A common need of application programs operating in an on-line environment is the ability to easily access the data contained in the various files or databases of the system. The WESTI System provides record access through the optional Data Base Interface and Access Method Controller facilities.</div> <bR> <div> The WESTI Data Base Interface Facility provides the ability for application programs to communicate with most of the Data Base Management Systems (DBMS) so that all data accesses can be overlapped with processing for other terminal devices. The Data Base Interface consists of generalized routines that enable WESTI to communicate with DBMS linked with the monitor or run as a 'Central Version' in a separate partition.</div> <bR> <div> The Access Method Controller (AMC) Facility provides a common facility for performing read/write operations on Direct Access (DA), Index Sequential Access Method (ISAM), Sequential Access Method (SAM) and Virtual Storage Access Method (VSAM) files. PSAM files may also be accessed if this product from Universal Software is being used in house as an access method. The Access Method Controller eliminates the programmer's need to become concerned with file access, deblocking, disk device type considerations, update protection, and return code considerations because all application data manipulation is accomplished at the record level. Systems programmers can make changes to the file structure without changing the applications that reference those files as long as the record layout doesn't change.</div> <bR> <div> In addition, the Access Method Controller is written in such a manner that all 'wait time' accrued during file access is returned to the monitor; therefore, the monitor can overlap file access requests with other terminal operations.</div> <bR> <bR> <div>     <B>DISKWORK Facility </B>.</div> <bR> <div> A common requirement of terminal systems is for a disk data management scheme suitable for data entry (keypunch replacement) applications or as a temporary data storage media. The DISKWORK Facility of the WESTI Monitor provides such a data management scheme.</div> <div> The DISKWORK Facility enables application programs to create, access, and update data record sets without being concerned with enqueuing schemes for data integrity in a multi-terminal environment. DISKWORK management routines will keep all data record sets unique within each DISKWORK File by not allowing multiple tasks to own or share the same data sets concurrently. Multiple tasks can operate on the same data set concurrently provided they declare their access to the data set to be of a read only nature.</div> <bR> <div> DISKWORK management routines optimize the utilization of disk space within each DISKWORK File by dynamically allocating and deallocating space to each task as required. Since each task's individual data sets are extended (more space made available) as records are added to the string, users need not become concerned with allocating a fixed area for each terminal's expected input. Processed data strings or temporary data sets that are no longer in use can be released (returned to the common pool) and made available for subsequent reuse by the system.</div> <bR> <div> Each data set created by a terminal attached to a DISKWORK application program is entry sequenced, that is, as new records are added to a task's data set(s), they are added at the end of the appropriate string. Within a given data set, all records are a fixed length specified by the user, but each given data set may have its own record length (record length is not fixed for the entire DISKWORK Facility).</div> <bR> <div> Once an application program gains access to a DISKWORK data set, either by initially creating the data set or by accessing a data set that was previously created, then the application program has complete freedom of movement within the string through the use of simple tape-like positioning commands. The position can be moved forward or backward to the end or the beginning of the string or forward or backward one record at a time. The program can also note a position contained within the string and return to that position when required. Additions to existing strings can be accomplished by simply forward positioning to the end of the string and writing the new records in the normal manner. Thus new records can be added to the end of the data string at any time and old records within the string can be reread and/or updated.</div> <bR> <div>  Data record strings that have been created by a WESTI on-line application program can be unloaded in a batch environment by an application program that uses the WESTI Batch DISKWORK module. The Batch DISKWORK Module communicates with the active WESTI System across partition boundaries in order to protect the integrity of the DISKWORK Data Structure should both the batch and on-line versions attempt to access the data structure at the same time.</div> <bR> <div> A DISKWORK batch utility is available to backup and restore WESTI DISKWORK  files containing user data sets as well as SCEPTER modules (SCEPTER modules are processed logically). This utility can either process entire DISKWORK files or individual modules and data sets from any disk device to any disk device. See the section 'Application Program Products' for more information on the  WESTI/SCEPTER DUMP/RESTORE Utility.</div> <bR> <div> The DISKWORK Facility has an automatic warm-start initialization, and so data left in the file(s) from previous program executions are retained. Additionally, this gives the user the ability to add records from a terminal to an already existing record string rather than creating a new data record string.</div> <bR> <bR> <div>    <B>Enqueuing Facility </B>.</div> <bR> <div> The optional Enqueuing Facility provided as part of the WESTI System allows application programs to schedule the use of serial resources in order to prevent multiple terminals from attempting to utilize the same resource or simultaneously access the same data file or record in situations where it is possible to alter the contents of that file or record. This function is automatically provided by the system for files which are under the control of the Access Method Controller.</div> <div>  Resources are identified symbolically by resource blocks which contain variable length key information. The longest resource key that can be used is established at monitor generation time. The length and content of this variable key provides a unique identity for the resource. Therefore it is possible to create a wide range of resource definitions. It is possible to identify as a resource a specific record within a file, or even specific fields within that record.</div> <bR> <div> All resources 'owned' by a terminal are defined in resource blocks contained in the Terminal-Data-Area allocated to the terminal. If any other terminal has already requested exclusive use of a matching resource block (same key length and contents) or the requesting terminal needs to obtain exclusive control of the resource, then the requesting terminal is informed that the resource is unavailable, which is equivalent to saying that some other terminal already owns the element defined by that key. If the enqueuing request is successful, then the application has obtained exclusive ownership of the resource until it is released. Resource ownership may also be requested on a shared basis. Any resource that is shared may be made available to other terminals willing to share it. The intent is to prevent acquisition of the resource by any terminal needing exclusive control while allowing concurrent usage by any other terminal willing to share.</div> <bR> <div>   Resources are released by means of application program dequeue function calls. Resources are also released anytime a terminal issues the function calls SIGNOFF-PAUSE, SIGNOFF-DEACT, SIGNOFF-LEAVE, or SIGNOFF-IMMED.</div> <bR> <div> Multiple resource blocks may be enqueued to provide the necessary depth of protection. The user may elect to wait for a specified time interval if a requested resource is not available immediately.</div> <bR> <div>   A circular lock check is made automatically on each enqueue request for a resource. Circular lock is another term for 'deadly embrace' or 'fatal wait', etc., which applies to situations where one or more terminals are waiting on each other's resources in a loop which cannot be broken. Circular lock is prevented by releasing all resources held by the offending terminal, thus permitting other terminals in the lock-chain to run.</div> <bR> <bR> <div>     <B>Logging Facility </B>.</div> <bR> <div> Most terminal systems have a requirement to maintain some sort of log or journal of transactions processed by the system. The Logging Facility of the WESTI System provides this function. A typical use of the Logging Facility is to record in transaction form any modifications which applications have made to the on-line disk files. If a file must be recreated or restored for any reason, transactions that were made to the file through the terminal network may be retrieved from the logging files and reapplied.</div> <bR> <div> To store transactions (or any other data) in the Logging File, an application program issues a LOGIT Function Call, naming the data area and data length to be recorded.</div> <bR> <div> Two separate disk data areas must be allocated for use by the Logging Facility. One area is always assigned to the active logging task while the other area is made available for backup. When the file currently in use fills, the operator may switch files. Logging continues on the new file while the original area is now available for backup. The operator has the option at system start-up time to decide which file will be active and whether WARM</div> <div> or COLD start initialization procedures should be used on that file.</div> <bR> <div> Access to the logging data is provided through a common module so that users need not be concerned with data recording techniques or disk device dependencies.</div> <bR> <bR> <div>       <B>Printer Control </B>.</div> <bR> <div> Sophisticated interactive terminal networks must make provisions for hard copy output. These provisions can range from printing an 'image copy' of currently displayed screen data to the preparation of complex reports and sending those reports to any device on the network.</div> <bR> <div>     WESTI Printer Control facilities provide application programmers with a comprehensive set of options that provide for acquisition of printers for exclusive or shared use, the serialization of printer output through use of the WESTI Enqueuing Facility, the printing of output by either hardware features or format control characters, and the ability to assign a group printer to a terminal. This allows application programs to issue writes to the group printer without having to know the name or physical device address of the printer associated with a particular terminal. In addition, all printer write requests are staged to an intermediate disk buffer to unhook the terminal network from the relatively slow speed of the printer hardware. This disk queue is designed in such a manner that a small report can easily be spooled for output as the printer becomes available. Options provide for the validation and compression of printer write data streams in order to make the most efficient use of the printer hardware characteristics.</div> <bR> <div>  Printers are defined to the WESTI System at monitor generation time in precisely the same manner as terminal devices. A printer is designated as a GROUP printer by naming it as the group printer for one or more of the terminals on the system. A printer can be assigned to serve as GROUP printer for any number of terminals on the system (there is no need for a printer to be located in physical proximity to the terminals it supports) and can also be used in regular printer write operations. Terminals do not need to have a group printer defined, but will be unable to sign on to any application that requires a GROUP printer assignment (see below). Printers (and GROUP printers) may be defined for WESTI systems where the physical hardware has yet to be installed.</div> <bR> <div>     Printers are acquired for use by an application program by specifying the device's name as part of a shared or unshared parameter list. Naming the special printer SYS000 as part of a shared or unshared printer request list causes the monitor to assign the specific hardware device designated as the group printer for the requesting application. If any requested printer is unavailable (either not defined or not assignable due to shared/unshared conflicts), then SIGNON of the application becomes impossible.</div> <bR> <div> Once printers have been assigned to a particular application program, then writes to those printers are accomplished by issuing a special Write Function that names the particular printer to which output is desired. Output to a group printer is accomplished by using the special system name SYS000.</div> <bR> <bR> <div>     <B>Remote Support </B>.</div> <bR> <div> Remote Support extends the facilities of the RJM Systems Teleprocessing Interface to 3270 series terminals and printers via non-switched (leased) multi-point lines and to Teletype (model 33/35 or equivalent) type terminals via switched communication lines.</div> <bR> <div> The implementation of remote support is such that the user need not become involved in any of the requirements for network management. For example, no change is required to a local 3270 application in order to support remote 3270 terminals. The monitor adds or deletes the message framing characters, controls the selection or polling process, and blocks incoming message segments in order to present a complete message to the application program. Similarly, users of Teletype type equipment employing the ASCII transmission code need not be concerned with translating incoming or outgoing messages as this function is provided automatically by the monitor. Thus a multi-entry application can simultaneously service any mix of local and/or remote devices or printers (of the same type) with no special programming considerations on the basis of whether a given terminal or printer is local or remote.</div> <div> Monitor generation macros permit the specification of the local/remote terminal network. Use of these macros allows specification of a terminal network consisting of local terminals or remote terminals or both. Remote terminals may be connected to a variable number of remote control units distributed over a variable number of remote lines. Network management routines provide controls necessary to activate or deactivate all or any part of the remote system.</div> <bR> <div> All remote writes to 3270 display units and printers are disk buffered and switched line terminals are memory buffered to eliminate performance considerations from the design and writing of application programs and to avoid adverse inter-action with response time of local devices on systems employing a mix of local and remote devices. Optional routines are provided which: memory buffer remote terminal I/O for improved performance; ensure the integrity of all data transmitted on remote lines; compress out redundant characters in order to create the most efficient data stream possible for transmission. Other options allow the favoring of terminal I/O over printer writes in order to minimize the impact of printer operations on terminal responses. Users may also designate the polling technique to be employed during periods of minimum line activity.</div> <bR> <bR> <div>     <B>Roll-In-Out (RIO) Facility </B>.</div> <bR> <div> An optional feature of the system enables a large number of application programs to share a common execution area and thus reduce overall storage requirements while simultaneously greatly extending the possible uses of the terminal system. The monitor completely controls the exchange of programs into and out of this common execution area, and the design is such that user application programs require no special structure or coding in order to operate in the roll-in-roll-out mode.</div> <bR> <div> This facility is useful for those systems with a small amount of real memory and/or a large number of applications. It is also a useful environment for testing applications, since during this stage the program's size is not fixed.</div> <bR> <div> At system initialization, the WESTI Monitor loads each program that is to be executed in the common RIO (Roll-In-Out) area, and writes them individually onto a specially formatted disk data set. From this point on the Core Image Library is not accessed again, but rather the program copy located in the RIO File is used, unless the user has requested that a fresh copy of a particular application be loaded.</div> <bR> <div>   The entire RIO Facility is designed to minimize the time required to complete a roll-out-roll-in cycle. This is accomplished by using direct disk addressing, special disk formatting, rolling in or out only the actual length of the application program involved and, in VSE Systems with a marginal page pool, breaking the RIO process into smaller segments to lessen the impact on paging operations and speed the TFIX task of the VSE Supervisor. To further increase system performance, certain application programs may be designated as READONLY. READ-ONLY application programs are not rolled-out. They are only rolled-in as required. This greatly reduces time needed for a memory exchange cycle.</div> <bR> <div>   The RIO Function also provides the option to have the monitor provide terminals with their own dynamically created copies of certain application programs. This greatly simplifies the writing of complex applications, while at the same time assuring maximum system availability to all terminals.</div> <bR> <bR> <div>      <B>Screen Management Facility </B>.</div> <bR> <div> On terminal systems containing video display terminals (3277's or 3278's for example), it is common for the overall system to contain hundreds of basic display formats which are completed and displayed in response to information requests. Although all of the basic screen formats may be contained in memory, a large storage savings and increased flexibility will usually result if these basic display formats are retained on disk and accessed as needed.</div> <bR> <div> The optional Screens Management Facility of the WESTI Monitor provides for the creation of screen display formats and storing the resulting data streams in a system managed disk data set. Other features provide for retrieval of requested display formats by relative record number identification, adding required information using mapping overlays, and unstringing terminal reply streams into defined data areas to ease application processing requirements. Records on the SCREENS File are also easily created, updated, and accessed which makes for a convenient and easy-to-use temporary storage area for variable length data.</div> <bR> <div> The maximum size record that can be stored on the SCREENS File is user defined. The SCREENS File is then preformatted to records of this length with a 2 byte key area which is used to store the actual length of the data recorded in that record location. Preformatting the SCREENS File allows the use of relative record addressing, but variable screen lengths may be specified since the system only reads into storage the actual data length as recorded in the key of the physical disk record.</div> <bR> <div> A SCREENS batch utility is available to backup and restore a WESTI SCREENS file. This utility can either process the entire SCREENS file or individual screens from any disk device to any disk device. See the section 'Application Program Products' for more information on the  WESTI/SCEPTER DUMP/RESTORE Utility.</div> <bR> <bR> <div>    <B>System Control </B>.</div> <bR> <div> Network expansion as well as an increasing number of complex application programs make it imperative that methods for monitoring system usage and controlling system functions be established. WESTI Systems provide methods for controlling system functions from any available terminal and/or the computer's console device. A terminal need not be dedicated to system control functions as control programs are handled exactly like any other application program (they can be signed on to any terminal device for which they have been written). Also, a terminal need not be placed in the computer room because it is possible to use the computer console as the control terminal.</div> <bR> <div> If the computer console is to be used as the control terminal, then the name of the console control application is specified at monitor generation time. This control application is dormant until it is activated by an external interrupt supplied to the monitor partition (INTERRUPT key on console or MSG F1, MSG F2 technique) which causes connection of the control application to the computer console. The application is then used to perform any needed control or display request. When all required functions have been completed, the application issues a SIGNOFF and again becomes dormant.</div> <bR> <div> A control application that is accessed from a terminal needs no special activation technique since it can be activated by normal system MENU control functions. Such applications would normally be protected from inadvertent activation by utilizing password protection to prevent unauthorized usage.</div> <bR> <div> WESTI control functions are incorporated in the control application program supplied with the system. This control application can operate with the computer console, 3270 series terminals or TTY terminals. Control functions not needed for a particular monitor may be omitted at link edit time. For example, those control routines associated with a remote system can be excluded from a control application intended to operate in a local-only environment. In addition, users may add additional functions as required by their particular installation.</div> <bR> <bR> <div>  The WESTI control application provides the ability to:</div> <bR> <div>          Activate or deactivate any local terminal or printer or any remote line, control unit, terminal or printer.</div> <bR> <div>          Deactivate or request a fresh copy load of any application program.</div> <bR> <div>          Change the priority of any terminal or application or enable or disable priority scheduling within the monitor.</div> <bR> <div>          Cause all or parts of the monitor, memory resident applications or the Roll-In-Out area to be page fixed or freed in virtual storage systems.</div> <bR> <div>          Display the status of any line, control unit, terminal, printer, application, DISKWORK File, AMC File, or various components of the monitor itself.</div> <bR> <div>          Change the READ-ONLY and/or ENTRY attributes of application programs.</div> <bR> <div>          Activate the orderly system shutdown process or command that rapid system shutdown procedures be performed.</div> <bR> <div>          Activate or deactivate system logging procedures or command that the active Logging File be swapped.</div> <bR> <div>          Open, close or change the accessibility attributes of files managed by the WESTI Access Method Controller.</div> <bR> <div>          Debug user applications with the Trace Facility.</div> <bR> <div> For a complete description of the commands available with the System Control application, consult the section 'System Control - $CNTRL Commands'.</div> <bR> <div> Users who desire to construct their own system control application can utilize the system monitor control application function MCNTRL to implement many of the control and status display features.</div> <bR> <bR> <div>     <B>Terminal Control </B>.</div> <bR> <div> The WESTI Monitor connects terminals to application programs. Once this connection is established, the application program exercises control over the terminal until that connection is broken or relinquished. Connections are broken by the monitor when an application program attempts an invalid operation or function. Connections are relinquished by application programs when they have completed the function for which the connection was originally established or when control must be passed to other applications in order to complete the function.</div> <bR> <div> The initial application program to which a terminal is connected is specified at WESTI Monitor generation time. Beyond this first connection, it is the role of the application program, to which a terminal is currently connected, to name the next application program which is to receive control of that terminal. That is, control of the terminal can be passed from application to application as needed to access the various components of the system.</div> <bR> <div>  The SIGNOFF Function indicates to the monitor that an application program wishes to pass control of a terminal that it currently owns to some other application program in the system. Since it is possible to have multiple SIGNOFF Functions within an application, programs can be constructed which can transfer the control of a terminal, currently belonging to it, to any other application program on the system. Although all application programs can each contain the necessary logic to pass control of terminals to all other applications, most system designers find this type of planning to be memory consuming, redundant, and difficult to maintain. It is usually deemed simpler and more flexible to plan application programs so that when all processing for a particular terminal has been completed, control of that terminal is passed to a common application whose job is to query the terminal operator as to what function should next be performed. This type of traffic directing application is called a MENU application as its function is to display a MENU of the available application choices and pass control of the terminal to the appropriate application program as chosen by the terminal operator.</div> <bR> <div>  On systems requiring that entry to certain applications be restricted because of the sensitive or confidential nature of the information being accessed, the necessary authorization editing is normally placed in the MENU application to centralize all such coding on the system. Unless a terminal operator satisfies all imposed restrictions required to gain access to an application, the MENU application can simply refuse to SIGNOFF the terminal to the desired application, which is an effective form of 'lockout'. When all security checks are successful, the MENU names the requested application in a SIGNOFF call to the monitor, which then transfers control of the terminal to the 'new' application. By specifying a user area in the TRMDEF via the WESTI macro parameter 'TRMUSER=(nnnn,mmmm)', information can be passed from one application to another.</div> <bR> <div>  Individual application programs can further restrict or limit functions performed for certain terminals or operators. For example, an operator might be permitted to make file inquiries but be prohibited from updating records while another operator might be allowed to perform both functions. Violations of such security checks are usually handled by transferring the offending terminal back to the MENU, thus denying access to any restricted routine while retaining the terminal for use by the system. In extreme cases, the offending terminal can be deactivated or removed from service until the cause of the violation is learned and it is deemed safe to return the terminal to active status.</div> <bR> <div>    SIGNOFF options provide the ability to pass control of a terminal from its owning application to a receiving application IMMEDiately or to pass the terminal through the monitor PAUSE routines. A PAUSE type of SIGNOFF places the terminal in an idle status where it remains until it is next accessed (e.g., a 3270 terminal operator presses the terminal interrupt key). This then causes the SIGNOFF to complete whereby control of the terminal is passed to the receiving application. The LEAVE type of SIGNOFF is a variation of the PAUSE and operates in exactly the same manner except the last terminal display image is left intact so that the terminal operator can view that display until the next time the terminal is accessed, at which time the SIGNOFF is completed as described above.</div> <bR> <div>    Other SIGNOFF types available cause control as well as all resources currently owned by the terminal to be passed to another application (SIGNOFF-RETAIN, SIGNOFF-LINK, and SIGNOFF-RETURN). These SIGNOFF types provide the system designer with a method for segmenting the flow of control into functional application modules which communicate via the resources passed by SIGNOFF. The LINK and RETURN types of SIGNOFF may be used where it is required to LINK from one application to another but at some RETURN to the original application. Like the RETAIN type of SIGNOFF, resources acquired by the LINKing application are passed to the receiving application and returned to the LINKing application upon a SIGNOFF RETURN. The implementation of the SIGNOFF LINK/RETURN is such that application programs may LINK to any desired depth. Each RETURN type of SIGNOFF returns control to the next higher application in the SIGNOFF LINK chain.</div> <bR> <div> The SIGNOFF Function of the WESTI Monitor gives application programs complete control of terminal flow through the system. Entry to applications can be allowed or denied, intricate menu applications can be constructed, security requirements can be enforced, and complex applications can be structured into more manageable segments by use of the various options available for Terminal Control via the SIGNOFF Function.</div> <bR> <bR> <div>     <B>Wait-On-User-Defined-Event (WOUDE) Facility </B>.</div> <bR> <div> The Wait-On-User-Defined-Event (WOUDE) Facility allows application programs to communicate with asynchronous subtasks in such a manner that any wait time accrued from the use of the subtask is available to the monitor, and so improves the overall performance of the system. NOTE: Use of this facility assumes that support for Multitasking (the execution of more than one program within a partition) was specified in the VSE Supervisor.</div> <bR> <div> When multiple applications or terminals attempt to use the same subtask, the WESTI Monitor queues these requests in priority sequence, and feeds them to the subtask as it indicates that it can accept new requests. The linkage between the subtasks and the WESTI Monitor is such that either multi-entry or single-entry subtasks can be accommodated. Single-entry subtasks are designed so that all processing on behalf of one WOUDE request must be accomplished before the subtask signals the monitor that it can accept another WOUDE request. Multi-entry subtask design is accomplished by having the subtask signal the monitor that it can accept another request for its services before having completed the previous request. Even if only single-entry subtask designs are employed, system performance is not degraded because only those terminals requiring subtask facilities are placed in subtask wait while the rest of the system continues to function. Wait time is accrued to the WESTI system regardless of subtask design due to the processing mechanism of VSE Multitasking support.</div> <bR> <div> One prime application for this facility is to use it to construct an out-of- line error correction facility. For example, if in the process of entering orders, customer information is found to be missing from a master file, then a WOUDE subtask could be dispatched to handle this situation at the same time the rest of the order is being processed.</div> <bR> <div> Another application for this facility is to use it as a mechanism to create a unique data-management facility tailored to the requirements of an individual installation. An important design consideration for creating such a task is to provide a method by which all wait time accrued during file I/O operations be returned to the monitor for other system purposes. One way to accomplish this goal is physically build into the monitor all the various data management schemes the user is expected to employ and require the use of these facilities (such a scheme is provided by the WESTI Access Method Controller (AMC) Facility). However, it is not always possible to encompass in one general purpose routine all of the file or database designs that a user might employ, especially when the user may have some proprietary or purchased database software system whereby including such coding into the monitor would violate a copyright or cause product infringement. An elegant solution to this problem would be to provide a mechanism to enable the monitor to benefit from any wait time accrued by the user task. Such an approach is provided by the WESTI System through the WOUDE Facility.</div> <bR> <div> To use WOUDE to create user-defined unique file and/or database handlers, one or more subroutines must be written to perform file and/or database I/O operations. These subroutines are attached as subtasks to the WESTI Monitor System (usually with a lower priority). When a user application program wishes to retrieve data from a file or a database, the application invokes the WOUDE Function, indicating the subtask and the required parameters or fields needed to accomplish the required request. If the indicated subtask is busy handling another request, the monitor simply queues the current request and continues with other processing. When the subtask indicates to the WESTI Monitor that it can accept another application request, the monitor dequeues the next request and passes it to the subtask along with the parameters that were an initial part of the I/O request. The subtask then operates on this request and again signals the WESTI Monitor when it is free to accept another request for service. The net result of this communication linkage is that any database or file I/O request is completely overlapped with all other processing by the monitor.</div> <bR> <bR> <div>    <B>Subroutine Linkage Facility </B>.</div> <bR> <div> The Subroutine Linkage Facility of WESTI allows application programs which are link independent of the controlling monitor to communicate with subroutines and/or tables which are normally link edited as a part of the monitor. The benefits of linking application programs independently from the monitor are somewhat offset by the larger working set of the WESTI partition due to replication of common subroutines throughout the application programs. The Subroutine Linkage Facility addresses just this problem and offers the diligent user the capability of creating a working set for the WESTI partition comparable to one which could be obtained by making applications link dependent to the monitor.</div> <div> Subroutines or tables which are to participate in the Subroutine Linkage Facility are first identified and then named in a special control section called WADDRMOD. The subroutines, tables and the address module (WADDRMOD) are then link edited as a part of the WESTI monitor where they will reside as singular copies in the partition. The reduction in working set size, which judicious use of this facility can effect, is significant and can be readily calculated by summing the sizes of the eliminated subroutines.</div> <bR> <div> Application programs which use the Subroutine Linkage Facility must be link independent to WESTI. These applications are termed SLINK applications (for Single LINK). SLINK applications which are to use subroutines and/or tables declared as participants in the Subroutine Linkage Facility must declare those subroutines and/or tables in a parameter of the application SIGNON function. All subroutines declared are made available to the application by the Subroutine Linkage Facility provided the references to the subroutines obey standard calling conventions. All tables declared are made available to the application through the use of a special subroutine (WSADRFND).</div> <bR> <bR> <div>     <B>Performance & Accounting Subsystem </B>.</div> <bR> <div> The Performance & Accounting Subsystem (P&A Facility) is an extension to the WESTI monitor. The P&A Facility monitors the performance of WESTI and all of the user defined components. Statistical data is collected and recorded in an ENTRY SEQUENCE (ESD) VSAM data set. The gathered data can subsequently be analyzed by user-written applications and/or the RJM Systems Report Writer to produce whatever job accounting and/or chargeback reports needed by the user.</div> <bR> <div> Each terminal user is required to 'SIGNON' to the WESTI System. The 'SIGNON' procedures will identify the user and establish a 'SESSION' for recording all of the events and resources used by the user during the 'SESSION'. During each 'SESSION', the following data is recorded:</div> <bR> <div> Start and Stop Time.</div> <div> CPU Processing Time.</div> <div> Terminal I/O's.</div> <div> DASD I/O's.</div> <div> Printer I/O's.</div> <div> Application Programs Used.</div> <div> Memory Requirements.</div> <bR> <div> When the user has completed their work, the 'SIGNOF' function ends the 'SESSION'. The operation of the P&A Facility is transparent to the terminal user with the exception of the 'SIGNON/SIGNOF' requirement.</div> <bR> <div> The Systems Administrator has access to the Master User/Session table through the System Control Application. The Systems Administrator can view the current Master table at any time. The Master table will show all allowable users, who is currently on the system, and what account numbers are being charged for the current users. The Systems Administrator can add/delete/change users id's and accounting information as needed.</div> <bR> <div>     <B>Report Writer Facility </B>.</div> <bR> <div> The Report Writer Facility is a batch reporting facility which allows a user to generate customized reports based upon the data collected by the P&A Facility. The Report Writer will select, sort and print data reports based upon user defined parameter cards. Summary and final totals are automatically produced for all numeric fields.</div> <bR> <div> Several canned reports are supplied and may be used as a basis for designing customized reports. The canned reports are:</div> <bR> <div> WESTI Execution Information          Detail by Operator (Individual Users)</div> <div> Detail by Terminal                             Detail by Application Program</div> <div>        Detail by Charge Account               SIO Counts by Device</div> <bR> </td> </tr></table></body>