C"SNST] Default 11:'1 iii
84 CICS/VS system/Application Design Guide
The task priority is useful in those cases where, because of the transaction volume, there Day be several tasks ccncurrently executing.
In this event, CICS/VS passes control to the highest priority task which is able to ccntin~e executing, and that task retains control of the CPU until it requests various elcS/VS services. If the high priority task is not able to continue processing until a particular event (such as an I/O operation) has occurred, CICS/VS passes control to the next highest task which is able to execute. A high priority task is given preference in the use cf the CEU and other facilities even if entered later than a loveI priority task.
CICS/VS preference that task.
value (for control to
ensures that such high priority tasks are given first in prcc~ssing to enable gcod performance to be achieved by
In the event that twc tasks with the same high priority example, 255) are both ready to process, CICS/VS gives that task which reachEd the system first.
CICS/VS is an event-driven system, and as such does not seize control from a currently dispatched (executing) task. Therefore, even a low priority task will continue to eXEcute once it has been dispatched, until it voluntarily relinquishes control by issuing a CICS/VS macro instruction. If no CICS/VS serviCES are required by such a task, it should periodically issue a task centrol dispatchable WAIT, or a CHAP
(change priority), macro instruction. The CHAP need not changE the task's priority, but merely relinquish control. (See the next topic, or Chapter 6, for Dore detail.)
CHANGE PEIOEITY
A task may commence execution at one priority, and then may need to change its priority at anothEr phase in its procEssing_ CICS/VS
provides this capability through the task control change priority (CHAP) macre instruction (see ChaFter 6). A high priority task may be changed through the use of this macrc instruction to low priority, or vice versa. In this way, secticns of an application Frogram may be given a high priority for processing, while cther sections may be given lower priority. This enables a task to dynamically change its priority based on differing requirements determined through execution. Some examples when sections of a program may wish to change the task priority are illustrated in "Friority ChaDge" in Chapter 6.
Chapter 3. CICS/VS Data Co.munications Design 85
This chapter discusses CICS/VS temporary storage and transient data in a tutorial fashion. Ex{erienced CICS users mal wish to omit the section en transient data. However, it is reccaDended that such users read the s~ction on temporarJ storage in its entirety. The temporary storage control program (TSP) is changed from that ~vailable in previous CICS versions. While still lrcviding compatibility with previous CICS versions, this new TSP.provides additional seguential as well as direct accessing capability, and utilizes VSAft.
-~----~--~---~-~---~---~~-~---~---~---~---~---. . .
CICS/VS, together with DL/I, provides extensive data base capability to online applications. In-additicn to this data base capability (which is discussed in Chapter 5), CICS/VS offers additional facilities for internal data management. This chapter first identifies various application reguiiements which demand the services offered by CICS/VS tempcrary storage Danage&entand transient data management. It then describes those services which can be used as "design tools" by the system designer to satisfJ his own application reguirements.
It is first necessary to define the various data management functions (as distinct frem data base capability) which online applications
require of a DB/DC system. These functions are triefly described below.
WOEK FILE CAPABILITY
Most online applicatiens reguire the ability to store information for later retrieval and use. This function is sometimes referred to as a "scratchpad" or work file capability, and is analogous to a person using sheets of Faper to jet down the intermediate re~ults of
calculations for later use in processing.
The following are two main work file requirements used for most online aFplicaticns:
• Scratchpad capability
• Cueuing capability
This capability refers to the teaporary storage of. information for later retrieval. In a batch environment, this capability is. often
provided through the use of work data sets. In CICS/VS, this capability is provided by the CICS/VS temporary storage contrel p"rograa. The
application program identifies data which is to be temporarily stored by name, and subseguently retrieved by name without any consideration of its physical location. Online apFlication uses of temporary storage include the following.
l»~DSdi~!§ Ei2Yl!§: ThE storagE of intermediate results developed during the processing of a transaction, for use later in the processing of that transaction.
Chapter 4. CICS/VS Data !anageaent Design 81
1;J;J;:.QI ~I§~:tie.!!: The stcrage ef input transactions which were
found to be in error, for subseguent use when the corrected error fields are received from the terminal.
12.9:t.9 ~J;:I91!§!§I: A tempora ry storage of data se it can be used to transfer data between programs. This data transfer may eccur
immediately or at scme future time.
1!i!:mi!ll\! fS.9i!l.9: An apFlicatien Frogram may develop several pages of information to be displayed at a terminal. This inforaation should be temporarily stored until the terminal operator requests that it be displayed for his attention.
In addition to the tempcrary storage of data, online applications generally require a facility which will enable data to be queued for subsequent processing. The difference between this and temporary storage is that temporary storage stores and retrieves individual sections of data, while a gueuing caFability enablES several different sections of the same type o( data to be queued, and then all sections retrieved together, sequentially, in the order that they were queued.
In eIeS/VS, this queuing capability is provided by the eleS/VS transient data centrol program. EIaDples in which cnline applications may utilize a queuing capability follow:
~at~h .Tra.n§A5:!ig iI.Q~§~i.ng: Transactions of a particular type may be received from many terminals. If the applicatien requires that all ef these transactions be Frocessed together, they may be stored in a unique queue for that transaction type, in the crder that they reach the
cpu.
This queue of transactions may then be processed in the eIes/vS partition as a small sequential group of transactions.,l!atcJl§.g .H!i§§.9.9.i 1ran§.!i,g§i2!l: The online application may require that messages be batched and tralsmitted to specific terminals.
~s.:t~l! .~.9!::ti:ti.Q'!! 12.91.9 l~Jl!§!.i": The online application may require that infermation be transferred tc batch partiticns for further
processing, and the results cf that Frocessing be provided to the online application for input at a later time.
The temporary storage management facility of CICS/VS provides a scratchpad capability for online aFplication programs. It enables data to be stored either in dynamic storage or on auxiliary storage. Data to be stored can be identified symtolically, and retrieved symbolically, without application progra.s being ccncerned with the actual physical location of that data. Data can be retrieved on request by an
application program in either a sequential or a direct access manner.
Temporary storage allcws reccrds tc be up to 32,000 bytes in length, but supports variable-length reccrds only.
TEepOEARY STOEAGE USAGE
The previous discussion of application requirements identified the general u:se of a scratcilpad facility by applicaticn programs. eIeS/VS temporary storage management is used to meet these application
requirements as follcvs.
88 eIeS/VS System/Application Design Guide
The atility to temporarily save data for later use, and retrieve it symbolically by name at a future time, enables easier implementation of complex processing. This complex processing may be broken into several logical steps, each step carried out by a separate module.
Information may be passed tetween these modules using temporary storage.
Depending upon the amount of information to be passed, and the time period before that informaticn will te used, this data may be stored either in dynamic storage cr, alternatively, in auxiliary storage.
Temporary storagE may be used to save information for later use.
An example would be the saving of error transactions for later
combination with corrected fields received from a terminal, as described in "Error Correction". Using this capability, ccrrect information in the original errcr tran~acticn dces not have to te reentered by the terminal operator. Consequently, error correction is easier, and the potential for further operater errors is reduced.
~§~inal R~ing
Terminal paging in CICS/VS is also supported through the use of temporary storage. Fages cf infcrmaticn developed by application
programs are presented by them to CICS/VS. These pages are stored in tempQrary storage for transmissien tc the terminal operator on request.
Refer to "Terminal Paging" in ChaFter 3 for more detail.
The ability to transmit messages frem one terminal to another
term~nal, using the CICS/VS message switching transaction CMSG, or the EMS BOUTE macro instruction, is sUFPcrted through the use of temporary storage. These messages are automatically transmitted to the relevant terminal when that terminal is atle to receive them, or the specified operator has signed on to CICS/VS. Refer to "Message Bouting" in Chapter 3 for more detail.
The CICS/VS interval control pregram uses temFcrary storage to pass data from one task te anether task which is to be initiated at a future time. An application program may indicate the task to be initiated at a specified time (based cn elapsed time or, alternatively, time of day) and may transfer data to that future task. The interval control PUT macro instruction results in the data to be transferred being written to temporary storage on disk for subsequent retrieval by the interval control GET macro instruction. Eefer to "Interval Control" in Chapter
6 for more detail.
DATA IDENTIFIC~TION
Each record may be presented to temForary storage with a unique eight-character data identification. Alternatively, several records may be presented with the same data identificaticn. 1 queue of re~ords
associated with a particular logical function (as indicated by the data identification) can be develeped, and subsequently retrieved in the same sequence.
ChaFter 4. CICS/VS Data Management Design 89
The data identificaticn is used by CICS/VS to develop a data element which contains that identificatien, the sequence or entIY number of the recoId i~ a gueue of records with the same data identification, and the location of the record eitheI in dynamic storage or on disk.
These data elements are maintained in CICS/VS dynamic storage. As records are written to temForary stoIage, data elements are dynamically built by CICS/VS and saved in dynamic storage. The number of temporary storage records which may te retained is limited only by the
availability of dynamic stcrage and/cr the amount of disk space allocated to the temporary storage data set.
Because many tasks may corcurrently use the same FrogIam, the use of a constant in the prcg~am for identification of individual records is not advisable. The data identification may be dynamically generated by the program based upon information such as:
• A combination of transaction identification (four characters) and operator identification (three characters) will enable that operator to store one record at a time for each transaction identification.
• A combination of oFerator identification and time of day, or
transaction identification and time of day, will enable the record to be uniquely identified. However, it requires the application program to determine the time of day and then respond to the terminal operator with the allocated data identification. He may then use it to uniquely identify the record in a lateI transaction.
• Each task initiated by CICS/VS is given a unique task sequence number. This task numter may be used as the data identification;
it may be returned to the terminal operator fer subsequent reentry ky him when the relevant recerd is to be retrieved.
The techniques for unique data identification described above assume an application environment where infermation is te be stored by the user's pIogram, and directly retrieved at some future time under control of the terminal operator.
If temporary storage is used to pass data from ene aPFlication program to another, the allocated data identification may be passed to a subsequent application program (exEcuted under ccntrol of the same task) thIough the transaction work area (TiA) appended to the task control area (TCA) for that task. !he program (executing under the same TCA) which is to retrieve the data from temporary storage can obtain the allocated data identificaticn from the !WA. This data identification is then used to identify the record to be retrieved.
If a r'9cord within a temperary storage gueue is to be directly retrieved, it must be uniguelyreferenced by the data identification
(10) and its relevant entry (or sequence) number. When a record is written tiD a temporary storage queue (data identification is nonunique), it is placed at the end of the queue of records with that same data identification. Temporary storage management will allocate the next sequential entry numker and return this entry numter to the program.
The recoId is now uniquely identified by the data ID and the entry number.
This data ID and entry number may be transmitted to a terminal operator for subsequent reentry, if the retrieval is to be initiated by the terminal eperator. If the xetrieval is to te in~tiated
automatically by subsequent application programs executed by the same task,-the data identificaticr: and entry number should be saved in the TWA. The program which is tc retIieve that unique record may then extract this infermatien fIom the TWA for use.
90 CICS/VS System/Application Design Guide
USE OF DYNAHIC StORAGE BY TE~PORAEY STCRAGE
Dynamic storage is a valuable resource, and the overall perfo~mance
of the online system is directly related to the al:cunt of available dynamic storage and its relationship to real storage available for use as a virtual storage page pool (see "CICS/VS iorking Set" in Chapter
7) •
Generally, dynamic sterage residence of records should be used only when the life of those recerds is to bE of very shert duration. Its main purpose is in passing data between program modules which are
executed Qnder control of the same task. Once the data has been passed between modules through dynamic stcrage, that data should te deleted and the storage occupied by it freed. Dynamic storage may be used for record queues as well as unique entries; however, write requests to dynamic and auxiliary storagE with the same data identification cannot be used. CICS/VS will fcrce all subsequent write requests with the same data identification to use the same storage facility specified by the first request.
The length of records to be stored in dynamic storage may be up to the VSA" control interval size specified during CICS/VS system
initialization, less 84 bytes for CICS/VS control information.
CICS/VS permits temporary storage records to reside in dynamic
storage only if the CICS/VS system is generated indicating no auxiliary storage residence sUIPort is required. The specification of no
auxiliary storage support removes the requirement for VSA" by temporary storage. Instead, virtual storage is utilized; temporary storage
information is only paged into real sterage when referenced.
Any temporary storage infcrmation residing in dynamic storage is lost if a controlled or unccntrolled shutdcwn cccurs. See the Gl~~!~
~Y§!~~ R'2~gmm~~!§ ~!!~!~§ ~gD~sl, 5H20-9004, and "Temporary Storage Recovery" in Chapter 8 for atditicnal information.
As a general rule, if a record must be stored for more than one second, it should be directed to auxiliary or secondary storage rather than to dynamic or main storage. Dynamic storage is then available as much as possible for use in initiating concurrently executed tasks.
certainly, the writing of Iecords to disk, and the subsequent retrieval from disk, will involve file accesses and so increase the processing time of those particular tasks. However, the overall effect on the entire online system is ene of potentially better ferformance than
would result if considerable dynamic storage were utilized for temporary storage residence.
ACCESSING RECORDS IN TEMPOEAEY STOBAGE
Temporary storage sUPIorts variable-length records only. A queue or message set of records may be developed by issuing a temporary storage ~UTQ macro instruction fcr each record, using the same data identification. As each reccrd is ~ritten, temporary storage allocates the next sequential entry nu.ber and returns it to the application program.
Using the data identification and the entry number, the records in the queue can be retrieved by application programs either seguentially, in the chronolcgical order in which they were written, or directly accessed by referencing a specific entry number.
A queue of records can te retrieved seguentially by specifying the data identification allocated for that queue and issuing a temporary storage GETQ macro instructicn. Temporary storage management retrieves
Chapter 4. CICS/VS Data Management Design 91
the first record in the queue for that data identificaticn and presents it to the application prograa. Each subsequent GETQ macto.instruction retrieves the next record in sequence until the last record has been retrieved., when an end-of-queue indication will te returned to the Frogram.
Alternatively, if it is required to commence sequential retrieval, not from the beginning of thE queuE tut from a lcgical point within the queue, both the data identification and the entry number are specified by the program. GITQ macro instructions are then issued to retrieve each record sequentially frem the logic~l starting point in the queue.
The program may directly retrieve records by issuing a temporary storage GETQ macro instructicn with the specific entry number of the record in a queue to be directly retrieved.
A record can subsequently be uFoated by issuing a temporary storage PUTQ macro instructien specifyin9 the relevant entry number.
The facilities offered ty temporary storage for direct and sequential retrieval of information make it a powerful work file capability for online aFplicaticns. Infermation may be retrieved as often as required until it is no lenger needed. At that time, the records may be deleted.
Queues of records based upon a specific data. identification may be purgEd by an apFlicatien program PURGE macro instruction. The deletion or purging of these records results in the logical deletion~f those records in the temporary storage data set, with the disk space occupied by those records being reclaimed when the space is subsequently used for another record. The data eleaents describing the deleted or purged records are freed, and the dynaaic storage occupied by these records is reclaimed for other uses.
The eICS/VS temporary storage centrol program supports requests for specific records using the POT, GET, and RELEASE macro instructions provided in previous versicns of eles. However, PUT, GE~, and RELEASE are mutually exclusive with FOTQ, GETO, and PURGE on a data
identification basis. That is, a record written by a PUT macro
instruction cannot te retrieved by a GETQ, or deleted by
a
PURGE, for example.TEMPORARY STORAGE RECOVEEY
After a ccntrclled or unccntrclled teraination of CleS/VS, temporary storage records on disk may remain available for use, if desired.
Temporary storagE in dynamic storage is lost.
Temporary storagE in dynamic storage is lost.