KICKS

A transaction processing system for CMS & TSO

KICKS KooKbooK recipe

Installing KEBR in real CICS

I've mentioned somewhere that KEBR (the KICKS version of the temporary storage browser) can easily be installed in real CICS if desired. You might want to use KEBR (instead of or in addition to the CEBR browser that comes with CICS) for KEBR's vertical hex display, for it's ability to browse vsam files, for printing, or ...  Whatever the reason, there really is nothing to it. KEBR installs just like any other command level COBOL program. But for those who want a true KooKbooK install...

(1) generate  the maps into accessible copy libraries and into a loadlib in your CICS's DFHRPL concatenation.

The following JCL is based on an install on one of my client's machines. He was using TS 3.2 at the time. Every CICS shop is a little different, so the odds that the JCL is exactly right in your shop is pretty small. Still, it should be close enough that you can figure out what you will need to change. 

I copied userid.kickssys.v1r5m0.cob(kebrpgm), ...cob(kebrhelp), and ...mapsrc(kebrmap) into userid.kicks.forcics(cob), ...(help), and ...(map). I then edited those three members to strip off the jcl and created members cobjcl, helpjcl, and mapjcl.  Since my client's procedure is for users to 'stage' programs into his test CICS (ie, he reviews then copies programs from your library to a library in the DFHRPL concatenation) I also created a userid.kicks.forcics.dfhrpl load library. The JCL I used to generate the maps (member mapjcl) looked like

//KEBRMAP JOB
//JOBPROC JCLLIB ORDER=(DFH320.CICS.SDFHPROC)
// EXEC DFHMAPS,MAPNAME=KEBRM,
// INDEX='DFH320.CICS',
// MAPLIB='USERID.KICKS.FORCICS.DFHRPL',
// DSCTLIB='USERID.KICKS.FORCICS'
//COPY.SYSUT1 DD DSN=USERID.KICKS.FORCICS(MAP),DISP=SHR
//

(2) compile the program into a library in your CICS DFHRPL concatenation (probably the same as in step 1).

The JCL I used to compile the program (member cobjcl) looked like

//KEBRPGM JOB
//JOBPROC JCLLIB ORDER=(DFH320.CICS.SDFHPROC)
//PP2 EXEC PGM=KIKPPCOB,
// PARM='-v -cb2 -t -nokicks'
//STEPLIB DD DSN=USERID.KICKSSYS.V1R5M0.SKIKLOAD,DISP=SHR
//SYSPRINT DD DISP=(,PASS),UNIT=SYSDA,SPACE=(800,(500,100)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800),
// DSN=&PP2OUT
//SYSTERM DD SYSOUT=*,DCB=(BLKSIZE=120,RECFM=F)
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DISP=SHR,DSN=USERID.KICKS.FORCICS(COB)
//KEBRPGM EXEC DFHYITVL,OUTC='*',
// PARM.COB='MAP,OFFSET,APOST,TRUNC(BIN)'
// INDEX='DFH320.CICS',AD370HLQ='IGY410',LE370HLQ='CEE',
// DSCTLIB='USERID.KICKS.FORCICS.COB',
// PROGLIB='USERID.KICKS.FORCICS.DFHRPL'
//TRN.SYSIN DD DSN=&PP2OUT,DISP=(OLD,DELETE)
//LKED.SYSIN DD *
NAME KEBRPGM(R)
/*
//

Note running the KICKS preprocessor in front on the CICS preprocessor, and specifying "-nokicks". This causes the KICKS preprocessor to edit the source so that the "<>" markup is handled (in this case for example it will select the COBOL2 statements and drop the MVT COBOL statements) but it does not processes the KICKS/CICS api statements. If this was a permanent migration of a program from KICKS to CICS you might want to store the result and not have to rerun the KICKS preprocesor every time, but since this is a KICKS system utility that will probably change in future KICKS releases you may want to keep the jcl as shown.

(3) assemble the help file into a library in your CICS DFHRPL concatenation (also probably the same as in step 1).

The JCL I used to assemble the help file (member helpjcl) looked like

//KEBRHLP JOB
//ASM EXEC PGM=ASMA90,PARM='DECK,LIST'
//SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1))
//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(2,1))
//SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(2,1))
//SYSPRINT DD SYSOUT=*
//SYSLIN DD DUMMY
//SYSPUNCH DD DSN=&&OBJSET,
// UNIT=SYSDA,SPACE=(80,(200,200)),
// DISP=(,PASS)
//SYSGO DD DDNAME=SYSLIN
//SYSIN DD DSN=USERID.KICKS.FORCICS(HELP),DISP=SHR
//LKED EXEC PGM=IEWL,PARM='XREF,MAP,LET,NCAL',
// COND=(0,NE,ASM)
//SYSLIN DD DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSIN DD DUMMY
//SYSLMOD DD DSN=USERID.KICKS.FORCICS.DFHRPL(KEBRHELP),DISP=SHR
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1))
//SYSPRINT DD SYSOUT=*
//

(4) define the resources (program, maps, help, etc) into a group on your CICS, using either DFHCSDUP if you have access to it, or using CEDA to do it online

Whether you are using DFHCSDUP or CEDA (or just giving your CICS administrator a list of what needs to be done) the commands are the same:

DELETE TRANSACTION(KEBR) GROUP(KEBR)
DELETE PROGRAM(KEBRPGM) GROUP(KEBR)
DELETE PROGRAM(KEBRHELP) GROUP(KEBR)
DELETE MAPSET(KEBRM) GROUP(KEBR)
DELETE PROFILE(KEBRPROF) GROUP(KEBR)
REMOVE GROUP(KEBR) LIST(USERID)
ADD GROUP(KEBR) LIST(USERID)
DEFINE TRANSACTION(KEBR) GROUP(KEBR) PROGRAM(KEBRPGM)
TWASIZE(1) PROFILE(KEBRPROF)
DEFINE PROGRAM(KEBRPGM) GROUP(KEBR) LANGUAGE(COBOL)
DEFINE PROGRAM(KEBRHELP) GROUP(KEBR) LANGUAGE(ASSEMBLER)
DEFINE MAPSET(KEBRM) GROUP(KEBR)
DEFINE PROFILE(KEBRPROF) GROUP(KEBR) SCRNSIZE(ALTERNATE)
INSTALL GROUP(KEBR)

Note that KEBR doesn't actually use a TWA; it just looks at the twasize to see if you paid attention to these install instructions assuming that if you did you probably also added the profile with scrnsize(alternate). This is necessary so that KEBR's selection of an alternate screen size map will work. If it sees no twa it will assume there is no permission to use an alternate screen size and stick with 24x80.

(5) run KEBR in CICS just like in KICKS!


Copyright Mike Noel, 2014; last updated 11/21/2014 for KICKS 1.5.0