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
- Integrated commercial KICKS features into free version,
including
- Support for large screens (up to 62x160) via 14 bit sba's.
- Support for OCCURS in BMS maps.
- Shared intrapartition transient data queues.
- Shared temporary storage queues.
- Improved DB2 compatibility using SYNCPOINT exit to automatically drive
database COMMIT/ROLLBACK.
- Enhanced application error recovery with HANDLE ABEND.
- Enhanced application debugging with COBOL and GCC source code trace /
breakpoint in KEDF.
- First release of full source code.
1.4.1
- 'Golden' version of KICKS
- Improved (simplified) Z/OS install. Ability of install on any userid in
Tur(n)key system.
- Major cleanup of documentation and example programs.
- Implementation of keyboard locking with SIT override/control.
1.4.0
- Release candidate for 'Golden' version of KICKS
- 'LENGTH OF' support for MVT COBOL; relaxed requirements for
LENGTH, FLENGTH, KEYLENGTH, (etc)
- Mapgen support for DSATTS & MAPATTS in addition to current support
for EXTATT.
- 'Help' screen & license display added to Good Morning Message (aka KSGM)
transaction.
- STRFIELD argument added to SEND TEXT api
- FROM/LENGTH added to DUMP api
- HOLD argument added to LOAD api
- Support for qualified names (X of Y of Z ...) as api arguments
- Catch/Fixup error on write to empty ksds
- COBOL preprocessor markup <ZOS>, </ZOS> changed to <CB2>,
</CB2>
- and of course the biggest new feature --
CMS support
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
- Improved sequential terminal (aka CRLP) with fielded input. The BATCH1
job in TESTCOB has been substantially updated to show most of the features
of this improved interface.
- Support for localization with ASSIGN api LANGINUSE and NATLANGINUSE
options, and SIT parameter to specify NATLANG, which defaults to E, (ENU,
American English).
- Other fixes / improvements:
- dynamic logo, colored letters changing every few seconds (can be turned
off)
- added 'API' section to 'Programming' section of KICKS User's Guide.
- more API test/examples added to TESTCOB and TESTGCC libraries.
- fixes for BMS input - erase EOF, numeric justify default, and improved
MAPFAIL compatibility.
1.1.2
- Support for ENQ and DEQ api calls.
- Support for GETMAIN and FREEMAIN api calls.
- Integrates a number of fixes from the first few months of user
experience with GCCMVS support.
- Other fixes / improvements:
- added NOHANDLE support to all api calls
- added preprocessor markup <PRO> </PRO>, <NPRO> </NPRO> so programs can
be setup to use KICKS Pro features based on availability. See
...TESTCOB(LINKTST) for example.
- added preprocessor markup <ZOS> </ZOS>, <NZOS> </NZOS> so programs can
be setup to use LE COBOL features based on availability. See ...TESTCOB(GETFREE)
for example.
1.1.1
- Support for modern LE COBOL compilers on Z/OS.
- A proc (KIKCB2CL) is supplied to compile and link using the LE compiler.
- Two new 'CB2' datasets - similar to the corresponding 'COB' datasets.
These contain the sample and supplied programs in COBOL2 form. The CB2
'Murach' programs in particular are completely different from the COB
versions: they are essentially straight out of the book.
- All the sample programs and all the api test programs work as expected.
- Only usable on modern systems obviously. Tested on Z/OS 1.6 (COBOL
3.3.1)
- The Z/OS install procedure has also been substantially improved.
- Command Level GCCMVS support.
- The TESTJCL dataset introduced in 1.1.0 has been split into TESTCOB
(COBOL programs) and TESTGCC (GCCMVS programs). In general the names of
the members are the same in both, and the programs exercise the same
api's.
- Four new 'GCC' datasets - similar to the
corresponding 'COB' and 'COBCOPY' datasets.
- The map generator proc KIKMG now generates GCC symbolic maps (by
default into GCCCOPY as well as COBOL symbolic
maps. The map generator also supports the FOLD= parameter on KIKMSD,
with LOWER being the default.
- A GCCMVS proc (KIKGCCPP) is provided to preprocess GCCMVS programs
(like KIKCOBPP does for COBOL programs). Since GCCMVS does not provide a
compile listing the proc provides one (with line numbers) so that GCCMVS
compiler diagnostics can be more easily traced to the offending source.
- GCCMVS programs are handled by KICKS just like COBOL programs, and
should be so defined in the PPT (ie, as LANG=COBOL).
- GCCMVS programs may LINK or XCTL to other GCCMVS programs or to
COBOL programs. And visa-versa: COBOL programs may LINK or XCTL to
GCCMVS programs.
- May need to increase region size for KICKS use: Each "link level" of
GCCMVS requires about 200k (~64 k for PDPCLIB plus 128k for the stack it
allocates). So a GCCMVS transaction will need at least 200K, and if it
links to another GCCMVS program add 200k more, etc. This is transient
use: KICKS cleans up when the program(s) return and when the transaction
ends (or abends), so a 1 meg TSO region should be sufficient for most
use (several link levels + some VSAM).
- Tested in Z/OS,MVS380, TK3UPD, and the base TK3 with GCCMVS and PDPCLIB 7.0, 7,6, and 8.0 (current
as of 10/31/2010).
- NOTE - KICKS does not include GCCMVS. It
is a standard component of MVS380, and may be downloaded and installed
on other operating systems as desired. See
http://gccmvs.sourceforge.net.
- A new SIT parameter, MAXDELAY (default 180 seconds) added to allow
overriding the previously hardwired 3 minute maximum delay.
- Changed install (TK3 & Z/OS) so that it is now by default all into one (userid)
HLQ. Added procedures to semi-automate customization for Z/OS use.
- A few other fixes / improvements:
- Fixed a variety of issues in new transient data & "spool" api's
- Fixed missing pgm/offset in KEDF on RETURN COMPLETE. Also RETURN
COMPLETE now displays as LINK COMPLETE.
- Fixed several formatted dump trace table print (and related KEDF hex
output) anomalies
- Fixed timestamp in map generator output (was gmt instead of
localtime)
- Added check in map generator to ensure field (MFD) is within map
(MDI)
- Fxed batch userid capture (when USERID= not coded on job card)
- Fxed KEDF for SEND MAP / RECEIVE MAP dsect scrolling
- Added KEDF display of absolute time when DELAY is for TIME or UNTIL
(ie, wait until a certain time).
1.1.0
- The User's Guide (what you're reading) has been migrated to the web.
- KEDF, a debugging facility similar to CEDF in real CICS. You use it to
peek around before and after each of your api calls. You can see the api
call itself, the variables passed in and out, the EIB, the trace table, the
comm-area(s), your program and it’s working storage, and various system
areas (cwa, twa, tctteua). See the “Debugging” topic in the “Programming”
section.
- Sequential terminal - KICKS can now run in batch as well as TSO. In batch, 3270 input comes
from the ‘card reader’, and 3270 output goes to the ‘line printer’ – so this
feature is also called a CRLP terminal. The CRLP terminal supports limited 3270
emulation. 3270 output screens are reasonably well rendered, less color and
highlighting obviously. On the input side provision for 3270 ‘aids’ is
provided so you can, for example, enter a CLEAR command. Sample jobs are
included to use KICKS with normal batch jcl, as well as use of the normal
KICKS clist with the TMP in a batch environment. See the “Using KICKS in
Batch” topic in the “Operation” section.
- Many of the 'supplied' transactions (KSGM, KSSF, KSMT, KEDF, etc) now
use larger screens when available (3270 mod 3, mod 4's). Alternate screen
size support is not new, but its use by the supplied transactions is. Source
for these transactions can be examined to see how it's done.
- Printing and job submission is supported with the SPOOLOPEN, SPOOLWRITE,
and SPOOLCLOSE protocol.
- Extrapartition Transient Data (TD) input and output queues are
supported, and a new table, the DCT, is provided to define those queues.
These can be used for general sequential file purposes, for example log
files. They could also be used (and often are) for printing and job
submission but the SPOOLOPEN api is much easier to use for those purposes.
- Screen handling has been improved in several subtle but important ways.
First, screens are rendered with 3270 sfe orders instead of with sa orders.
This means KICKS maps almost always display exactly like they display in CICS. Second,
KICKS now supports the “dataonly” option for SEND MAP, so
complex applications that partially update and reread screens now look and
work exactly like they do in CICS. Finally, SEND CONTROL has been
implemented making porting existing programs between CICS and KICKS a
little bit easier.
- WRITE OPERATOR (including REPLY option) has been implemented.
- The COBOL language preprocessor has a SYSLIB facility, providing a COBOL
‘COPY’ syntax more like modern COBOL compilers and the old ANSI COPY syntax
is still available as well.
1.0.0
- The first real release of KICKS, implementing enough of the full CICS api that useful applications could be developed and run, and many existing
CICS applications could be ported to KICKS.
0.9.0
- An alpha distribution of KICKS. It initially lacked an MVS based
BMS map generator; a PC based Perl script had to be used to generate maps and
the resulting output upload to MVS for final processing.
Goals for the next release / level-set.
- The 1.5.1 interim release (mid 2015?) will provide early support for 31
bit applications; the goal being to get that into user testing well before
its official debut in the 1.6.0 release. 1.5.1 thus is primarily for 'z'
users and will also feature a preprocessor for IBM C and KICKS
build using that compiler.
- The 1.6.0 release (2016 timeframe?) will feature 31 bit compatibility, IC
(interval control), trigger processing, and internals documentation.
- The 1.7.0 release (2018 timeframe?) will feature Journaling & DTB
(dynamic transaction backout), dynamic table update, and maybe a command
level interpreter.
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