Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

CREATE-CONTROL-STATEMENTS - create KDCDEF control statements

When regenerating your application, inverse KDCDEF allows you to retain UTM objects in the configuration which were entered dynamically during runtime. Further information can be found in section "Inverse KDCDEF".

The statement CREATE-CONTROL-STATEMENTS generates KDCDEF control statements for the UTM objects which can be entered dynamically, and outputs them to the file control_statements_file. During the same KDCDEF run, you can use
control_statements_file as the basis for generation by defining it as an input file using the statement OPTION ...,DATA=control_statements_file.

Using the statement CREATE-CONTROL-STATEMENT, you can generate control statements for UTM objects of type TAC, PROGRAM, PTERM, LTERM, USER, CON, LTAC, LSES and KSET.

However, for users generated implicitly, inverse KDCDEF neither creates USER statements nor adds the user name in the USER= operand in the LTERM statement.

It does not transfer UTM objects to the file control_statements_file, which were marked for deletion by administration using KC_DELETE_OBJECT. In a KDCDEF run in which control_statements_file is defined as an input file, the names of the deleted UTM objects can be used again.

You can start KDCDEF for inverse KDCDEF with at least one CREATE-CONTROL-STATEMENTS statement and without any further KDCDEF control statements.

If you upgrade to a new version, the KDCDEF control statements must first be created in the previous version before being processed in a later version by the KDCDEF generation tool.


CREATE-CONTROL-STATEMENTS


 { *ALL | CON | DEVICE | KSET | LSES | LTAC |
   PROGRAM | USER }
  ,FROM-FILE=kdcfile
  ,TO-FILE=control_statements_file |
           *LIBRARY-ELEMENT 1 (LIBRARY=<lib-name> 
                   ,ELEMENT=<element>
                  [ ,VERSION=C‘<version>‘ | 
                             *HIGH EST-EXISTING |
                            *UPPER-LIMIT |
                             *INCREMENT ]
                 [ ,TYPE=<element-type> ]) ]
  [ ,MODE={ CREATE |EXTEND } ]

1 only on BS2000 systems


*ALL

KDCDEF control statements are generated for the following object types:

  • KSET

  • LSES

  • LTAC

  • TAC

  • CON

  • PROGRAM

  • PTERM

  • LTERM

  • USER

They cannot be created for other object types.

CON

This creates KDCDEF control statements for the transport connections to remote applications.

DEVICE

KDCDEF control statements are generated for LTERM partners, clients and printers, i.e. for the following object types:

  • PTERM

  • LTERM

KSET

KDCDEF control statements are generated for key sets, i.e. for objects of type KSET.

LSES

This creates KDCDEF control statements for the assignment of session names.

LTAC

KDCDEF control statements are generated for transaction codes via which service programs in partner applications are started. These are objects of the type LTAC.

PROGRAM

KDCDEF control statements are generated for programs, service exits
transaction codes and TAC queues , i.e. for the following object types:

  • TAC

  • PROGRAM

USER

KDCDEF control statements are generated for user IDs, i.e. for objects of type USER.

Please note that passwords cannot be reconstructed. In the case of user IDs with passwords, statements are created with the following format:

USER username, PASS=*RANDOM, ...

In the case of standalone applications, you must use the KDCUPD tool to transfer the passwords to the new KDCFILE after the KDCDEF run has finished. This is also possible for the UTM-F generation variant.

FROM-FILE=

kdcfile

Name of the KDCFILE from which the control statements are to be generated.

The openUTM version of the KDCFILE must match that of the KDCDEF generation tool.

TO-FILE=

Specifes where the KDCDEF control statements are to be written to.

    control_statements_file

The generated KDCDEF control statements are written to the file specified in control_statements_file. For control_statements_file, you must enter a valid file name. control_statements_file can be defined as an input file for the KDCDEF run using the statement OPTION ...,DATA=control_statements_file.

    *LIBRARY-ELEMENT(...)

This parameter is supported on BS2000 systems only.

The KDCDEF control statements are written to the LMS library element specified here. The following restrictions apply:

  • Delta elements are not supported.

  • UTM always writes records with record type "1".

       LIBRARY=

<lib-name>

Name of an LMS library. The file name can be up to 54 characters in length. If the library does not yet exist, it is created.
LIBRARY is a mandatory parameter of *LIBRARY-ELEMENT(...).

       ELEMENT=

<element>

Name of the LMS element.
The element name may be up to 64 characters in length and consists of an alphanumeric string which can be subdivided into multiple substrings separated by periods or hyphens.
ELEMENT is a mandatory parameter of *LIBRARY-ELEMENT(...).

       VERSION=

Version of the LMS element.

           C'<version>'

  

The element version is specified as an alphanumeric string of up to 24 characters in length which can be subdivided into multiple substrings separated by periods or hyphens.

        *HIGHEST-EXISTING

The statements are written to the highest version of the specified element present in the library.

        *UPPER-LIMIT 

The statements are written to the highest possible version of the specified element. LMS indicates this version by means of an "@".

        *INCREMENT

A new version is created for the specified element. *INCREMENT may only be specified if MODE=CREATE.

Default value:

  • *HIGHEST-EXISTING in MODE=EXTEND

  • *INCREMENT in MODE=CREATE

    If MODE=CREATE and VERSION is not equal to *INCREMENT then any existing element is overwritten with the specified version.

       TYPE=

<element-type>

Type of LMS element. An alphanumeric string of up to 8 characters in length can be specified for the type.

Default value: S

KDCDEF does not check whether the specifications for ELEMENT, VERSION or TYPE comply with the LMS syntax rules. For further information on the syntax rules for the names of LMS elements and a specification of version and type, see the manual "LMS SDF Format".

MODE=

Write mode of the file containing the generated KDCDEF control statements

    CREATE

The file specified in control_statements_file is created.

On BS2000 systems the file is created as a SAM file or an LMS library element. The following applies:

  • If a file with the same name already exists, this must be a SAM file. This SAM file is then overwritten.

  • If an element of the same name already exists and if *HIGHEST- EXISTING or *UPPER-LIMIT is specified for VERSION=C‘<version>‘ then the element is overwritten.

If a file with the same name already exists on Unix, Linux or Windows systems, it is overwritten.

    EXTEND

The generated control statements are appended to the existing control_statements_file. If this file does not exist, it is created.

If an LMS library is specified in the BS2000 system then the library must already exist. In this case, an existing element of the specified version is extended. If the element does not yet exist in this version then it is created.



Powered by Atlassian Confluence and Scroll Viewport.