Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

AREA - define additional data areas

The AREA statement allows you to define the name, properties, and sequence of additional shareable data areas. The structure of these areas is not defined by openUTM and can be defined as chosen. The addresses of such areas are passed to the program unit as parameters at the start of the program with the address of the communication area and the standard primary working area.

You have an alternative to administering areas with openUTM using AREA statements in most programming languages (especially under COBOL and C/C++). The alternative is to declare areas as external data areas and to access these areas from the program units. This option offers a number of benefits compared with AREAs. You will find more information on this subject in the openUTM manual „Programming Applications with KDCS”.

Each area to be defined in openUTM must be defined in a separate AREA statement. The order of the AREA statements indicates the order in which these areas must be specified in the parameter list and declared in the program unit (e.g. on BS2000 systems in the LINKAGE-SECTION under COBOL). If the area defined on the n-th location is required, then all areas in the parameter list and in the data declaration must be specified or declared up to this area.

It is possible to specify up to 99 AREA statements in a single generation run.

AREAs in UTM cluster applications are local to the node, i.e. each node application has its own instance of each AREA.

Generating areas on BS2000 systems

On BS2000 systems areas can be created:

  • in the global common memory pool (for all applications).

  • in the local common memory pool (for all application processes started under the same user ID).

  • in non-privileged subsystems.

  • in the linked application program.

The following applies for the AREA statement:

  • If you specify the operand LOAD-MODULE=, you must also write a LOAD-MODULE statement. Note that no load module may be referenced which has been generated with LOAD-MODULE ...LOAD-MODE=ONCALL.

  • AREA statements that do not contain the LOAD-MODULE operand define data areas that are linked statically to the application program.

  • The default values for AREA are set using the DEFAULT PROGRAM statement. 

AREA

areaname 
[ ,LOAD-MODULE=lmodname ]

areaname

Name of the area. areaname is an alphanumeric value up to 32 characters in length. areaname must be a module.

LOAD-MODULE=lmodname


lmodname can be up to 32 characters in length.

LOAD-MODULE= identifies the name of the load module to which the module is linked. This load module must be defined using the LOAD- MODULE statement, and must not be generated with the operand LOAD-MODE=ONCALL.

Generating areas on Unix, Linux and Windows systems

An area must be explicitly defined, compiled, and linked to the program unit as external C/C++ data structures.

In the AREA statement, you can define whether the area is transferred directly to the program unit, or is accessed indirectly by means of a pointer. When accessing indirectly, a pointer must be supplied with the address of the area before the first program unit is started. You can set the addresses before compiling or during the application run in the event exit START, for example.

AREA

 areaname 
 [ ,ACCESS={ DIRECT | INDIRECT } ]

areaname

Name of the area. areaname is an alphanumeric value up to 32 characters in length. areaname must be a module.

ACCESS=

Mode of access to the additional data area

    DIRECT

The area is defined directly as a C data structure.Default: DIRECT

    INDIRECT

The area is defined as a pointer. The pointer areaname must be supplied with the address of the area. It is possible to first set the address during the application run, e.g. you can store the address of a shared memory area in the pointer in the START event exit.