| KICKS |
A transaction processing system for CMS & TSO |
Every install environment is different, and there is no way to describe exactly what needs to be done to install any product in every environments. The following TSO install and CMS install sections are thus necessarily generic. However, since some environments are well known the following pre-install suggestions are provided. They apply to unmodified versions only (fresh standard installs of the subject operating system distribution).
These instructions are for use by a normal TSO user to perform an unassisted install of KICKS into his or her own TSO account. Instructions for systems programmers to install KICKS for general use are elsewhere.
KICKS has been successfully installed on Z/OS 1.4, 1.6, 1.10, and 1.12. I am not aware of any Z/OS system where it does not install and run.
1. KICKS is available from a number of sites, including the KICKS forum on Yahoo, so download a copy and review and accept the license...3. Prepare for install:kicks-tso-v1r5m0.xmi - an XMIT file you will upload to your system
If you aren't familiar with XMI files I recommend the NASPA reprint on the subject at http://www.lbdsoftware.com/Packaging_z/OS_Open_Source_Software_For_Distribution.pdf.
User's Guide - a folder containing this User's Guide.
Note - Although a copy of the User's Guide is included in the distribution package you should always use the online version (at www.kicksfortso.com/User's Guide) if possible as it is the most current. In particular, many installation problems can be resolved by reinstalling using the instructions in the online version!
kicks-license.txt - a text file of the license you agreed to when you downloaded the KICKS package.
readme.txt - a text file with this information, and telling you to go to the User's Guide Installation section to continue the install.
Review the environment specific instructions above for your TSO environment. It may also be useful to look at the instructions for 'similar' TSO environments.
KICKS requires a TSO region of at least 4 megs. It may start in smaller regions, but abends are likely as it opens more VSAM files and/or runs complicated applications.
KICKS can be installed using your TSO id, or your TSO prefix, or some fixed literal as a high level qualifier. The default is your TSO id. Regardless of your choice, the remainder of these install instructions will refer to that choice as USERID.
There are two kinds of KICKS files: 'system' and 'user'. The 'system' files are installed as USERID.KICKSSYS... and the 'user' files are installed as USERID.KICKS. So if your TSO id (or prefix, or literal) is "JACKSON" the 'system' files will be JACKSON.KICKSSYS and the 'user' files will be JACKSON.KICKS.
KICKS dataset names include a lower level qualifier of V1R5M0 so they will not conflict with dataset names for earlier KICKS installations.
Unless you change it, KICKS non-VSAM files will be allocated on non-specific storage volumes. If you want those files installed on specific volumes you will need to modify the installation code to specify those volumes (see step 7). This preparation step is to decide if non-specific is OK, and if not what volume(s) you want them on.
Unless you change it, KICKS VSAM files will be allocated on volume PUB002. Most shops won't have such a volume, or if they do you probably shouldn't allocate on it. You should change the idcams DEFINE's for these files to specify volumes appropriate to your shop, possibly non-specific, ie, VOLUME(*). See steps 10-14. This preparation step is to decide if you want to use non-specific allocation, or if not what volume(s) you want the files on.
You should have at least 2000 tracks of disk space available.
4. Upload the xmi file.
Use a binary file transfer (ftp? ind$file?) to upload kicks-TSO-v1r5m0.xmi to the system as USERID.KICKS.V1R5M0.XMI (or some other name you like, but these instructions will call it USERID.KICKS.V1R5M0.XMI). You should select recfm=fb, lrecl=80 for the uploaded file. Since kicks-TSO-V1R5M0.xmi is about 10 megs it may take several minutes to upload.
Some systems will require you to pre-allocate the upload file (or override the default space allocation for the upload). The clue is a B37 (etal) during the upload. If that happens pre-allocate USERID.KICKS.V1R5M0.XMI like this
dsn=userid.kicks.v1r5m0.xmi,unit=sysda,disp=(,catlg),
space=(trk,(225,15)),dcb=(recfm=fb,lrecl=80,blksize=3200)
Alternately, you could specify appropriate options to the file transfer program. For example, for ind$file you could add
space(225,15) tracks
5. 'Receive' the uploaded file.
Get to a TSO READY prompt.
Enter RECEIVE INDS(KICKS.V1R5M0.XMI)
You might need to press enter a few more times at TSO *** prompts...
6. Delete USERID.KICKS.V1R5M0.XMIT, it's no longer needed.
7. You will find you have a new pds USERID.KICKS.V1R5M0.BIGPDS, most of whose members also need to be received.
First member in the pds is $$V1R5M0 which is a REXX to do all the receives.
Run without any optional arguments it will restore the KICKS non-VSAM datasets to non specific volumes with a high level qualifier (HLQ) of your userid, ie
EXEC 'USERID.KICKS.V1R5M0.BIGPDS($$V1R5M0)'
The first optional argument is an HLQ to use instead of your userid, ie
EXEC 'USERID.KICKS.V1R5M0.BIGPDS($$V1R5M0)' 'otherHLQ'
The second optional argument is the volser to use for specific volume allocation.
EXEC 'USERID.KICKS.V1R5M0.BIGPDS($$V1R5M0)' '* volid'
Note the '*' in front of the volid above. That's a placeholder for a missing first optional argument. Of course both could be specified if desired, ie
EXEC 'USERID.KICKS.V1R5M0.BIGPDS($$V1R5M0)' 'otherHLQ volid'
Decide what you want to do, then
Get to a TSO READY prompt
Enter one of the above commands as you choose
You will need to press enter a few dozen times at TSO *** prompts...
8. Delete USERID.KICKS.V1R5M0.BIGPDS, it's no longer needed.
9. Customize KICKS for your USERID.
Get to a TSO READY prompt
Enter EXEC KICKSSYS.V1R5M0.CLIST(KFIX)
Responding as appropriate to the query regarding the userid/prefix/literal to be used for customization. If necessary edit the clist (ZFIX as called by KFIX) to obtain the desired customization and restart this step.
When the clist finishes successfully you should see a "Done" message above the next READY prompt.
10. Edit USERID.KICKS.V1R5M0.INSTLIB(LOADMUR), which is batch jcl
Change the jobcard as appropriate to conform to your shop standards and your own needs (do you want output be printed or held?).
If you want specific volumes global change PUB002 to whatever volume you want the VSAM files allocated on; if you want non-specific volumes, global change PUB002 to '*'.
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
11. Edit USERID.KICKS.V1R5M0.INSTLIB(LOADTAC), which is batch jcl
Change the jobcard as appropriate/
If you want specific volumes global change PUB002 to whatever volume you want the VSAM files allocated on; if you want non-specific volumes, global change PUB002 to *
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
12. Edit USERID.KICKS.V1R5M0.INSTLIB(LOADSDB), which is batch jcl
Change the jobcard as appropriate
If you want specific volumes global change PUB002 to whatever volume you want the VSAM files allocated on; if you want non-specific volumes, global change PUB002 to *
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
13. Edit USERID.KICKSSYS.V1R5M0.INSTLIB(LODINTRA), which is batch jcl
Change the jobcard as appropriate
If you want specific volumes global change PUB002 to whatever volume you want the VSAM files allocated on; if you want non-specific volumes, global change PUB002 to *
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
14. Edit USERID.KICKSSYS.V1R5M0.INSTLIB(LODTEMP), which is batch jcl
Change the jobcard as appropriate
If you want specific volumes global change PUB002 to whatever volume you want the VSAM files allocated on; if you want non-specific volumes, global change PUB002 to *
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
15. Start KICKS
Get to a TSO READY prompt
Enter EXEC KICKSSYS.V1R5M0.CLIST(KICKS)
You will need to press enter at the TSO *** prompt, then you'll see
Your colors may vary they are randomly selected each time the program runs - press enter to change them. Press clear to begin normal use. BTW, if you want to see this screen later just clear the screen and type KSGM (the KICKS good morning message transaction) and press enter. Do that now then press clear again.
On the resulting blank screen type KSSF (the KICKS signoff transaction) and press enter to logoff KICKS. You should see
then TSO ready prompt.
16. (Optional) Make it easier to start KICKS
It would be nice if it were easier to start KICKS than typing EXEC KICKSSYS.V1R5M0.CLIST(KICKS) every time.
If, as is common, you have a user modifiable ISPF panel library available you can add the command as a menu selection, thus allowing you to run KICKS by simply selecting that menu item.
Alternately there are a couple of ways to make the command you have to type shorter (ie, just 'KICKS'):
This completes basic KICKS installation.
17. Optional post-installation steps:
In addition to COBOL programming, KICKS supports application development using the free GCCMVS C compiler and libraries. You may want to download and install those next if you haven't already done so. Find them at http://gccMVS.sourceforge.net/. KICKS is tested with the "GCC 3.2.3 MVS 8.5" version.
The above install enables the KSGM dynamic color logon screen. As a result the TSO user will not be TI swapped when that screen is up, which may be undesirable on a very busy system. To revert to the static version of the screen modify the 4th line of USERID.KICKSSYS.V1R5M0.CLIST(KICKS) from this
NATLANG() PLTPI() PLTSD() PCT() PPT() FCT() DCT() +
to this
NATLANG() PLTPI(CSGM) PLTSD() PCT() PPT() FCT() DCT() +Further testing of the procs, preprocessors, and compilers is recommended, and the easiest way to do this is to run the API test/demonstration jobs in USERID.KICKSSYS.V1R5M0.TESTCOB (for COBOL) and USERID.KICKSSYS.V1R5M0.TESTGCC (for GCCMVS C).
After that (and after trying the precompiled versions!) , recompile the online example maps by submitting USERID.KICKS.V1R5M0.MAPSRC($TACMAPS) and USERID.KICKS.V1R5M0.MAPSRC($MURMAPS), then recompile the online example programs by submitting USERID.KICKS.V1R5M0.CB2($TACPGMS) and USERID.KICKS.V1R5M0.CB2($MURPGMS). Finally verify that the online examples work like the precompiled ones.
These instructions are for use by a normal TSO user to perform an unassisted install of KICKS into his or her own TSO account. Instructions for systems programmers to install KICKS for general use are elsewhere.
KICKS has been successfully installed on every MVS38J distribution I know of. I am not aware of any where it does not install and run. I use the MVS38J "MVS380" distribution to build and test KICKS , and that plus "TK3UPD" and "TK4-" are the supported MVS38J distributions. KICKS can probably be installed on other (older) MVS38J distributions but doing so may require deviation from these instructions.
1. KICKS is available from a number of sites, including the KICKS forum on Yahoo, so download a copy and review and accept the license...3. Prepare for install:kicks-tso-v1r5m0.xmi - an XMIT file you will upload to your system
If you aren't familiar with XMI files I recommend the NASPA reprint on the subject at http://www.lbdsoftware.com/Packaging_z/OS_Open_Source_Software_For_Distribution.pdf.
User's Guide - a folder containing this User's Guide.
Note - Although a copy of the User's Guide is included in the distribution package you should always use the online version (at www.kicksfortso.com/User's Guide) if possible as it is the most current. In particular, many installation problems can be resolved by reinstalling using the instructions in the online version!
kicks-license.txt - a text file of the license you agreed to when you downloaded the KICKS package.
readme.txt - a text file with this information, and telling you to go to the User's Guide Installation section to continue the install.
Review the environment specific instructions above for your TSO environment. It may also be useful to look at the instructions for 'similar' TSO environments.
KICKS requires a TSO region of at least 4 megs. It may start in smaller regions, but abends are likely as it opens more VSAM files and/or runs complicated applications.
KICKS can be installed using your TSO id, or your TSO prefix, or some fixed literal as a high level qualifier. The default is your TSO id. Regardless of your choice, the remainder of these install instructions will refer to that choice as USERID.
There are two kinds of KICKS files: 'system' and 'user'. The 'system' files are installed as USERID.KICKSSYS... and the 'user' files are installed as USERID.KICKS. So if your TSO id (or prefix, or literal) is "JACKSON" the 'system' files will be JACKSON.KICKSSYS and the 'user' files will be JACKSON.KICKS.
KICKS dataset names include a lower level qualifier of V1R5M0 so they will not conflict with dataset names for earlier KICKS installations.
Unless you change it, KICKS non-VSAM files will be allocated on non-specific storage volumes. If you want those files installed on specific volumes you will need to modify the installation code to specify those volumes (see step 7). This preparation step is to decide if non-specific is OK, and if not what volume(s) you want them on.
KICKS vsam files will be allocated on volume PUB002, which should be available (and owned by the TSO user catalog) on any TK3 based system. If you want those files installed on some other volumes you will need to modify the delete/define/load jcl (see steps 6d and 6e).
You should have at least 2000 tracks of disk space available.
4. Upload the xmi file.
ind$file binary uploads are unreliable on Tur(n)key MVS systems.
Since Tur(n)key systems are running under Hercules you can simply input the xmi file through a defined card reader. For example on the "TK4-" distribution you can copy the xmi file to the JCL folder, then issue a
devinit 10C jcl/kicks-TSO-v1r5m0.xmi ebcdic
hercules command, then edit and submit the following "GETXMI" job to load the file
//GETXMI JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
//SCRATCH EXEC PGM=IEFBR14
//* UPDATE THE HLQ IN THE FOLLOWING CARD BEFORE RUNNING <<<<<<<<<<
//SYSUT2 DD DSN=userid.KICKS.V1R5M0.XMI,DISP=(MOD,DELETE),
// UNIT=SYSDA,SPACE=(TRK,(0))
//LOAD EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY,DCB=BLKSIZE=80
//SYSUT1 DD UNIT=10C,DISP=OLD,DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)
//* UPDATE THE HLQ IN THE FOLLOWING CARD BEFORE RUNNING <<<<<<<<<<
//SYSUT2 DD DSN=userid.KICKS.V1R5M0.XMI,DISP=(,CATLG),
// DCB=(DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=3200),
// UNIT=SYSDA,VOL=SER=PUB002,SPACE=(TRK,(225,15),RLSE)Note this job takes longer than you might think - 15-20 seconds is normal...
Check that all condition codes in the JES log are zero.
5. 'Receive' the uploaded file.
Tur(n)key MVS systems do not have a RECEIVE command in TSO, so you will need to edit and submit the following "RCVKICKS" batch job.
//RCVKICKS JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),REGION=4096K
//RECV370 EXEC PGM=RECV370
//RECVLOG DD SYSOUT=*
//* UPDATE THE HLQ IN THE FOLLOWING CARD BEFORE RUNNING <<<<<<<<<<
//XMITIN DD DSN=userid.KICKS.V1R5M0.XMI,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=&&SYSUT1,
// UNIT=SYSDA,
// SPACE=(TRK,(300,60)),
// DISP=(NEW,DELETE,DELETE)
//* UPDATE THE HLQ IN THE FOLLOWING CARD BEFORE RUNNING <<<<<<<<<<
//SYSUT2 DD DSN=userid.KICKS.V1R5M0.BIGPDS,
// UNIT=(SYSDA,SEP=SYSUT1),
// SPACE=(TRK,(300,60,20)),
// DISP=(NEW,CATLG,DELETE)
//SYSIN DD DUMMYBe sure to cut/paste a fresh copy from here, and make indicated updates before submitting.
Check that all condition codes in the JES log are zero.
6. Delete USERID.KICKS.V1R5M0.XMIT, it's no longer needed.
7. You will find you have a new pds USERID.KICKS.V1R5M0.BIGPDS, most of whose members also need to be received.
Last member in the pds is V1R5M0 which is batch jcl to do all the receives.
Make userid changes as indicated, and, if desired, specify the volume for the received files.
When you've finished any changes to the JCL, submit it.
Check that all condition codes in the JES log are zero.
8. Delete USERID.KICKS.V1R5M0.BIGPDS, it's no longer needed.
9. Customize KICKS for your USERID.
Get to a TSO READY prompt
Enter EXEC KICKSSYS.V1R5M0.CLIST(KFIX)
Responding as appropriate to the query regarding the userid/prefix/literal to be used for customization. If necessary edit the clist (TFIX as called by KFIX) to obtain the desired customization and restart this step.
When the clist finishes successfully you should see a "Done" message above the next READY prompt.
On some systems this step fails with a message
"DATA SET XXXXX NOT ALLOCATED, TOO MANY DATA SETS+"
This occurs because TSO has not set aside enough control block space to dynamically allocated all the datasets that the clist needs. To fix this you must update your TSO logon proc, SYS1.PROCLIB(xxxxx) where xxxxx can be determined by looking for "TSO-proc" in the upper right corner of the RPF main menu. Edit the proc and observe the 2nd line, which should look like
//IKJACCNT EXEC PGM=IKJEFT01, ...
add DYNAMNBR=64 to the end of that line (or if DYNAMNBR is already present with a value less than 64 increase the number to 64), then save the change.
Then logoff your TSO session, and log back on again. This is necessary to pick up the logon proc change you just made.
Finally, resume the KICKS install at step 9 above.
10. Edit USERID.KICKS.V1R5M0.INSTLIB(LOADMUR), which is batch jcl
Change the jobcard as appropriate to conform to your shop standards and your own needs (do you want output be printed or held?).
If necessary global change PUB002 to whatever volume you want the VSAM files allocated upon.
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
11. Edit USERID.KICKS.V1R5M0.INSTLIB(LOADTAC), which is batch jcl
Change the jobcard as appropriate/
If necessary global change PUB002 to whatever volume you want the VSAM files allocated upon.
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
12. Edit USERID.KICKS.V1R5M0.INSTLIB(LOADSDB), which is batch jcl
Change the jobcard as appropriate
If necessary global change PUB002 to whatever volume you want the VSAM files allocated upon.
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
13. Edit USERID.KICKSSYS.V1R5M0.INSTLIB(LODINTRA), which is batch jcl
Change the jobcard as appropriate
If necessary global change PUB002 to whatever volume you want the VSAM files allocated upon.
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
14. Edit USERID.KICKSSYS.V1R5M0.INSTLIB(LODTEMP), which is batch jcl
Change the jobcard as appropriate
If necessary global change PUB002 to whatever volume you want the VSAM files allocated upon.
Submit the job and make sure it runs ok. All condition codes in the JES log should be zero.
15. Start KICKS
Get to a TSO READY prompt
Enter EXEC KICKSSYS.V1R5M0.CLIST(KICKS)
You will need to press enter at the TSO *** prompt, then you'll see
Your colors may vary they are randomly selected each time the program runs - press enter to change them. Press clear to begin normal use. BTW, if you want to see this screen later just clear the screen and type KSGM (the KICKS good morning message transaction) and press enter. Do that now then press clear again.
On the resulting blank screen type KSSF (the KICKS signoff transaction) and press enter to logoff KICKS. You should see
then TSO ready prompt.
16. (Optional) Make it easier to start KICKS
It would be nice if it were easier to start KICKS than typing EXEC KICKSSYS.V1R5M0.CLIST(KICKS) every time.
There are a couple of ways to make the command you have to type shorter (ie, just 'KICKS'):
This completes basic KICKS installation.
17. Optional post-installation steps:
In addition to COBOL programming, KICKS supports application development using the free GCCMVS C compiler and libraries. You may want to download and install those next if you haven't already done so. Find them at http://gccMVS.sourceforge.net/. KICKS is tested with the "GCC 3.2.3 MVS 8.5" version. Note this is preinstalled on many Tur(n)key systems including "TK4-".
However, on a "TK4-" system the install does not correspond to the GCC compile procs I include with KICKS. You will need to modify the procs (KIKGCCCL & KIKGCCCS) to comment out the GCCPREF proc argument, the COMP.STEPLIB, and to change the PDPPREF proc argument to remove the ".V85".
The above install enables the KSGM dynamic color logon screen. As a result the TSO user will not be TI swapped when that screen is up, which may be undesirable on a very busy system. To revert to the static version of the screen modify the 4th line of USERID.KICKSSYS.V1R5M0.CLIST(KICKS) from this
NATLANG() PLTPI() PLTSD() PCT() PPT() FCT() DCT() +
to this
NATLANG() PLTPI(CSGM) PLTSD() PCT() PPT() FCT() DCT() +
Further testing of the procs, preprocessors, and compilers is recommended, and the easiest way to do this is to run the API test/demonstration jobs in USERID.KICKSSYS.V1R5M0.TESTCOB (for COBOL) and USERID.KICKSSYS.V1R5M0.TESTGCC (for GCCMVS C).
After that (and after trying the precompiled versions!) , recompile the online example maps by submitting USERID.KICKS.V1R5M0.MAPSRC($TACMAPS) and USERID.KICKS.V1R5M0.MAPSRC($MURMAPS), then recompile the online example programs by submitting USERID.KICKS.V1R5M0.COB($TACPGMS) and USERID.KICKS.V1R5M0.COB($MURPGMS). Finally verify that the online examples work like the precompiled ones.KICKS is installed with a terminal driver (2$) that should work with any version of Tur(n)key MVS. It also includes the higher function Z/OS terminal driver (1$) that will work if you have a 'recent' Tur(n)key version (such as "TK4-"). You can try this driver by starting KICKS with "KICKS TCP(1$)". If this works you could change the KICKS clist to use 1$ instead of 2$ (end of line 5).
These instructions are for use by a normal CMS user to perform an unassisted install of KICKS into his or her own CMS account. Instructions for systems programmers to install KICKS for general use are elsewhere.
However, full function will require
(1) that DOS and VSAM is installed and available on the system, and
(2) that an empty (or emptiable) mini-disk is available to DOS format for vsam use.
If these requirements are not met vsam files can't be used, so although KICKS can be installed it may be of limited use and many of the example programs won't run.
1. KICKS is available from a number of sites, including the KICKS forum on Yahoo, so download a copy and review and accept the license...3. Prepare for install:kicks-cms-v1r5m0.vmarc - a VMARC file that you will upload to your system
User's Guide - a folder containing this User's Guide.
Note - Although a copy of the User's Guide is included in the distribution package you should always use the online version (at www.kicksfortso.com/User's Guide) if possible as it is the most current. In particular, many installation problems can be resolved by reinstalling using the instructions in the online version!
kicks-license.txt - a text file of the license you agreed to when you downloaded the KICKS package.
readme.txt - a text file with this information, and telling you to go to the User's Guide Installation section to continue the install.
KICKS is packaged using the VMARC utility. If that isn't already installed on your system it can be downloaded from the IBM Downloads site and installed in your own CMS for your own use with KICKS (and anything else you choose).
All KICKS permanent non-vsam files will be installed onto your 'A' mini-disk.
A DOS formated mini-disk is required for vsam use.
4. Upload the installation package.
Use a binary file transfer (ftp? ind$file?) to upload kicks-cms-v1r5m0.vmarc to the z/VM system as KICKS VMARC A Specify LRECL 80. It may take several minutes to upload.
5. Do a 'VMARC UNPACK' to get 1st level of KICKS files.
| vmarc unpack kicks vmarc a = = a (olddate replace notrace |
5. Build the VSAM environment on an empty mini-disk. This is in three steps. Define the DOS environment to KICKS by updating and assembling the FCT (file control table); then run the PREVSAM EXEC to dos format the vsam mini-disk; and finally run the POSTVSAM EXEC to define the vsam catalog and space, and to define and load the sample files.
Edit KIKFCT1$ ASSEMBLE K and change the CATXXXX arguments in lines 3-5 per the instructions in the configuration section of this guide. Especially note/change
CATUSER, the CMS userid of the 'owner' of the mini-disk (probably your own id),
CATLNK1, the disk address by which the mini-disk is defined in the system directory,
CATPASS, the write password for the mini-disk.
The other arguments (CATLNK2, CATFM, CATVOL) are probably OK as they are...
You will also need to re-assemble the FCT, which you do by entering the following command
| kiktable fct 1$ |
Next start the PREVSAM EXEC and proceed as directed..
| prevsam
DEV xxx DOES NOT EXIST About to erase and DOS format your xxx mini disk! Please type YES now to confirm this action.. YES DASD 0xxx DETACHED Filemode O not accessed Device 0222 does not exist Device 0xxx does not exist 222 replaces O (222) ICKDSF - CMS/XA/ESA DEVICE SUPPORT FACILITIES 17.0 INIT UNIT(222) - PRG NVFY VOLID(VSAMIN) - FBAVTOC(END) ICK00700I DEVICE INFORMATION FOR 0222 IS CURRENTLY AS FOLLOWS: PHYSICAL DEVICE = 3370-2 STORAGE CONTROLLER = 3880 STORAGE CONTROL DESCRIPTOR = 01 DEVICE DESCRIPTOR = 04 ICK01731I MAP FUNCTION NOT SUPPORTED FOR MINI-DISKS ICK00001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 After 'I CMS' press ENTER you type enter here... |
| postvsam |
| NOTE you will need to press enter several times (at the end of a screen full of messages) until you finally get to a 'Ready;'.. |
6. Startup KICKS to test your install
Type KICKS and press enter as below
kicks <{>}:EXEC TEST FOR MECAFF KICKS version 1.5.0(0) startup using SIT=1$, which with command line and stdin overrides results in... loading KIKSIT1$ - 80 bytes at D0398, ep D0398 loading KIKPCP1$ - 59912 bytes at D03E8, ep D09E8 loading KIKKCP1$ - 23816 bytes at DEDF0, ep DF6E8 loading KIKFCP1$ - 42168 bytes at E4AF8, ep E4CC4 loading KIKDCP1$ - 34944 bytes at EEFB0, ep EF194 loading KIKBMS1$ - 17192 bytes at F7830, ep F7DD0 loading KIKTCP2$ - 61320 bytes at FBB58, ep 1009B0 loading KIKSCP1$ - 4416 bytes at 10AAE0, ep 10AB68 loading KIKTSP1$ - 15192 bytes at 10BC20, ep 10BCB0 loading KIKPPT1$ - 4080 bytes at 10F778, ep 10F778 loading KIKPCT1$ - 1464 bytes at 110768, ep 110768 loading KIKFCT1$ - 9512 bytes at 110D20, ep 110D20 loading KIKDCT1$ - 256 bytes at 113248, ep 113248 OPID=999, DMPCLASS=A, ICVR=5000, ENQSCOP=SYSTEMS, CWAL=100 TRCFLAGS=1, TCTUAL=100, TRCNUM=100, PLTPI=KSGM, PLTSD=K999 NATLANG=E, MAXDELY=180, FFREEKB=NO RUNNING |
Briefly the above shows KICKS loading its nucleus modules and tables and displaying the other startup variables.
When 'MORE...' appears press enter (maybe more than once). Next you will see
KSGM for CMS user CMSUSER at terminal 00C0 15:19:41 07/31/14 KK KK IIIIIIIIII CCCCCCCCCC KK KK SSSSSSSSSS KK KK IIIIIIIIII CCCCCCCCCCCC KK KK SSSSSSSSSSSS KK KK II CC CC KK KK SS SS KK KK II CC KK KK SS KK KK II CC KK KK SSS KKKKKKK II CC KKKKKKK SSSSSSSSS KKKKKKK II CC KKKKKKK SSSSSSSSS KK KK II CC KK KK SSS KK KK II CC KK KK SS KK KK II CC CC KK KK SS SS KK KK IIIIIIIIII CCCCCCCCCCCC KK KK SSSSSSSSSSSS KK KK IIIIIIIIII CCCCCCCCCCC KK KK SSSSSSSSSS TM For CMS V1R5M0 September 2014 Press PF1 for help, CLEAR to continue... © Mike Noel |
Your colors may vary they are randomly selected each time the program starts up, and every 5-6 seconds thereafter.. Press clear to begin normal use. BTW, if you want to see this screen later just clear the screen and type KSGM (the KICKS good morning message transaction) and press enter. Do that now then press clear again.
On the resulting blank screen type KSSF (the KICKS signoff transaction) and press enter to logoff KICKS. You should see
KICKS is shutting down... |
then the CMS ready prompt.
This completes basic KICKS installation for a z/VM system.
7. Optional post-installation steps for a 6-pack system:
| kiktable pct 1$ |
In addition to Cobol programming, KICKS supports application development using the GCCCMS C compiler and libraries.You may want to download and install those next if you haven't already done so. Find them at http://gccmvs.sourceforge.net/
Uninstalling KICKS.
There is a KGONE EXEC that will delete all (at least most) of the KICKS distribution files from the A mini-disk (type KGONE A).
These instructions are for use by a normal CMS user to perform an unassisted install of KICKS into his or her own CMS account. Instructions for systems programmers to install KICKS for general use are elsewhere.
1. KICKS is available from a number of sites, including the KICKS forum on Yahoo, so download a copy and review and accept the license...3. Prepare for install:kicks-cms-v1r5m0.vmarc - a VMARC file that you will upload to your system
User's Guide - a folder containing this User's Guide.
Note - Although a copy of the User's Guide is included in the distribution package you should always use the online version (at www.kicksfortso.com/User's Guide) if possible as it is the most current. In particular, many installation problems can be resolved by reinstalling using the instructions in the online version!
kicks-license.txt - a text file of the license you agreed to when you downloaded the KICKS package.
readme.txt - a text file with this information, and telling you to go to the User's Guide Installation section to continue the install.
The VM/370 6-pack 1.2 system may be downloaded from http://vm370.31bits.net/vm370sixpack-1_2.zip
The X'58' full screen support package may be downloaded from the Yahoo H390-VM forum 'FILES' area (most current as of this writing is called 'diag58v108.zip'). This may not be absolutely necessary if you install the optional MECAFF console support, but these instructions assume you do have X'58' support installed.
The MECAFF tools package may be downloaded from the Yahoo H390-VM forum 'FILES' area (most current as of this writing is called 'mecaff-tools-and-console-1.2.5.zip'). Be sure you install the 'static linked' version of the MECAFF tools. This is necessary because KICKS uses the DOS/VSAM components of VM/370, whose use will cause the 'dynamically linked' versions of the MECAFF tools to abend (and require you to re-IPL CMS all the time, very irritating...
The CMSUSER account on the VM/370 6-pack has empty 192, 193, 194, and 195 mini-disks. The KICKS install will modify CMSUSER's PROFILE EXEC to release/detach the 194 mini-disk, and to access the 195 mini-disk as 'K'.
All KICKS permanent non-vsam files will be installed onto the 195 mini-disk that will be accessed as 'K'.
The 194 mini-disk will be DOS formatted. A vsam master catalog and vsam space will be allocated on it, and the KICKS sample vsam files will be defined and loaded into that vsam space. The 194 mini-disk will otherwise remain unlinked so that not just CMSUSER, but any KICKS user can access the vsam files. KICKS or associated programs, run by any user, will access this 194 mini-disk as 'O'.
Ensure you are not using CMSUSER's 194 or 195 mini-disks before you start the KICKS install!!
4. Unload installation package from tape.
Edit SIXPACK DIRECT to change CMSUSER's default storage size down to 14M
(so that there is room for the
DOS/VSAM segment)
change 'USER CMSUSER CMSUSER
15M 16M G'
to 'USER
CMSUSER CMSUSER 14M 16M G'
then after you save that change,
|
direct sixpack DMKUDR476I System Directory loaded from volume VM50-1 EOJ DIRECTORY UPDATED AND ON LINE |
|
l * * f l * * g |
| if there's anything you want on either
of those mini-disks (including old KICKS installs if you want to be
able to go back to them) and back it up, 'cause this procedure will erase it!!! |
Edit PROFILE EXEC
add 'REL F (DET' after 'ACC 194 F',
and
add 'ACC 195 K' after 'ACC 195 G'
Logoff CMSUSER
Log back onto CMSUSER
Check to ensure 194 is not linked at all, and that 195 is accessed as K (not G)
| q disk |
Format the 195 k disk to get rid of anything that's already on it.
| format 195 k
DMSFOR603R FORMAT WILL ERASE |
Do a 'VMARC UNPACK' to get 1st level of KICKS files.
| vmarc unpack kicks vmarc k = = k (olddate replace notrace |
5. Build the VSAM environment on the 194 mini-disk. This is in three steps. Define the DOS environment to KICKS by updating and assembling the FCT (file control table); then run the PREVSAM EXEC to dos format the vsam mini-disk; and finally run the POSTVSAM EXEC to define the vsam catalog and space, and to define and load the sample files.
Edit KIKFCT1$ ASSEMBLE K and, if necessary, change the CATXXXX arguments in lines 3-5 per the instructions in the configuration section of this guide. This will probably be unnecessary since KICKS comes with these arguments pre-configured for the VM/370 6 pack system. If you change nothing just quit out of the editor. If you do change something you will also need to re-assemble the FCT, which you do by entering the following command
| kiktable fct 1$ |
Next start the PREVSAM EXEC and proceed as directed. When it's done you will need to re-ipl CMS as shown..
| prevsam
DEV 194 DOES NOT EXIST About to erase and DOS format your 194 mini disk! Please type YES now to confirm this action.. YES DASD 194 DETACHED DISK 'O' NOT ACCESSED. DEV 222 DOES NOT EXIST O (222) R/W - DOS New file: EDIT: NO FILES PURGED PUN FILE 0782 TO CMSUSER COPY 01 NOHOLD PUN FILE 0783 TO CMSUSER COPY 01 NOHOLD IBCDASDI has been IPLed to format the vsam disk. - Press ENTER to see the 'DEFINE INPUT' request - then type 'INPUT=2540,00C' and press ENTER When done (almost immediately), type 'I CMS' and press ENTER, - then ENTER again to finish the IPL, Finally type POSTVSAM and press ENTER you type enter here... IBC105A DEFINE INPUT DEVICE. DASDI 7.91 input=2540,00c DASDI 7.91 JOB 'DOS INIT 194 AS VSAMIN' MSG TODEV=1052,TOADDR=009 DADEF TODEV=3350,TOADDR=222,IPL=NO,VOLID=SCRATCH,CYLNO=0115 VLD NEWVOLID=VSAMIN,OWNERID=CMSUSER VTOCD STRTADR=1,EXTENT=15 END IBC163A END OF JOB. CP ENTERED; DISABLED WAIT PSW '00060000 0000EEEE' i cms |
| postvsam |
| NOTE you will need to press enter several times (at the end of a screen full of messages) until you finally get to a 'Ready;'.. |
6. Startup KICKS to test your install
Type KICKS and press enter as below
kicks <{>}:EXEC TEST FOR MECAFF KICKS version 1.5.0(0) startup using SIT=1$, which with command line and stdin overrides results in... loading KIKSIT1$ - 80 bytes at D0398, ep D0398 loading KIKPCP1$ - 59912 bytes at D03E8, ep D09E8 loading KIKKCP1$ - 23816 bytes at DEDF0, ep DF6E8 loading KIKFCP1$ - 42168 bytes at E4AF8, ep E4CC4 loading KIKDCP1$ - 34944 bytes at EEFB0, ep EF194 loading KIKBMS1$ - 17192 bytes at F7830, ep F7DD0 loading KIKTCP2$ - 61320 bytes at FBB58, ep 1009B0 loading KIKSCP1$ - 4416 bytes at 10AAE0, ep 10AB68 loading KIKTSP1$ - 15192 bytes at 10BC20, ep 10BCB0 loading KIKPPT1$ - 4080 bytes at 10F778, ep 10F778 loading KIKPCT1$ - 1464 bytes at 110768, ep 110768 loading KIKFCT1$ - 9512 bytes at 110D20, ep 110D20 loading KIKDCT1$ - 256 bytes at 113248, ep 113248 OPID=999, DMPCLASS=A, ICVR=5000, ENQSCOP=SYSTEMS, CWAL=100 TRCFLAGS=1, TCTUAL=100, TRCNUM=100, PLTPI=KSGM, PLTSD=K999 NATLANG=E, MAXDELY=180, FFREEKB=NO RUNNING |
Briefly the above shows KICKS loading its nucleus modules and tables and displaying the other startup variables.
When 'MORE...' appears press enter (maybe more than once). Next you will see
KSGM for CMS user CMSUSER at terminal 00C0 15:19:41 07/31/14 KK KK IIIIIIIIII CCCCCCCCCC KK KK SSSSSSSSSS KK KK IIIIIIIIII CCCCCCCCCCCC KK KK SSSSSSSSSSSS KK KK II CC CC KK KK SS SS KK KK II CC KK KK SS KK KK II CC KK KK SSS KKKKKKK II CC KKKKKKK SSSSSSSSS KKKKKKK II CC KKKKKKK SSSSSSSSS KK KK II CC KK KK SSS KK KK II CC KK KK SS KK KK II CC CC KK KK SS SS KK KK IIIIIIIIII CCCCCCCCCCCC KK KK SSSSSSSSSSSS KK KK IIIIIIIIII CCCCCCCCCCC KK KK SSSSSSSSSS TM For CMS V1R5M0 September 2014 Press PF1 for help, CLEAR to continue... © Mike Noel |
Your colors may vary they are randomly selected each time the program starts up, and every 5-6 seconds thereafter.. Press clear to begin normal use. BTW, if you want to see this screen later just clear the screen and type KSGM (the KICKS good morning message transaction) and press enter. Do that now then press clear again.
On the resulting blank screen type KSSF (the KICKS signoff transaction) and press enter to logoff KICKS. You should see
KICKS is shutting down... |
then the CMS ready prompt.
This completes basic KICKS installation for a VM/370 6-pack system.
7. Optional post-installation steps for a 6-pack system:
| kiktable pct 1$ |
If you want to be able to run
KICKS under CMSBATCH you will need to add the REALTIMER option to
that VM's directory entry (CMSBATCH won't allow a a submitted job to do a
'SET' to change that option). Logon to MAINT again and Edit SIXPACK DIRECT
again
add
'OPTION REALTIMER'
after the line 'USER
CMSBATCH CMSBATCH 8M 8M G'
then after you save that change,
|
direct sixpack DMKUDR476I System Directory loaded from volume VM50-1 EOJ DIRECTORY UPDATED AND ON LINE |
|
link cmsuser 195
111
acc 111 k rel y acc 19e y copy pdpclib txtlib k = = y (replace rel y acc 19e y/s rel k (det |
Uninstalling KICKS.
KICKS can be uninstalled simply by re CMS formatting the 194 (KICKS code) and 195 (dos vsam) mini-disks. You might also want to revert your PROFILE EXEC to access these mini-disks as F and G respectively.
There is also a KGONE EXEC that will delete all (at least most) of the KICKS distribution files from the K (ie, 194) mini-disk (type KGONE K). This may make it easier to find any of your own files you want to save before you reformat...
Installing KICKS for many users is much the same as installing it for one. The effort is not so much in the installation as in deciding exactly what to provision to users who need access to it. Following is the simplest case: KICKS will be installed in one place and all TSO/CMS users will have fully shared access to it. To accomplish that
For example, if you have a TK4- Tur(n)key MVS system you might have installed KICKS into the account HERC01. To turn that installation into a "system install" you would
DATASET HERC01.KICKS.MURACH.CUSTMAS UPDATE DATASET HERC01.KICKS.MURACH.INVCTL UPDATE DATASET HERC01.KICKS.MURACH.INVOICE UPDATE DATASET HERC01.KICKS.MURACH.INVOICE.PATH UPDATE DATASET HERC01.KICKS.MURACH.PRODUCT UPDATE DATASET HERC01.KICKS.TACDATA UPDATE DATASET HERC01.KICKS.V1R5M0.SDB UPDATE DATASET HERC01.KICKSSYS.V1R5M0.KIKINTRA UPDATE DATASET HERC01.KICKSSYS.V1R5M0.KIKTEMP UPDATE
At this point all TSO users can start KICKS, run the sample applications, and read or update the sample application files. The first time they run KICKS (that is, the KICKS clist) it will create empty user SKIKLOAD, KIKRPL COBCOPY, and GCCCOPY libraries that they may use to define and contain their own applications. They may however still require a private copy of the KICKS clist to allocate their own files (or customize the clist).
VSAM files for KICKS use in TSO are shared if their allocation in the KICKS clist specifies SHR. If that allocation instead specifies OLD the file is not shared..
If you are using a Z/OS system you would follow a very similar procedure.
If instead you have a "nicoff-playground" VM/370 six pack system you might have installed KICKS into the account CMSUSER. To turn that installation into a "system install" you would
At this point all CMS users can start KICKS, run the sample applications, and read or update the sample application files. The first time they run KICKS (that is, the KICKS exec) it will create empty user KIKULOD & KIKURPL txtlibs and KIKCOUSR & KIKGCUSR maclibs that they may use to define and contain their own applications. They may however still require private copies of the KICKS, KICKSD, TKICKS, and TKICKSD exec's to allocate their own files (or customize the exec's).
VSAM files for use of KICKS in CMS are either all shared (meaning only that other KICKS users will access them) or unshared (meaning only that other KICKS users will not access them). If VSAM files are to be shared
If you are using a Z/VM system you might follow a similar procedure (but don't ignore the security rules!).
KICKS users are expected to possess skill sets roughly corresponding to skill sets for similar roles in a CICS environment.Terminal users need to know how to logon, start and use the applications they are assigned, and logoff.
Those who write and maintain those applications will require additional skills, similar to those of a CICS application programmer, familiar with TSO or CMS tools and techniques necessary to write COBOL/VSAM/CICS programs. KICKS installation is oriented to people with this skill set.
Those who wish to make effective use of the KICKS source will require additional skills, similar to those of a CICS systems programmer, familiar with 360/370/z assembler programming and CICS internals. Additionally, since KICKS is written in C, substantial experience with that language is required. KICKS source installation and use is oriented to people with all these skills.
KICKS for TSO and KICKS for CMS are intended for use across a broad spectrum of systems - from old MVS38J and VM/370 systems to the most current Z/OS and Z/VM systems. I expect the source can be built on any combination of the above, however I only support a single specific combination. Since that combination is freely available software that can build KICKS for any of the broader set of systems I do not consider this to be a significant limitation.By "support" I mean I've built KICKS in the environment myself and it works, but that is not a guarantee I'll be able to help you in your own efforts to build KICKS or otherwise use the source. I expect people who try to do that to have a high level of skill and determination, and to solve most (if not all) their own problems.
For TSO use the "TK4-" (update 5) Tur(n)key MVS system.
For CMS use the same "TK4-" (update 5) system, plus the "nicof-0.6.0-playground" VM/370 system. There is only one source for both TSO and CMS. It 'lives' in TSO, and TSO is used to punch the build steps to the CMS reader (destined for CMSBATCH) to generate KICKS for CMS.
You first need to build a special "TK4-" (update 5) system that you will use to build KICKS for TSO, and as a necessary tool to build KICKS for CMS. You can get "TK4-" at http://wotho.ethz.ch/tk4-. After you have installed "TK4-" update 5 as per the instructions, you will need to install the following modifications:
*** NOTE *** Most of these changes require RAKF authority, so make them while logged on as HERC01.
1. Update sys1.proclib(TSOlogon) to change dynamnbr=20 on the end of line 2 to dynamnbr=64
After you save this change you will have to logoff TSO, then log back on again to activate the change.
Reason for the change: KICKS needs to be able to dynamically allocate more than 20 files
2. Run the following job to copy sys2.linklib gcc member(s).//MAKGCC JOB // EXEC PGM=IEBCOPY //SYSPRINT DD SYSOUT=* //OUT DD DSN=GCC.LINKLIB,DISP=(NEW,CATLG),UNIT=SYSDA, // SPACE=(CYL,(1,1,10)),DCB=(RECFM=U,BLKSIZE=6144) //IN DD DSN=SYS2.LINKLIB,DISP=SHR //SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(1)) //SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(1)) //SYSIN DD * COPY INDD=IN,OUTDD=OUT SELECT MEMBER=((GCC,GCC370)) /*Reason for the change: Simplify KICKS installation by standardizing gcc install. KICKS compile procs refer to the 24 bit gcc compiler explicitly to emphasis the ability to run KICKS in "pure" 24 bit environments. Since those procs also assume the need for a steplib to access the compiler this change allows the procs to be installation modified similarly to typical Z/OS installs.
3. Update sys1.jes2parm(jes2parm) to change initiator 1 from class A only to class C and class A by changing line 160 to add a 'C' to the end, like thisI1 START,NAME=1,CLASS=ACReason for the change: KICKS needs to single thread jobs in it's build process so that those jobs will run in the correct order and it uses class C assuming it is so defined.
3b. Update sys1.jes2parm(jes2parm) to add&C NOJOURN,LOG,OUTPUT,PROCLIB=00,PERFORM=1, Single thread batch C CONVPARM=00000100099921E00011after lines 184-185 which should look like&B NOJOURN,LOG,OUTPUT,PROCLIB=00,PERFORM=1, Standard batch C CONVPARM=00000100099921E00011After you save these two changes (3 & 3b) you will need to ipl to activate them.
Reason for the change: The jes2parm default for undefined input classes requires that the JOB card contain accounting information and programmer id, but KICKS jcl does not contain those job card fields.
4. Update sys1.secure.cntl(profiles) to addDATASET * PRDGROUPALTERjust *before* line 22, which should look likeDATASET * STCGROUPALTERafter you save this change activate it by entering "S RAKFPROF" on the console. (or just ipl).
Reason for the change: KICKS submits jobs thru the internal reader, depending on any security system present to propagate user credentials. But RAKF does not do so, resulting in those jobs being assigned to the default user. This change allows the default user unrestricted dataset access.
5. (optional) Make job step return codes show up on the console:
issue operator command "vary 009,console,rout=all"
or
add "$VS,'V 009,CONSOLE,ROUT=ALL'" to jes2parms (& ipl)
or add a similar command to sys1.parmlib(startMVS) (& ipl)
Reason for the change: It can save time to quickly see a job ran OK without reviewing the listing.
6. (optional) Set the timezone for your location
change sys1.parmlib(parmtz) to match, for example, I use
W,09 for alaska standard time
W,08 for alaska daylight time
after you save this change you will need to ipl to activate it.
Reason for the change: I like to see the right date/time on messages and listings.
7. Copy MVS.BAT to MVS3725.BAT, then edit MVS3275.BAT adding 'SET CNSLPORT=3275' just in front of the last line.
Reason for the change: make the TK4- console port 3275 so that vm/370 can be up at the same time (with VM/370's console port staying at 3270). This enables use of VM/370 to generate KICKS for CMS.
8. Copy tk4-.cnf to tk4-.oldcnf (as a backup) then edit tk4-.cnf adding "CODEPAGE 819/1047" pretty much anywhere (suggest after line 13 "XPNDSIZE 0").
Reason for the change: match the code page used by VM/370 so that output generated on MVS can be used on VM/370 to build KICKS for CMS.
Once these modifications (at least 1-4, 7, 8) are in place you should install KICKS for TSO 1.5.0 into "userid" (recommend HERC01) using the normal install instructions.
Follow that by installing the KICKS source into the same "userid". This install is a microcosm of the normal KICKS install: you upload the source xmi file, receive it, then run a job inside the received pds to receive most of the other members into more pds's, and finally run a clist to customize the received pds's for the HLQ associated with the install. In other words, steps 4 thru 9 of the Tur(n)key TSO install near the top of this page. For the steps 4 thru 8 just substitute "userid.KICKSTS." for "userid.KICKS.V1R5M0.". For step 9 substitute "KICKSTS.UTIL(SFIX)" for "KICKSSYS.V1R5M0.CLIST(KFIX)".You will note that the KICKS source datasets do not include VRM. That's because they are used to define and create new versions!
At this point your build environment is complete unless you want to build for CMS as well as TSO (or instead of TSO).
If you want to build KICKS for CMS your next step is to build a special "nicof-0.6.0-playground" VM/370 system that you will use to build KICKS for CMS. You can get "nicof-0.6.0-playground" from the files area of the yahoo VM/370 group https://groups.yahoo.com/neo/groups/Hercules-VM370/info.
After you have installed the "nicof-0.6.0-playground" as per the instructions, you will need to install the following modifications:
1. KICKS for CMS optional install step 7b, configuring CMSbatch for KICKS use, is required for building KICKS for CMS from source. To reiterate those instructions:Reason for the change: Some of the KICKS for CMS source compiles run KICKS in batch.Logon to MAINT from a full screen capable 3270 session.
Edit SIXPACK DIRECT
add 'OPTION REALTIMER'
after the line 'USER CMSBATCH CMSBATCH 8M 8M G'
then after you save that change,
DIRECT SIXPACK
you should see messages
DMKUDR476I System Directory loaded from volume VM50-1
EOJ DIRECTORY UPDATED AND ON LINE
After these messages you will have shutdown/reboot to get CMSbatch running with timer support.
2. In addition to the required REALTIMER update to the CMSbatch directory entry (as above), that same entry must also be updated to increase its default memory allocation,Reason for the change: Some of the KICKS for CMS source compiles require more memory than the default CMSbatch 8M provides.Logon to MAINT from a full screen capable 3270 session.
Edit SIXPACK DIRECT
change 'USER CMSBATCH CMSBATCH 8M 8M G'
to 'USER CMSBATCH CMSBATCH 14M 16M G'
then after you save that change,
DIRECT SIXPACK
you should see messages
DMKUDR476I System Directory loaded from volume VM50-1
EOJ DIRECTORY UPDATED AND ON LINE
After these messages you will have shutdown/reboot to get CMSbatch running in a larger memory.
Once these modifications (1, 2) are in place you should install KICKS for CMS 1.5.0 into "userid" (recommend CMSUSER) using the normal install instructions.Then you need to obtain or create a couple a vmarc files that will be used by the build process.
GCCCMS VMARC is a more up-to-date version of the GCC compiler than is installed on the nicof playground system. The copy I made is available in the files area of the yahoo kicksfortso forum, but you really should build your own from file on the source forge repository.
MECAFAPI VMARC is a set of compiler and linker include files for the mecaf api used by the KICKS VM/370 terminal driver build. The copy I made is available in the files area of the yahoo kicksfortso forum, but you really should build your own from the files on the yahoo H390-VM forum.
These two vmarc files should be placed with the KICKS non-VSAM files (probably in the CMSUSER 195 disk).
A final customization detail for your build environment: edit the TSO dataset userid.KICKSTS.CMSBATCH(MAPN) to change lines 11-12 from
&USER = CMSUSER
&DISK = 195
to
&USER = userid the CMS userid for the kicks install
&DISK = ??? the address of the kicks non-VSAM mini diskIf you examine userid.KICKSTS.CMSBATCH you will see that the CMSbatch jobs are all routed as from CMSUSER. This isn't important; the MAPN exec provides all the necessary targeting.
At this point your build environment is complete, except for one little detail. How is punched output from MVS going to make its way to the CMS reader? There are at least three ways: (1) You could run MVS under VM and simply spool the MVS punch to CMSBATCH; or (2) You could send the MVS punch to a PC file, then move it (physically or logically) to the PC file the CMS reader is attached to; or (3) You could attach the MVS punch to a socket device, and arrange that socket device sends its output to another socket device attached to the CMS reader. The following instructions detail the third alternative.
Download xbar.pl to your pc from userid.KICKSTS.UTIL(XBAR). This is a perl script to cross connect the socket devices as described above. The procedure to use this script is:start the hercules "TK4-" instance.
issue the following thru the "TK4-" web interface (http://localhost:8038/):detach 10dstart the hercules "nicof-0.6.0-playground" instance
attach 10d 1403 127.0.0.1:4510 sockdev
issue the following thru the "nicof-0.6.0-playground" consoledevinit 00c 127.0.0.1:3510 sockdev ascii trunc eofstart the xbar.pl scriptin linux terminal get a shell windows
in windows get a cygwin window
in either, type "chmod +x xbar.pl"
then type "./xbar.pl &"
To build all of KICKS for TSO submit userid.KICKSTS.JCL(ADOALL). This set of jobs will take about 5 minutes. Review the output of about 20 jobs. There should be no failures. Review of these jobs is fairly simple: Obtain the print listing (prt/prt00e.txt for TK4-) and search for "JES2 JOB STATISTICS". Immediately following will be the job name and the step condition codes associated steps of the job. Check that these look reasonable, mark off that job on the adoall list, then search for the next set of job statistics. Note there are a few jobs that didn't come directly from adoall, but rather came indirectly from jobs that adoall submitted.
To build all of KICKS for CMS submit userid.KICKSTS.CMSBATCH(ADOALL). On the MVS side this will take about 15 seconds to ship all the necessary jobs to the CMS reader. On the CMS side these jobs will take about 5 minutes. Review the output of about 20 CMS jobs. There should be no failures. Review of these jobs is fairly simple: Obtain the print listing (io/print1.listing for the nicof playground) and search for "REPORT CARD". Immediately following will be the job name and the step condition codes associated steps of the job. Check that these look reasonable, mark off that job on the adoall list, then search for the next set of job statistics. Note there are a few jobs that didn't come directly from adoall, but rather came indirectly from jobs that adoall submitted.Both the TSO and CMS builds have an optional final step, which is running a set of tests. If you examine the adoall jobs you will see a '//' in front of the ADO12 steps. Remove these will allow those steps to run, submitting the tests. These result in another 15 or so jobs, and take an additional 10 minutes, mostly due to delays caused by exercising delay api calls!
As you no doubt noticed the ADOALL job (TSO or CMS) is just an ordered submission of a long sequence of jobs to build KICKS. Once you understand the dependences you can run the jobs individually, but exercise care in this: There is no "make" function ensuring that dependencies are observed; that is all up to you!