KICKS good morning screen

The screen you see when you start KICKS is the KSGM transaction. Did you know you can replace the KSGM transaction with another one ?

The above screen is the default KICKS screen, or better say map ? It doesnt matter, as long as you understand what I am trying to tell you.

Now, the KSGM transaction, of wich you have the source code available in hlq.KICKSSYS.V1M5R0.COBOL dataset, and the MAPSET dataset, can be altered and recompiled if you like to have a different screen.

Above you can see my KICKS screen. The reason for change is that I also want to see some figures on my login screen. In my case I created a user to user message system, (will be covered in another blog post) and like to see if I have a new message waiting for reading. Also I like to see if there are new helpdesk tickets are been created. What would be a better place than the KSGM screen ?

It is possible to change the default one, or create a new one, what I did, and use that as the startup transaction is to create new one, BSGM. Of course I added it to the PPT and PCT tables, and changed the SIT table to start the new good morning screen.

              PLTPI=KSGM, first transaction 

If you change the PLTPI to read your desired transaction code, it will start that after logging on to KICKS. You can find the SIT table in HLQ.KICKSSYS.V1M5R0.INSTLIB. Or, a better practice is to copy the member to another dataset, and use that to make modifications.

How you change the program ?

Well, its not different from other transactions. In the blog you can already find a COBOL sample, and a BMS mapping instruction. The COBOL sample shown here, can be modified to display your new map, and do additional tasks.

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.