Step 4 - FCT, PPT and PCT

In this blog post we are going to take a deeper look in the three most important tables KICKS uses for its transactions, programs and databases to access.

See previous steps for a better understanding.

KICKS knows about the System Initialization Table (SIT), the File Control Table (FCT), the Task Control Table (PCT), the Destination Control Table (DCT), and the Program Properties Table (PPT).

We are going to take a look to the FCT, PCT and the PPT in this post. The SIT will be looked at to in another blog post.

Those tables are been compiled in load modules and loaded during KICKS startup. Let sink this in for a moment. This means that all changes require a restart of KICKS. So if you change one of those tables when KICKS is running, and by use of another terminal, change one of the tables, then you must logoff from KICKS, the KSSF (or CSSF) transaction and restart KICKS again to load the changes.

This is also required for the map and COBOL program, since at first reference by either entering the transaction code, or linking to one, it resides in memory (oops, should say storage in the IBM terminology) during the KICKS session.

They are named KIKPCT1$, KIKPPT1$, etc. The suffix 1$ is the region name. 

Regions

What you can do with these tables is set up different regions in KICKS. The difference is that you can start KICKS with different settings, and different programs, transactions and file access. So in fact a whole different region of operation. The regions can however share datasets.

I still use 1$ for all of the transactions and dont see a need (yet) to split things up. But you can if you want. ( see official documentation about this)

Furthermore, it is wise to make a copy of the 1$ files to a different location and use these and not the originals.

The PROCESSING PROGRAM TABLE, PPT

This table, in the form of macros in a dataset member, is to be compiled after change. You can find this one in the HLQ.KICKSSYS.V1M5R0.INSTLIB, where the hlq is the dataset where you installed KICKS in.

In here you define the programs that can be executed. Thus all compiled programs, also maps are a compiled program. COBOL programs, and those you will link to or call need to be defined here, otherwise KICKS will not know about them, and will not load or execute them. This is also a nice security feature, at least in a real CICS system. In KICKS its not that easy to secure. But quickly starting a non approved program is not possible.

      PROGRAM=,                                               *
      MAPSET=,                                                *
      USAGE=,                                                 *
      PGMLANG=CMDLVL,                                         *
      LOAD=DEFERRED,    INITIAL or DEFERRED                   *
      PGMSTAT=ENABLED   ENABLED or DISABLED

PROGRAM or MAPSET are aliasses of each other, but stick to the naming to differentiate between them for easy reference later on.

PGMLANG=CMDLVL, always use this and forget the rest.

PGMSTAT is the availablity to KICKS, see below about the transactions.

The PROGRAM CONTROL TABLE, PCT

This table, in the form of macros in a dataset member, is to be compiled after change. You can find this one in the HLQ.KICKSSYS.V1M5R0.INSTLIB, where the hlq is the dataset where you installed KICKS in.

All KICKS transactions needs to be started from withing KICKS itsel by entering a 1 to 4 byte transaction code. If the transaction code is not in the PCT it cannot be started. Linked programs however do not need to have a transaction code. Only other transactions.

       TRANSID=,                                              *
       PROGRAM=,                                              *
       ISTAT=ENABLED     ENABLED or DISABLED

It is possible to enter a transaction in the PCT, and disable it. This is needed to temporary disable a transaction without removing it completly. For our small KICKS world on TK4 it might be overkill, but if you run KICKS in a small production environment with multiple users (as I do) then it can be a good practise. See the ISTAT parameter in the KICKS help.Its enabled by default if omitted. Same for PGMSTAT in the PPT.

The FILE CONTROL TABLE, FCT

This table, in the form of macros in a dataset member, is to be compiled after change. You can find this one in the HLQ.KICKSSYS.V1M5R0.INSTLIB, where the hlq is the dataset where you installed KICKS in.

All VSAM database clusters are to be defined in this table.

This is not the full path, but just the DDNAME (handle) as it is allocated in the CLIST.

For example:

     KIKFCT TYPE=DATASET,DATASET=INVOICE

You will also use this DDNAME for the EXEC KICKS commands that access this reference to it.

 Pitfall in MVS 3.8J

When you decide to create an alternate index (AIX) to a VSAM cluster/database, then you will end up with more then one reference to the same data. First there will be the original, and second an alternate path to the same data. This alternate index can be created by a JCL, and works excellent in TK4, MVS 3.8J.

A definition in the FCT would then look like this:

    KIKFCT TYPE=DATASET,DATASET=INVOICE
    KIKFCT TYPE=DATASET,DATASET=INVPATH,BASE=INVOICE

However, in TK4 there is a problem with this. You cannot in KICKS refer to both files in the same KICKS transaction. This is a serious shortcomming, but I can live with it.

So imagine you have invoices with a number that is the key, we can easily find the record by key reference.

Imagine also we make an path file (AIX) with for example another key (customers) to the same invoice file.

We normally look those up, and find and display map data with it, but we cannot in the same transaction look to the base invoice dataset in the meantime, and the path file.

Its the one or the other.

You can further also imagine it took me a long time to figure that out.