This live demo system is based on one of the TK4-Rob releases with my TK3 customisations retrofitted to it, plus the latest stable versions of my software.

This play system now runs in a non-persistent Docker container so do not expect any work you do to be saved, all changes will be lost on every restart of the container. The container image is available for download from the obtaining hercules section of this site it you want to play with it on your own machine rather than here. However you still need to read all this page to see how to use the mvs3.8j system within the container.

The container running here is stopped/deleted/restarted nightly at 23:00 NZDST to clean up anything users playing have been doing.

If you have a serious interest in the old MVS3.8J system running under hercules you should probably actually install hercules and a Turnkey release on your local machine. Remember this is an old OS, from the days when OS's ran in megabytes and even gigabyte disks were out of reach, it has a really small footprint (the docker container runs with an allocation of 80Mb of memory which is enough for the OS components, hercules, and under that mvs3.8j to run quite happily).
The major benefit of running it outside a container on your own system is that changes you make will be permanent; although you should use shadow files just in case you want to back those out.

How to use this live/play system

Read the entire page. Then you will know how.

Live System Rules (guidelines)

The compulsary privacy statement: all GUESTn.* datasets are readable and writeable by any guest user and the system admins. Do not store any sensitive information (or proprietory code) on this system even temporarily.

Batch job standards

Follow these guidelines and your batch jobs should run sucessfully.

Batch job execution rules

• Submit batch jobs in execution class A
• Only create permanent datasets using the prefix of the TSO userid you have chosen to logon with using "UNIT=3390,VOL=SER=MDTSO2", see dataset restrictions section below. Remember that the container image here is restarted afresh nightly so the datasets are not really permanent, they will not be there the next day.
• Batch jobs requiring temporary work datasets should use UNIT=WORK and not provide a volser (using something like UNIT=3330 will get your job cancelled if there are not enough packs online)
• Your batch jobs may use tapes, there are special considerations for these covered in the 'Tape usage rules' section below
• While you may (and should) create your own load libraries GUEST users do not have access to update APF authourised libraries. If you are at that stage you would be better installing your own copy of Turnkey3 or TK4- using the resources documented on the obtaining hercules page

Batch job print (sysout/sysprint) classes to use

• T - this class is for held output. You should use this class if you wish to view any of your output from TSO. There is a quick video tutorial on viewing held output from TSO
• G - to send output to the JRP 3270 printer if you have read the TK4- documentation on how to connect to the JRP printer, if you have not leave class G alone
• P - that individual jobs output is written to both a text and a PDF file, into container directory /home/mark/hercules/tk4-minus/prt/prt00e/job. Use class P if you want to keep a copy of your output as on this demo system the conatiner maps that directory to a physical host location so output from print class P is available for you to retrieve as either text or PDF from the printed output directory
• A - the default which you probably should not use, class A output will be printed to one of the two line printers defined, these are both large text files (one per printer) located in the container at /home/mark/hercules/tk4-minus/prt and if you are looking for one jobs output it could prove difficult to find. This class is the default to ensure jobs are printed instead of filling up the spool datasets and crashing the system. This class is also totally useless to you if you are using the live system as you cannot access it
• 8 - this class is for output that will be purged immediately the batch job finishes

Dataset rules and restrictions additional notes

As noted above only create datasets on disk using the GUESTn prefix you have logged on with, and use "UNIT=3390,VOL=SER=MDTSO2". Guest datasets created on any other volser will if dsorg=PO or PS be automatically migrated to the correct volser within 2hrs (but only the space actually used will be allocated, no free space will be allocated); any other dataset types will be manually deleted.

You have read access to all the system datasets needed to run assembler (370/asm at IFOX00 level), cobol (MVT 360 level), even PL/1 and fortran etc. Example S370/asm and cobol jobdecks are provided in the provided default guest files.
Obviously you have no write access to anything except GUESTn.* datasets.

For jobs that need temporary datasets you may use UNIT=SORT or UNIT=WORK, avoid using SYSDA or specific unit types like 3330 as that is likely to get your jobs cancelled by automation if not enough dasd packs of the requested type are online.

Do not attempt to password protect datasets you create, I have not checked to see if RAKF ignores/prevents that, but if it does not it will cause issues to my maintenance jobs and get your ip-address banned from this server. GUEST* datasets are there for anybody to use !.

Tape usage rules and restrictions

Tape mounts on my live system are fully automated my by a combination of my MMPF and TAPEMAN3 utilites (available in the downloads section), as long as you use tapes that are in the automation pool.

• So always request a scratch tape first, so you are allocated a tape volser you can use and re-use from the automated mount pool
• any request for a tape not in the automation pool will trigger site automation rules to cancel your job
• Do not repeatedly run jobs requesting scratch tapes, that will just exhaust the scratch pool and get your ip-address banned from accessing this server
• Never catalog datasets written to tape, or, you guessed it, your ip-address will be banned.

Example 1 - allocate a scratch tape, to get a volser to use

//SYSUT2   DD   DISP=(NEW,KEEP),UNIT=TAPE,
// VOL=(,RETAIN),    NO SER SO GET A SCRATCH TAPE
// LABEL=(1,SL),DSN=GUEST1.ANYTHING,
// DCB=*.SYSUT1      ASSUMING SYSUT1 PROVIDED THE INPUT

Example 2 - DD to use a named tape volser

//SYSUT1    DD   DISP=OLD,  OR DISP=(NEW,KEEP) FOR WRITE
// DSN=GUEST1.ANYTHING,
// VOL=(,RETAIN,,,SER=XXXXXX),  USE VOLSER XXXXXX
// UNIT=TAPE,LABEL=(1,SL)

Please note that for writing a dataset to tape you should use DISP=(NEW,KEEP); do not use DISP=(NEW,CATLG) for tape datasets as I don't want tape datasets cataloged as that is a major effort to clean up.

Console and Syslog access

You will probably never need direct console access, but as this is a play system I have permitted guest users to access the console via IMON, that will display what is currently on the master console and allow console command entry.

However for troubleshooting you really need to see what happened in the past rather than what is currently on the console, the syslog is available via QUEUE. Note that the syslog display via queue will always be a little behind what has actually been written to the syslog, be patient.

• To access the console - from the TSO READY prompt use 'IM' to start IMON, select option 'O'
  There is a quick video tutorial on using SPY and IMON to access the console
• To view the syslog history - from the TSO ready prompt use 'Q' to start QUEUE, then enter 'SLOG' to view the syslog.
• An alternate way of displaying syslog if you want to view older spooled off output is to use the Q command "ST SYSLOG" and select from the outputs shown. Note that every friday all syslog is archived from spool to disk (so I can keep track of what you are doing (grin)) so prior days logs may not be available to you if you are looking on a friday.
  There is a quick video tutorial on using Q to view the syslog output

Ok, the TSO logon userids you have been waiting for

Yes I deliberately put this information right at the end so you would at least try to read the rest of the page.

Currently there are three guest userids setup, these are the userids GUEST1, GUEST2 and GUEST3. The password for all three is 'GUEST'.
These users only have authority to create and write to datasets beginning with those prefixes.
Aof course they also have read access to all the system datasets needed to run JCL to manage those datasets and perform S/370 asm, COBOL, PL1, FORTRAN, PASCAL, ALGOL, GCC compiles and play some of the old TSO games such as startrek and advent.

Use the 3270 emulator of your choice to logon to this site using port 3270 with one of those userids.

If you do not currently have a client 3270 terminal emulator I would recomend installing the x3270-x11 package for fedora/centos/redhat users and the wc3270 (a port of x3270) for windows users (see the 'key resources' page).
Dez Blanchfield has also let me know there is a OS X version of tn3270 available at https://www.brown.edu/cis/tn3270/ for Mac users although check your version of OS X is supported from that page as it does state it does not support 64 bit which seems to be macOS 10.15 Catalina and above.

On logon you will be presented with an ISPF like interface. You can from there if you prefer F3 back to the TSO ready prompt and start RPF or RFE instead if you prefer one of those. RFE supports editing VB (brexx370 rexx datasets) and also can display vsam files in the 3.4 option which RPF does not and also has a nice spooled output viewer; however for day-to-day use on 80 byte length datasets I prefer RPF [as it can fix some dataset members that RFE corrupts... but in the build of TK4Rob used for the container image running here RPF crashes a lot, so a trade off]. I just spend a lot of time flicking between the two, the default for the default ISPF menu is RFE in the background in most cases.

The 3270 emulator java applet that used to be provided by this site has been archived as no modern browsers (FireFox, Safari, Opera, Chrome, Edge etc) support java plugins so the java applet is now only useful for users of the old Windows Internet Explorer, and if you are viewing this section of my site you are probably a Linux user :-).
If you are on a Windows machine with IE or Edge configured with IE compatability mode you can also with a lot of messing about use the archived java applet that provides a 3270 terminal emulator; however MS Edge for Linux while available does not provide an IE compatible mode so that will only work for windows users (I installed Edge for linux to see if that would work but as soon as I noticed it did not support that compatability feature uninstalled again, what a waste of space Edge for Linux is).