System Productivity Facility Dialog Management Services

(1)

Program Product

Order No. SC34-2036-1 File No. S370/4300-39

System Productivity Facility Dialog Management Services

Program Number 5668-009

- - . - .

-

-~-,-

^- _{- ---'---} - -

^{, - . ,}

^--_ --- ^--- ^....

---

---_. ^-

(2)

Second Edition (March,1981)

This edition applies to the System Productivity Facility (SPF) Program Product (5668-009), for use with the following:

OS/VS2 MVS Release 3.8 VM/SP

and to all subsequent releases until otherwise indicated by Technical Newsletters. Changes are con- tinually made to the information herein; before using this publication in connection with the opera- tion of IBM systems, consult the latest IBM System/370 and 4300 Processors Bibliography, Ge20-0001, for the editions that are applicable and current.

It is possible that this material may contain reference to, or information about, mM products, programming, or services in your country. Such references or information must not be construed to mean. that IBM intends to announce such IBM products, programming, or services in your country.

Publications are not stocked at the address given below. Requests for copies of IBM publications should be made to your IBM representative or to the IBM branch office serving your locality.

A form for readers' comments is provided at the back of this publication. If the form has been removed, com-ments may be addressed to IBM Corporation,$yste,ms PU~Jicattons, Department Z59, Building 931, P.O. Box 390, Poughkeepsie, New York, U.S.A. 12602. mMmay use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation whatever. You may, of course, continue to use the information you supply.

@Copyright International Business Machines Corporation 1981

(3)

PREFACE

The System Productivity Facility (SPF) is a program product that assists in program development. It is designed to take advantage of the characteristics of IBM 3270 display terminals, and to

increase programmer productivity in an interactive environment.

The System Productivity Facility replaces the previous Structured Programming Facility program products (SPF/TSO and SPF/CMS). It includes significant new functions that support the development, testing, and execution of interactive applications.

New services are provided to display predefined screen images and messages, build and maintain tables of user information, generate output fi les for job submi ssi on or other pro.cessi ng, defi ne and control symbolic variables, interface to edit and browse, and log hardcopy output.

This manual provides a detailed description of the new SPF services and related information required to develop an interactive application that runs under SPF. It applies to both the MVS/TSO and VM/CMS environments.

The manual is divided into the following chapters:

1. Introduct ion - A general overv i ew of SPF, i ncludi ng its structure and function.

2. Concepts and Facilities - A description of the services and control facilities that support the operation of interactive applications.

3. SPF Invocation - A description of the library setup requirements, and the ISPF command used to invoke the dialog manager.

4. Description of Services - A detailed description of each dialog service, including syntax conventions for command or call invocation.

5. Panel, Message, and Skeleton Formats - A detailed description of the syntax for defining panels, messages, and file tailor- i ng skeletons.

6. Dialog Testing Procedures - A description of the test aids available for testing dialogs.

The manual also includes two appendixes:

A. Sample Problem

B. Summary of SPF Dialog Services

TERMINOLOGY

In thi s manual, the followi ng terms are used to bri dge the di ffer- ences in terminology between the MVS and VM environments:

• library - A partitioned data set in the MVS environment, or a MAClIB in the VM environment.

• File - A sequential data set in the MVS environment, or a sequential CMS file in the VM environment.

• Command Procedure -.A ClIST in the MVS environment, or an EXEC (coded in EXEC2 language) in the VM environment.

Preface iii

(4)

NOTATION CONVENTIONS

The following notation conventions are used for describing the ISPF command and each SPF service:

• Command verbs, service names, and keywords that must be coded exactly as shown are represented with uppercase characters.

• Substitutable operands are represented with lowercase characters.

• Optional parameters are enclosed in brackets, "[" and "1".

• Within brackets, a choice of parameters is indicated with slashes and the default is underscored.

• Multiple choice parameters, of which one is required, are enclosed in braces, "I" and "I", and aligned vertically.

Example:

ISPEXEC VGET name-list [SHARED/PROFIlEl

The command verb (ISPEXEC) and the service name (VGET) must be coded exactly as shown. A list of variable names must be substituted.for "name-list". The keyword parameter is optional. Either SHARED or PROFILE may be coded. If the parameter is omitted, SHARED is the default.

. . . . '.

Chapter 2. Concepts and Facilities Elements of a Dialog . . • . Dialog Organization

Flow of Control

SELECT Service . Dialog Services Overview

Display Services Table Services

File Tailoring Services Variable Services

Other Serv ices . • • . . Control Facilities . . • . • .

Online Tutorial . . • • . . . • • Screen Management . . . . • . .

Program Access and Function Keys Chapter 3. SPF Invocation . • . .

Library Setup - MVS Environment . . • . Requi red Li brari es . . • . • • . Table and File Tailoring Libraries CLlST and Program libraries

Library Setup ~ VM Environment Requi red L i brari es . . . • . Table and File Tailoring Libraries EXEC and Program L i brari es . . . . Restrictions on Use of MODULE Files Restrictions on Use of GLOBAL Commands lSPF Command . • • • . • . • • • . Chapter 4. Description of Services

Invocation of Services Command Invocation Call Invocation

Return Codes from Services

Display Services . . . . • . . . • . . • DISPLAY - Display Panels and Messages TBDISPL - Display Table Information Table Sarvi ces - General . . . . • .

TBCREATE - Create a New Table

TBOPEN - Open a Table . . • • . . TBQUERY - Obtain Table Information TBSAVE - Save Table . • • . . • • . TBCLOSE - Close and Save Table • . TBEND - Close Table without Saving TBERASE - Erase a Table . . . • Table SQrvices - Row Operations

TBADD - Add Row to Table . • • • •

'. .

TBDELETE - Delete Row from Table • . . . TBGET - Retrieve Row from Table

TBPUT - Update Row in Table

TBMOD - Modify Row in Table . . • • . . . TBEXIST - Determine if Row Exists in Table TBSARG - Define a Search Argument . . • • • TBSCAN - Search Table . . . . • • • •

TBTOP - Set Row Pointer to Top

TBBOTTOM - Set Row Pointer to Bottom TBSKlP - Move the Row Pointer

TBVCLEAR - Clear Variables Fi Ie Ta; lor; ng Servi ces • . • •

FTOPEN - Begi n Fi Ie Ta; lori ng . • • . FTINCL - Include Skeleton . • • • • . FTCLOSE - End Fi Ie Tai lor; ng . • . . • . • . FTERASE - Erase F; Ie Tai lori ng Output

Variable Services . . • • • . . . • . . . • VGET - Retrieve Variables from Pool or Profile VPUT - Update Variables in Pool or Profile

Contents 1 3 5 5 6 8 10 8 11 15 18 20 26 27 27 27 28 31 31 31 32 33 34 34 35 36 37 37 38 41 41 41 43 45 46 46 48 50 50 52 53 55 57 59 60 61 61 62 63 64 65 66 67 68 69 70 71 72 73 73 74 75 76 77 77 78

v

(6)

VDEFINE - Defi ne Functi on Vari abIes • • • • • • • VDELETE - Remove Definition of Function Variables VCOpy - Create Copy of Variable

VREPLACE - Replace Variable

VRESET - Reset Function Variables

Other Serv ices . • . . • . '. . . • . • . • SELECT - Select Panel or Function . • . . CONTROL - Set Processing Modes • • • . BROWSE - Display Data Set or-File

EDIT - Edit Data Set or File lOG - Write Message to Log File

Chapter 5. Panel, Message, and Skeleton Formats Panel Definitions - General Syntax

Panel Body • . • • . . • . . • • . . Initialization and Processing Sections

Attribute Section . . • . . • • . • • • • . • • • • Processing Considerations . . • • • .

Syntax Rules and Restrictions . • • • • • • • • Panel Definitions - Formatting Guidelines

Panel Definitions - Special Requirements

Selection Menus . • . . • . • • • • Hel p/Tutor i a I Panel s . . • • • . • . • • Tabl e Display Panel s • • • .

Message Definitions . • • . . • . . . • • • Skeleton Definitions . . . • • .

Data Records . . • . Control Statements Sample Skeleton File

Chapter 6. Dialog Testing Procedures Set Up Procedures . . • . . . Operating in Test and Trace Modes Support (Option 7) . . • . . • .

Test Panel (Option 7.1) Test Function (Option 7.2) Test Variables (Option 7.3) Convert Menus (Option 7.4) Convert Messages (Option 7.5)

Test Menu (Option 7.6) . . . • • • Appendix A. Sample Problem

Appendix B. Summary of SPF Dialog Services Command Invocation Syntax .

Call Invocati on Syntax . . . • Index

vi SPF Dialog Management Services

79 81 82 83 84 85 85 88 91 93 95 97 97 98 100 111 114 114 117 119 119 124 127 130 133 133 134 137 139 139 140 141 142 143 144 145 147 147 149 159 159 161 163

(7)

Figure 1.

Figure 2.

Figure 3.

Figure 4.

Figure 5.

Figure 6.

Figure 7.

Figure 8.

Figure 9.

Figure 10.

Figure 11.

Figure 12.

Figure 13.

Figure 14.

Figure 15.

Figure 16.

Figure 17.

Figure 18.

Figure 19.

Figure 20.

Figure 21.

Figure 22.

Figure 23.

Figure 24.

Figure 25.

Figure 26.

Figure 27.

Figure 28.

Figure 29.

Figure 30.

Figure 31.

Figure 32.

Figure 33.

Figure 34.

Fi.gure 35.

Figure 36.

Figure 37.

Figure 38.

Figure 39.

Figure 40.

Figure 41.

Figure 42.

Figure 43.

LIST OF ILLUSTRATIONS

SPF Organization • . • • Typical Dialog Organization Other Dialog Organizations Flow of Control . . ••

Sample Panel Definition

Sample Panel - When Displayed

Sample Member in Message Library • • • • . Sample Table • • • . . • • • • . . • • •

Sample Skeleton File . . . • • . . • • . Sharing Variables via VPUT/VGET

Service Access to Variables

Sample Panel Definition • • . . . • . . . • • Sample Panel - When Displayed . . • .

Sample Panel with TRANS and TRUNC

Sample Panel wi th IF Statement . . • • • . • • • Sample Panel with Verification .

Sample Panel with Control Variables SPF Primary Option Menu

Master Application Menu Lower Level Selection Menu Sample Tutorial Hierarchy

Sample Tutorial Panel (B) • • • • •

Sample Tutorial Panel (F2) . . . . • • Table Display Panel Definition • • •

Current Contents of Table . • . . • . ••

Table as Di splayed . . . ••

Sample Member in Message Library Sample Skeleton Fi Ie . • ••

Support Selection Menu . • • . • . • • . • • • Entry Panel for Testing a Panel Definition

Entry Panel for Testing a Function • • • • Entry Panel for Testing a Variable . . . . Entry Panels for Converting Menu Definitions Panel for Testing Old Format Menus . • . . ••

Sample Problem - Overall Dialog Organization Sample Problem - Pri mary Opt i on Menu (EMPL) ••

Sample Problem - First Data Entry Panel (EMPLA) Sample Problem - Second Data Entry Panel (EMPLB) Sample Problem - Messages (Member EMPX) . • • • Sample Problem - CLIST (EMPLCMD) . • . • . • • Sample Problem - Pl/I Main Program (EMPLPGM)

Sample Problem - PL/I Included Segment (EMPLDCL) Sample Problem - PL/I Included Segment (EMPLDEL)

3 6 7 9 13 14 13 15 19 22 23 99 99 103 105 107 109 121 122 123 125 126 126 129 129 129 132 137 141 142 143 144 146 148 149 149 150 151 152 154 155 156 157

L i s,t 0 f I 11 u s t ra t ion s vii

(8)

vi i i SPF Di alog Management Servi ces

(9)

SUMMARY OF AMENDMENTS

This revision to SPF Dialog Management Services includes:

• Additional information pertaining to operation of SPF in the VM/CMS environment.

• Corrections to errors in the previous edition.

• Clarification of information in the previous edition.

All technical changes are marked with a vertical bar ( I ) on the left-hand side of the page.

Summary of Amendments 1

(10)

2 SPF Di alog Management Serv ices

(11)

CHAPTER 1. INTRODUCTION

The System Productivity Facility (SPF) is a program product that replaces both of the previous Structured Programming Facility 'products (SPF/ISO and SPF/CMS). SPF supports two env i ronments:

• MVS Time Sharing Option (SPF-MVS)

• VM/SP Conversational Monitor System (SPF-VM)

The new name, System Productivity Facility, reflects the addition of 5i gni fi cant 'new functions beyond the support for structured 'programming. The new functions support the development, testing,

and execution of interactive applications that run under control of SPF and use new SPF serv ices to:

• Display predefined screen images and messages

• Bui ld and mal ntai n tables of user i nformati on

• Generate output files for job submission or other processing

• Define and control symbolic variables

• Interface to edit and browse, and log hardcopy output

• Control operational modes.

SPF consists of two major components: the dialog manager and the program development facility (see Figure 1). Conceptually, the dialog ma'nager is an extension to the operating system. It provides control and services Tor running interactive applications.

One such ~pplication is the program development facility, which includes the prev; ousSPF funct; ons.

DIALOG MANAGER

CONTROL FACILITIES

Menu/Tutorial Processing Screen Management

Program Key Interpretation SERVICES

Display

Table Creation/Maintenance File Tailoring

Variable Definition/Control Other

PROGRAM DEVELOPMENT FACILITY SPF Parms

Browse Edit Utilities Foreground

Background (Batch) Command

Support Tutorial

Figure 1. SPF Organization

Chapter 1. Introduction 3

(12)

The dialog manager allows totally new applications to be devel- oped. They may be DP-oriented applications, including extensions to the SPF program development facility, or applications for which the end user is not a DP-professional, such as an inventory application.

Displays and .messages may be tailored to the particular needs and terminology of the end user, so that information is presented in a user-friendly way.

An installation may have several applications that run under the di alog manager. They may be independent, entered vi a separate command procedures, or" linked via menu options that transfer from one application to another. A sample "master menu," distributed with SPF, allows application selection to occur on entry to SPF.

Its use is not required; any selection menu may have options that link to other applications.

Applications may be coded in:

• The command language of the host system (CLIST for MVS/TSO, or EXEC2·for VM/CMS), or

• A programming language, such as PL/I or COBOL.

An application may have mixed languages, with some functions coded in a command language and other functions coded in one or more programming languages.

Applications coded in programming languages may be designed for cross-system use, to be run under either MVS or VM.

SPF also provides new testing aids for debugging applications. These are part of the SPF program facility -- the SUPPORT option (primary option 7).

4 SPF Dialog Management Servi ces

interactive

dev~lopment

(13)

CHAPTER 2. CONCEPTS AND FACILITIES

This chapter describes basic concepts of dialog organization and control, and the capabilities of the SPF dialog services.

gLEMENTS OF A DIALOG

A "dialog" is any application designed to be run under the SPF dialog manager. Each dialog is composed of program and data elements, which allow an orderly interaction between the computer and the end user of the application. The types of elements that make up a dialog are:

• Ftinctions. A functi~n is a program that performs processing requested by the user. It may invoke SPF dialog services to display panels and messages, build and maintain tables, and generate output files. A function may be coded in a command language (CLIST or EXEC2) or a programming language.

• Panels.¹ A panel is a predefined display image. It may be a selection menu, a data entry display, or an information-only display. Most panels prompt the user for input. The user response may identify which path is to be taken through the dialog, or it may be interpreted as data.

• Messages. A message is a comment that provides special information to the user. It may confirm that a user-requested action is in progress or completed, or report an error in the user's input. Messages may be directed to the user's terminal, to a hardcopy log, or both.

• Tables. A table is a two-dimensional array used to maintain data. A table may be created as a temporary data repository, or it may be retained across sessions. A retained table may also be shared between different applications. The type and amount of data stored in a table depends upon the nature of the application.

• File Skeletons. A file skeleton is a generalized representation of sequential data which may be customized during dialog execution to produce an output file. The output file may be used to drive other processes. File skeletons are frequently used to produce job files for batch execution.

A dialog need not include all types of elements. In particular, tables and file skeletons may not be needed, depending upon the type of application.

Panels, messages, and file skeletons are stored in libraries prior to execution of the dialog. They are created by editing directly into the panel, message, or skeleton libraries; no compile or preprocessing step is required.

Tables are generated or updated dynamically during dialog execution. The organization of ' each table is specified toSPF by the functions that use SPF table services.

1 Previously, all SPF screen images were called menus. The terminology has been changed to more closely reflect general usage. The term menu is now used to mean a display from which the user may select options.

The term panel is used to mean any predefined display image, of which one type is a menu.

Chapter 2. Concepts and Facilities 5

(14)

DIALOG ORGANIZATION

A di alog may be organi zed. ina variety of ways ·to ,sui t the requtrementsof the application and the needs~f the end user. A typical dialog 'organization is shown in Figure 2.

This example starts with the display of a high level selection menu, the primary option menu for the application. User options selected from this menu may result in the invocation of acdialog function, or the display of a lower level selecti~n meriu.E~~h

16wer level menu may also cause functions to receive control, or still lower level menus to be displayed. The menu hierarchy may extend as many levels deep as desi red.

Eventually a dialog function will receive control. The junction may use any of the dialog services provided by SPF. In particular, the function may continue the interaction with the ~nd user by means of the DISPLAY service. Typicarly, the function will display data entry panels to prompt th~ user for information.

When the function completes, the selection menu from which it was invoked is redisplayed.

SELECTION MENU

r---r---r-->

,..---V'---. __ --V"""--"'I.

DIALOG FUNCTION

SELECTION MENU

v v

DISPLAY v

t--->

Figure 2. Typical Dialog Organization

6 SPFDialog Management Servi ces

I'----v-~"'\

v

DATA ENTRY PANELS

SELECTION MENU

v v v

(15)

Figure 3 shows a different type of dialog organization. In this example, a dialog function receives control first, prior to the display of a menu. It may perform application-dependent initial-

ization, and display data entry panels to prompt the user for basic information. It may then start the selection process by using the SELECT service to display the primary option menu for the application.

This example also shows one function invoking another function, via SELECT, without displaying a menu. This provides a convenient way to pass control from a program-coded function to a command-coded function, or vice versa. The invoked function then starts a lower level selection process, again by using the SELECT service.

DIALOG FUNCTION

DISPLAY t - - - >

SELECT _ - - V ' - - " " \

SELECTION MENU

DATA ENTRY PANELS

~---~---r--->

,..----V--'""I

DIALOG FUNCTION

- - - ' V - - " " \ SELECTION MENU

v v

,..----'V---,

SELECT

v

_ - - V ' - - " " ,

SELECTION MENU

v

DIALOG FUNCTION

1 - - - > DIALOG FUNCTION

SELECT - - - V ' - - " " \

(

SELECTION MENU

Figure 3. Other Dialog Organizations

v

Dialog Organization 7

(16)

FLOW OF CONTROL

The flow of control is shown in Figure 4. A dialog is started by means of the ISPF command. (AnSPF command may be established as an al i as of ISPF.) The command may be entered:

• By a user at the termi nal,

• From a command procedure (CLIST or EXEC2), or

• During LOGON (from a TSO LOGON procedure or CMS PROFILE EXEC).

When the ISPF command is used to invoke the SPF program development facility, no command parameters are required.

When the ISPF command is used to invoke any other dialog, command parameters are used to specify the first selection menu to be displayed or the first dialog function to receive control (prior to the display of a menu). In this case, the ISPF command is typically entered from a command procedure or during LOGON.

Example: The user might invoke a new application by entering the ABC command. ABC would be coded as a command procedure that allo- cates the appropriate libraries for the application, and then issues an ISPF command with a parameter that specifies the first selection menu or dialog function. The ABC command serves as a

"front end" to start the application. It may not use SPF dialog services, since it is not running under SPF.

The ISPF command invokes the SPF controller, which initializes the environment. The controller then calls the SELECT service to display the first menu or invoke the first dialog function, pass-

ing it the parameters specified on the ISPF command.

SELECT SERVICE

SELECT is both a control facility and a dialog service. It con- trols the sequence of selection menus, based on user inptits, and invokes dialog functions. From a dialog function, SELECT may be used as a serv ice to start the di splay of a menu hi erarchy or

invoke other functions without displaying a menu.

Selection menus contain sufficient information to determine the next action to be taken for any option entered by the user. This information is interpreted by the SELECT service. The next action may be:

• Display a lower level selection menu, or

• InvDke a dialog function.

When the SELECT service is used to display a menu hierarchy, it will display the first menu (via the DISPLAY service) and continue to display successively lower levels of menus, until a dialog function is specified as the next action. The SELECT service will then invoke the function. When the function completes execution, the SELECT service will redisplay the menu from which the function wa s invoked.

When the SELECT service is used to invoke a function without displaying a menu, it simply passes control to the lower level function. When that function completes execution, SELECT returns to the function that called it, passing along the return code from the lower level function.

Parameters may be passed to any dialog function from the selection menu or function that invoked it (or from the ISPF command, if it is the first function to receive control prior to the display of a menu). These parameters may be used, for example, to pass the name of a panel to be displayed, a table to be updated, or a file skeleton to be used by the function.

8 SPF Dialog Management Services

(17)

...---v--....

CONTROLLER

...----v---.

SELECT SERVICE

. . . - - - V , - -....

--->

DIALOG -' - - >

FUNCTION

- - > CONTROL FLOW

- - \

- - I DATA FLOW

Figure 4. Flow, of Control

0 I A L

0 G

S E R V

I

C E S

DISPLAY SERVICES

TABLE SERVICES

FILE TAILORING SERVICES

VARIABLE SERVICES

/'--- '\.--- 1--- '\---

/ ' - - - - ' \

'\ /

/'---

\.---

- - - \ - - - /

PANEL LIBRARY

MESSAGE LIBRARY

DATA TABLES

SKELETON LIBRARY

OUTPUT FILES

Flow of Control 9

(18)

DIALOG SERVICES OVERVIEW

Once a dialog function receives control, it may use SPF dialog services to continue the interaction with the end user, and to assist in processing operations. The dialog services allow a function to:

• Display predefined screen images and messages

• Build and maintain tables of user information

• Generate output files for job submission or other processing

• Define and control symbolic variables

• Interface to edit and browse, and log hardcopy output

• Control operational modes.

Dialog services may be used only within the SPF environment. They may not be invoked by command procedures or programs running out- side of SPF.

Functions coded in a command language may invoke dialog services by means of the ISPEXEC command. Example:

ISPEXEC DISPLAY PANEL(XYZ)

This command invokes the DISPLAY service to display a panel named XYZ.

Caution:

• Functions coded in the ClIST command language must not include attention exits.

• Functions coded in the EXEC2 command language must include a

&PRESUME statement prior to issuing an ISPEXEC command. For more information, see "Invocation of Services" in Chapter 4.

Functions coded in a programming language may invoke dialog services by calling a service interface routine, named ISPLINK. Exam- ple:

CALL ISPLINK ('DISPLAY', 'XYZ ');

ISPlINK is a small program module which is distributed with SPF.

It may be called from programs coded in any language that uses standard OS register conventions for call interfaces, and the standard convention for signaling the end of a variable length parameter list.

Data is communicated between the functions and the services by means of "dialog variables." A dialog variable is a character string that may vary in length from zero to 32K bytes. It is referenced symbolically, by name.

For functions coded in a command language, the CLIST or EXEC2 variables are automaticallY treated as dialog variables; no special action is required to define them to SPF.

For functions coded in a programming language, the internal program variables that are to be used as dialog variables may be identified to SPF via the VDEFINE service, or the program may access and update dialog variables via the VCOPY and VREPLACE services.

Dialog variable names appear in panel, message, and skeleton definitions to allow communication with the functions. A variable name in a panel definition, for example, corresponds exactly to the name of a dialog variable accessible to a function. The variable may be used to initialize information on the panel (prior to display), and to store input entered by th~ user.

(19)

DISPLAY SERVICES

The display services allow a dialog to display information and interpret responses from the end user. There are two display services:

• DISPLAY - Display panel

• TBDISPL - Display t~ble

The DISPLAY service reads panel definitions from the panel library, initializes variable information in the panel from the corresponding dialog variables, and disp!ays the panel on the screen. A message may optiona!!y be disp!ayed with the panel.

After the user has entered information, the user inputs are stored into corresponding dialog variables, and the DISPLAY service returns to the calling function.

···Th·;····TBDISPL ~ervi ~ combi~-;;--i nfor;;ti o·n-from-panel-ae=rrnTtTons·

with information stored in SPF tables. It displays selected columns from all rows in a table, and allows the user to identify rows for processing (one row at a time).

The user may scro!l the information up and down, using program function (PF) keys. The amount of scrolling for each depression of a PF key is specified by a scrol! field, displayed on the panel, that may be changed by the user. The user may cause a one-time override of the scroll field by entering a scroll value in the command input field, and then pressing one of the Scroll PF keys. See SPF Program Reference for more information on scrolling.

Panel definitions used by the table display service contain non-scrollable text, including column headings, followed by a

"model line" that specifies the format of the scrollable data.

Attribute characters in the model line indicate whether each column is protected or unprotected (user-modifiable). Typically, the left-most column is defined as an unprotected selection field. A code entered in that field is interpreted by the dialog function to determine the particular processing for that row.

Panel Definitions

A panel definition consists of up to four sections, of which only the body is required:

1. Attribute section (optional) - defines the special characters that wi 11 be used in the body of the panel defi nit i on to represent attribute (start of field) bytes. Default attribute characters are provided, which may be overridden.

2. BodY (required) - defines the format of the panel as seen by the user, and defines the name of each variable field on the panel.

3. Initialization section (optional) - specifies the initial processing that is to occur prior to displaying the panel.

Typically used to define how variables are to be initialized.

4. Processing section (optional) - specifies processing that is to occur after the panel has been displayed. Typically used to define how variables are to be verified and/or translated.

The panel definition syntax is fully described in Chapter 5 of this document.

Dialog Services Overview 11

(20)

Panel definitions are created by editing directly into the panel library; no compile or preprocessing step is required. Each panel definition is a member in the library, and is identified by member name.

A sample panel definition is shown in Figure 5. It consists of a panel body followed by an ") END" control statement. It has no attribute, initialization, or processing sections. It uses the default attribute characters, namely:

% (percent sign) - text (protected)' field, high intensity + (plus sign) - text (protected) field, low intensity

(underscore) - input (unprotected) fi~ld,high intensity For text fields, the information following the attribute character is the text to be displayed. Text fields may contain substitutable variables, consisting of a dialog variable name preceded by an ampersand (&). The name and ampersand are replaced wi th the value of the variable prior to displaying the panel.

For input fields, a dialog variable name immediately follows the attribute'character (with no intervening ampersand). The name is replaced with the value of the variable prior to displaying the panel, and any information entered by the user is stored in the variable after the panel has been displayed.

The panel .in this example has ten input fields (TYPECHG, LNAME, ,etc.), indicated with underscores. It also has a substitutable

variable (EMPSER) withi,n a text field (on line 2). The first two lines of the panel and the arrows· preceding the input fields are all highlighted, indicated with percent signs. The other text fields are low intensity, indicated with plus signs.

Before the panel is displayed, all variables in the panel body will be automatically initialized from the corresponding dialog variables (TYPECHG, LNAME, ,etc., and EMPSER). After the panel has been displayed, the input fields will be automatically stored

into the corresponding dialog variables.

Figure 6 shows the panel as it will appear when displayed, assum- ing that the current value of EMPSER is "123456", and that the other .variables are initi.lly null.

12 SPF Di alog Management Serv ices

(21)

X---

EMPLOYEE RECORDS --- XEMPLOYEE SERIAL: &EMPSER

+ TYPE OF CHAHGEX===>_TYPECHG + (NEW, UPDATE, OR DELETE) + EMPLOYEE NAME:

+ LAST X===>_LNAME + + FIRST X===>_FNAME + + INITIAL7.===>_I+

+ HOME ADDRESS:

+ LINE 1 7.===>_ADDR1 +

+ LINE 2 7.===>_ADDR2 +

+ LINE 3 7.===>_ADDR3 +

+ LINE 4 X===>_ADDR4 +

+ HOME PHONE:

... -... ···-AR.E-A-COOE -X===~..2I:IAt...""" ..

+ LOCAL NUMBERX===>_PHNUM ~

)END

Figure 5. Sample Panel Definition

--- EMPLOYEE RECORDS --- EMPLOYEE SERIAL: 123456

TYPE OF CHANGE ===>

EMPLOYEE NAME:

LAST ===>

FIRST ===>

INITIAL ===>

HOME ADDRESS:

LINE 1 ===>

LINE 2 ===>

LINE 3 ===>

LINE 4 ===>

HOME PHONE:

AREA CODE ===>

LOCAL NUMBER ===>

(NEW, UPDATE, OR DELETE)

Figure 6. Sample Panel - When Displayed

(22)

Message Definitions

When a display service is invoked, a message may optionally be displayed with the panel, or superimposed on the panel that is currently displayed. Messages may also be written to the SPF log file via the LOG service.

Message definitions are created by editing directly into the message library; no compile or preprocessing step is required. Each member of the library may contain several messages. Messages are referenced by message id.

Each message consists of two lines. The first line contains the message id, and optionally:

• Short message text, enclosed in apostrophes (')

• Correspondi ng help panel (i f the user presses the Help PF key)

• Audible alarm indicator (yes or no).

The second line contains the long message text, enclosed in apostrophes.

If a short message is specified, it will be displayed first in the upper right-hand corner of the screen. If the user presses the Help PF key, the long message will then b~ displayed on line 3 of the screen. If the user presses the Help key again, tutorial mode will be entered.

If a short message is not specified, the long message will be displayed first (on line 3). If the user then presses the Help key, tutorial mode will be entered.

Variable names, preceded by an ampersand (&), may appear anywhere within the short and long message text.

Figure 7 shows an example of a member in the message library.

This member contains all mess~ge ids which begin with "EMPX21".

The message definition syntax is fully described in Chapter 5 .

EMPX210 'INVALID TYPE OF CHANGE' .HELP=PERS033 • ALARM=YES 'TYPE OF CHANGE ^~tUSTBE NEW, UPDATE, OR DELETE.'

EMPX213 'ENTER FIRST NAME' .HELP=PERS034 .ALARM=YES 'EMPLOYEE NAME MUST BE ENTERED FOR TYPE OF CHANGE = NEW OR UPDATE.' EHPX214 'ENTER LAST NAME' .HELP=PERS034 .ALARH=YES 'EMPLOYEE NAf"tE MUST BE ENTERED FOR TYPE OF CHANGE = NEW OR UPDATE.' EHPX215 'ENTER HOME ADDRESS' .HELP=PERS035 .ALARM=YES 'HOME ADDRESS MUST BE ENTERED FOR TYPE OF CHANGE = NEW OR UPDATE.' EMPX216 'AREA CODE INVALID' .ALARM=YES

'AREA CODE &PHA IS NOT DEFINED. PLEASE CHECK THE PHONE BOOK.' EHPX217 '&EMPSER ADDEO'

'EMPLOYEE &LNAME, &FNAME &I ADDED TO FILE.' EHPX218 '&EMPSER UPDATED'

'RECORDS FOR &LNAHE, &FNAME &1 UPDATED.' EMPX219 '&EMPSER DELETED'

'RECORDS FOR &LNAHE, &FNAME &I DELETED.'

Figure 7. Sample Member in Message Library

14 SPF Di alogManagement Serv ices

(23)

TABLE SERVICES

Table se ... vices allow sets of dialog va ... iables to be maintained and accessed. A table is a two-dimensional a ... ay of information in which each· column corresponds to a dialog variable, and each row cQntains a set of values for those variables.

A~~xample is shown in Figure 8. In this table, the variables that defi ne the c.olumns a ... e:

EMPSER IN.AME FNAME I PHA

- 'Employe~ Serial Numbe ...

- Last Name - Fi rst Na.me - Middle Initial

- Home Phone: A ... ea Code . PHNUM Home Phone: Local Number

EMPSER lNAME 598304

172397 813058 395733 502774

Roberston Smith Russell Adams Caruso

Figu ... e 8. Sample Table

Table Residency

FNAME Richard Susan Charles John Vincent

I P A l Q J

PHA PHNUM 301

301 202 202 914

840-1224 547-8465 338-9557 477-1776 294-1168

A table may be defined as tempo ... a ... y 0 ... permanent. A tempo ... ary table is created in virtual storage, and deleted upon completion of processing. A permanent table resides on di ... ect access stor-

age~ It may be opened for update or for read-only access, at which time the entire table is read into vi ... tual sto ... age. An ENQ

is automatically issued to prevent multiple access to a table which is being updated.

Permanent tables are ma inta i ned in one or more table Ii brari es, in whi ch each member contai'ns an enti re table. The ENQ that occurs when a table is ... ead into virtual storage applies only to that table (member); not the entire library.

When a" permanerittable i sope.ned for processi ng, it is read from a .tabla input library. When the table is saved, it is written to a table output library that may be different from the input lib ... ary.

The input and output libraries should be the same if the updated version of the table is to be reopened for further processing by the same dialog. See discussion of library setup in Chapter 3 for specification of input and output libraries.

Accessing of Data

The variable names that define the columns bf a tabli are specified when the table ;s created. At the same time, one or more columns (variable names) may be specified as keys for accessing the table. For the table shown in Figure 8, EMPSER might be defined as the key val"'; able. 0 ... EMPSER and lNAME might both be defined as keys, in which case a row would be found only if EMPSER and lNAME both match the current values of those vari abIes.

Dialog SerVices Overview 15

(24)

A table may also be.accessed by one or more "argument" variables, that need not b~key variables. The variabl~s'that constitute the search argument may be defined dynamically by ~eans of the TBSARG and TBSCAN'services.

In addition, a table may 'be accessed by "current row pointer"

(CRP). When a table is~pened, the ~RPis atitomaticelly positioned to TOP -- ahead of the first row. The table may be scanned by mov-

ihg the CRP forward or back. A row.is retrievedea~htime the CRP 1 s moved.

When a row is retrieved from a table, the contents of the row are stored into the ~orresponding dialog variables. ^Wh~na row is stored (updated or added), the cur~ent contents ~f the dialog var-

i abIes are saved in thatr,ow.

When a row is stored, a list of "extension" variables may be spec- ifi'ed',byha'me . This allows the varl ables i nthat row to be extended beyond what was specified wherr the table was created. A list of extension variable names for a row may be obtained when the row is read. The list of extension variables must be respeci- fied whenever the row is rewritten. Otherwise the extensions to the rOw will be deleted.

General Services

The following services operate on an entire table:

TBCREATE Create a new table and open it for processing.

TBOPEN Open an existing (permanent) table for processing.

TBQUERY Obtain information about a table.

TBSAVE Save a permanent copy of a table without closing.

TBCLOSE Close a table, and save a permanent copy if the table was opened in L.JRITE mode.

TBENO Close a table without saving.

TBERASE Oel~te a permanent table from the table library.

Temporary tables are created by TBCREATE (NOWRITE mode> and deleted by eitherTBEND or TBCLOSE. A new permanent table is created by TBCREATE (WRITE mode); This simply creates the table in virtual storage.· It does not become permanent until it is stored on d~rectaccess storage by either TBSAVE or TBCLOSE.

An existing permanent tabl9 is opened and read into virtual storage by TBOPEN. If the table ;s to be updated (WRITE mode), the new copy is saved by either TBSAVE or TBCLOSE. If it is not to be updated CNOWRITE mode), the virtual storage copy is delated by either TBEND or TBCLOSE.

Row Operations

The following services operate on a row of the table:

TBAOD Add a new row to the table.

TBDEtETE Delete a row from the table.

TBGET Retrieve a row from the table.

TSPUT Update an existing row in the table.

16 SPF OJ alog ManagementServi ces

(25)

-"~~'" .,., •• , •• , ... " .... " + ••••••••• , ... ' ' ' , • • ~ •• ' ... ' - ' " ••• .~. ~" •• ,.

TBMOD TBEXIST TBSCAH

Update a row ;n the table if it exists (if the keys match); otherwise, add e new row to the table.

Test for the exi stence of a row' (by key).

Search a table for a row that matches a list of

"argument" variables, and retrieve the row.

TBSARG Establish a new search argument for use with TBSCAN.

TBTOP S"t CRP to TOP (ahead of the f1 rst row).

TBBOTTOM Set CRP to BOTTOM and retrieve the last row.

TBSKIP Move the CRP forward or back by a specified number of rows, and then retrieve a row.

TBVCLEAR

.' .' ... ' .... -... '.-' ... " ... ---:-'.-.. ~, ... --^...^,-^... Set dialog variables (that correspond to vari.ables in

the table) to null.

..-.. - ... -.l..--., ... - .. -~ .. ---.. -.... -... ~ .... --.-... ,.-.. -... -.. ,._ ... ~ ... ' .... ' ... _ ... _ .... ,_" ... , _____ ... , .. " ... ~~ ... .

S~ora9' Reguirements

The length of any row in a table cannot exceed 65,536 bytes. The length'can be computed as follows:

Row size

=

²² ⁺^4a ⁺^b ⁺^9c

where:

a

=

total number of variables in the row' including extensions b

=

total length of variable data in the row

c

=

total number of extension variables in the row

The total table size is the sum of the row lengths, plus the length of the data table control block (OTCB). The length of the DTCD can be computed as follows:

DYCD length

=

88 + 16d where:

d

=

total number of columns (not including extension variables) in the table

The number of tables that may be processed at one time is limited only by the amount of available virtual storage.

(26)

FILE TAILORING SERVICES

File tailoring services read,skel,eton files from a library and write tailored output that may be used to drive other functions.

Frequently, file tailo~ing is used to generate job files for batch execution.

The file tailoring output maybe directed ~o a library or sequential file that has been specified by the dialog function, or it may be directed to a temporary sequential file provided by SPF.

The name of the temporary file is available in system variable ZTEMPF. For MVS, ZTEMPF contains a data set name; for VM it con-

ta ins a f i 1 e name. '

Each skeleton fi Ie is read record by record. Each record is scanned to find any dialog variable names (preceded by an ampersand). When. variable name is found, its current value is sub-

stituted. .

Skeleton file records may also contain statements that control processing. These provide the ability to:

• Set dialog variables

• Imbed other skeleton files

• Conditionally include records

• Iteratively process records in which variables from each row of a table are substituted.

In the latter case, file tailoring services,will read.the selected rows from the ~able. If the tabl~ was already open (prior to processing thaskeleton), it will remain open with the CRP positioned to TOP. If the table was not already open, file tailoring will open it automaticallY and close it upori completion of processing.

A sample skeleton file is shown in Figure 9. It contains MVS job control language (JeL) for an assembly andoptiona1 load-go. In an MVS environment, the tailored output could be submitted to the background for execution. In a VM environment, it could be punched to an MVS machine for batch execution.

The sample skeleton references several dialog variables (ASMPARMS, ASNIN, MEMBER, etc.). It also illustrates use of select statements nlSEL" and ") ENDS EL " t o conditionally include records. The first part of the example has nested selects to include concatenated macro libraries if the library names have been specified by the user (i.e., if variables ASMMAC1 and ASMMAC2 are not equal to the null variable Z).

In the second part of the example, select statements are used to conditionally execute a load-go step. An imbed statement, ")IM", is used to bring in a separate skeleton for the load-go step.

The file tailoring services are:

FTOPEN FTINCL FTCLOSE FTERASE

Prepare the file tailoring process, and specify whether the temporary file is to be used for output.

Specify the skeleton to be used, and start the tailoring process.

End the file tailoring process.

Erase (delete) an output file

tailoring. created by file

18 SPF D,i alogManagem,ent·· Serv ices

(27)

IIA5M EXEC PGM=IFOXOO,REGION=128K, II PARM=(&ASMPARMS)

IISYSIN DO DSN=&ASMIN(&MEMBER),DI5P=SHR IISYSLIB DO DSN=SYS1.MACLIB,DISP=SHR

)SEL &ASMMACl ^~=&Z

II DO DSN=&ASMMAC1,DISP=SHR )SEL &ASMMAC2 ~= &Z

II DO DSN=&ASMMAC2,DISP=SHR )ENDSEL

)ENOSEL

IISYSUTl DO UNIT=SYSOA,SPACE=(CYL,(S,2»

IISYSUT2 DO UNIT=SYSDA,SPACE=(CYL,(2,1»

IISYSUT3 DO UNIT=SYSOA,SPACE=(CYL,(2,1»

IISYSPRINT DO SYSOUT=(&ASMPRT)

)CM IF USER SPECIFIED "GO", WRITE OUTPUT IN TEMP DATA SET )CM THEN lUBED "LINK AND GO" SKELETON

)5EL &GOSTEP = YES

·--·-1/515(;0 DD I';)SI~-&&&&OOJSET,\R'iIT-Sn)IJA ,SPACE=(CYL .... (.2..Jl.tL .. _ .. _

II DlSP=(MOD,PASS)

)IM LINKGO )ENDSEL

)eM ELSE (NOGO), WRITE OUTPUT TO USER DATA SET )SEL &GOSTEP = NO

IISYSGO DO DSN=&ASMOUT(&MEMBER),DISP=OLD )ENDSEL

11*

Figure 9. Sample Skeleton File

(28)

VARIABLE SERVICES

Variable. services allow a function to define and use "dialog variables." A dialog variable is a character string that may vary in length from zero to 32K bytes. It is referenced symbolically, by name. The name may be from one to eight characters in length, composed of alphameric characters (A-Z, 0-9, #, $, or ~) of which the first must not be numeric.

Dialog variables serve as the main communication vehicle between dialog functions and SPF services. They may also be used to com- municate between a function and another function.

Referencing Variables from Command Procedures

From command procedures (ClISTs and EXECs), the variables are always referenced implicitly. All ClIST and EXEC2 variables are automatically treated as dialog variables; no special action is required to define them to SPF. The variables are created dynamically either by execution of the command procedure or by the SPF services that the command procedure uses. ClIST example:

SET &AAA

=

¹

ISPEXEC DISPLAY PANEleXYZ) SET &CCC

=

&BBB + &AAA Same example in EXEC2 language:

&AAA

=

¹

ISPEXEC DISPLAY PANEl(XYZ)

&CCC

=

&BBB + &AAA

Variable AAA is created by the command procedure, simply by set- ting it to a value. The DISPLAY service is then invoked to display panel XYZ. If panel XYZreferences variable AAA, its value may be displayed or changed by the user, depending on how the panel is defined.

The same panel may allow the user to enter a value for another variable (BBB). If a variable of that name does not already exist, a ClIST or EXEC2 variable will be created automaticallY.

Its value may then be referenced in subsequent statements.

Referencing Variables from Programs

From program functions (compiled modules), dialog variables that are to be referenced by the function may be explicitly defined to SPF. The function calls the VDEFINE service to identify the name, address, format, and length of one or more variables within the program to be used as dialog variables. Example in Pl/I language:

DECLARE AAA CHAR(S);

CALL ISPlINK e'VDEFINE', 'CAAA)', AAA, 'CHAR', 8);

CALL ISPLINK ('DISPLAY', 'XYZ ');

Variable AAA is declared as an internal program variable (character string, length 8). The program calls the VDEFINE service to define it as a dialog variable. The program then calls the DIS- PLAY service to display panel XYZ. If panel XYZ references variable AAA, its value may be displayed or changed by the user, depending on how the panel is defined.

If panel XYZ allows the user to enter a value for another vqriable (BBB) and the program has not defined a dialog variable of that name, storage for the variable will be allocated automatically.

BBB is then considered an implicit dialog variable associated with this function. The program can access BBB only via an SPF 20 SPF Dialog Management Services

(29)

se~vice (VCOPY), since the prog~am does not.have add~essability

to the implicit area. But if the p~ogram invokes an SPF se~vice,

the se~vice will be able to access and/o~mod;fy the va~iable (see

"Va~iable Access f~om Se~vices").

The VDElETE se~vlce performs the opposite function of VDEFINE. It may be called to specify the names of one o~ mo~e p~og~am va~i

abIes that a~e no longer to be t~eated as di alog va~i abIes.

Va~iables msy be defined wheneve~ desi~ed. Defining a va~iable

wi th the same name as exi sti ng functi on variable causes the prev;- ous occurrences to be masked out. Deleting addressibility to a variable causes the previous occu~rence (if any) to be restored.

This allows a subroutine to use different variables with the same name as used in the main routine.

-. . . d • • • • • • • • • • • • • • • • • • • • • _ • • • • • • • • • • • • - - •• Seope af Vari ablQ5

The scope of a dialog variable may be limited to an individual function or shared between functions.

When a variable ;s created, it is associated with the function that is ^cu~rentlyin control and may not be referenced by other functions. When the function completes execution, all of its var-

iables (defined and implicit) are automatically deleted.

When a function invokes a lower level function via the SELECT service, the lowe~ level function has its own set of va~iables

(which may have the same names as variables belonging to other functions). Again, the lower level function may not access the

va~iables of the invoking function.

Data may be passed f~om one function to another via parameters.

In addition, the~e are two mechanisms that allow sharing of variables between functions:

• Sha~ed variable pool

• Use~ profi Ie

The shared va~iable pool allows communication of variables between functions that belong to the same application. A function may copy ona or more of its variables into the shared pool by means of the VPUT service. Another function may then obtain a copy of the variable by means of the VGET service.

The user profile contains variables that a~e automatically retained across sessions for each use~. Again, a function may use the VPUT and VGET services to copy ^va~iablesto/from the user profile. Variables in the profile a~e limited to 255 bytes in length.

Note: The use~ profile contains variables that are used by the SPF program development facility. New dialogs may access and update those variables via VGET and VPUT. Generation of new variables in the profile should be approached with caution, since the names must not confl i ct wi th those already used by SPF. See SPF Installation and Customization fo~ a list of va~iable names in the profile.

Figure 10 shows an example of variable sharing. Function A uses VPUT to copy its variables (defined O~ implicit) to the shared variable pool and/or user p~ofile, and function Buses VGET to obtain the variables.

In this document, the terms function variables, shared variables, and profile variables a~e used to distinguish the scope and acces- sibility of the variables~ The term dialog variable includes all

th~ee. .

Dialog Services Ove~view 21

(30)

VPUT

~---,

~---/

~---,

~---/

FUNCTION A FUNCTION VARIABLES

• DEFINED

• IMPLICIT

SHARED VARIABLES

PROFILE VARIABLES

FUNCTION B FUNCTION VARIABLES

• DEFINED

• IMPLICIT

Figure 10. Sharing Variables via VPUT/VGET

Variable Access from Services

VGET

,

/

When variables are accessed by SPF services~ the shared variable pool is logically concatenated to the set of function variables.

The search order is:

1. Defined function variables (if any) 2. Implicit function variables (if any) 3. Shared variebles

Only the variables for the current function (i.e., the function that invoked the service) are searched. If neither a function variable nor a shared variable of the specified name is found, the current value of the variable is assumed to be null.

Figure 11 shows the logical concatenation of the shared variable pool when a variable is fetched from a service.

When a variable is created or updated by an SPF service, it is stored as a function variable associated with the current function. It is stored in the function's defined area if a variable of that name has been explicitly defined. Otherwise, it is stored in the function's implicit area.

In general, services do not store variables directly into the shared pool nor the user profile. The exceptions are:

• The VPUT service, which is used explicitly for the purpose of copying variables into the shared pool or user profile.

• The SELECT service, when a ,sel~ction menu (panel) definition references variables in addition to those required by SELECT.

See description of selection menus in Chapter 5.

(31)

FETCH

r---,

. - - - - /

DIALOG SERVICE

CURRENT FUNCTION

STORE

-==--=--=---.

-'--"f)ff-lNE-&-_·"·_·_·- -._ .

.f-.---

~ VARIABLES 'I'~

~

^IMPLICIT

~

VARIABLES '~---"

SHARED VARIABLES

Figure 11. Service Access to Variables

Representation of Variables

Information entered by a user on a panel is in character string format. All dialog variables remain in character string format when stored as implicit function variables, or when stored in the

shared pool, the user profile, or SPF tables.

Defined variables, however, may be translated to fixed binary or to a bit string when stored internally in a program module. The internal format is specified when the variable is defined (via VDEFINE). The translation occurs automaticallY when the variable is stored by an SPF service. A translation back to character string format occurs automatically when the variable is fetched.

When a defined variable is stored, either of two errors may occur:

• Truncation - if the current length of the variable is greater than the defined length within the module. -

• Translation - if the variable is defined as other than a character string, and the external representation has invalid characters.

In either case, the SPF service issues a return code of 16.

(32)

System Variables

Certain variable names are reserved for use by the system. They all begin with the letter HZ". Dialog developers should avoid names whi ch begi n wi th "Z" when choosi ng di alog vari able names.

Some system variables cannot be modified. They provide the dialog with information about the environment, such as user id, current date and time, and terminal characteristics. These variables reside in the shared variable pool, and may be obtained via the VGET service.

These variables are:

ZUSER - User id

ZPREFIX - TSO user prefix²

ZLOGON - Name of TSO LOGON procedure² ZTIME - Time of day (format hh:mm) ZDATE - Current date (format yy/mm/dd) ZJDATE - Julian date (format yy.ddd) ZDAY - Day of the month (2 characters) ZMONTH - Month of the year (2 characters) ZYEAR - Year (2 characters)

ZTERM - Terminal type ZKEYS - Number of PF keys

ZTEMPF - Name of temporary file for file tailoring output Z - Null Variable

Other system variables are used for communication of special information between the dialog and the dialog manager. These variables are:

ZERRMSG - Error message id

ZERRSM - Short error message text ZERRLM - Long error message text

ZERRHM - Name of help panel associated with error message ZHTOP - Top page (panel name) in tutorial

ZHINDEX - First index page in tutorial

ZTDTOP - Current top row upon return from table display The first four are set by SPF services whenever an error condition is encountered (return code of 12 or higher). They are stored in the function variable area.

The variables ZHTOP and ZHINDEX specify the top level table of contents and first index ~age, respectively, in the tutorial.

They should be initialized' by the application in the event that the user enters the tutorial via the Help PF key and then requests TOP or INDEX. These two variables should be stored in the shared vari able pool.

2 In the VM environment, ZPREFIX has the same value as ZUSER, and ZLOGON ha san u 11 va 1 u e .

24 SPF Dialog Management Serv ices

System Productivity Facility Dialog Management Services

Program Product