You can pass data to another program when control is passed to that other program by means of a program control command.
The COMMAREA option of the LINK and XCTL commands specifies the name of a data area (known as a communication area) in which data is passed to the program being invoked. In the receiving program you must give this data area the name DFHCOMMAREA.
In a similar manner, the COMMAREA option of the RETURN command specifies the name of a communication area in which data is passed to the transaction identified in the TRANSID option.(The TRANSID option specifies a transaction that will be initiated when input is received from the terminal associated with the task.) The length of the communication area is specified in the LENGTH option; PL/I programs need not specify the length.
The invoked program receives the data as a parameter. The program must contain a definition of a data area to allow access to the passed data.
In an assembler language program, the data area should be a DSECT. The register used to address this DSECT must be loaded from DFHEICAP, which is in the DFHEISTG DSECT.
In a COBOL program, if a program passes a COMMAREA as part of a LINK, XCTL, or RETURN command, the data area can be in either working storage or the linkage section. A program receiving a COMMAREA should have the data specified in the linkage section. This applies whether the program is the receiving program during a LINK or XCTL command where a COMMAREA is passed or the initial program where a COMMAREA and TRANSID have been specified on the RETURN command of a previously called task.
In a PL/I program, the data area can have any name, but it must be declared as a based variable, based on the parameter passed to the program. The pointer to this based variable should be declared explicitly as a pointer rather than contextually by its appearance in the declaration for the area. This will prevent the generation of a PL/I error message. No ALLOCATE statement can be executed within the receiving program for any variable based on this pointer. This pointer must not be updated by the application program.
The receiving data area need not be of the same length as the original communication area; if access is required only to the first part of the data, the new data area can be shorter. It must not be longer than the length of the communication area being passed, because the results in this situation are unpredictable.
The invoked program can determine the length of any communication area that has been passed to it by accessing the EIBCALEN field in the EIB of the task. If no communication area has been passed, the value of EIBCALEN will be zero; otherwise, EIBCALEN will always contain the value specified in the LENGTH option of the LINK, XCTL, or RETURN command, regardless of the size of the data area in the invoked program.
When a communication area is passed by means of a LINK command, the invoked program is passed a pointer to the communication area itself. Any changes made to the contents of the data area in the invoked program are available to the invoking program, when control returns to it; to access any such changes, the program names the data area specified in the original COMMAREA option.
When a communication area is passed by means of an XCTL command, a copy of that area is made unless the area to be passed has the same address and length as the area that was passed to the program issuing the command. For example, if program A issues a LINK command to program B which, in turn, issues an
XCTL command to program C, and if B passes to C the same communication area that A passed to B, program C will be passed addressability to the communication area that belongs to A (not a copy of it) and any changes made by C will be available to A when control returns to it.
A communication area can be passed by means of a RETURN command issued at the highest logical level when control returns to CICS; in this case, a copy of the communication area is made, and addressability to the copy is passed to the first program of the next transaction.
The invoked program can access field EIBFN in the EIB to determine which type of command invoked the program. The field must be tested before CICS commands are issued. If a LINK or XCTL invoked the program, the appropriate code will be found in the field; if RETURN is used, no CICS commands will have been issued in the task, and the field will contain zeros.
Showing posts with label CICS. Show all posts
Showing posts with label CICS. Show all posts
Monday, December 22, 2008
Sunday, December 21, 2008
Files and databases
CICS transactions can access files and databases, which can be on either a local or remote system. Files are processed by the CICS file control program, which allows you to read, add, update, delete (VSAM only), and browse records in VSAM and BDAM data sets. When you access files through the file control program, you do not have such considerations as buffer management, blocking and De-blocking, and access method dependencies.
DL/I databases give you a greater degree of data independence than file control does. You are presented with a logical view of the database in terms of hierarchy of segments. DL/I offer you facilities for manipulating these segments and you do not need to know how they are organized.
CICS has two programming interfaces to DL/I: the EXEC DLI interface, and the DL/I CALL interface.
You identify records in VSAM data sets by key, by relative byte address (RBA), or by relative record number (RRN).
To distinguish which format of record identification is to be used, the RBA and RRN options can be used on most file commands that access VSAM data sets. The options effectively define the format of the record identification field (RIDFLD). If neither the RBA nor the RRN option is specified, the RIDFLD option should contain a key to be used for accessing a VSAM KSDS, or a VSAM KSDS or ESDS by way of a path.
The RBA option specifies that the RIDFLD contains the relative byte address of the record to be accessed. A relative byte address is used to access a VSAM ESDS, and it may also be used to access a VSAM KSDS. However, if a KSDS is accessed in this way, the RBA of the record may change during the transaction as a result of another transaction adding records to, or deleting records from, the same data set.
The RRN option specifies that the RIDFLD contains the relative record number (the first record in a data set being numbered 1) of the record to be retrieved.
Operations involving use of VSAM keys may specify either a complete key or a generic (partial) key. (The one exception to this rule is when a record is written to a SAM KSDS. In this instance, the complete key must be specified in the RIDFLD option of the command.) When a generic key is used, its length must be specified in the KEY LENGTH option, and the GENERIC option must also be specified on the command. A generic key cannot have a key length equal to the full key length. That is, a generic key is defined to be of a length that is strictly less than that of the complete key.
For both complete and generic keys, the GTEQ option may also be specified on certain commands. The command then positions at, or applies to, the record in the data set with the next higher key if a matching key cannot be found. When a data set is being accessed by way of an alternate index path, the record identified is the one with the next higher alternative when a matching record cannot be found.
The application programmer should always, even when using generic keys, use an area of storage for the RIDFLD whose length is equal to the length of the complete key. This is because during a browse operation, after retrieving a record, CICS copies into the RIDFLD area the actual identifier of the record retrieved. In some cases, CICS will return to the application program a complete key, even when a generic key was specified on the command. An example of this is a generic browse through a VSAM KSDS where the complete key is returned to the application program on each READNEXT and READPREV command.
DL/I databases give you a greater degree of data independence than file control does. You are presented with a logical view of the database in terms of hierarchy of segments. DL/I offer you facilities for manipulating these segments and you do not need to know how they are organized.
CICS has two programming interfaces to DL/I: the EXEC DLI interface, and the DL/I CALL interface.
You identify records in VSAM data sets by key, by relative byte address (RBA), or by relative record number (RRN).
To distinguish which format of record identification is to be used, the RBA and RRN options can be used on most file commands that access VSAM data sets. The options effectively define the format of the record identification field (RIDFLD). If neither the RBA nor the RRN option is specified, the RIDFLD option should contain a key to be used for accessing a VSAM KSDS, or a VSAM KSDS or ESDS by way of a path.
The RBA option specifies that the RIDFLD contains the relative byte address of the record to be accessed. A relative byte address is used to access a VSAM ESDS, and it may also be used to access a VSAM KSDS. However, if a KSDS is accessed in this way, the RBA of the record may change during the transaction as a result of another transaction adding records to, or deleting records from, the same data set.
The RRN option specifies that the RIDFLD contains the relative record number (the first record in a data set being numbered 1) of the record to be retrieved.
Operations involving use of VSAM keys may specify either a complete key or a generic (partial) key. (The one exception to this rule is when a record is written to a SAM KSDS. In this instance, the complete key must be specified in the RIDFLD option of the command.) When a generic key is used, its length must be specified in the KEY LENGTH option, and the GENERIC option must also be specified on the command. A generic key cannot have a key length equal to the full key length. That is, a generic key is defined to be of a length that is strictly less than that of the complete key.
For both complete and generic keys, the GTEQ option may also be specified on certain commands. The command then positions at, or applies to, the record in the data set with the next higher key if a matching key cannot be found. When a data set is being accessed by way of an alternate index path, the record identified is the one with the next higher alternative when a matching record cannot be found.
The application programmer should always, even when using generic keys, use an area of storage for the RIDFLD whose length is equal to the length of the complete key. This is because during a browse operation, after retrieving a record, CICS copies into the RIDFLD area the actual identifier of the record retrieved. In some cases, CICS will return to the application program a complete key, even when a generic key was specified on the command. An example of this is a generic browse through a VSAM KSDS where the complete key is returned to the application program on each READNEXT and READPREV command.
How does CICS help you set up an online system?
After your system has been designed, the programming effort to turn the specification into a working application is normally divided between two groups: the people who install and maintain the system and those who write the application programs it will use. (We don't want to rule out the possibility of all this work being done by one heroic person.) CICS offers a variety of helpful features for both groups. Concentrating on the application programming side, CICS aids include:
A choice of programming language. You can write your application programs in assembler, COBOL, PL/I, or C language.
A command-level programming interface with CICS. You need know little about how CICS works. You request data or communication with terminals by issuing CICS commands that resemble those of the programming language you are using. A command language translator preprocesses the application source code, translating CICS commands into CALL statements in the language of the application program. It also provides useful diagnostics.
An execution diagnostic facility (EDF), for testing command-level application programs interactively.
A choice of programming language. You can write your application programs in assembler, COBOL, PL/I, or C language.
A command-level programming interface with CICS. You need know little about how CICS works. You request data or communication with terminals by issuing CICS commands that resemble those of the programming language you are using. A command language translator preprocesses the application source code, translating CICS commands into CALL statements in the language of the application program. It also provides useful diagnostics.
An execution diagnostic facility (EDF), for testing command-level application programs interactively.
How does a CICS-based application differ from a batch application?
Basic Difference
Not everything is different, of course. But here are some points to think about:
In a batch program, you often define all the required input/output and work areas within the program. In CICS, these areas are allocated by CICS, as needed, by CICS itself from a dynamic storage area within the CICS region. This lets CICS economize on main storage, and use the same copy of a program to do work for several users at once.
A batch program reads its own input data, whereas CICS reads the data on behalf of the CICS application programs. A particular CICS application program need not even be loaded into the computer before its first input message arrives.
A batch program issues its input/output instructions directly to the operating system. CICS application programs always issue such instructions to CICS, and CICS handles the interface to the operating system.
Not everything is different, of course. But here are some points to think about:
In a batch program, you often define all the required input/output and work areas within the program. In CICS, these areas are allocated by CICS, as needed, by CICS itself from a dynamic storage area within the CICS region. This lets CICS economize on main storage, and use the same copy of a program to do work for several users at once.
A batch program reads its own input data, whereas CICS reads the data on behalf of the CICS application programs. A particular CICS application program need not even be loaded into the computer before its first input message arrives.
A batch program issues its input/output instructions directly to the operating system. CICS application programs always issue such instructions to CICS, and CICS handles the interface to the operating system.
CICS application programs
Online application programs have certain features and needs in common. Typically, they:
* Serve many online users, apparently simultaneously.
* Require common access to the same data sets and databases.
* Try to give each end user a timely response to each interaction.
* Involve telecommunications access to remote terminals.
The host operating system is in overall charge of the computer and manages resources in whatever way you set up. But the very versatility of a general-purpose operating system means that it often cannot give online programs the sort of priority treatment they need. Instead, CICS may be given "privileged" treatment on behalf of all the online programs that run under it.
To make the best use of the time and system resources that the operating system gives to CICS, CICS takes on itself some of the aspects of an operating system. For example, CICS allows more than one of its programs (tasks) to be in an active state at the same time. But CICS doesn't duplicate all of the services provided by the operating system. Whenever appropriate, CICS goes straight to the operating system to provide what its tasks ask for.
* Serve many online users, apparently simultaneously.
* Require common access to the same data sets and databases.
* Try to give each end user a timely response to each interaction.
* Involve telecommunications access to remote terminals.
The host operating system is in overall charge of the computer and manages resources in whatever way you set up. But the very versatility of a general-purpose operating system means that it often cannot give online programs the sort of priority treatment they need. Instead, CICS may be given "privileged" treatment on behalf of all the online programs that run under it.
To make the best use of the time and system resources that the operating system gives to CICS, CICS takes on itself some of the aspects of an operating system. For example, CICS allows more than one of its programs (tasks) to be in an active state at the same time. But CICS doesn't duplicate all of the services provided by the operating system. Whenever appropriate, CICS goes straight to the operating system to provide what its tasks ask for.
What does CICS do?
CICS controls online DB/DC application programs. But what does this mean? In fact, it means that CICS is a program that does a lot of work on your behalf. CICS handles interactions between terminal users and your application programs. An interaction may consist of one or more requests from, and responses to, a terminal user in the course of a single job by that user.
CICS provides:
The functions required by application programs for communication with remote and local terminals and subsystems
Control of concurrently running programs serving many online users Facilities for accessing databases and files, in conjunction with the various IBM database products and data access methods that are available
The ability to communicate with other CICS systems and database systems, both in the same computer and in connected computer systems.
IBM has left things as open as possible to allow customers to produce the system they need. It's up to your systems and applications designers (which could mean you, of course) to choose what they want from the various CICS facilities, and to build whatever kind of user interface that best suits the end users. So, although you still have to provide the application programs that the end users actually run, CICS makes it much easier. Your programs gain access to the CICS facilities they need by straightforward, high-level, commands.
CICS provides:
The functions required by application programs for communication with remote and local terminals and subsystems
Control of concurrently running programs serving many online users Facilities for accessing databases and files, in conjunction with the various IBM database products and data access methods that are available
The ability to communicate with other CICS systems and database systems, both in the same computer and in connected computer systems.
IBM has left things as open as possible to allow customers to produce the system they need. It's up to your systems and applications designers (which could mean you, of course) to choose what they want from the various CICS facilities, and to build whatever kind of user interface that best suits the end users. So, although you still have to provide the application programs that the end users actually run, CICS makes it much easier. Your programs gain access to the CICS facilities they need by straightforward, high-level, commands.
What is CICS?
CICS (Customer Information Control System) is a general-purpose data communication system that can support a network of many hundreds of terminals. You may find it helpful to think of CICS as an operating system within your own operating system (although this definition might offend purists). In these terms, CICS is a specialized operating system whose job is to provide an environment for the execution of your online application programs, including interfaces to files and database products.
Subscribe to:
Posts (Atom)
