Overview of the SAS/C and CICS Environments |
In the chapters that follow, these system components
are discussed in terms of steps involved in setting up a SAS/C application
program for use under CICS. These steps are discussed in detail in the tutorial
in Tutorial: Creating a Simple Transaction,
and again in the comprehensive example in Examples.
Developing a basic application program for CICS might consist
of writing code to coordinate the flow of control between a terminal, the
task at hand, files, and your program. The structure and control necessary
for this kind of coordination is provided via CICS system control programs
and their associated tables. Files, programs, and transactions must all be
defined in the appropriate CICS tables (that is, the FCT, PPT, PCT). For
example, providing links to remote systems requires working with a terminal
control table (TCT), which is then used by the CICS terminal control program
to set up intercommunication.
Whenever appropriate, references may be made to CICS
control tables with respect to particular aspects of your SAS/C application
program. Examples and discussion of structuring your program to take advantage
of CICS interfaces are found throughout this user's guide.
CICS
is a multitasking,
multithreading system environment. Multitasking means that CICS provides
an environment where more than one CICS task runs concurrently. Multithreading
means that tasks share the same program in a multitasking environment. CICS
is characterized as multitasking and multithreading because it provides an
environment in which multiple CICS tasks, using the same program, can run
concurrently.
To make this type of environment possible, SAS/C programs
running under CICS must be re-entrant. Since, by definition, re-entrant
programs do not modify themselves, they can continue processing after
an interruption by the operating system. This includes continuing processing
after an interruption during which other tasks controlled by the same program
may have been executed.
To comply with CICS requirements for re-entrancy, SAS/C programs
must be compiled using the
rent
(or
rentext
) compiler option. Preprocessing, Compiling, and Linking provides more information on how to specify
options.
You can
fully exploit 31-bit addressability.
If your program is link-edited as AMODE 31, the library will request that
stack, heap, and PRV storage be allocated above the 16-M line. (The PRV,
or pseudoregister vector, contains all external and static data for re-entrant
programs.) The CICS release and the size of a storage allocation request
determine whether the storage is actually allocated above the line. For example,
an initial stack size of 3072 bytes is allocated below the line in CICS Version
2, but it is allocated above the line in CICS Version 3. Consult one of the
following CICS Application Programmer's Reference manuals for exact details
on storage allocation:
SAS/C
programs
that are link-edited with the specification of AMODE(31) and RMODE(ANY) can
be loaded above the 16M line by CICS. The ability for SAS/C programs
to reside above the 16M line provides virtual storage constraint relief for
storage-constrained CICS systems. That is, programs are not restricted to
sharing what below-the-line storage is left over after that used by tables
and other components related to CICS.
Most of the SAS/C transient
library for CICS can reside above the 16M line. Application programs linked
with a release earlier than 6.00 of the resident library will continue to
work correctly if they are link-edited as AMODE 31. Programs linked as AMODE
24 must be relinked or have one or more zaps applied. Contact SAS/C Technical
Support for information about these zaps. Unless you have a specific reason
for doing so, you do not need to link-edit SAS/C CICS
applications as AMODE 24.
The run-time library is freely redistributable, so you
can develop your applications and distribute them without interaction with
SAS Institute.
The
Systems
Programming Environment is designed to enable the C language to be used as
a systems programming language in the IBM S/390 environment. SPE consists
of the minimum number of support routines needed to execute a C program, and
a small run-time library that is systems-programming oriented. For complete
details on using SPE with CICS, see Chapter 14, "Systems Programming with
the SAS/C Compiler," in the
SAS/C Compiler and Library User's Guide.
Normally, when a C program is linked,
the resulting load module does not contain all of the support routines needed
by the program. These support routines are dynamically loaded from the transient
library and released (freeing the memory required as well) when they are no
longer needed.
In certain specialized applications and environments,
it may be desirable to force the program load module to contain a private
copy of all the required support routines. These programs can be characterized
as all-resident programs because no transient library routines need to be
used. For more information on creating all-resident CICS programs, see Chapter
10, "All-Resident C Programs," in the
SAS/C Compiler and Library User's Guide.
Developing application programs for CICS requires attention
to design issues involving user-friendliness, system security, and performance.
Copyright © 2001
by SAS Institute Inc., Cary, NC, USA. All rights reserved.