Other data areas (AREAs)

In addition to the communication area and SPAB, you can also pass other areas as parameters (see Other areas). You create such an area in C/C++ as a source code file that only contains data definitions but no executable statements.

The following examples will demonstrate how you define such areas in C/C++ and how to use them in your C/C++ programs.

Example with AREAs (Unix, Linux and Windows systems)

In the following, two areas are generated, defined in a C source and passed to a program unit. The following are defined:

• the area area for direct access (i.e. the data area is passed directly to the program unit)

• the area areaind for indirect access

KDCDEF generation

AREA area,ACCESS=DIRECT
AREA areaind,ACCESS=INDIRECT

Creating a C/C++ source to supply the additional data areas

You define the data structures belonging to the areas in a C/C++ source as follows. In this example, the address of the area is set for areaind (i.e. for the area with indirect access) at compilation time.

Definition of areas

char area[20] = "Area direct "; 
static char area_ind[30] = "Area indirect "; 
char *areaind = &area_ind[0]; 

You have to compile the C/C++ source with the C/C++ compiler and link the created object module to the program units.

If you want to set the address of the area areaind during the application run, you have to define areaind in the C/C++ source as follows:

char *areaind:

During the application run (typically in the START event exit) you then have to supply areaind with the address of the area that you want to pass to the program units as a parameter – by means of the following statement, for example:

static char area_ind[30] = "Area indirect ";
areaind = &area_ind[0];


This makes it possible, for example, to open a shared memory in the START event exit and store the address of the shared memory in the pointer variable areaind. The program units are thus able to access the shared memory.

Access to the areas in the program units on Unix, Linux and Windows systems

A program unit in which you use the areas or one of the areas must be as below. Note that the order of the areas in the parameter list has to be the same as the order of the AREA statements at KDCDEF generation.

Program unit in C

void areaprg ( 
struct spab *spab , 
struct kc_ca *kb , 
char area1 [20] , 
char area2 [30] ) 
{ 
sprintf ( BUFFER 
, "Hello world from UTM (Lterm = %.8s)\n" 
"Area is '%s' \n" 
"Area (indirect) is '%s' \n" 
, kb -> kopf.kclogter 
, area1 
, area2 
); 
... 

Alternatives to AREAs

If program units that use AREAs are to be transferred from one application to another application, then the use of AREAs can lead to problems due to possible differences in the parameter lists.

The following alternatives are available for C/C++ programs. You must determine whether the data area is stored in memory local to the process or in shared memory on Unix and Linux systems or in the memory mapped file on Windows systems.

BS2000 systems

Data areas in local process memory
To use this option, it is necessary to provide a global C/C++ structure which other modules can then access with the same definition and with the 'external' storage class attribute.

Unix, Linux and Windows systems

For Unix and Linux systems in shared memory and for Windows systems in the memory mapped file:

In the start exit you must provide a data structure (see example 3):

static DataAreas struct {
       struct table *TABLE1;
       struct table *TABLE2;
       struct table *TABLE3;
       };
...  
struct DataAreas ExternDataAreas;

The shared memory area will then be requested in the start exit and the addresses will be set in the ExternDataAreas data structure.
Other program units will access the data structure with:

extern struct DataAreas ExternDataAreas;

Example with AREASs (BS2000 systems)

You must provide a data area (see the example) which has been written in Assembler, for example:

TABLE1   CSECT PUBLIC
         DS    CL64
         END

This CSECT is compiled and may be linked with other modules. The module (without an additional module that has code linked to it) should be named MTABLE1; you should then generate it as a load module:

LOAD-MODULE  MTABLE1
           , LOAD-MODE = (POOL , poolname , NO-PRIVATE-SLICE ) -
           , ...

You then make it possible for a program unit or event exit to access the data area with:

extern struct table TABLE1;

This program unit or event exit must then be linked dynamically afterwards.

Example with AREAs (all systems)

The areas TABLE1, TABLE2 and TABLE3 have been defined in this order with the AREA statement. TABLE3 is required in a program unit. TABLE1, TABLE2 and TABLE3 have the same structure and are defined as follows:

struct TABLE
   { int   no;
     int  tag;
     char name[20];
     char company[20];
     int order_no;
     int quantity;
     float price;
     int discount;
   };

The addresses of these areas are passed as follows:

...
#include <kcmac.h>                       /* UTM data structures    */
   ...
   struct ca_area
     {...};
   struct work
     {...};
struct TABLE
   {...};
...
void cprog (struct ca_area *ca, struct work *spab, struct TABLE *TABLE1,
            struct TABLE *TABLE2, struct TABLE *TABLE3)
{ ...