KICKS

A transaction processing system for CMS & TSO

Overview

KICKS is an enhancement for CMS & TSO that lets you run your CICS applications directly instead of having to 'install' those apps in CICS. You don't even need CICS itself installed on your machine.

KICKS provides a high level of source code compatibility with CICS so you can move an application either way between CICS and KICKS simply by recompiling. Whether for ease of testing, fast deployment to small groups of your users, or simple "guerrilla marketing", join your colleagues using KICKS to speed up their development.

Being TSO/CMS based, KICKS can't support the many thousands of users a multi-user system like CICS can. But if KICKS can't support thousands of users, it can certainly support a few hundred of your users, and if having separate address spaces means it can't run as many users it also means your users aren't so tied to each other's fates - one crash does not kill all. This reduced consequence of failure often means your new application's "Time to Market" can be dramatically shortened.

Like CICS, KICKS supports file sharing among its users. Hundreds of TSO or CMS users share db2 tables or VSAM files with no more concern about doing so than CICS users - and since KICKS VSAM support is also available in batch there's usually no need to "close" KICKS VSAM files just so such batch jobs can access them.

Unlike CICS, KICKS requires no special systems or security services and can be easily installed and used by a single applications programmer with a TSO or CMS account.

Version/Release encoding (VRM)

KICKS modification levels are encoded in a Version/Release/Modification format. So for example its TSO distribution datasets for this release are named as USERID.KICKS.V1R5M0.XXX, signifying version 1, release 5, modification 0 (aka 1.5.0).

Since KICKS is highly modular, with separate nucleus management modules and tables as well as components compiled and linked with user applications, KICKS performs extensive version checking to ensure all components are compatible. Eventually that will allow a newer release of KICKS to tolerate older applications and maps, perhaps even older tables or even older management modules in some cases. But for now the version checking is very rigid: All components, including user applications and maps, must be at exactly the same level. This means you will have to recompile all your applications with each new KICKS distribution. The symptom of a version mismatch in your application is a VERS abend (or similar, such as VER1, VER2, etc).

Release history

1.5.0

1.4.1

1.4.0

What happened to the releases between 1.1.3 and 1.4.0 ?  They never existed. While in development of 1.1.4 we decided VRM was off track. There was a reason for 1.1.1 in that substantial features (GCCMVS & LE support) intended for 1.1.0 were being delivered late, but 1.1.2 and 1.1.3 really should have been 1.2.0 and 1.3.0. We fixed it by changing VRM for the new release from 1.1.4 to 1.4.0.

1.1.3

1.1.2

1.1.1

1.1.0

1.0.0

0.9.0

Goals for the next release / level-set.

Maintenance/support plan for this release

1.5.0 requires that all user programs and maps be recompiled.

KICKS has been tested been tested with Z/OS thru 1.12 and with the MVS38J  "Tur(n)key" system including the base TK3 (the one on the CD) as well as with TK3UPT, MVS380 and TK4-. It greatly benefits from the VTAM fixes and dynamic proclib support in the newer TK3 versions, but does not require them.

KICKS has been tested with Z/VM thru 6.x and with the VM/370 "Six Pack" system. Its usability with Z/VM is limited by lack of VSAM support on most Z/VM systems.

User self help is available on the kicksfortso yahoo forum at https://groups.yahoo.com/neo/groups/kicksfortso/info

Paid support is also available, for more information please contact me at http://www.kicksfortso.com/same/kicks-contact.htm


Copyright © Mike Noel, 2008-2014; last updated 10/23/2014