Mainframe - Parte 7 - Apostila CICS

Índice

Unit 1 - What is CICS ?

CICS functions 2

Online transaction processing—transactions 2

CICS components and domains 3

Single-region and CICSPlex setups 5

Unit 2 - Managing data and resources

The EXEC interface 6

API Commands 7

CICS system definition 7

Transactions CEDA, CEDB e CEDC 8

List and Group 8

Usign de CEMT Commands 9

Terminal Definition and Management 10

File control 11

CICS-supported databases 12

Architecture example overview 14

Unit 3 – CICS Supplied Transactions

CEMT – Mater Terminal 16

CEMT  Option Discard 17

CEMT  Option Inquire 18

CEMT  Option Inquire – Example 19

CEMT  Perform and Set 20

CEMT  SET PROGRAM – Example option NEW 21

CECI - Command-Level Interpreter 22

CECI - Command-Level Interpreter - Sintax 23

CECI - Command-Level Interpreter - Process the Command 23

CEBR - Temporary Storage Browse 24

CEDA - Resource Definition Online 25

CEDA - Resource Definition Online – Example: DEFINE TRANSACTION 26 CEDA - Resource Definition Online – Example: INSTALL TRANSACTION 27

CEDF Execution Diagnostic Facility 28

CEDF - Beginning an EDF session (single-screen mode) 30

What does EDF display? 31

CEDF – Working Storage 35

CEDF – EIB Display 37

CEDF – Swith hex/char 37

Unit 4 – Basic mapping support

Basic mapping support 39

Defining map fields: DFHMDF 40

Defining map fields  Options 42

Defining the map set DFHMSD and map DFHMDI 52

The symbolic input map 54

The symbolic output map 55

An input-output example 56

An input-output example (cont.) 58

Sending and receiving maps – Example 58

Preparing maps 59

Unit 5 - CICS application programs – APIs

A CICS program preparation procedure 62

The translation process - Example 63

COBOL statements not allowed in CICS programs 64

EIB - EXEC interface block 65

The DFHAID copy member 68

The DFHBMSCA copy member 69

Pseudo-conversational processing 71

Conversational processing 73

CICS API commands 74

NOHANDLE option 75

RESP and RESP2 options 76

HANDLE ABEND 87 HANDLE CONDITION 79 IGNORE CONDITION 81 RETURN 82 ASKTIME 85 FORMATTIME 86 FORMATTIME – Example 90 ASSIGN 91 ASSIGN – Example 104 BIF DEEDIT 105 DELAY 106 DELAY – Examples 108 SEND TEXT 109 SEND CONTROL 114 SEND MAP 118 HANDLE AID 123 RECEIVE MAP 125

Temporary storage queues 127

READQ TS 128 DELETEQ TS 130 WRITEQ TS 131 LINK 134 XCTL 137 START 139 RETRIEVE 144 COMMAREA 147 STORAGE VIOLATION 149 LINK x XCTL  RETURN 150

CALL x LINK x XCTL  GOBACK x STOP RUN x RETURN 150

READ 153 READNEXT 160 READPREV 162 DELETE 164 WRITE 167 REWRITE 170 UNLOCK 172 STARTBR 174 SYNCPOINT 180

Topics:

•

Introducing CICS

•

Online transaction processing

•

The structure of CICS

CICS functions

Online transaction processing—transactions

Each transaction in CICS has a four-character transaction identification (TRANSID) which

describes the function that the transaction performs.

CICS components and domains

When a TRANSID enters the

system, XM starts a task for

that transaction request to be

processed. XM does this by

first searching the Program

Control Table (PCT) to validate

the TRANSID.

XM then calls the Storage

Manager (SM) to create a

control block called the Task

Control Area (TCA) to keep

track of task processing. A

separate TCA is associated

with each task.

Notes:

During processing, a task alternates among these different states:  Ready to run

 Running  Waiting

CICS components and domains

To locate the required

application program, the PG

searches the

Processing Program Table

(PPT) for the name of the

module to receive control.

Single-region and CICSPlex setups

As you have learned, CICS manages an area of storage called a region.

In some systems, CICS can manage more than one region. These

different regions are identical except for the system or data function they

perform. Each region can be devoted to particular types of transactions or

applications while communicating easily with other regions in the system.

Notes:

CICS can be used in any business that requires the power of a mainframe to operate efficiently. Different CICS architectures suit different business needs.

Unit 2 - Managing data and resources

Topics:

Domains and resources

Major domains

The EXEC interface

•

Resource definition

CICS system definition (CSD)

Terminal definition and management

Structure of a CEDA command

Conserving and sharing resources

Data access and storage

The EXEC interface

The EXEC interface block (EIB) is a control block associated with each task in this command level.

API Commands

The basic format for API

commands in CICS is:

EXEC CICS command

option(arg)

The command argument is the

operation required, and the

optional option(arg) is a value

such as length(data value) or

file(name).

Some of the more common

commands are shown at the

right.

Transactions CEDA, CEDB e CEDC

There are three major transaction groups in RDO:

• CEDA allows users to modify

both the active CICS system and the CSD.

• CEDB allows limited

modification of the CSD (all but INSTALL) and read-only commands.

• CEDC allows only read-only

commands.

List and Group

Storage of CICS resource definitions in CSD is hierarchical.

First, CICS organizes related resources into named groups. Then, these groups of

resources are themselves stored in a list that is installed when CICS TS is started.

Using the CEMT commands

Users can get information

about resources and their

definitions in a few different

ways. One is through the

master terminal program.

The TRANSID for the

master terminal program is

CEMT.

A CEMT transaction has

four types of commands, as

shown to the right.

Terminal definition and management

When input is received from

a terminal, the message is

stored in a Terminal

Input/Out Area (TIOA).

A unique 4-character

identifier for the terminal

Notes:

Each TCTTE contains:

 A unique 4-character identifier for the terminal  The type of terminal

 The terminal status

 A pointer to the buffer (TIOA) containing any pending input or output messages  An area reserved for use by CICS during processing

File control

When a CICS application

program needs some data,

it sends a request to the

FCP by issuing a CICS file

control command.

A file I/O command

contains:

– The words EXEC CICS (like all CICS commands) – The function (for example,

READ) – The file name

– The name of the record area in the program’s working storage, and its length

CICS-supported databases

The two most common

types ofdatabases are

relational and

hierarchical.

CICS supports both

types ofdatabases,

primarily through these

IBM applications:

DB2, developed in the

1980sIMS, used since

the early 1970s

Notes:

The database application that a business selects depends directly on business needs.

Although DB2 is widely popular in mainframe use, some businesses (financial institutions in particular) have found it expensive and difficult to adapt their existing data resources entirely to DB2. Therefore, IMS is still widely used in businesses that have need for a large and accessible database with well-defined structural and maintenance requirements.

The language used for data manipulation in IMS is Data Language I (DL/I).

DL/I enables the definition of data structures and the relation of structures to applications, and the loading and reorganization of these structures. DL/I can enable application programs to retrieve, replace, delete and add segments to databases

There are other important interfaces that are helpful when using IMS as a primary database structure. In many systems, CICS online programs interface with the IMS Database Control (DBCTL) facility. In addition to the CICS EXEC / EXEC SQL similarity, CICS applications that can process DB2 tables can also access any SQL data manager and file control.

That is, CICS applications can use SQL, and any SQL database manager can access CICS applications. This means that DB2 data can be accessed from a CICS TS for OS/390 environment.

CICS TS for OS/390 comes with anattachment facility that allows you to operate DB2 with CICS.

Through this facility, CICS applications can access DB2 data while operating within the CICS TS for OS/390 environment. Thus, the CICS applications can access both DB2 and CICS data.

CICS coordinates the recovery of both DB2 and CICS data if transaction or system failure occurs.

Through the DB2 attachment facility API, the connection between CICS and DB2 can be created or terminated at any time. This connection and disconnection can be set up to occur automatically.

You can also start and stop CICS and DB2 independently.

The DB2 system can be shared by several CICS systems, but an individual CICS system can be connected to only a single DB2 system at a time.

Using the CICS attachment facility

CICS application programs make requests to DB2 in the form of Structured Query Language (SQL) statements.

When a CICS application issues an QL request, the CICS resource manager processes the request and passes control to the CICS attachment facility.

1) A transaction thread is scheduled by the attachment facility.

2) DB2 checks the authorization for the request and creates control blocks for it.

3) When the SQL request has been completed, DB2 passes data back to the CICS attachment facility, and the CICS application program regains control.

You can use RDO to declare a particular DB2 database available to your CICS TS system.

Defining database resources online means that you do not have to shut down the CICS-DB2 attachment facility in order to make changes to CICS-DB2 resources.

This allows continuous availability for both systems.

Using RDO to define DB2 resources as CICS-managed resources also has the advantage of providing a consistent end-user interface.

This means that users can use familiar CICS transaction identifiers to perform tasks such as installing and manipulating database entries.

Architecture example overview

Notes:

NCPs are key for routing communication as they manage the communication traffic between terminals and CICS.

NCPs also route information between the VTAM-serviced OS/390 images and connected CICS regions using ISC (intersystem communication).

Transaction initiation

A customer goes to an ATM and inserts a bankcard. The ATM requests the PIN number and other information needed for the transaction. The customer enters the information at the PIN pad (1).

The information is routed to the remote NCP (2), which in turn takes it through the network to the mainframe switch and then to the system NCPs (3), which are tied to miniprocessors.

After VTAM establishes a session with the CICS TOR, CICS gives the transaction a name and sends it back through VTAM to the appropriate AOR, which might or might not be in the same CICS system. After CICS determines the source of the transaction and names it, the application required for processing the transaction is located by the AOR.

The AOR also initiates updates by scheduling a program specification block (PSB). The PSB is sent by CICS to IMS, where it is accepted by DBCTL.

The DBCTL controls the different functions involved in the database update.

Like CICS, IMS/DBCTL can be split into regions, which improves speed and efficiency in updating and accessing data.

A multiregion setup consists of these four regions:

Unit 3 – CICS Supplied Transactions

Topics:

CEMT - Master Terminal

CECI - Command-Level Interpreter

CEBR - Temporary Storage Browse

CEDA - Resource Definition Online

CEDF

- Execution Diagnostic Facility

CEMT – Mater Terminal

Use CEMT to invoke all the master terminal functions.

The master terminal program provides dynamic user control of the CICS system. By using this function, an operator can inquire about and change the values of parameters used by CICS, alter the status of the system resources, terminate tasks, and shut down the CICS system.

Notes:

Use CEMT to invoke all the master terminal functions.

The master terminal program provides dynamic user control of the CICS system. By using this function, an operator can inquire about and change the values of parameters used by CICS, alter the status of the system resources, terminate tasks, and shut down the CICS system.

After you have initiated the CEMT transaction, you need not reenter CEMT on subsequent requests, because the identifier is implied at the beginning of any further request. However, if you are using the system console, you must always start each master terminal request with CEMT.

The scope of a particular DISCARD, INQUIRE, SET, or PERFORM command can be limited by a combination of several levels of security checking.. CEMT calls the exec interface programs to process the user's commands, in much the same way as CECI or a user's command-level program would. The resource security and the command security used by the command-level programming interface are thus applicable to the master terminal user

CEMT

 Option Discard

There are two ways to discard a resource:

1) If you know the name of the resource that you want to discard, type:

CEMT DISCARD resourcetype(resourcename)

2) If you do not know the name of the resource, type:

CEMT INQUIRE resourcetype

Then type "D" as shown and press ENTER.

The DISCARD command allows you to remove an installed resource definition

Notes:

The DISCARD command allows you to remove an installed resource definition and its corresponding catalog entry from an active CICS system.

DISCARD does not affect the CICS system definition (CSD) file, and you can therefore reinstate the resource using CEDA INSTALL(resourcename). DISCARD commands require ALTER access to the resource to provide similar security to that for SET commands (which use UPDATE access). You cannot discard resources that are currently in use or are CICS owned resources (beginning with "DFH" or "C"). If you do not know the name of the resource, type:

CEMT INQUIRE resourcetype

1. A CEMT INQUIRE display can be used to discard more than one entry at a time. If you overtype another value as well as typing 'D', the 'D' is ignored.

CEMT

 Option Inquire

You can inquire about any of the displayed options by typing its keyword after INQUIRE on the command line INQUIRE PROGRAM

Notes:

Most CEMT requests either inquire about (INQUIRE), or change (SET) the status of one or more named instances of a resource (such as a terminal), a particular subgroup of resources (such as a class of terminals), or all resources of a particular type (such as all terminals).

The INQUIRE command causes the status of the specified resources to be displayed. The SET command makes the changes that you specify, and displays the new status of the resources. No changes are made if there are syntax errors in the SET command.

If, for example, you want to inquire about a resource, enter INQUIRE (or a suitable abbreviation) on the command line. The keywords you can use with CEMT INQUIRE are described in the rest of this section. If you want to perform those functions that are not concerned with resource status, enter PERFORM (or a suitable abbreviation) on the command line.

And finally, if you want to change the attributes of a resource, enter SET (or a suitable abbreviation) on the command line.

CEMT

 Option Inquire - Example

CEMT I PROG(AD*)

CEMT I TRAN(MOD*)

Notes:

INQUIRE PROGRAM returns information about the programs, map sets, and partition sets that are defined to your system:

Length(value)  displays the size of the program in bytes

Program(value) indicates that this panel relates to a PROGRAM inquiry and displays an 8-character program identifier (1-8 characters), which is the name of a specific program entry in the table of installed program definitions.

Rescount(value)  displays a 3-character string identifying the number of separate invocations of this program that are taking place at the time of this inquiry

Usecount(value)  displays a 10-character string identifying the total number of times the program has been executed since the start of the current CICS session.

Status  displays whether the program is available for use. The values are: Enabled  The program is available for use.

Disabled  The program is not available for use.

INQUIRE TRANSACTION returns information about transaction definitions:

Transaction(value)  indicates that this panel relates to a TRANSACTION inquiry and displays a 4-character transaction identifier

Program(value)  displays an 8-character string identifying the name of the first program to be executed when this transaction is started

Status  displays whether the transaction is available for use. The values are: Enabled  The transaction is available for use.

CEMT

 Perform and Set

Notes:

The CEMT PERFORM commands are not concerned with resource status. They are used to:

 Initialize and terminate the shared class cache, and set its attributes (PERFORM CLASSCACHE)  Publish or retract all the beans installed in a CorbaServer; or scan a CorbaServer's deployed JAR

file directory for new or updated deployed JAR files (PERFORM CORBASERVER)

 Cause the CICS timeout delete mechanism to be invoked immediately (PERFORM DELETSHIPPED)

 Publish or retract beans installed in a deployed JAR file (PERFORM DJAR)  Dump and continue processing (PERFORM DUMP or PERFORM SNAP)  End an affinity owned by CICS (PERFORM ENDAFFINITY)

 Reset the date and time of day (PERFORM RESET)

 Rebuild the RACF resource profile (PERFORM SECURITY REBUILD)  Shut down the CICS region (PERFORM SHUTDOWN)

 Request statistics to be recorded (PERFORM STATISTICS RECORD).

The SET command changes the status of one or more named instances of a resource (such as a terminal), a particular subgroup of resources (such as a class of terminals), or all resources of a particular type (such as all terminals).

The SET command makes the changes that you specify, and displays the new status of the resources. No changes are made if there are syntax errors in the SET command.

CEMT

 SET PROGRAM – Example option NEW

Change the attributes of installed programs.

Notes:

NEwcopy

CICS is to use a new copy of the program whenthe program ceases to be in use by any transaction. (You can determine whether a module is in use from the RESCOUNT option in an INQUIRE PROGRAM command; a value of zero means the program is not in use.) It is possible for CICS to replace the program with the new version during a single transaction, at a point when one use of the program has completed, and a subsequent use has yet to start.

PHasein

CICS is to use a new copy of the program now for all new transaction requests. CICS continues to use the old copy for all currently running transactions until they have finished (RESCOUNT equal to zero). CICS loads the new version either from the DFHRPL library concatenation or uses an LPA-resident version, depending on the PRIVATE or SHARED options. PRIVATE is the default setting. Note: PHASEIN cannot be specified for a program specified with the HOLD option or for a JVM program.

PHASEIN performs a REFRESH PROGRAM function to inform the loader domain that a new version of the program has been cataloged and that this version of the named program should be used in all future ACQUIRE requests.

Until the program goes to a zero RESCOUNT and a subsequent ACQUIRE PROGRAM has been performed, CEMT INQUIRE PROGRAM ( ) will return information on the first copy of the program.

CECI - Command-Level Interpreter

Notes:

Use CECI, which invokes the CICS command-level interpreter, to enter an EXEC CICS command, check its syntax, and modify it if necessary. In most cases, you can also process the command.

For details of how to use the CECI transaction, see the CICS Application Programming Guide, which includes an example of a complete session with CECI.

Start the transaction by entering CECI on the command line of the screen, as follows: CECI  Press ENTER. You get a list of all EXEC CICS commands.

Alternatively, you can enter CECI together with the name of the command in which you are interested, and bypass the full list of commands; for example:

CECI - Command-Level Interpreter - Sintax

CECI - Command-Level Interpreter - Process the Command

1

2

CEBR - Temporary Storage Browse

Use the CEBR transaction to browse temporary storage queues and

to delete them.

You start the CEBR transaction by entering the transaction identifier

CEBR, followed by the name of the queue you want to browse.

You can type other queue here!

You can use PURGE command to delete queue!

Notes:

You can also use CEBR to transfer a transient data queue to temporary storage in order to look at its contents, and to recreate the transient data queue when you have finished. The CEBR commands that perform these transfers allow you to create and delete transient data queues as well.

Remember that:

 browsing of Temporary Storage queues retrieves the next record, following whichever record has most recently been retrieved by ANY active task. This is can lead to confusion if for example an EXEC CICS READQ NEXT and a CEBR transaction attempt to work with the same Temporary Storage queue at the same time.

 transient data queue reads are destructive. If you read a transient data queue that is being used on an active system by applications, this is likely to cause problems.

If the queue name includes lower case characters, ensure that upper case translation is suppressed for the terminal you are using, and then enter the correct combination of upper and lower case characters.

CEDA - Resource Definition Online

Notes:

With CEDA, you can update both the CICS system definition (CSD) file and the running CICS system. CEDA provides the following functions:

 ADd Adds a group name to a list, and creates a new list if the list did not already exist.  ALter Changes some of the attributes of an existing resource definition.

 APpend Copies a list to another list.

 CHeck Checks that the resource definitions within a group or list are consistent with one another.

 COpy Copies one or more resource definitions.

 DEFine Creates a new resource definition on the CSD file.

 DELete Erases one or more resource definitions from the CSD file.  DIsplay Displays one or more lists or groups on a full-screen panel.

 Expand Shows the resource definitions in one or more groups on a full-screen panel.  Install Dynamically makes one or more resource definitions available to an active CICS

system.

 Lock Assures exclusive access to a group or list by restricting update and delete access to a single operator identifier.

 REMove Removes a group name from a list.  REName Renames a resource definition.

 UNlock Removes a lock on a group or list which was previously put there by a CEDA LOCK command.

 USerdefine Instead of using CICS-supplied default values with the DEFINE command, you can set your own defaults and use the USERDEFINE command to create a new resource definition on the CSD file.

CEDA - Resource Definition Online – Example: DEFINE TRANSACTION

Transaction name Group name Related program

CEDA - Resource Definition Online – Example: INSTALL TRANSACTION

CEDF Execution Diagnostic Facility

The CICS execution diagnostic facility (EDF) provides two transactions that you can use for testing application programs.

It allows you to intercept your application programs at the program's initiation, at each CICS command, and at the program termination. CEDF helps you to isolate and focus on problems in your application programs.

CEDF

Use CEDF to invoke EDF for testing application programs that are associated with user transactions initiated from a terminal.

Notes:

CEDX

Use CEDX to invoke EDF for testing application programs that are associated with non-terminal transactions.

Use CEDX to monitor and debug non-terminal transactions. The transaction you specify for debugging can be:

 Initiated without an associated terminal; for example, by an EXEC CICS START command, or by a transient data queue trigger-level.

 Initiated at a terminal, which can be either the EDF terminal or a different terminal.

CICS intercepts the transaction specified on the CEDX tranid command, and displays the EDF diagnostic panels at the terminal at which the EDF command is issued. CEDX provides the same function and diagnostic display panels as CEDF, and the same basic rules for CEDF also apply to CEDX.

Command options

 OFF  specifies that the EDF screen is to be switched OFF. If you specify OFF you must enter the preceding comma, as shown in the following example: CEDX TRNA,OFF

 ON  specifies that the EDF screen is to be switched ON. The default is ON. If you specify ON you must enter the preceding comma, as shown in the following example: EDX TRNB,ON  tranid  specifies the identifier of a transaction that you want to test using the execution

diagnostic facility. The diagnostic panels are displayed on the terminal at which you issue the CEDX tranid command. The transaction you specify on the CEDX command must run in the local

CEDX cannot interrupt transactions that are already running when you issue the CEDX command. It affects only a transaction that starts after you issue the command.

The following diagram illustrates the use of CEDX to invoke EDF for a transaction initiated by an EXEC CICS START command. It shows two terminals. The CICS terminal used for EDF issues a CEDX command before BBBB is started, to invoke EDF services to intercept and debug the specified transaction. The CICS user terminal issues an EXEC CICS START command to start BBBB, without a terminal.

CEDF - Beginning an EDF session (single-screen mode)

When you press ENTER, the response is:

THIS TERMINAL: EDF MODE ON

Now clear the screen and enter the name of your transaction:

What does EDF display?

Notes:

This example shows a typical display; occurring after execution of a SEND MAP command. Note: 1 Header 2 Body 3 Message line 4 Menu of functions

The display consists of a header, a body (the primary display area), a message line, and a menu of functions you can select at this point. If the body does not fit on one screen, EDF creates multiple screens, which you can scroll through using PF7 and PF8. The header, menu, and message areas are repeated on each screen.

The header shows:

• The identifier of the transaction being executed • The name of the program being executed

• The internal task number assigned by CICS to the transaction

• The applid of the CICS region where the transaction is being executed • A display number

• STATUS, that is, the reason for the interception by EDF

The function keys that you can use at any given time are displayed in a menu at the bottom of every EDF display. The function of the ENTER key for that display is also shown. Functions that apply to all displays are always assigned to the same key, but definitions of some keys depend on the display and the intercept point. To select an option, press the indicated function key. Where a terminal has 24 function keys, EDF treats PF13 through PF24 as duplicates of PF1 through PF12 respectively. If your terminal has no PF keys, place the cursor under the option you want and press the ENTER key.

ABEND USER TASK

terminates the task being monitored. EDF asks you to confirm this action by displaying the message "ENTER ABEND CODE AND REQUEST ABEND AGAIN." After entering the code at the position indicated by the cursor, the user must request this function again to abend the task with a transaction dump identified by the specified code. If you enter "NO," the task is abended without a dump and with the 4-character default abend code of four question marks (????). Abend codes beginning with the character A are reserved for use by CICS. Using a CICS abend code may cause unpredictable results. You cannot use this function if an abend is already in progress or the task is terminating.

BROWSE TEMP STORAGE

produces a display of the temporary storage queue CEBRxxxx, where xxxx is the terminal identifier of the terminal running EDF. This function is only available from the working storage (PF5) screen. You can then use CEBR commands, to display or modify temporary storage queues and to read or write transient data queues.

CONTINUE

redisplays the current screen if you have made any changes, incorporating the changes. If you had not made changes, CONTINUE causes the transaction under test to resume execution up to the next intercept point. To continue, press ENTER.

CURRENT DISPLAY

redisplays the current screen if you have made any changes, with the changes incorporated. If you have not made changes, it causes EDF to display the command screen for the last intercept point. To execute this function, press ENTER from the appropriate screen.

DIB DISPLAY

shows the contents of the DL/I interface block (DIB). This function is only available from the working-storage screen (PF5).

EIB DISPLAY

displays the contents of the EIB. If COMMAREA exists, EDF also displays its address and one line of data in the dump format.

INVOKE CECI

Accesses CECI. This function is only available from the working storage (PF5) screen. These CECI commands include INQUIRE and SET commands against the resources referenced by the original command before and after command execution. The use of CECI from this panel is similar to the use of CEBR within CEDF.

END EDF SESSION

Ends the EDF control of the transaction. The transaction continues running from that point but no longer runs in EDF mode.

NEXT DISPLAY

It is the reverse of PREVIOUS DISPLAY. When you have returned to a previous display, this option causes the next one forward to be displayed and the display number to increase by one.

PREVIOUS DISPLAY

Causes the previous display to be sent to the screen. This is the previous command display, unless you saved other displays. The number of the display from the current intercept point is always 00. As you request previous displays, the display number decreases by 1 to -01 for the first previous display, -02 for the one before that, and so on, down to the oldest display, -10. When no more previous screens are available, the PREVIOUS option disappears from the menu, and the corresponding function key becomes inoperative.

REGISTERS AT ABEND

Displays storage containing the values of the registers should a local ASRA abend occur. The layout of the storage is:

 Register values (0 through 15)  PSW at abend (8 bytes)

In some cases, when a second program check occurs in the region before EDF has captured the values of the registers, this function does not appear on the menu of the abend display. If this happens, a second test run generally proves to be more informative.

REMEMBER DISPLAY

Places a display that would not usually be kept in memory, such as an EIB display, in the EDF memory. (EDF automatically saves the displays at the start and completion of each command.) The memory can hold up to 10 displays. The displays are numbered in reverse chronological order (that is, -10 is the oldest display, and -01 is the newest). All pages associated with the display are kept in memory and can be scrolled when recalled. Note, however, that if you save a working-storage display, only the screen on view is saved.

SCROLL BACK

Applies to an EIB, DIB, or command display that does not all fit on one screen. When the screen on view is not the first one of the display, and there is a plus sign (+) before the first option or field, you can view previous screens in the display by selecting SCROLL BACK.

SCROLL FORWARD

Applies to an EIB, DIB, or command display that does not all fit on one screen. When this happens, a plus sign (+) appears after the last option or field in the display, to show that there are more screens. Using SCROLL FORWARD brings up the next screen in the display.

SCROLL BACK FULL

Has the same function for displays of working storage as the SCROLL BACK option for EIB and DIB displays. SCROLL BACK FULL gives a working-storage display one full screen backward, showing addresses lower in storage than those on the current screen.

SCROLL FORWARD FULL

Has the same function for displays of working storage as the SCROLL FORWARD option for EIB and DIB displays. SCROLL FORWARD FULL gives a working-storage display one full screen forward, showing addresses higher in storage than those on the current screen.

SCROLL BACK HALF

Is similar to SCROLL BACK FULL, except that the display of working storage is reversed by only half a screen.

SCROLL FORWARD HALF

Is similar to SCROLL FORWARD FULL, except that the display of working storage is advanced by only half a screen.

STOP CONDITIONS

Produces the menu screen. You use this screen to tell EDF when to resume its displays after you have pressed the SUPPRESS DISPLAYS key. You can use STOP CONDITIONS and SUPPRESS DISPLAYS together to cut down on the interaction between you and EDF when you are checking a program that you know is partly working.

CEDF – Working Storage

Press enter to return to current display

You can change the address

Notes:

The working-storage contents are displayed in a form similar to that of a dump listing, that is, in both hexadecimal and character representation. The address of working storage is displayed at the top of the screen. You can browse through the entire area using the scroll commands, or you can simply enter a new address at the top of the screen. This address can be anywhere within the CICS region. The working-storage display provides two additional scrolling keys, and a key to display the EIB (the DIB if the command is a DL/I command). The meaning of "working storage" depends on the programming language of the application program, as follows:

COBOL

All data storage defined in the WORKING-STORAGE section of the program C, C++ and PL/I

The dynamic storage area (DSA) of the current procedure Assembler language

The storage defined in the current DFHEISTG DSECT

Assembler language programs do not always acquire working storage; it may not be necessary, for example, if the program does not issue CICS commands. You may get the message "Register 13 does not address DFHEISTG" when you LINK to such a program. The message does not necessarily mean an error, but there is no working storage to look at. Except for COBOL programs, working storage starts with a standard format save area; that is, registers 14 to 12 begin at offset 12 and register 13 is stored at offset 4.

Working storage can be changed at the screen; either the hexadecimal section or the character section can be used. Also, the ADDRESS field at the head of the display can be overtyped with a hexadecimal address; storage starting at that address is then displayed when ENTER is pressed. This allows any location in the address space to be examined. If the program storage examined is not part of the working storage of the program currently executing (which is unique to the particular transaction under test), the corresponding field on the screen is protected to prevent the user from overwriting storage that might belong to or affect another task.

If the initial part of a working-storage display line is blank, the blank portion is not part of working storage. This can occur because the display is doubleword aligned.

At the beginning and end of a task, working storage is not available. In these circumstances, EDF generates a blank storage display so that the user can still examine any storage area in the region by overtyping the address field.

Note that if you terminate a PL/I or Language Environment program with an ordinary non-CICS return, EDF does not intercept the return, and you are not able to see working storage. If you use a RETURN command instead, you get an EDF display before execution and at program termination.

If you are using a Language Environment-enabled program, working storage is freed at program termination if the program is terminated using a non-CICS return. In this case, working storage is not available for display

CEDF – EIB Display

If there isn't a COMMAREA, line 4 on the screen is left blank and EIBCALEN has a value of zero.

CEDF – Swith hex/char

PF2 SWITCH HEX/CHAR

Unit 4 – Basic mapping support

Topics:

Macro DFHMDF

Macro DFHMDI

Macro DFHMSD

Symbolic input/output map

Preparing maps

Basic mapping support

Basic mapping support (BMS) is an application programming interface

between CICS programs and terminal devices.

BMS provides three assembler language macro instructions (macros)

for defining maps . The three assembler macros used to define BMS

maps are:

DFHMDF

Defines an individual field on a screen or page.

DFHMDI

Defines a single map as a collection of fields.

DFHMSD

Droups single maps into a map set.

Notes:

For many applications, BMS has several advantages. First, BMS removes device dependencies from the application program. It interprets independent output commands and generates device-dependent data streams for specific terminals. It also transforms incoming device-device-dependent data into device-independent format. These features eliminate the need to learn complex device data streams. They also allow you to use the same program for a variety of devices, because BMS determines the device information from the terminal definition, not from the application program.

Second, BMS separates the design and preparation of formats from application logic, reducing the impact of one on the other. Both of these features make it easier to write new programs and to maintain existing code.

BMS provides three assembler language macro instructions (macros) for defining maps. This method of map definition is still widely used, and we are about to explain how to do it. However, there are also other products for creating maps which exploit the facilities of the display terminal to make the map creation process easier. They produce the same outputs as the BMS macros, generally with less programmer effort.

One of these is the Screen Definition Facility II (SDF II). SDF II allows you to build your screens directly from a display station, testing the appearance and usability as you go.

Defining map fields: DFHMDF

You should design the layout of your screen before you attempt to code any macros. After you have done that, you define each field on the screen (page) with a DFHMDF macro. In it, you indicate:

• The position of the field on the screen • The length of the field

• The default contents (unless you always intend to provide them in the program)

• The field display attributes, governing whether and what the operator can key into the field, whether the cursor stops there, the intensity of the characters, and the initial state of the modified data tag

• For some terminals, extended display attributes, such as color, underlining, highlighting

• The name by which you refer to the field in your program, if you ever modify its contents or attributes

Notes:

Fields that are referenced by the application must be allocated field names. The length of the field name and the characters that may be used to form field names must conform to the following rules. (Note that these rules apply to currently-supported compilers and assemblers.)

The characters used must be valid for names of assembler ordinary symbols. This character set consists of the alphabetic characters A - Z (upper or lower case), $, #, @, numeric digits 0 - 9, and the underscore (_) character.

 There is one exception to this rule. The hyphen (-) character may be used in field names provided that:

 The mapset is only used by application programs written in COBOL.  The mapset is generated using the High Level Assembler.

 The first character of the field name must be alphabetic, but the other characters can be any from the character set described above.

In addition, the characters used in field names must conform to the character set supported by the programming language of the application using the map. For example, if the application language is COBOL, you cannot use either the @ character or an underscore.

The DFHMDF macro allows the length of field names to be from one through 30 characters. DFHMDF derives additional variable names by appending one of several additional characters to the defined name to generate a symbolic description map. These derived names may therefore be up to 31 characters in length. The assembler, PL/1, and C languages all support variable names of at least 31 characters. However the COBOL language only allows up to 30 characters, which means that field names used in maps must not exceed 29 characters for COBOL applications. For example, the following field definition is valid for all languages except COBOL:

ThisIsAnExtremelyLongFieldName DFHMDF LENGTH=10,POS=(2,1) and the following field definition is only valid for COBOL:

Must-Not-Exceed-29-Characters DFHMDF LENGTH=10,POS=(2,1) "

The POS (position) parameter indicates the row and column position of the field, relative to the upper left corner of the map, position (1,1). It must be present. Remember that every field begins with a field attributes byte; POS defines the location of this byte; the contents of the field follow immediately to the right.

The LENGTH option tells how many characters long the field is. The length does not include the attributes byte, so each field occupies one more column than its LENGTH value. In the case of the first field in our map, for example, the attributes byte is in row 1, column 1, and the display data is in columns 2-4. Fields can be up to 256 characters long and can wrap from one line to another. (Take care with fields that wrap if your map is smaller than your screen.

The ATTRB (attributes) option sets the field attributes of the field. It is not required; BMS uses a default value of (ASKIP, NORM)--autoskip protection, normal intensity, modified data tag off--if you omit it. There are other options for each of the extended attributes, none of which was used in this map. The INITIAL value for the field is not required either. You use it for label and title fields that have a constant value, such as 'QCK', and to assign a default value to a field, so that the program does not always have to supply a value.

The PICOUT option on the definition of the field CHG tells BMS what sort of PICTURE clause to generate for the field. It lets you use the edit facilities of COBOL or PL/I directly, as you move data into the map. If you omit PICOUT, and also the numeric (NUM) attribute, BMS assumes character data. You can omit the LENGTH option if you use PICOUT, because BMS infers the length from the picture. The GRPNAME and OCCURS options do not appear in our simple example, because they are for more complex problems. GRPNAME allows you to subdivide a map field within the program for processing, and OCCURS lets you define adjacent, like map fields so that you can treat them as an array in the program.

[fld] DFHMDF,options

POS

LENGTH

JUSTIFY

INITIAL

ATTRB

HILIGHT

PICIN

PICOUT

COLOR

Defining map fields

 Options

Notes:

ATTRB

This operand applies only to 3270 data stream devices; it is ignored for other devices, except that ATTRB=DRK is honored for the SCS Printer Logical Unit. It is also ignored (except for ATTRB=DRK) if the NLEOM option is specified on the SEND MAP command for transmission to a 3270 printer. In particular, ATTRB=DRK should not be used as a method of protecting secure data on output on non-3270, non-SCS printer terminals. If ATTRB is specified within a group of fields, it must be specified in the first field entry. A group of fields appears as one field to the 3270. Therefore, the ATTRB specification refers to all of the fields in a group as one field rather than as individual fields. It specifies device-dependent characteristics and attributes, such as the capability of a field to receive data, or the intensity to be used when the field is output. It could however, be used for making an input field nondisplay for secure entry of a password from a screen. For input map fields, DET and NUM are the only valid options; all others are ignored.

ASKIP

is the default and specifies that data cannot be keyed into the field and causes the cursor to skip over the field.

BRT

specifies that a high-intensity display of the field is required. Because of the 3270 attribute character bit assignments, a field specified as BRT is also potentially detectable. However, for the field to be recognized as detectable by BMS, DET must also be specified.

DET

specifies that the field is potentially detectable. The first character of a 3270 detectable field must be one of the following:

? > & blank

If ? or >, the field is a selection field; if & or blank, the field is an attention field. A field for which BRT is specified is potentially detectable to the 3270, because of the 3270 attribute character bit assignments, but is not recognized as such by BMS unless DET is also specified.

DET and DRK are mutually exclusive.

If DET is specified for a field on a map with MODE=IN, only one data byte is reserved for each input field. This byte is set to X'00', and remains unchanged if the field is not selected. If the field is selected, the byte is set to X'FF'.

No other data is supplied, even if the field is a selection field and the ENTER key has been pressed. If the data in a detectable field is required, all of the following conditions must be fulfilled:

The field must begin with one of the following characters: ? > & blank

and DET must be specified in the output map.

The ENTER key (or some other attention key) must be pressed after the field has been selected, although the ENTER key is not required for detectable fields beginning with & or a blank.

DET must not be specified for the field in the input map. DET must, however, be specified in the output map.

DRK

specifies that the field is nonprint/nondisplay. DRK cannot be specified if DET is specified.

FSET

specifies that the modified data tag (MDT) for this field should be set when the field is sent to a terminal. Specification of FSET causes the 3270 to treat the field as though it has been modified. On a subsequent read from the terminal, this field is read, whether or not it has been modified. The MDT remains set until the field is rewritten without ATTRB=FSET, or until an output mapping request causes the MDT to be reset.

Either of two sets of defaults may apply when a field to be displayed on a 3270 is being defined but not all parameters are specified. If no ATTRB parameters are specified, ASKIP and NORM are assumed. If any parameter is specified, UNPROT and NORM are assumed for that field unless overridden by a specified parameter.

IC

specifies that the cursor is to be placed in the first position of the field. The IC attribute for the last field for which it is specified in a map is the one that takes effect. If not specified for any fields in a map, the default location is zero. Specifying IC with ASKIP or PROT causes the cursor to be placed in an unkeyable field. This option can be overridden by the CURSOR option of the SEND MAP command that causes the write operation.

NORM

specifies that the field intensity is to be normal.

NUM

ensures that the data entry keyboard is set to numeric shift for this field unless the operator presses the alpha shift key, and prevents entry of nonnumeric data if the Keyboard Numeric Lock feature is installed.

PROT

specifies that data cannot be keyed into the field. If data is to be copied from one device to another attached to the same 3270 control unit, the first position (address 0) in the buffer of the device to be copied from must not contain an attribute byte for a protected field. Therefore, when preparing maps for 3270s, ensure that the first map of any page does not contain a protected field starting at position 0.

UNPROT

specifies that data can be keyed into the field.

COLOR

indicates the individual color, or the default color for the mapset (where applicable). The valid colors are blue, red, pink, green, turquoise, yellow, and neutral.

The COLOR operand is ignored unless the terminal supports color, as indicated by the RDO option COLOR.

HILIGHT

specifies the default highlighting attribute for all fields in all maps in a mapset.

OFF

is the default and indicates that no highlighting is used.

BLINK

specifies that the field must blink.

REVERSE

specifies that the character or field is displayed in reverse video, for example, on a 3278, black characters on a green background.

UNDERLINE

specifies that a field is underlined.

The HILIGHT operand is ignored unless the terminal supports highlighting, as indicated by the RDO TYPETERM option HILIGHT(YES).

INITIAL (or XINIT)

specifies constant or default data for an output field. INITIAL is used to specify data in character form; XINIT is used to specify data in hexadecimal form. For fields with the DET attribute, initial data that begins with one of the following characters:

? > & blank

should be supplied. The number of characters that can be specified in the INITIAL operand is restricted to the continuation limitation of the assembler to be used or to the value specified in the LENGTH operand (whichever is the smaller).

Hexadecimal data is written as an even number of hexadecimal digits, for example, XINIT=C1C2. If the number of valid characters is smaller than the field length, the data is padded on the right with blanks. For example, if LENGTH=3, XINIT=C1C2 results in an initial field of 'AB'.

If hexadecimal data is specified that corresponds with line or format control characters, the results are unpredictable. The XINIT operand should therefore be used with care. Only one of GINIT, INITIAL, or XINIT may be specified.

JUSTIFY

specifies the field justifications for input operations. This operand is ignored for TCAM-supported 3600 and 3790, and for VTAM-supported 3600, 3650, and 3790 terminals, because input mapping is not available.

LEFT

specifies that data in the input field is left-adjusted.

RIGHT

specifies that data in the input field is right-adjusted.

BLANK

specifies that blanks are to be inserted in any unfilled positions in an input field.

ZERO

specifies that zeros are to be inserted in any unfilled positions in an input field.

LEFT and RIGHT are mutually exclusive, as are BLANK and ZERO. If certain arguments are supplied but others are not, assumptions are made as follows:

Specified Assumed LEFT BLANK RIGHT ZERO BLANK LEFT ZERO RIGHT

If JUSTIFY is omitted, but the NUM attribute is specified, RIGHT and ZERO are assumed. If JUSTIFY is omitted, but attributes other than NUM are specified, LEFT and BLANK are assumed. Note: If a field is initialized by an output map or contains data from any other source, data that is typed as input overwrites only the equivalent length of the existing data; surplus existing data remains in the field and could cause unexpected interpretation of the new data.

LENGTH

specifies the length (1-256 bytes) of the field or group of fields. This length should be the maximum length required for application program data to be entered into the field; it should not include the one-byte attribute indicator appended to the field by CICS for use in subsequent processing. The length of each individual subfield within a group must not exceed 256 bytes. In general LENGTH can be omitted if PICIN or PICOUT is specified, unless PICOUT defines a COBOL picture containing a currency symbol that will be replaced by a currency sign of length greater than 1. LENGTH is required otherwise. You can specify a length of zero only if you omit the label (field name) from the DFHMDF macro. That is, the field is not part of the application data structure and the application program cannot modify the attributes of the field. You can use a field with zero length to delimit an input field on a map.

The map dimensions specified in the SIZE operand of the DFHMDI macro defining a map can be smaller than the actual page size or screen size defined for the terminal.

If the LENGTH specification in a DFHMDF macro causes the map-defined boundary on the same line to be exceeded, the field on the output screen is continued by wrapping.

PICIN (COBOL and PL/I only)

specifies a picture to be applied to an input field in an IN or INOUT map; this picture serves as an editing specification that is passed to the application program, thus permitting the user to exploit the editing capabilities of COBOL or PL/I. BMS checks that the specified characters are valid picture specifications for the language of the map. However, the validity of the input data is not checked by BMS or the high-level language when the map is used, so any desired checking must be performed by the application program. The length of the data associated with "value" should be the same as that specified in the LENGTH operand if LENGTH is specified. If both PICIN and PICOUT are used, an error message is produced if their calculated lengths do not agree; the shorter of the two lengths is used. If PICIN or PICOUT is not coded for the field definition, a character definition of the field is automatically generated regardless of other operands that are coded, such as ATTRB=NUM.

As an example, assume the following map definition is created for reference by a COBOL application program:

MAPX DFHMSD TYPE=DSECT, LANG=COBOL, MODE=INOUT MAP DFHMDI LINE=1,COLUMN=1, SIZE=(1,80)

F1 DFHMDF POS=0,LENGTH=30

F2 DFHMDF POS=40,LENGTH=10, PICOUT='$$$,$$0.00'

F3 DFHMDF POS=60,LENGTH=6, PICIN='9999V99', PICOUT='ZZ9.99' DFHMSD TYPE=FINAL

This generates the following DSECT:

01 MAPI.

02 F1L PIC S9(4) COMP. 02 F1A PIC X.

02 FILLER REDEFINES F1A. 03 F1F PIC X.

02 F1I PIC X(30). 02 FILLER PIC X. 02 F2L PIC S9(4) COMP. 02 F2A PIC X.

02 FILLER REDEFINES F2A. 03 F2F PIC X.

02 F2I PIC X(10). 02 FILLER PIC X. 02 F3L PIC S9(4) COMP. 02 F3A PIC X.

02 FILLER REDEFINES F3A. 03 F3F PIC X.

02 F3I PIC 9999V99. 02 FILLER PIC X. 01 MAPO REDEFINES MAPI.

02 FILLER PIC X(3). 02 F1O PIC X(30). 02 FILLER PIC X. 02 FILLER PIC X(3). 02 F2O PIC $$$,$$0.00. 02 FILLER PIC X. 02 FILLER PIC X(3). 02 F3O PIC ZZ9.99. 02 FILLER PIC X.

Valid picture values for COBOL input maps are: A P S V X 9 / and (

Valid picture values for PL/I input maps are:

A B E F G H I K M P R S T V X Y and Z 1 2 3 6 7 8 9 / + - , . * $ and (

Refer to the appropriate language reference manual for the correct syntax of the PICTURE attribute. Note: PL/I supports multiple currency signs and multi-character currency signs in PICTURE specifications.

The default currency picture symbol is the dollar sign ($), which represents the national currency symbol; for example the dollar ($), the pound (£), or the yen (¥).

The default currency picture symbol may be replaced by a currency string enclosed by less than (<) and greater than (>) symbols. For example:

DECLARE USPRICE PICTURE '$99.99', UKPRICE PICTURE '<£>99.99', EUPRICE PICTURE '<EUR>99.99';

PICOUT (COBOL and PL/I only)

is similar to PICIN, except that a picture to be applied to an output field in the OUT or INOUT map is generated. Valid picture values for COBOL output maps are:

A B E P S V X Z 0 9 , . + - $ CR DB / and ( Valid picture values for PL/I output maps are:

A B E F G H I K M P R S T V X Y and Z 1 2 3 6 7 8 9 / + - , . * $ CR DB and (

Refer to the appropriate language reference manual for the correct syntax of the PICTURE attribute. Note: PL/I supports multiple currency signs and multi-character currency signs in PICTURE specifications.

The default currency picture symbol is the dollar sign ($), which represents the national currency symbol; for example the dollar ($), the pound (£), or the yen (¥).

The default currency picture symbol may be replaced by a currency string enclosed by less than (<) and greater than (>) symbols. For example:

DECLARE USPRICE PICTURE '$99.99', UKPRICE PICTURE '<£>99.99', EUPRICE PICTURE '<EUR>99.99';

Note: COBOL supports multiple currency signs and multi-character currency signs in PICTURE specifications. The default currency picture symbol is the dollar sign ($), which represents the national currency symbol; for example the dollar ($), the pound (£), or the yen (¥).

The default currency picture symbol may be replaced by a different currency picture symbol that is defined in the SPECIAL NAMES clause. The currency sign represented by the picture symbol is defined in the same clause.

LENGTH must be specified when PICOUT specifies a COBOL picture containing a currency symbol that will be replaced by a currency sign of length greater than 1.

POS

specifies the location of a field. This operand specifies the individually addressable character location in a map at which the attribute byte that precedes the field is positioned.

number

specifies the displacement (relative to zero) from the beginning of the map being defined.

(line,column)

specify lines and columns (relative to one) within the map being defined. The location of data on the output medium is also dependent on DFHMDI operands.

The first position of a field is reserved for an attribute byte. When supplying data for input mapping from non-3270 devices, the input data must allow space for this attribute byte. Input data must not start in column 1 but may start in column 2.

The POS operand always contains the location of the first position in a field, which is normally the attribute byte when communicating with the 3270. For the second and subsequent fields of a group, the POS operand points to an assumed attribute-byte position, ahead of the start of the data, even though no actual attribute byte is necessary. If the fields follow on immediately from one another, the POS operand should point to the last character position in the previous field in the group.

When a position number is specified that represents the last character position in the 3270, two special rules apply:

ATTRIB=IC should not be coded. The cursor can be set to location zero by using the CURSOR option of a SEND MAP, SEND CONTROL, or SEND TEXT command.

If the field is to be used in an output mapping operation with MAP=DATAONLY on the SEND MAP command, an attribute byte for that field must be supplied in the symbolic map data structure by the application program.

DFHMDF POS=(1,1),LENGTH=3,ATTRB=(ASKIP,BRT),INITIAL='QCK'

DFHMDF POS=(1,26),LENGTH=28,ATTRB=(ASKIP,NORM), X INITIAL='Quick Customer Account Check'

DFHMDF POS=(3,1),LENGTH=8,ATTRB=(ASKIP,NORM),INITIAL='Account' ACCTNO DFHMDF POS=(3,13),LENGTH=7,ATTRB=(ASKIP,NORM) DFHMDF POS=(4,1),LENGTH=5,ATTRB=(ASKIP,NORM),INITIAL='Name:' SURNAM DFHMDF POS=(4,13),LENGTH=15,ATTRB=(ASKIP,NORM) FNAME DFHMDF POS=(4,30),LENGTH=10,ATTRB=(ASKIP,NORM) DFHMDF POS=(5,1),LENGTH=11,ATTRB=(ASKIP,NORM),INITIAL='Max charge:' CHG DFHMDF POS=(5,13),ATTRB=(ASKIP,NORM),PICOUT='$,$$0.00' MSG DFHMDF LENGTH=20,POS=(7,1),ATTRB=(ASKIP,NORM)

Defining map fields: DFHMDF - Example

Field definitions for the map

Notes:

Fields that are referenced by the application must be allocated field names. The length of the field name and the characters that may be used to form field names must conform to the following rules. (Note that these rules apply to currently-supported compilers and assemblers.)

The characters used must be valid for names of assembler ordinary symbols. This character set consists of the alphabetic characters A - Z (upper or lower case), $, #, @, numeric digits 0 - 9, and the underscore (_) character.

There is one exception to this rule. The hyphen (-) character may be used in field names provided that: The mapset is only used by application programs written in COBOL.

The mapset is generated using the High Level Assembler.

The first character of the field name must be alphabetic, but the other characters can be any from the character set described above.

In addition, the characters used in field names must conform to the character set supported by the programming language of the application using the map. For example, if the application language is COBOL, you cannot use either the @ character or an underscore. You should refer to the appropriate Language Reference manual for information about these character sets.

The DFHMDF macro allows the length of field names to be from one through 30 characters. DFHMDF derives additional variable names by appending one of several additional characters to the defined name to generate a symbolic description map. These derived names may therefore be up to 31 characters in length. The assembler, PL/1, and C languages all support variable names of at least 31 characters.

However the COBOL language only allows up to 30 characters, which means that field names used in maps must not exceed 29 characters for COBOL applications. For example, the following field definition is valid for all languages except COBOL:

ThisIsAnExtremelyLongFieldName DFHMDF LENGTH=10,POS=(2,1) and the following field definition is only valid for COBOL:

Defining the map set DFHMSD and

After all the fields on your map are defined, you tell BMS that they form a single map by preceding them with a DFHMDI macro

Example:

QCKMAP DFHMDI SIZE=(24,80),LINE=1,COLUMN=1

You need one more macro to create a map: DFHMSD, which defines a map set. Example:

QCKSET DFHMSD TYPE=MAP,STORAGE=AUTO,MODE=OUT, x

LANG=COBOL,TIOAPFX=YES

Notes:

DFHMDI

After all the fields on your map are defined, you tell BMS that they form a single map by preceding them with a DFHMDI macro. This macro tells BMS:

• The name of the map

• The size, in rows and columns

• Where it appears on the screen (you can put several maps on one screen) • Whether it uses 3270 extended display attributes and, if so, which ones

• The defaults for these extended attributes for fields where you have not assigned specific values on the DFHMDF macro

• Device controls associated with sending the map (such as whether to sound the alarm, unlock the keyboard)

• The type of device the map supports, if you intend to create multiple versions of the map for different types of devices