For Turnkey3 users, there is now a TK4- available

Another updated version of Tunkey3 called TK4- is floating about on the internet. The primary site seems to be http://wotho.ethz.ch/tk4-/. It is not the long awaited Turnkey4 but a version of Turnkey3 with a lot of connectivity enhancements implemented.

The doco says it is shipped as a full solution so users do not need to know anything about
MVS in order to obtain the extra SNA protocols.

And it is shipped as a full running system, unzip and go. For that reason if you have never gone through a Turnkey3 install which walks you through the steps to be taken to install a MVS3.8J system from scratch I would suggest you still install TK3 first just to see the steps involved, and to end up with a lot of very useful jcl decks; then use TK4-.

The main changes from TK3 seem to be

These highlights are based upon the documentation. I have not excercised any of them yet. Concentrating on making it look a bit more like my system for a hands off environment, or it would not be usefull to me.

• JES2 remote print available, providing SNA LU0 and LU2; the SNA connectivity seems to be the hightlights
• the supplied hercules binaries apparently have the tcpip interrupt enabled in them, but as the linux binaries do not run on a Fedora23 system (looks like thats because of a F23 packaging bug affecting shared libraries rather than an issue with the binaries [see end of post]) so I have no way of testing if the tcpip feature has actually been implemeted
• it has TCAM and TP running
• JRP printing to a 3270 is installed (see notes from running it below)
• the CTC devices are in the IOGEN
• it has a FTPD task, so presumably allows FTP (see notes from running it below)
• RFE (review) is installed (as seen in screen shot in manual) as well as RPF
• the CBT and MVSSRC volumes are optional, as MVSSRC volumes are needed for any serious coding they at least have to be added seperately

Changes observed from running it unmodified are

• minor issue it has a FTPD proc so presumable should provide ftp services, however every attempt to start the proc results in a SOC1 abend; it may work with the supplied binaries (which do not run on F23) but because the F23 repo hercules binary does not have the tcpip feature implemented I do not expect it to work anyway
• minor issueThe JRP printing to a 3270 doesn’t work. The appl can be logged onto OK and the function keys to set the device to accept printout all work as documented, but printing to the application gets IO errors. I am assuming the documentation for using it is wrong in this case. A minor issue as it is not really needed, just looks cool
• a major issue with the supplied linux startup script,
  • As supplied using the provided startup script results in SPY showing no console log output, MVS command responses go to the combined hercules/MVS console log, plus the SPY version in TK4- doesn’t seem to issue JES2 commands; actually neither does IMON so it is possible JES2 responses are not shown in the combined log
    My solution is simply to use my existing TK3 linux headless startup script (available on my website of course) instead of the supplied script(s), which allows console displays in both SPY and IMON correctly
• Catalogs: are not to my liking. The catalog SYS1.UCAT.MVS has the aliases for things like KLINGON and DUCHESS, going to have to do a lot of catalog cleanup, however
  the MVS alias has been moved to this user catalog from the master catalog so a lot of TK3 cleanup was obviously done before it got messy again… not that I am much better, my TK3 system has a seperate HLQ of GAMES and every game dataset is prefixed with that to keep things clean, likewise all compilers I installed are under SYS9.COMPILER where TK4- has them under unique prefixes like PL1 for example, making them hard to fine. But I have noticed I put my GAMES alias into my software source catalog instead of a meaningfull catalog myself so I am lazy as well :-)
• File placement: same blasted bad design as is TK3, key files (such as SYS1 and SYS2 prefixed files) are on PUBnnn volumes. Means I cannot copy acrosss my PUBnnn volumes but will have to JCL backup/restore jobs to move my files across
• big improvement: It must have a usefull apar/zap/usermod for syslog messages. If message logging to syslog is requested with a
  V SYSLOG,HARDCPY,STCMDS then the messages available to be viewed via Q for the syslog job are almost real-time; in TK3 messages were written to syslog a buffer-at-a-time so were normally quite a while behind; so this is a big improvement
• using the SHUTDOWN command implemented into TSO when not using daemon mode (but still using the supplied scripts for manual start) causes a machine check. That TSO clist needs to be removed.
• The default TSOAPPLS procedure used by the default TK4- TSO logon clists does something nasty I cannot figure out !. The error on the console is SYS9.CLIST is not available on dasd PUB0000. Yes SYS9.CLIST is one of my datasets added to the login proc not a supplied one but IDCAMS catalog listings clearly shows SYS9.CLIST is cataloged on SYS001 (and utils like RPF find it on SYS001 using dsname lookup). The error is below.

  IEC020I 001-1,SYSPROG,IKJACCNT,SYSPROC,270,PUB001,SYS9.CLIST
  

  It is something specific to that proc (and a tso listalc shows sys9.clist is allocated to tso ok from sys001, the tsoappls proc just cannot locate it). I changed the login proc for all my users not to use the tsoappls proc and they login just fine using sys9.clist; but from the ready prompt typing in TSOAPPLS gives the same error (other clsists, including those in sys9.clist work just fine). My solution is to discard that tsoappls proc for all users and just use my own

• full screen help doesn’t work properly. On TK3 from within “ACCOUNT” typing ‘help add’ shows the help for the add command for account. On TK4- the same command gives a blank help screen and I must manually type ‘ACCOUNT’ into the member field and ‘ADD’ into the subcommand field to get the help screen. While that may seem a minor inconvenience it is actually a major inconvenience for commands I seldom use… however from the TSO READY prompt ‘help account’ shows the help for account ok… that is an issue as while it may be considered just a pain to have to exit the utility to get help for it in actuality account has its own help that would be displayed if the full screen help program was not installed. The help intercept works in TK3 but not properly in TK4-. Not an issue for most users, but I can see myself finding it irritating
• it has the usermod to allow blank lines in assembler source files
• it has the usermod to make consoles start in roll-delete mode; my headless startup script issued the commands for that anyway but it’s a nice to have for most people
• big improvement: in TK3 replacing a program with a new version in a linklisted library required an IPL to pick up the changed program; must be a useful apar/zap/usermod in TK4- as the behaviour has changed, now any new copy is available immediately

The only thing that was really frustrating me in TK3 was trying to figure out how to iogen CTC adapters. As TK4- already has those iogen’ed in that is a good reason for me to keep it,
although I haven’t found time to play with the CTC adapters yet.

Changes I had to make to make it similar to my running TK3 environment

• DASD:
  • copies of all my personal DASD volumes have beeen taken and attached in the TK4- config file, a critical requirement as they have user catalogs I will need
  • created a new 3350 volser MDTSO1 and restored all my personal datasets onto that rather than on PUBnnn volumes; so with future TK4 updates I can just move that volume across to keep all my work
  • I need the MVSSRC and CBT files, have attached those dasd volumes
• Catalogs:
  • imported the MVSSRC and CBT catalogs
  • imported all my custom dataset catalogs
  • created a new TSO user catalog on the new MDTSO1 volume mentioned above, and added my user aliases to that so they will not be impacted by any tk4- refreshes I might download
• Datasets:
  • backup/restore all datasets owned by my custom prefixes/aliases/users from TK3 to the new TK4- system
  • update the SYS1.PARMLIB members for my customised LINKLIST, APFLIST, VATLIST etc
  • remember those old lineflow pictures everyone used to collect, copied those across. I may have the only copies left
  • I have recreated all the GDGs I use so my batch that needs them will run
• Usermods:
  • TK4- modified the TK3 ZUM0003 usermod for IEECVXIT with ZJW0006. I had to merge all the ZJW0006 changes with my changes and SMP them in as a SUP of that. Rollback (SMP restore) tested OK; but because of the way the usermods (and prerequsites) up until zjw0006 were just superceeding each other rollback must be to the base OS level, and all usermods needed to get back to the
    zjw0006 have to be reapplied… no biggee, fully tested and documented in my jobs
  • It gave me the chance to chance to change my SMP usermod to add additional console display commands from a full program replacement to a much cleaner ‘proper’ SMP job that just needs the few lines being changed, that implemented OK as well
• Applications:
  • Added my MDDIAG8 and made sure HERCCMD is not in the linklist; I prefer source so prefer my program where possible. Will have to see what breaks (actually I’m not sure if HERCCMD was in TK4- to start with)
  • As part of including my dasd volumes and importing their catalogs I have all my SYS9 datasets available. MMPF, TAPEMAN3 and TASKMON needed for my automation needs are running ok
  • as I have installed every compiler available over the years, I will have to decide whether to re-install or copy those libraries as well; after finding out what is missing, as they are under various different dataset prefixes as well in TK4-. As an interum as all my SYS9 datasets have been imported that includes all my SYS9.COMPILER datasets so I haven’t lost anything while I try and see what TK4- provides
• Security:
  • added the users I use via ‘account’, update the RAKF profile for the users and groups I use; all my users now aliased to the new catalog I created on new volume mdtso1 and rakf profile updated to allow them to catalog user files in that catalog only
  • deny all on the default PROD batch defaulted to by RAKF and add my much tighter batch rules
  • delete all the default users from RAKF profiles, left them in account for now until the next TK4- uodate in case the updates need them
  • TK4- PDF mentions RAKF DIAG8CMD, probably for HERCCMD, removed all rules for DIAG8CMD and replace with DIAG8 facility, as that is what my diagnose code eight program uses
  • TK4- has only 8 TSO terminals defined to VTAM. I need more, on my todo list
  • What NOT to do. This time when adding guest users via account I gave them an esoteric volume of GUEST.. which did exist by the way. For some reason they could NOT see (via TSO LISTC and the RPF dataset list options; tso listc gives catalog unavailable error) any datasets in my new SYS9.UCAT.TSOMID catalog (including their own prefixes)… BUT could quite happily lookup via catalog datasets in my other SYS9 user catalogs ????
    Anyway, redefined the guest users to account without a generic unit entry and they could access all catalogs again
• As all my datasets were copied across and the catalogs imported my MMPF message automation STC is running OK and happily responding to messages, cancelling jobs, mounting tapes etc., plus the batch job scheduler is running ok
• my startup/shutdown scripts can start/stop the environment under screen as I require, which allows the use of a working SPY and IMON console
• added to the JES2PARM startup commands the command to log console activity to SYSLOG to it can be viewed via Q, and more importantly archived; syslog archiving is working
• Changed the system SMF ID to what I use so I can swap it in with my live system
• Found one CBT program I use that abends on TK4-, cleaned that up so it works on TK4-
• One major issue I found the normal BSPPILOT SHUTDOWN, SHUTFAST and SHUTDOWN members in SYS1.PARMLIB are ALIASed to STSTD, SDSTDFST and SDSTDNOW. It’s probably a RPF issue but editing the normal members any TK3 user is used to editing (ie:SHUTNOW, which are aliases) is a waste of time as the changes made to an ALIAS member entry are not preserved over an IPL, you end up back with the origional member contents. A nasty trap for people used to the TK3 system… and I see no point in why sys1.parmlib was polluted with additional members if the origional names are expected to be used anyway
  This caused enough pain that I intend to remove all the aliases and rename the SDSD* members to the expected names when I get time to test the impacts; in the short term don’t edit the aliases, just the real members

Summary

TK4- (update 7) is stable, in that everything that works under TK3 can be made to work under TK4-, plus TK4- has a few new things for me to play around with.

I have replaced my TK3 system with TK4- as that has had no major detrimental effect on my use of it; apart from the minor detail it has a lot more virtual dasd volsers so my backup virtual tape pool ran out of scratch tapes, added more.

People new to hercules and Turnkey3 should start with Turnkey3 even if they immediately afterward switch to TK4-, simply because TK3 walks you through installing MVS3.8J and that is an understanding you will probably need at some point.

One issue I did have on an old CentOS6.0 VM running an old hercules RPM was that the CTC adapter entries in the hercules configuration file errored. Not an issue if you keep your version of hercules up-to-date but be aware that even though I recomend starting with TK3 that comes with a really old version of hercules, so if you start with TK3 you will need to update hercules before using TK4-.

Edits: 2016/02/18 added the new observed behaviour when a program is replaced in a linklisted library as that is a major improvement, for me anyway.

Update 2016/05/02, Fedora23 users are out of luck

TK4- comes with binaries for hercules that include the modification to implement the tcpip opcode instruction, that are expected to run on most systems. That may get FTPD working… however the binaries do not work on Fedora23… that appears to be a Fedora23 packaging issue however, the TK4- supplied linux hercules file complains about a missing library file (that is actually missing) but the package that is supposed to provide the missing file is installed… just without that key file that is supposed to be in the package.

mark@vmhost3 tk4-minus]$ hercules -f mark/marks.conf
hercules: error while loading shared libraries: libbz2.so.1: cannot open shared object file: No such file or directory
[mark@vmhost3 tk4-minus]$ 

[root@vmhost3 init.d]# find / -type f -name libbz2.so.1
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/run/user/42/gvfs’: Permission denied

[root@vmhost3 init.d]# dnf provides libbz2.so.1
Last metadata expiration check performed 0:55:44 ago on Mon May  2 16:52:53 2016.
bzip2-libs-1.0.6-17.fc23.i686 : Libraries for applications using bzip2
Repo        : fedora

bzip2-libs-1.0.6-19.fc23.i686 : Libraries for applications using bzip2
Repo        : updates

[root@vmhost3 init.d]# dnf install bzip2-libs
Last metadata expiration check performed 0:56:43 ago on Mon May  2 16:52:53 2016.
Package bzip2-libs-1.0.6-19.fc23.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
[root@vmhost3 init.d]# 

It is not in the bzip2-devel package either, bother.