In this section let us get introduced to some unique concepts under CICS. In order to understand how CICS performs, knowledge of these basic concepts is essential. Some of these concepts are not necessarily unique to CICS, but CICS manages all these quite efficiently and effectively.
Multitasking means that the Operating system allows more than one task to be executed concurrently regardless of whether the task uses the same program or different programs. This is not a unique concept of CICS, but CICS manages the multitasking of the CICS tasks within its own region. In other words, CICS provides a multitasking environment where more than one CICS task or transaction can run at the same time.
Multithreading is a technique that allows a single copy of an application program to be processed by several transactions concurrently. For example, one transaction may begin to execute an application program. When an EXEC CICS command is reached, causing a CICS WAIT and call to the dispatcher, another transaction may then execute the same copy of the application program. (Compare this with single-threading, which is the execution of a program to completion: processing of the program by one transaction is completed before another transaction can use it.)
Multithreading requires that all CICS application programs be quasi- reentrant; that is, they must be serially reusable between entry and exit points. CICS application programs using the EXEC CICS interface obey this rule automatically. For COBOL, C, and C++ programs, reentrancy is ensured by a fresh copy of working storage being obtained each time the program is invoked. You should always use the RENT option on the compile or pre-link utility even for C and C++ programs that do not have writable statics and are naturally reentrant. Temporary variables and DFHEIPTR fields inserted by the CICS translator are usually defined as writable static variables and require the RENT option. For these programs to stay reentrant, variable data should not appear as static storage in PL/I, or as a DC in the program CSECT in assembler language.
As well as requiring that your application programs are compiled and link-edited as reentrant, CICS also identifies programs as being either quasi-reentrant or threadsafe.
A re-entrant program is one, which does not modify itself so that it can re-enter to itself and continue processing after an interruption by the operating system. A non re-entrant program modifies itself so that it cannot re-enter to itself. Therefore, a non re-entrant program cannot be used in a multithreading environment. Examples of this kind of programs are batch programs.
Re-entrant programs are used in on-line systems and they make it possible for the Operating system to establish a multithreading environment that most on-line systems require.
The re-entrant programs works like this. Between two consecutive Supervisor calls (SVCs) an Operating system task A, which uses a program has exclusive use of the CPU resource, At an interruption time in the program, that is during a SVC, the task A is suspended. Operating system saves the status of the task A and executes other tasks. When the other tasks reach an interruption point, and if the task A's wait status is complete, then the operating system restores the status of A, which it continues to execute till the next SVC.
This process makes it possible to run different tasks, say A, B, C, etc., to run concurrently. If these tasks use the same program, data areas of the program Will be destroyed unless they are kept unique for each task. Also if the tasks use a program, which alters itself during execution of a task, the program will not be the same among the tasks. The re-entrant program ensures the uniqueness of the data area and program logic to each task. This is achieved by following certain programming conventions. They are given below:
Quasi Re-entrant Programs
CICS runs user programs under a CICS-managed task control block (TCB). If your programs are defined as quasi-reentrant (on the CONCURRENCY attribute of the program resource definition), CICS always invokes them under the CICS quasi-reentrant (QR) TCB. The requirements for a quasi-reentrant program in a multithreading context are less stringent than if the program were to execute concurrently on multiple TCBs.
CICS requires that an application program is reentrant so that it guarantees consistent conditions. In practice, an application program may not be truly reentrant; CICS expects "quasi-reentrancy". This means that the application program should be in a consistent state when control is passed to it, both on entry, and before and after each EXEC CICS command. Such quasi-reentrancy guarantees that each invocation of an application program is unaffected by previous runs, or by concurrent multi-threading through the program by multiple CICS tasks.
For example, application programs could modify their executable code, or the variables defined within the program storage, but these changes must be undone, or the code and variables reinitialized, before there is any possibility of the task losing control and another task executing the same program.
CICS quasi-reentrant user programs (application programs, user-replaceable modules, global user exits, and task-related user exits) are given control by the CICS dispatcher under the QR TCB. When running under this TCB, a program can be sure that no other quasi-reentrant program can run until it relinquishes control during a CICS request, at which point the user task is suspended, leaving the program still "in use". The same program can then be reinvoked for another task, which means the application program can be in use concurrently by more than one task, although only one task at a time can actually be executing.
To ensure that programs cannot interfere with each others working storage, CICS obtains a separate copy of working storage for each execution of an application program. Thus, if a user application program is in use by 11 user tasks, there are 11 copies of working storage in the appropriate dynamic storage area (DSA).
Quasi-reentrancy allows programs to access globally shared resources--for example, the CICS common work area (CWA)--without the need to protect those resources from concurrent access by other programs. Such resources are effectively locked exclusively to the running program, until it issues its next CICS request. Thus, for example, an application can update a field in the CWA without using compare and swap (CS) instructions or locking (enqueuing on) the resource.
On typing the TRANSID BOOK on the computer terminal, the booking software program displays MAIN MENU on the screen and stops. As you decide, what option to select, the booking software isn’t running. After you select option 1, and press Enter, the booking software starts again, processes the selected option, displays the BOOKING MENU on the screen and stops. Take your time to plan the trip and fill the reservation form; the booking software is not running. Only when you complete the form, and press Enter, the booking software starts again, books the ticket, and outputs the PNR number on the screen. Such type of processing can be likened to conversational, but it is false, hence pseudo-conversational.
CICS Macro and Command Level
The Customer Information and Control System (CICS) was developed by IBM ah the 1960s as a DB/DC control system. The initial version was the macro level CICS,, under which the application programs used the Assembler-macro type CICS macros for requesting CICS services. Even though the macro level made the application programming significantly easier, it was still a tedious task and required special skills. Over time and with new versions CICS was upgraded and enhanced. Thus CICS command level came into existence. CICS commands are the high-level equivalents of CICS macros. One CICS command achieves a CICS service, which would have been achieved by a series of macros. The CICS command level has made the application development very easy.
The changeover from macro level to command level has made the life of the application programmer much easier. For example in the macro level programming, the programmer had to follow all the programming conventions that we discussed earlier to make the programs re-entrant or reusable. But with the CICS command level, all the activities are performed by CICS. Thus, when CICS executes a command level application program, it automatically acquires a unique copy of the working storage section of the application program for each task, thus freeing the application programmer from the task of obtaining the DWS for each task. In the case of programs, which alter itself during execution, the information about the program alteration is kept in the Task Global Table (TGT), which is a part of the program. Since CICS acquires TGT uniquely for each task, each task gets the original and not the altered program.
This implies that for all CICS command level application programs, quasi-re-entrancy is automatically ensured. Therefore an application programmer can write programs without any consideration of quasi-re-entrancy. This is one of the major achievements of CICS command level.
IBM Mainframe Related Interview Questions
|IBM Lotus Notes Interview Questions||IBM-CICS Interview Questions|
|COBOL Interview Questions||Linux Interview Questions|
|IBM-JCL Interview Questions||IBM Mainframe Interview Questions|
|IBM AIX Interview Questions||IBM WAS Administration Interview Questions|
|IBM Lotus Domino Interview Questions||IBM Integration Bus Interview Questions|
|Mainframe DB2 Interview Questions||Unix Production Support Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.