| KICKS |
A transaction processing system for CMS & TSO |
Paraphrasing Wikipedia’s TSO entry (http://en.wikipedia.org/wiki/Time_Sharing_Option),
The Time Sharing Option (TSO) is an interactive time-sharing environment for IBM mainframe operating systems running from OS/MVT through MVS and OS/390 to the current z/OS. "Time-sharing" means that many persons can access MVS concurrently but each is unaware that the operating system is being accessed by others - so it appears to each TSO user that he or she is the only user on the system. TSO is most commonly used by mainframe system administrators and programmers because it provides: a text editor; the ability to submit batch jobs, be notified of their completion and view the results without waiting for printed reports; debuggers for some of the programming languages used on System/360 and later IBM mainframes; other vendors' end-user applications, for example for querying IMS and DB2 databases. The name "Time Sharing Option" derives from the fact that, when it was originally introduced in the 1960s, time-sharing was considered an "optional feature", as compared to standard batch processing, and hence TSO was offered as an optional feature of OS/MVT. It became a standard part of MVS in 1974. TSO interacts with users in either a line-by-line mode or in a full screen, menu-driven mode. In the line-by-line mode, the user enters commands by typing them in at the keyboard; in turn, the system interprets the commands, and then displays responses on the terminal screen. TSO commands can be embedded in clists which can be run either interactively or in batch.
Paraphrasing Wikipedia’s CICS entry (http://en.wikipedia.org/wiki/CICS),
CICS (Customer Information Control System) is a transaction server that runs primarily on IBM mainframe systems. It is a transaction manager designed for rapid, high-volume online processing. This processing is mostly interactive (screen-oriented), but background transactions are possible. While CICS has its highest profile among financial institutions such as banks and insurance companies, over 90 percent of Fortune 500 companies are reported to rely on CICS for their core business function], along with many government entities. CICS is used in bank-teller applications, ATM systems, industrial production control systems, insurance applications, and many other types of interactive applications. A CICS transaction is a set of operations which together perform a task. Usually, the majority of transactions are relatively simple tasks such as requesting an inventory list or entering a debit or credit to an account. A primary characteristic of a transaction is that it should be atomic. On large mainframes CICS easily supports thousands of transactions per second, making it a mainstay of enterprise computing. Each CICS program is initiated using a transaction identifier. CICS screens are sent as a construct called a map, a little program created with BMS (Basic Mapping Support) assembler macros. The end user inputs data, which is made accessible to the program by receiving a map from CICS.
The first release of the CICS Program Product developed by IBM became available on July 8, 1969. CICS was originally developed in the United States at an IBM Development Center in Des Plaines, Illinois, beginning in 1966. Since 1974 CICS development has been at IBM's Hursley, United Kingdom Laboratory. When CICS was first released, it supported programs written in IBM Assembler, PL/I and COBOL. Programs needed to be quasi-reentrant in order to support multiple concurrent transaction threads. CICS services emulated the functions of the operating system, but provided services tailored to support only transaction processing that were more efficient than the generalized services in the operating system and much simpler for programmers to use, particularly with respect to communication with terminal devices. CICS owes its early popularity to its relatively efficient implementation, its multi-threaded processing architecture, and its relative simplicity for developing terminal based applications. Today CICS has millions of applications worldwide that have been executing reliably for decades.
And paraphrasing the TSO TIMES (see http://www.tsotimes.com/articles/archive/fall03/historyoftsopart2.html),
The most descriptive word for TSO is conversational. Conversational, in a shared computing context, means that each TSO user logged on to MVS has their own address space. The hallmark of a conversational environment is the long term holding of what could be a shared resource. That is, a resource (file, memory, source member) is held onto as long as a user is using it. The term for this is think time. Something like editing a program (which can take many hours of think time) would be a good example of a conversational task. For the entire time that a TSO user is editing a file, an exclusive lock is maintained on the file being edited. No one else can edit the same file while the original TSO user edits it.
To underscore the conversational nature of TSO sessions, compare TSO to CICS which is said to be pseudo-conversational. In the simplest sense, the difference can be seen in the following graphics.
The Conversational TSO teleprocessing model
TSO requires a server address space called the TCAS (Terminal Controlling Address Space). TCAS constantly polls its chain of attached TSO address spaces looking for input. When a TSO user is not pressing Enter (or another AID key), the operating system "swaps out" that TSO address space. This conserves some resources but still each TSO user requires significant operating system servicing.
The Pseudo-Conversational CICS teleprocessing model
CICS has a single address space (commonly called a "CICS region") with a large number of terminals connected to it. It is a task-based model in that when a user initiates some work, a pre-defined task is run to display data on the user's terminal screen and sometimes the displayed data is updated. However during the time that occurs between the initial request to view data and the eventual update of the data, no locks are held (unless explicitly programmed) and other terminal users are free to inquire against the same data. What this means is that during the potentially long think time period, the CICS user is not holding on to data resources as a TSO user would be. This is called a pseudo-conversational task-based environment.
With CICS, all terminals sign-on to a single address space. The CICS software manages this multi-tasking, concurrent terminal access by using a standard api. This is a one-to-many relationship: One CICS region (address space), many users attached to it.
TSO is a direct one-to-one relationship: One user, one address space.
Because of this, even on a large MVS mainframe, TSO consumes far too many finite resources to be a viable application platform for a large group of users. This is why CICS followed on to TSO and became the dominant teleprocessing monitor for heavy-duty, high volume business applications—it is far less expensive in terms of machine utilization.
So what about KICKS, trying to be a CICS environment running under TSO or CMS?
Ideally KICKS provides a happy combination of the TSO/CMS and CICS worlds:
The above advantages are also the seeds of the major limitations KICKS faces:
Although KICKS now supports nearly all of the CICS command level programming api, a big KICKS advantage over CICS is freedom from the CICS api! If you don’t care about compatibility, techniques that would crash a CICS system will work very well in KICKS. Some examples:
Q. Where can I find manuals for the legacy COBOL compiler?
A. The manuals for the legacy COBOL compiler (360S-CB-545, 360S-LM-546) used in the MVS Turnkey and the VM/370 six pack, are COBOL Manual GC28-6396 and COBOL Programmer’s Guide GC28-6399. Both are on Bitsavers (bitsavers.trailing-edge.com/pdf/ibm/360/os/cobol). Other than those manuals the best reference I’ve found is Jay Moseley’s "Assembling, Compiling, Link-Editing, and Executing User-Written Programs" page (http://www.jaymoseley.com/hercules/compiling/compile.htm).
Q. I’m using a ‘programmer generated’ symbolic map but it doesn’t work right
A. This might happen because your programmer generated symbolic map does not match the symbolic map that KICKS generates. Check that there are no missing or changed fields between the two. Older versions of KICKS did not support DSATTS/MAPATTS in the map generation and instead changed them to EXTATT, resulting in more or fewer bytes in the symbolic map than might otherwise be expected. KICKS now honors DSATTS/MAPATTS and should produce symbolic maps fully compatible (in this respect) with CICS.
Q. I’m getting enqueue timeouts (30 second pause, then AFCT/ADCT abend).
A. Also RESP=19, RESP2=99 if you are trapping errors. This is probably due to a KICKS batch job or perhaps an online conversational transaction holding on to a file for a long time, preventing other transactions like yours from being able to access the file. Batch jobs and conversational transactions should periodically release their files (SYNCPOINT) to allow others to operate normally.
This can also be caused by someone using KEDF to debug a transaction that uses the file your transaction is trying to access. KEDF freezes transactions at each api call, so transactions that might ordinarily hold a file for a fraction of a second can end up holding the file indefinitely while a programmer is slowly stepping thru the code analyzing its progress. The best cure for this problem is to insist programmers use a different set of files for their debugging.
Q. My printout of CRLP batch runs has a few characters that are different from what's shown here.
A. And/Or my screen displays show different (or even missing) characters from what's shown here. These are symptoms of 'CODEPAGE' issues, translating EBCDIC characters to ASCII characters on your printouts and/or tn3270 client. Under hercules you should use "CODEPAGE 819/1047" in your hercules.conf file (the one you use to start hercules, define all you disks & termnals, etc). This should fix printout problems. Making the same codepage selection for your tn3270 client should fix screen problems.
Q. I’m getting a VER1 abend.
A. VER1 abend means your program was not compiled for the current version of KICKS. You should recompile it.
Q. I’m getting a VER2 abend.
A. VER2 abend also means your program was not compiled for the current version of KICKS. You should recompile it. This abend usually happens instead of a VER1 abend if you attempt to just relink your program instead of compile and relink...
Q. I’m getting a VER3 abend.
A. VER3 abend might mean your program was not compiled for the current version of KICKS, but usually means there is a problem with your COBOL compile options. KICKS programs require that PIC S9(4) COMP items be able to hold halfword numbers (ie, -32768 to + 32767), so you must specify whatever compiler option does that on your machine. Probably something like NOTRUNC or TRUNC(BIN) as seen in the standard KICKS COBOL compile procs.
Q. I’m getting an ATCP abend.
A. Also RESP=222, RESP2=?? if you are trapping errors. This can happen when you are using the "FULLSCR" version of TCP (2$) in TSO when you do a SEND MAP (or SEND TEXT) and that results in an attempt to send invalid characters to the terminal. TCP=2$ checks outbound messages for characters (0x01,.0x02, 0x03, 0x04, 0x06, 0x14, 0x15, 0x16, 0x17, 0x24, 0x26, 0x37, and 0x3D) that would be filtered (turned into colons) by the TSO "tput fullscr" macro, and if it finds any it produces this abend and aborts sending the data to the terminal. RESP2 will be the offset from the beginning of the message (which is displayed as the 'TIOA' in the formatted dump) to the first invalid character.
This error is unique to the "FULLSCR" version of TCP (2$) used with older distributions of the Tur(n)key MVS system. It is not generated with the "NOEDIT" version of TCP (1$) always used in z/OS, nor in any of the CMS versions of KICKS.
Q. My application can't lock the keyboard.
A. Older version of KICKS always unlocked the keyboard regardless of the application specification (ie, FREEKB), but more current version of KICKS honor (by default) the application specification. To revert to the older behavior set the SIT parameter FFREEKB=YES.
A. The TSO tput macro, as used by the "FULLSCR" version of TCP (2$, default in legacy MVS) in TSO , ignores the FREEKB bit in the 3270 WCC and always unlocks the keyboard. To obtain keyboard lock functionality in the TSO version of KICKS you must use the "NOEDIT" version of TCP (1$, which is the default in z/OS).
This does not apply to CMS; all CMS version of the terminal driver support keyboard lock.
Q. I’m getting a "Alternate 3270 screen > 4095 chars, ignoring" startup message.
A. The TSO tput macro, as used by the "FULLSCR" version of TCP (2$, default in legacy MVS), can only use 12 bit sba's due to its inability to use certain characters that might occur using 14 bit sba's. This limits its maximum screen size to 4095 characters. To work with larger screens in the TSO version of KICKS you must use the "NOEDIT" version of TCP (1$, which is the default in z/OS).
This does not apply to CMS; all CMS version of the terminal driver support large screens.
Q. Can KICKS share VSAM files with CICS?
A. No. KICKS VSAM file sharing works by opening and closing files as necessary. CICS does not close files until explicitly asked to, so once CICS has opened the file (usually when it starts, sometimes not until first use) KICKS probably won't be able to get it. If it does get it (because the file's VSAM share options are defined to allow it) that's a very bad thing, since neither KICKS nor CICS will know the other is using the file...
Different versions of KICKS can share VSAM files without issue. A older version with the current, or the free version with KICKSpro, etc.
Q. Is KICKS available in other languages?
A. KICKS is localized for American English (en-US). If you translate some components to your own locale please upload your work to the 'files' area in the support forum ( https://groups.yahoo.com/neo/groups/kicksfortso/info ) so that others don't need to reinvent the wheel. Thanks in advance!!
Q. DFHBMF?? is missing from KIKBMSCA
A. The DFHBMSCA copy member defines a number of useful 3270 attributes, but by no means all of them. Even the member IBM distributes for CICS does not cover all possibilities, and some find it's naming convention difficult. The prevailing wisdom is to not use DFHBMSCA, but to code and use your own attribute definition member with the names and combinations you like - or, equivalently from my perspective, to use a 'shop standard' attribute definition member. See for example http://www.nwrdc.fsu.edu/mainframe/bms-attribute-names or others you can easily find Googling DFHBMSCA. As such the BMSCA I supply is just a starting point for your efforts if you don't have something better. About the only time I add to it is if I need something for an example program.
Q. Do paid licenses include "support"?
A. I offer free basic support with all licenses, paid or otherwise. However, recognizing that some customers require a higher level of support I offer "guaranteed response" telephone and/or online support on a prepaid basis. If you require such support please contact me.
TSO rawhide published 9/3/2014
generated 9/3/14, open
1. noticed the READY READY issue
in z/OS. This is a long standing issue but not one I have seen previously except
in legacy MVS with the tcp=1$ driver. What happens is that, now and then, after the
colored 'KICKS is shutting down' message is shown you don't get the TSO ready
prompt. When you press enter again you get two READY prompts (usually white, not
red in legacy MVS). This does not happen with tcp=2$ or with any CMS tcp...
- can't reliably make the problem appear, so difficult to tell if attempted
fixes work...
- maybe due to leaving 'strange' stuff on the screen (such as the SA orders
associated with the shutting down message when KICKS ends.
- fix? -9/3/2014 - changed KSSFPGM to do a clear screen after 2 second delay after
sending the colored shutdown mesage - so that the screen TSO sees will be
totally blank.
** not the problem, 'fix' had no effect, issue remains
- maybe due to not doing a read after colored letter write? Noted on z/OS that
the colored letters where not showing up!
- fix? -9/25/14 - changed KSSFPGM to do a 'check' after colored letters write.
** 10/4/2014 nope, not fixed - READY READY appeared again (in
legacy MVS).
- more info -- 2/16/2015 can now reliably generate issue (on legacy MVS).
Generating procedure does not
generate ready-ready on z/OS, but does display possibly related issue in that
the KB is not locked after clear. Also noticed that I need to use QWS to test
this, as vista tn3270 seems to have a bug this procedure exposes ('short read'
for enter aid following clear aid). Also confirmed my "expected" result is
correct by trying in real CICS, and confirmed that it works properly in all CMS
versions of KICKS (and, within driver limitations, with tcp=2$ in
legacy MVS). At this point I'm testing to see if ready-ready may
be related to KICKS being called, not a command processor.
reported 9/3/14, fixed 9/4/14
2. KEBRPGM does not compile in
z/OS
due to compile diagnostic complaining about kik-aids1 being moved to a pointer
type.
- this due to LOAD api (for KEBRHELP) generating code for 'move after' from
kik-aids1 used (off label) for entry/set to a pointer.
- fix: updated KIKPPCOB (and PPGCC) to use given arg directly.
- also, while I was at it, updated PPCOB, PPGCC, KIKPCP1$, and KEDF to separate
SET/ENTRY (now reporting both) and to make all LOAD args optional.
reported 9/3/14 - resolved 9/5/14 - not a problem
3. IEC161I 020-054 abend (re
SDBDATA) in TSO when trying to use source trace. (this is z/OS system) also "1st startbr failed, resp=84, resp2=50" message in kedf
- this is an 'out of memory' situation. What's the region (below the line) for
the TSO session?
- resolved - 2m region, KICKS doc says min 4m
reported 9/4/14, fixed 9/4/14
4. GCC test program LINKTST fails
due to 'testcob3' not abending!
- this due to testcob3 not detecting condition to do FCP access to file NOFILE,
thus not abending. This due to PPGCC generating bad code in the case of an api
call directly following an if (ie, no preceding '{'), When that occurred PPGCC
gened a {linenum} {api expansion}, meaning the api expansion would not be within
the if as intended.
- fix: updated PPGCC to add another set of brackets so it looks like {{linenum}
{api expansion}}
- also, while I was at it, updated PPGCC to turn (8) error for missing KIKEIB in
main routine def into warning (4).
reported 9/6/14 queued to 1.5.1 release
5 Some GOLD and PRO markup still
exists.
- 1.5.0 is a 'PRO' version, but since that's the only kind there is now the GOLD
& PRO markup, thou still recognized, should be removed and when finally gone
PPCOB and PPGCC should have their recognition of it removed as well.
CMS rawhide published 9/7/2014
generated 9/9/14, fixed 9/9/14
6 KUNLKED vrm wrong, so stamped
in vrm in KIKENTRY is wrong for anything using it Most everything really...
- this is not vrm that is checked, except by eyeball, so it's ok in the rawhide,
but needs fixing before another publish
- KUNLKED updated, fix will propagate next ADOALL...
TSO, source, and CMS rawhides published 9/22/2014
generated 9/23/14, closed 9/28/14, all items addressed
7 z/OS source install issues
NOTE - z/OS is not a "supported" build platform for KICKS,
but since some may want to casually play with the source on z/OS it seemed best to address
these issues by fixing them when easy, and by otherwise documenting them...
- source install does not support update to JCLLIB for z/OS fixed 9/25/14
- ADOALL jobs run out of order due to multiple initiators serving class A jobs.
Need to fix to run right, or run one at a time instead of using ADOALL.
- added notes to ADOALL fixed 9/25/14
- FB2VB, PARMINFO, PDSUPDTE & KIKALI do not compile various JCL issues
- parminfo - not using proc, using mvt COBOL compiler
not gonna fix, not used in z/OS closed 9/25/14
- pdsupdt$ - using ASMFCL proc, doesn't work in z/OS
not gonna fix, used only in install, closed 9/25/14
- fb2vb - fixed 9/24/14
- kikali
not really a 'source' issue, but exposed in source testing...
fixed 9/25/14
- MUR & TAC examples do not compile
- these should compile from .CB2 lib, not from .COB lib
added notes to ADOALL & KIKSAMP fixed 9/25/14
- ASRB (ASRA, AICA) routine does not compile. also SIP won't
link due to missing ASRB routine
- jcl issue
fixed 9/25/14
- COB glue routine does not compile.
- jcl issue
fixed 9/25/14 by making it like GCC glue
- KEDFPGM compile fails
not really a 'source' issue, but exposed in source testing...
- bad PPCOB code gen, LOAD api expansion exceeds col 71
- result of issue 2 fix??
fixed 9/25/14
- KSDBLOAD compile fails
not really a 'source' issue, but exposed in source testing...
- cob2 doesn't like redefining 01 levels under FD
fixed 9/25/14
reported 9/23/14, fixed 9/25/14
8 z/OS install does not fully
support userid/prefix/literal HLQ due to missing support in the 2nd level rexx
($$V1R5M0) in the xmi.
- rewrote rexx to provide arguments allowing HLQ to be overridden.
- while I was at it I also provided ability to override volser.
reported 9/26/14, fixed 9/26/14
9 license does not address
concern re LE/370 in distros leaving legacy (legacy MVS, VM/370) systems behind.
- added restriction to license against incompatible objects
reported 9/27/14, fixed 9/27/14
10 running test programs as part
of ADOALL in source install takes to long for no purpose.
- made the last ADOALL step (running tests) optional
reported 9/27/14, fixed 9/27/14
11 tempstor, intrapartition
queues, and source db not defined during CMS install. This due to not running
LOADSYS in POSTVSAM exec.
- added LOADSYS to POSTVSAM
TSO, source, and CMS rawhides published 9/28/2014
reported 9/30/14, fixed 9/30/14
12 KEDF lines shown as green in
User's Guide are always blue...
- some tn3270 clients enable 3270 base color mode, some don't. Most don't allow
a choice! This is not an issue normally, but KEDF screens are really busy and losing the
color separation of its screen areas when using a tn3270 client that does enable
base color mode is not helpful.
- added attribute set into DOTOP to force green
last minute change! 10/2/14, fixed 10/12/14
13 TSO version needs KICKS...SKIKLOAD
in addition to KICKSSYS...SKIKLOAD (like CMS version already has). This to simplify user table maintenance for
"system install" versions of KICKS.
- updated both clist & exec to create user libs if not already present, and to
incorporate into appropriate concatenations.
reported 10/3/14, fixed 10/3/14
14 ksgmlic fails on mod 3 terms.
This due to incorrect map select (switched mod 3 & mod 4).
- corrected map select code.
reported 10/7/14, fixed 10/9/14
15 source trace compiles failing
IEC020I 001-4. compile proc(s) jcl issue, possible mismatch of blocksizes in
concatenation.
- fixed source trace compile procs.
reported 10/9/14, fixed 10/9/14
16 source trace reporting source
date non-match when should report source not found. "i16" (used in startbr
call) was short but should be int.
- made i16 int instead of short
reported 10/10/14, fixed 10/10/14
17 'funny' chars in KEBRPGM
source code. Actually just a few "[" and "]" characters mistranslated (more ind$file mess ups) in a couple of comments, but fixed anyway...
reported 10/10/14 - resolved 10/13/14 - not a problem (but maybe worth a
comment in doc or KooKbooK someplace)
18. KEDF source trace PF4 "skip
subroutine" did not return.
- skip subroutine returns when the program gets to the next executable instruction,
but that may not
be the same as the next instruction the program executes! For example, consider
IF blah blah THEN
PERFORM SKIP-THIS
ELSE
PERFORM MARKS-THIS-AS-RETURN.
PERFORM EXPECTED-RETURN-HERE.
if you were at "PERFORM SKIP-THIS" and pressed PF4 you might expect to return
to "PERFORM EXPECTED-RETURN-HERE", but KEDF sets up the temporary
breakpoint at "PERFORM MARKS-THIS-AS-RETURN", which is not hit so no "return" is
apparent.
- working as designed!
- possible enhancement: PF16 (shift PF4) to do "set temp BP at current
location (or
cursor) and go".
reported 10/16/14, fixed 10/17/2014
19 when using source trace, and
no source is found, and a resp<>0 event occurs, the resp is not shown,
which is confusing since the only reason for the break is the bad resp! This due
to not calling api_resp before dobottom in those error cases in source_trace.
- added required api_resp calls.
generated 10/20/14, open
20 this is to document some
'rough edges' in the KEBR program..
- analyze-cursor sometime reports wrong when cursor on "**bottom**" or bottom
ruler line of hex display
- repeated find sometimes does not switch directions properly
- need KooKbooK recipe for CICS install ✓(see issue 27)
- online help could be improved to show *all* commands instead of just those new
or different from CEBR; also vget should note the vsam file name is as in the
FCT (ie, its DDN), not as in its DSN.
- 'checksum' partially implemented to detect queue changed since last displayed;
needs to be finished...
- find highlight could be improved. 'scroll to' highlighting a bit confusing
reported 10/20/14, fixed 10/23/2014
21 KEBR does not find short tdq/file
names in get/vget if an optional argument is present
- changed to move only up to first space to tdq/file name
reported 10/23/14, resolved 10/23/14 - not a problem
22 some dates in the issues list
are beyond the
"last updated date" at the bottom of the page
- "Last updated date"
refers to the Appendices document, but the issues list is a server side include
and can change without the Appendices document changing. Added 'issues last
updated' to bottom of the include...
feature request 10/30/14, request declined 11/11/14
24 show "source listing not found"
message only once per program per task instead of for every source statement.
- really only an issue for a program that was compiled with source trace, but
the source code database has since been reinitialized so the source is no longer
available. Options: recompile (with or without source trace), switch to API mode
(PF2), or just turn off
source trace (PF13).
- 4/22/16 - changed 'SOURCE LISTING NOT FOUND' msg suffixing ', PRESS PF2 FOR API MODE'.
TSO, source, and CMS final (?) published 11/7/2014
reported 11/9/14, resolved 11/9/14 - ** unpublished **
25 On TK4- system, where
KICKS "system install" done, tso source build ADOALL step ADO11 submitted jobs (LOADMUR, LOADTAC, LOADSDB, LOADTEMP, LOADINTR) fail due to RAKF issue, unable to delete vsam file(s).
- cause is that specific RAKF rules exist for these (system install use) files, and the default id
associated with intrdr job isn't allowed to delete. Maybe not a big deal, since
this step isn't actually necessary to the build; the files are already built in
the course of the normal KICKS install.
- solution: delete step 11 since it is not necessary anyway
observed 11/16/14, resolved 11/19/14 - ** unpublished **
26 Syncpoint exit may foul up
pseudo conversational tasks. Fixing this turned out to be one of those efforts
that kept turning up mostly unrelated minor issues that also got fixed along the
way, as noted.
- fixed KCP code calling exit to preserve calen & nextran
- also noted and fixed related issue in PCP setting nextran
- also noted and fixed tempstor & intrapartition queue 'empty startup' problem
- also upgraded SIP auxtrace to show more decoded trace entries
published 11/21/14
27 KooKbooK recipe 15, "Installing KEBR in real CICS"
generated 11/22/14 open
28 status of KooKbooK updates (1-14)
- 1 - Designing and implementing simple BMS maps - republished 11/19/2014
- 2 - Designing and implementing simple KICKS COBOL programs -
republished 11/21/2014
- 3 - Designing and implementing simple KICKS COBOL programs, part II - republished 11/22/2014
- 4 - Run Away Task! - republished 11/23/2014
- 5 - Designing and implementing simple
KICKS COBOL programs, part III
- republished 12/06/2014
- 6 - 251 project – Scripting 3270 apps with open source tools ( I ) -
republished 12/30/2014
- 7 - 251 project – Scripting 3270 apps with open source tools ( II ) - republished
1/16/2015
- 8 - 251 project – Resource Definition ( I ) - republished
1/17/2015
- 9 - 251 project – Resource Definition ( II ) - republished
1/18/2015
- 10 - 251 project – Workload & Final Project Wrap Up - republished
1/19/2015
- 11 - Designing and implementing simple KICKS GCCMVS programs - republished
2/3/2015
- 12 - Using Alternate 3270 screen sizes in COBOL and GCCMVS programs - republished
11/23/2015
- 13 - Using DB2 with KICKS (reformat only, content update
queued to
1.5.1 release) -
- 14 - VSAM in the VM/370
SixPack (1.2) system -
pending change 11/22/14 queued to
1.5.1 release
29 improve tempstor, intra queue
sharing
a. change FCP close so that, in CMS, rel/det happens after last open file is closed
b. close tempstor, intra on conversational read even if pct entry says files stay open
reported 11/26/14 open
30 PDSman.xls does not handle
member aliases. This utility is not distributed with KICKS, but it
is something I've posted to the KICKS web site so I will
fix this sooner or later. Since no KICKS distribution datasets
contain aliases it's not a high priority...
feature request 11/30/14 queued to
1.5.1 release
31 Claim is KICKS already
'does' IRC, it just doesn't name it. This request is to support, for
compatibility, specification of SYSID in api calls. Such calls would be
execution time comments, but since files/queues are (or can be) shared, the
result is the same as if 'real' IRC was happening. Request prompted by desire to
add IRC to KEBR for use in real CICS.
- looks like a good idea, may need further research and definition
pending change 12/16/14 queued to
1.5.1 release
32 improve trace, auxtrace & kedf
trace by adding eibline & eibprog to each trace entry (internal entry size will
go from 16 to 32). This may also allow backward lookup (how you got here) at a
source trace breakpoint...
pending change 12/31/14 open
33 update User's Guide Install
section for TK4- update 6, 7.
- also do more clean up of the whole install section...
observed 1/5/15, resolved 1/6/15 - ** unpublished **
34 noticed that VRM checking
apparently systematically (but accidentally!) removed from the suffixed
management modules, needs to get put back...
observed 2/6/15, fixed 8/8/2015 - ** unpublished **
35 directly returning current
comm-area does not work. Usual code is to move it to working storage, change in
working storage as needed, then return the working storage copy. But fails if
RETURN TRANSID(EIBTRNID) COMMAREA(INPUT-COMM) LENGTH(EIBCALEN)
- because INPUT-COMM is cleared before it's moved to itself...
- changed to clear remaining after move...
reported 2/6/15, resolved 2/10/15 - ** unpublished **
36 use of SYSALLDA in legacy MVS
install procedures causes install job failures when the allocation
occurs onto a pack without sufficient space.
- changed GETXMI & RCVKICKS (install instructions) and V1R5M0 (in BIGPDS
install library) jcl to
specify SYSDA instead of SYSALLDA.
last minute change! 2/15/15 - ** unpublished **
37 While working on issue
#1 (ready-ready) I made a temporary change to ACP to un-suppress normally
suppressed transaction dumps when intense tracing is active. Having decided this
is a worthwhile change I've decided to make it permanent.
last minute change! 5/8/15 - ** unpublished **
38 Minor license revision; Under
USE, authorized users to "agree to" as well as "not violate" terms.
reported 5/13/15, fixed 8/7/15 - ** unpublished **
39 screen shots in 'examples'
part of user's guide missing.
generated 5/17/15 open
40 TS QUEUE and QNAME arguments
(for DELETEQ, READQ, WRITEQ) need additional clarification in their API
description to state QUEUE expects 8 characters of name, and QNAME expects 16
characters of name. Either will be right padded with spaces to make 16
characters. Names in the queue itself are always 16 characters..
reported 12/18/15, fixed 12/18/15 - ** unpublished **
41 Install fails with "IKJ56221I
VOLUME ..." message trying to install KICKS (or KICKS source) onto specific
volume in z/os.
- happens when volume specified isn't part of the default volume group.
Fixed by adding 'UNIT(SYSALLDA)' to allocation in $$V1R5M0 rexx.
reported 5/4/16, fixed 6/26/16
42 license does not address
transfer.
- added 'non-transferable' to free license grant.
reported 5/14/16, fixed 6/26/16 - ** unpublished **
43 Cobol preprocessor with source
trace option generates bad code when using as a pre step for a DB2 program.
- 'exec sql' block must not have trace statements inserted!
feature request 7/1/16 queued to
1.5.1 release
44 Would be helpful if SPOOLOPEN
supported nocc/asa/mcc options for carriage control..
- nocc is what it's doing now, but some 'printables' (like KEBR help) have asa
control.
- looks like a good idea, may need further research and definition (re
additional options beyond those mentioned)
reported 8/14/16, fixed 8/20/16 - ** unpublished **
45 Compiling for 'no KEDF' does
not work in TSO, program still traps into KEDF when it's turned on. Works
in CMS.
- fix for issue 7 introduced new bug KIKCOBGX same as KIKCOBGL! Replaced 'undef
DOEDF' for KIKCOBGX compile (like in CMS).
- added 'with source trace' to KEDFPGM 'on/s' response while fixing this.
reported 3/21/17 open
46 CONDITION(s) in HANDLE
CONDITION (etal) should be documented in Users Guide, rather than just saying
they are the same as DFHRESP (which is itself undocumented in Users Guide).
feature request 4/1/17 queued to
1.5.1 release (or later)
47 Would be helpful if RETURN
TRANSID
supported IMMEDIATE option..
- helpful in a db2 environment.
- might be a good idea, needs further research, especially wrt INPUTMSG.
reported 7/30/17 open
48 0C1 abend in batch KICKS
following install of v8 TK4-.
- circumvention: add LDMOD S37X to tk4-.cnf to restore 37x opcodes...
- long term: need to change the way KICKS detects 31 bit capable/zos...
reported 1/25/20, fixed 1/25/20 - ** unpublished **
49 Protection Exception in
KIKCB2CL EXEC (zvm). Caused by lack of support for new format libraries in
KIKPPCOB.
- circumvention: dont use new format maclibs, so if KICKS EXEC creates some user
libs on A disk (as it will if you install KICKS elsewhere), move the supplied
oncs from there to your A disk so they will be in 'OLD' format...
- updated KIKMACLB subroutine to support new lib format (as well as old).
issues last updated 1/25/2020