Platform-specific characteristics on BS2000 systems

Compiling C/C++ program units

If a link and load module (LLM) is to be created that consists of a code CSECT and a data CSECT section at compilation of C/C++ program units, you must set MODULE-GENERATION(MODULE-FORMAT=LLM) for the COMPILER-ACTION option when calling the compiler. The LLM must be made available in a PLAM library for linking with the BINDER. Object modules can also be created for your C program units (type=R in LMS).

Using shareable code

If you plan on loading C/C++ program segments as shareable code, then you must set the following option when compiling:

COMPILER-ACTION=MODULE-GENERATION(SHAREABLE-CODE=YES,...)

The shareable code does not have to be stored in its own object module, rather it can be placed together with the non-shareable segment in an LLM that is divided into a public and a private slice.

The shareable program segments only need to be loaded together once for all processes (tasks) of the application(s). Then only the non-shareable segments need to be loaded into the local task memory.

openUTM offers several ways of loading shareable objects:

• as a non-privileged subsystem

• with the ADD-SHARED-PROGRAM command into system memory

• into a common memory pool in user memory (class 6 memory).

You can find additional information on compiling shareable code in the User’s Manual for your compiler. The openUTM manual “Generating Applications” as well as the openUTM manual “Using UTM Applications on BS2000 Systems” contains detailed information on linking and loading shareable code.

Creating formats with the IFG

A detailed explanation of how to create formats using the IFG can be found in the IFG manual. Please follow the guidelines below when creating these formats for use with openUTM:

• The format name may be at most 7 characters long.

• Select "Structure of the data transfer area" in the user profile:

  • for #formats: separated attribute blocks and field contents

  • for *formats: unformatted, without attribute fields

  • for +formats: unformatted, with attribute fields

• For the C/C++ programming languages the IFG always creates one address assistant. Fields with the "arithmetic field data type" are represented as character strings (char [..]).

• Please note when defining the addressing assistants for *formats and +formats that openUTM deletes the transaction code from the UTM message for MGET and FGET (as long as this is not explicitly prevented in an INPUT exit). If the first field in the format contains the transaction code, then you can take this into account by reading the UTM message into the second field.

  Example

  struct work
     { union kc_paa param;  
       FORM1 std_mask;               /* declare addressing aid for */
            ..                       /* the *format FORM1          */
      } *spab;
            ...
            ...
      /* MGET call */
       KDCS_MGET ( spab->std_mask.FUNCTION                1)
                  ,sizeof( FORM1 )
                  ,"*FORM1  "               );
            ...           
      /* MPUT call */
       KDCS_MPUTNT (&spab->std_mask,sizeof(FORM1)
                   ,KDCS_SPACES,"*FORM1  ",KCNODF);
      /* PEND FI call */
            ...
  

  ¹⁾ FUNCTION is the second input field of the format.

• When preparing for the application, you bring the formats into the format application field (format library). You specify these names together with the FHS start parameters.

Extended line mode

You must define the control characters yourself when working in extended line mode if they are not available in C/C++. You will find a list of which control characters correspond to which hexadecimal values in the "TIAM User Guide", for example in the description of the VTCSET macro.