magnificEnterprise

We understand why Rob McNelly is hoping that mainframe computing will benefit from a new hands-on training program, the field continues to experience a shortage of talent, but for many reasons the DeVry/IBM partnership is probably not the answer.

On top of DeVry’s stigma as an allegedly mediocre institution, reaping profits in the shadow of controversy, this new track’s marketing materials commingle System z with PHP.

For a different approach let’s get our feet wet with a Hercules virtual machine on Amazon EC2, emulating an IBM System/370 running an old version of MVS.

We’ll be able to IPL and operate the system from the console and remote users will be able to concurrently log on and utilize Time Sharing Option environments.

Some find it surprising how much MVS and today’s z/OS have in common. At the end of this post we’ll link to some sources for taking our self-education to new levels and discuss what we hope to achieve in Part II.

We will need:

- An AWS account, authorized to lease the EC2 service.

- A local installation of Python.

- A local installation of Subversion, just so we can pull down boto.

Additionally, depending on our local platform, we might need to install one or two additional third-party client programs. Our instructions show a Gnome terminal on Linux using screen but Windows and Mac in conjunction with the appropriate software should also work fine for this exercise; likely requiring separate windows for each terminal connection and minor adjustments to the way commands are executed:

Windows	puTTY & tn3270
Linux	c3270
Mac	Terminal & tn3270

OK, Here are the steps:

1. Get boto
2. Create a keypair
3. Create the EC2 security group
4. Launch our linux host
5. Accept default configuration for the vm
6. Prepare MVS
7. IPL MVS
8. TSO logon
9. Try RPF
10. Additional reading

1. Get boto

To install and fire up boto on our local Linux system, we can do this:

svn checkout http://boto.googlecode.com/svn/trunk/ boto-read-only
cd ./boto-read-only
sudo python ./setup.py install
cd
python

Now we should see the interactive Python prompt, indicated by >>>. Type:

import boto

2. Create a keypair

Unless we already have one created, let’s generate a keypair so we can build and log into the Ubuntu instance we’re going to deploy:

import os
ec2_conn = boto.connect_ec2()
key_pair = ec2_conn.create_key_pair('gsg-keypair')
fileHandle = open ('id_rsa-gsg-keypair', 'w')
fileHandle.write(key_pair.material)
fileHandle.close()
os.chmod('id_rsa-gsg-keypair',0600)

3. Create the EC2 security group

And now create a security group that will let us reach our mainframe emulator after it’s up and running:

mvs_sg = ec2_conn.create_security_group('mvs_sec', 'MVS Security Group')
mvs_sg.authorize('tcp', 22, 22, '0.0.0.0/0')
mvs_sg.authorize('tcp', 3270, 3270, '0.0.0.0/0')
mvs_sg.authorize('tcp', 3505, 3505, '0.0.0.0/0')

3270 will be used for our remote connections to the emulated mainframe. Externally submitting JCL jobs to the mainframe is outside the scope of this post but to explore that functionality the ec2 instance will need port 3505 open.

4. Launch our linux host

We’ll use a stock Ubunutu image for this. When a call to instance.update() finally returns the word ‘running‘ (it may take a few moments), we’ll know it’s up and will be able to print out the system’s public domain name:

images = ec2_conn.get_all_images(image_ids=['ami-26bc584f'])
reservation = images[0].run(key_name=’gsg-keypair’, security_groups=['mvs_sec'])
instance = reservation.instances[0]
instance.update()
print instance.dns_name

At this point we would normally disable password authentication, add a new user with an ssh keypair, and use that user instead of staying logged in as root. We’re only skipping this step for brevity here; be sure to employ adequate security for the need at hand.

Back at the regular system prompt (exit out of Python or open up a new system prompt), we should now be able to log in as root with our keypair over ssh, substituting in the public domain name for the ec2 instance we deployed:

ssh -i id_rsa-gsg-keypair root@ec2-255-55-25-5.compute-1.amazonaws.com

We’re root on the remote host now. Let’s make sure the host itself is online:

ping www.redbooks.ibm.com

PING dispsd-45-redbk.boulder.ibm.com (207.25.253.45) 56(84) bytes of data.
64 bytes from dispsd-45-redbk.boulder.ibm.com (207.25.253.45): icmp_seq=1 ttl=241 time=66.7 ms

Yep.

At this point there are a couple prerequisites we need to install, as well as an iso to mount:

apt-get update
apt-get install unzip hercules
wget http://www.ibiblio.org/jmaynard/turnkey-mvs-3.zip
unzip turnkey-mvs-3.zip
cd /mnt
mkdir tk3cd
mount -t iso9660 -o loop /root/turnkey-mvs-3.iso /mnt/tk3cd
cd tk3cd
./setup -as

Later, when we want to do things like increase the number of available TSO logons or make other adjustments, we can just rerun the ‘./setup’ command without the ‘-as’ arguments and we’ll be presented with all kinds of options.

5. Accept default configuration for the vm

At this point we should see a screen like this one in our ec2 root console. Type ‘Y’ and hit return:

Then type ‘SECRET’ and hit return:

And finally just hit return:

6. Prepare MVS

Caveat usor, until we connect to our MVS 3.8J operator’s console, it’s up for grabs. In theory some nefarious user could beat us to it. If you’re paranoid don’t open up port 3270 for TSO connections until after you’ve seized control of the operator console through a 3270 connection to localhost on the ec2 intstance itself.
cd /var/adm/mvs38j/
./startmvs

Just hit return:

And now we’re ready to connect our terminals to the vm:

In the image below we added new screen windows, numbered and labeled across the bottom, to separately run the several terminal connections we’ll need:

boto	controlling our ec2 instance
hercules	emulating an IBM S/370
console	operator console
tso1	time share option logon #1
tso2	time share option logon #2
tso3	time share option logon #3

We only really need one of those tso windows to test the environment, the others are optional and discussed below.

OK let’s go ahead and connect to Hercules. We’ll need the c3270 program for Linux or something similar, or one of the tn3270 programs for Windows or Mac listed above.

In the console window, we’ll stay on our local system and run the following command, again substituting in the public domain name for our actual ec2 instance:

c3270 ec2-255-25-55-5.compute-1.amazonaws.com 3270

We should see something like this:

Now do the same for tso1 and, if desired, tso2, and tso3 as well. Subsequent tn3270 connections should show a slightly different value after Connected to device, e.g., 0010, 00C0, 00C1, and 00C2. The default setup we chose is configured to refuse any additional beyond 00C2.

All connections we establish now beyond the operator console will switch to TSO logon screens, as we’ll see in a moment.

7. IPL MVS

In the hercules window, type:

ipl 148

We should see:

Then, in the console window, just to make sure we’re in a sane environment:

r 00,clpa

We should see something like this in response:

At this point, since this is our first time bringing up the system, we need to follow the IPL steps starting after r 00,clpa at the BSP GmBH site, up through the command:

r 03,y

There are subsequent console commands in the instructions on that page that you can try as well. For more commands see the the links in Additional reading.

8. TSO logon

Now the terminal connection(s) we established beyond the one used as the operator console should be operational TSOs and look(s) similar to this:

We can log in as HERC01 or one of several other preexisting users:

If we want to allow remote users to log on to this system, here is the console procedure for connecting a tn3270. Based on that guideline these commands in the operator console seem to work for “pre-enabling” the TSO logons:

v net,inact,id=cuu0c1,i
v net,act,id=cuu0c1
v net,inact,id=cuu0c2,i
v net,act,id=cuu0c2
v net,inact,id=cuu0c3,i
v net,act,id=cuu0c3

9. Try RPF

And logged in TSO users can now do their thing, firing up RPF, if desired:

That’s it for now. We’ve only scratched the surface of the things we can learn, practice, and build on. Next time we’ll take a look at some possibilities for computing in a TSO environment and explore some ways to customize this Turnkey distribution of MVS 3.8j.

10. Additional reading

• Compare z/OS and distributed terminology
• The MVS to Unix migration HOWTO
• MVS 3.8 System Documentation
• MVS operator console commands
• RPF User’s Guide(pdf)
• CBT Software for MVS 3.8
• A notice from Jay Moseley

Posted on Friday, January 2nd, 2009 at 1:34 pm in architecture, aws, buzzwords, devry, ec2, gartner, hercules, ibm, mainframe, mvs, s/370, tso | rss feed for comments| Leave a response, or trackback