Friday, October 3, 2008

Part 2: Practical Experience

Part 2: Practical Experience

Approximate time to completion: More than ten hours

You must complete Part 1 of the contest before beginning Part 2.

The object of this part of the contest is to get you acquainted with some of the more practical aspects of systems programming and application development on the mainframe. These challenges are modeled after tasks that are commonly performed in z/OS shops.

If you manage to complete Part 2 100% correctly, you will have demonstrated many skills that employers are looking for. All contestants who complete Part 2 will be invited to put their resumes in the Student Opportunity System, a recruitment tool used by many of IBM's largest customers and business partners.

The instructions are not nearly as detailed for this part of the contest — you might have to use some additional resources, along with your new-found mainframe expertise, to complete the challenges.

The first 60 contestants to complete this section 100% correctly each win a $100 pre-paid debit card and a certificate from IBM.

Good Luck!
Before you begin: where to look for help
(1.) Prime your Part 2 data set
(2.) Become an ISPF guru
(3.) Job Control Language and Spool Display and Search Facility
(4.) Fix a JCL error
(5.) System z mainframe operating system commands
(6.) Better know a sysplex
(7.) Hit all the HILITEs
(8.) RACF challenge
(9.) Disk storage management
(10.) z/OS Data set organization: Catalogs
(11.) Executing JCL on the mainframe
(12.) z/OS POSIX-compliant UNIX services
(13.) Send all your hard work to IBM
(14.) What's next?
Before you begin: where to look for help

If you get stuck during the contest, or just want to find out more about mainframes, check out these mainframe resources:


Introduction to the New Mainframe: A new college textbook; great for introductory and overview information about the mainframe.

z/OS Library Center: Contains all of IBM's official technical documentation on z/OS, with hundreds upon hundreds of searchable books and documents. Everything you'd ever need to know about mainframes can be found here.

ABCs of System Programming, Volume 9: Written by system users, this is a great resource for systems programmers.

Message LookAt Facility: If you receive an error message from the system, you can look up a detailed explanation of the error here.

Mainframe blog: A mainframe blog that gives you a chance to interact with other mainframe enthusiasts.

z/OS Hot Topics newsletters: Keep up on the latest technical news about z/OS.

Return to the top
(1.) Prime your Part 2 data set

Background: You're an old pro at cruising around ISPF panels by now. Refer to "Part 1: Breaking the Ice," if you need a refresher.

For Part 2 we have created a data set called 'Z9#####.Z9#####.COMPETE.PARTTWO' (where Z9##### is your assigned userid). Your user ID is purposefully used twice in this data set name; this aids IBM in the judging of your work when you are finished with this part of the contest. This data set is very important -- it will eventually contain all of your work to be handed in for Part 2. From here on out, we will refer to this data set as COMPETE.PARTTWO. You'll need to keep its full name in mind, though, to complete many of the Part 2 challenges successfully.

Your challenge: Go to the DSLIST panel (ISPF option 3.4) and enter your user ID in the Dsname Level field.

On the next panel, enter E to the left of COMPETE.PARTTWO.

On the command line, enter S NEWMEMBR.

In the editor session that automatically opens, enter "Z9##### WAS HERE 2008. WOO HOO!" (The WOO HOO! part is optional, depending on your level of enthusiasm at this point. If you'd like to personalize your response further, alternate expressions of your mainframe zeal, such as "w00t!" or any phrase containing variations of the words "awesome" and "hooray" are also acceptable.)

F3 back out, and you'll see that NEWMEMBR has been created in COMPETE.PARTTWO. Now you know how to quickly create new members, which is a handy thing to know.

You just knocked out the first challenge. That was fast! Let's keep plowing through this.

Return to the top
(2.) Become an ISPF guru

Background: As you've already seen in Part 1, ISPF is a powerful tool set, and mastering ISPF can make your mainframe life much easier. ISPF can be used in many, many ways, including (but not limited to):

* using ISPF Edit and the Hardcopy utility to prepare and print memos
* communicating with z/OS through TSO commands, CLISTs, and REXX execs
* developing batch or interactive programs
* monitoring and controlling program libraries

If you'd like to do a little light reading on ISPF, you can find just about everything you ever wanted to know in the ISPF User's Guide, Volume 1. Simply click on the book title to open the table of contents.

Documentation note: The instructions for Part 2 talk you through the clickable BookManager online documentation, but if you'd prefer to download the PDF and follow along that way, you'll find the PDF download link to the left of each book title. All z/OS documentation is also available through the z/OS Library Center, which is a fantastic resource as well. Feel free to use whichever documentation suits you best.

Let's move on to your next challenge.

Your challenge: Become comfortable with some advanced ISPF editor commands.

A member named ISPFGURU has already been created in your COMPETE.PARTTWO data set. Open this member for editing.

Ready to rock? Okay. Let's get rid of the "warning" message at the top of the member. To do this, enter RESET on the command line. Voila! The next time you edit the member, it will be back, but it can be dismissed with the same command.

Since RESET is entered on the command line, it is called a primary command. The other flavor is a line command, which is entered over the line numbers to the left of the text (such as the I and CC commands you saw in Part 1). As you can see, primary commands affect the entire member and line commands affect only the line (or group of lines) they are entered on.

Note: If at any point during this challenge you want to start over from scratch, enter this line command on the first line of the member: d9999. This will delete 9999 lines (which should be all of them, unless things have gone seriously awry for you). Then enter this primary command:

copy 'zos.contest.source(ispfguru)'

and you will have a fresh copy of ISPFGURU.

You can issue the CAPS ON and CAPS OFF primary commands to make all of you editor input automatically roll to capital letters or not. This can be handy when dealing with JCL (which you'll see a little later). Issue the command CAPS OFF. To check whether you have CAPS ON or CAPS OFF, issue the primary command PROFILE. This shows all settings that are active for your current session, and you should see that it shows your CAPS setting. Nicely done. To get rid of the PROFILE output, you can use the RESET command.

So far, so good? Now would be a good time to check out one of your handy reference books, the ISPF Reference Summary.

Click on the book title to access the table of contents. Check out sections 1.7.1 and 1.7.2, which list primary commands and line commands that can be used while in edit mode. To read a more detailed description of any of these commands, the ISPF Edit and Edit Macros reference is a good place to look.

Now, back to ISPFGURU. Use the primary command SORT to sort all the lines in this member. The gibberish will resolve into a very important message.

The SORT command has many options which allow you to sort on any field of data. The numbers located in column 1 and 2 were used by SORT to organize the records in the manner you see them now.

Your next order of business is to remove the numbers in columns 1 and 2. There are several ways to do this; a simple one is to use the primary version of the CHANGE command. The command below is a form of the CHANGE command, including the parameters you need to complete your task. Issue the following from the command line:

c p'=' ' ' 1 2 all

Now that you've issued the command and seen what it does, let's dissect it and see how it worked. The command included four parameters to specify exactly what you wanted to change and how you wanted to change it.

* p'=' tells ISPF to change any character found.
* The blank (marked off with quotes) tells ISPF to replace the found characters with a blank.
* 1 2 tells ISPF that the requested change is applied starting in column 1 and ending in column 2.
* all tells ISPF to apply this change to all lines.

The CHANGE command is a very powerful command when used with the right combination of parameters. To learn more about the parameters that can be used with CHANGE or any other command, check out the good ol' ISPF Edit and Edit Macros reference.

The next thing you're going to do with ISPFGURU is add a nice border. You'll do this by putting a lower case z in the first and 72nd column of each row. You guessed correctly if you guessed that there is a simple, automated way to do this.

First, run the RESET command again to get your line numbers back. Now put a lower-case z in the first and 72nd column of the first line.
You can issue the COLS command to assist you in locating that elusive 72nd column. The COLS command is interesting in that it is both a primary and a line command - it can be issued either from the command line or from the line command area.

You may remember from Part 1 that ISPF is very careful to preserve system resources and removes excess blank lines from a new data member when the user hits enter. In some emulators, it also tries to preserve space on lines themselves. If you happened to use the arrow keys or the mouse (instead of the space bar) to move the cursor to column 72, you may notice on pressing enter that your second z hops over to the third column, eliminating the extra space.

There are two ways to fix the problem. The first is to use the space bar to get from column 1 to 72, letting the mainframe know that you are intentionally leaving that space. The other is the ISPF primary command NULLS ON. When the arrow key is used to move to cursor position across a single line instead of the space bar, then a space is automatically assumed in every position covered by the arrow key stroke. NULLS ON is like CAPS ON; it is part of your user profile that persists after a normal termination, until you issue NULLS OFF.

Remember from Part 1 that you can issue line commands on single lines (such as when you used the REPEAT line command to repeat a line ten times) or on groups of lines (such as when you used the COPY line command to copy a block of lines).

To make the same changes you made to line 1 on every other line, put a C in the line command area of line 1 and an OO in the line command area of the second and last lines. This will copy line 1 and overlay its contents on the rest of the lines.

That's almost it! Except for one more ISPF trick that you'll learn right now. Along with a multi-functional super awesome editor, ISPF includes several useful utilities. One of these is the SuperC compare utility that can be used to compare two data sets (or members within data sets) and flag any changes. To use SuperC, enter the primary command =3.12. Remember, this is the same as going to the ISPF Primary Option Menu and choosing option 3, then option 12.

First you will be prompted for a "new" data set name.

In the "Data Set Name" field, enter Z9#####.COMPETE.PARTTWO(ISPFGURU) then press enter.

At the next screen you will be prompted for an "old" data set name.

Update this panel with two data set name changes as follows:

Listing DS Name . . .Z9#####.COMPETE.PARTTWO(SUPERC)

The Listing DS Name field is the location to which SuperC will save its results. To get credit for this challenge, the SuperC output must be in your COMPETE.PARTTWO dataset. If everything goes correctly, you'll see it there as a member named SUPERC.

Hopefully you noticed that when you entered your PARTTWO data set name, your user ID was prefixed to it. If you don't want that to happen, you must put the data set name in quotes. You already knew that, right?

If you completed every part of this task correctly, you should see a report that tells you there were 45 line matches and 0 total changes. Hooray! If not, all of the non-matching lines will be listed. If this happens, you can go back and fix those lines or follow the instructions above to delete your old ISPFGURU and start over.

Whew! That was a long challenge. Hopefully you learned some handy tricks along the way that will aid you on your path to mainframe mastery. Good luck tackling the more technical challenges through the rest of the contest.

Return to the top
(3.) Job Control Language and Spool Display and Search Facility

Background: In Part 1, you ran a simple REXX program from the ISPF Command Shell (=6). Now we are going to run that same REXX program in batch. In z/OS, you have two different ways to do work: interactively in the foreground or non-interactively in the background. All of your work from Part 1 was considered foreground work. You can do a lot of stuff in the foreground, but when a program takes a lot of time to process, you can't do anything else with your interactive session while it's running. If you submit long-running programs to process in the background, then you can continue to use the interactive foreground while your long-running program processes in the background.

In order to submit work to run in batch, you need to instruct z/OS through JCL (Job Control Language). You submit your JCL to JES (Job Entry Subsystem) and the system allocates the necessary resources for your job, then executes the work when the resources are available.

JCL is a very rich language, and it's very different from any other programming languages. JCL has been around for over 30 years; as you might imagine, JCL for just about every conceivable task has already been written. Most systems programmers will find a JCL file (normally called a "job" in mainframe-speak) that does something very close to what they want to do, and then make a few little changes to it so that it fits their needs. You're going to do the same thing.

Your challenge: Submit JCL to execute the REXX exec from Part 1 as a batch job.

First, edit member RUNREXX in Z9#####.JCL. This member contains a job that is very close to what you need.

Inside that member, change jobname to REXX####, where #### is the last four numbers of your ID. For example, change jobname to REXX0001 if your ID is Z900001.

Note: While z/OS is not case sensitive, you must use UPPERCASE letters in JCL (with the only exceptions being comments and UNIX file system paths).

Change partone_member to the name of the member you created in Step 6 of Part 1, which was either your first name or the first eight letters of your first name. (In the examples for Part 1, the member was named JENNIFER.)

On the command line, enter SUB (short for submit).

This will send your JCL, which you can also call your job, to JES for processing. See the text MAXCC=0 inside the system-generated message? That means that your job ran with a return code of 0, which is good news. Not so hard, right?

But where do you find out what happened when your job ran?

The answer is the Spool Display and Search Facility, or SDSF.

To get to SDSF on this system, enter SD from the ISPF Primary Option Menu. (The savvy mainframer would take the shortcut and enter =SD from any ISPF command line to jump right to SDSF Primary Option Menu.)

At the SDSF Primary Option Menu, enter the following command:

OWNER Z9#####

Then enter the following SDSF command:


ST, or STATUS, will display the status of all tasks owned by OWNER Z9#####.

View your output, along with some system-generated output, by entering a ? to the left your jobname. The jobname specified in your JCL job was REXX####. Enter S (select) to the left of each piece to see output of your job.

F3 will exit each piece of the output and a second F3 will return to the panel that lists the entire REXX#### job in the JES output queue.

Enter an S to the left of REXX####.

What you'll see now is the same output. Entering ? to the left of the jobname separates the output into logical sections. Entering S to the left of the jobname will display all the logical sections concatenated as a continuous stream of output. To view all of the output, you'll need to use F7 and F8 to scroll up and down, and F10 and F11 to scroll left and right.

After verifying that your job produced the same output that it did in Part 1, write out all of the output to a member of your COMPETE.PARTTWO data set called REXXRUN.

To do this, navigate to the left of job REXX#### and enter the command XDC.

From the next menu, correctly enter the Data set name (specify COMPETE.PARTTWO, remembering the syntax rules you've learned), the Member to use (REXXRUN) and Disposition (OLD). You can accept all the other defaults.

Now you'll find a new member in your COMPETE.PARTTWO data set. Back out of SDSF and go have a look. Guess what? You just knocked out another challenge!

If you weren't successful and need to purge your job output, go to the SDSF Status Display menu (ST) and enter P to the left of any jobs that you want to purge. Press enter and watch them vanish. Happy purging!

Return to the top
(4.) Fix a JCL error

Background: As a systems programmer, you will be doing lots of work with JCL. If you make a simple JCL error, such as forgetting a comma or coding a JCL statement that runs past column 71, your job will, in most cases, end very quickly, and the system will inform you of a JCL error.

Your challenge: Fix a simple JCL error. Sounds simple enough, right? To get started, edit the member BADJCL in Z9#####.JCL As you might gather from the name, this JCL is not good. Well, not until you fix it, that is.

Change jobname to JCL####, where #### is the last four numbers in your user ID. Now submit the job.

Oh, man! A JCL ERROR message will be returned to the screen. Bet you saw that one coming.

What gives? Check your output in SDSF and fix the error.

Remember, to view just your held output in SDSF, use the OWNER Z9##### command followed by the ST command.

On the last line of output, you'll see that there's something wrong with a continuation on Statement 3. Hmmmm. What to do now?

Hint: Plug the message ID from JESYSMSG into the LookAt facility for some help (the message ID starts with IEF). The system you are currently using is z/OS, release level V1R8. The Application Programmer Response provides the information needed to correct this JCL problem.

Correct the JCL error and submit the job again.

Oh no! Another JCL error? (If your job takes a moment to run, pressing Ctrl again will show you the error message once the job completes.) At this point, you might be thinking that today is not your day. But today is your day. Your day to learn about JCL!

Go take a look in SDSF. Look for the IEF212I message. The system seems to be having trouble finding your data set. Why? Here's a hint: Look at your job and carefully check the spelling of the data set names. Go to ISPF option 3.4 if you need to look at what data set names start with your ID Z9#####.

After you fix the error and get the job to run correctly with no JCL errors, go back to SDSF. You'll find a new piece of held output there.

Once you verify that you got this new output, XDC all of the output from the job into your COMPETE.PARTTWO data set name with the member name FIXEDJCL.

Again, be sure that you XDC from beside the JOBNAME (not the DDNAME), to ensure that your new member will contain JESMSGLG, JESJCL and JESYSMSG, as well as the new piece of output.

That's it! You just debugged a JCL job. Life is good. Let's keep going.

Return to the top
(5.) System z mainframe operating system commands

Background: In this challenge, you will learn how to investigate the system configuration used for this contest. It's time to snoop around.

Your challenge: Your next challenge, should you choose to accept it, is waiting for you in your COMPETE.PARTTWO data set, inside the member named SYSCMDS.

Follow the instructions, entering your answers into
COMPETE.PARTTWO(SYSCMDS) as you go. Important: Make sure you edit this member, rather than viewing or browsing it. If you enter it in Browse mode, you'll get a very unhappy surprise when you try to save your work.

Navigation tip: To aid your navigation for this challenge, it's time you learned how to use an indispensable tool: screen splitting. From any ISPF panel, move your cursor to the topmost line and press the F2 key. You will notice that a brand new ISPF Primary Option Menu has appeared, and there is a row of dots across the top. You just started a second screen, which you can use just like you would use a normal screen. To toggle between your two screens, use the F9 key. (To view both screens at the same time, position your cursor where you want the split to occur and press the F2 key.) You might find this newfound knowledge helpful when you're comparing data sets, or copying output from one member into another. When you're done with your second screen, just hit F3 until you back all the way out of it. Your second screen will disappear, leaving you with only your original screen.

Note: After answering all of the questions in SYSCMDS, you'll see that the route command is sending a system command to a specific z/OS system for execution. Well, doesn't that mean that the contest environment involves more than one z/OS system? It sure does.

These z/OS systems are in what is called a Parallel Sysplex, a configuration that allows a cluster of systems to work together.

You now know the sysplex name and the unique name assigned to each participating z/OS system in the contest environment. Try to remember what you learned here, as you will need this information later on in Part 2!

Return to the top
(6.) Better know a sysplex

Background: As you learned in the previous challenge, this contest system is participating in what is known as a Parallel Sysplex. A sysplex involves many systems working together to handle a single workload in one of the most highly available environments in existence.

Parallel Sysplex, which was introduced in the mid-1990s, takes the concept of sysplex one step further with the introduction of the Coupling Facility. A Coupling Facility is a System z component that provides hardware and microcode for a rich set of data-sharing functions. Coupling Facilities are connected to systems via high-speed coupling links that provide fast data transfer rates. A Coupling Facility enables high performance read/write sharing of data by applications running on each system of the Parallel Sysplex. It also provides cluster-wide queuing mechanisms for workload distribution and message passing between nodes. The Coupling Facility combines the benefits of full data sharing and parallel processing in a highly scalable environment.

Data in a Coupling Facility is organized into structures. There are three types of structures, each with its own benefits:

* A lock structure supports high performance, fine grained resource locking and contention detection.
* A cache structure provides controls for distributed local server caches and a high performance shared data cache.
* A list structure provides a set of queuing constructs to support workload distribution and inter-system communication.

Coupling Facility structures are used by numerous software components to support data sharing, communication, work queuing, and serialization.

Many of our daily activities, such as banking and shopping, involve Parallel Sysplex technology. We just take it for granted that these services are available to conduct the business of our lives.

Your challenge: Use the commands found in section 4.9.47 of the MVS System Commands book to answer the questions found in your COMPETE.PARTTWO data set, in the member called SYSPLEXQ. You may also need to do a quick Internet search to answer the last question -- might we recommend Wikipedia's entry on scalability?

Just four questions this time? Phew!

Return to the top
(7.) Hit all the HILITEs

Background: As you've recently learned, there's a lot you can do with the ISPF editor. Let's take a look at one of the more useful features, the HILITE function.

HILITE allows the ISPF editor to color-code data based on context. The editor is capable of coloring keywords, symbols, comments, and operands. Simply invoke HILITE at the command line, and the editor will take care of the rest. It recognizes just about every major language out there, and if you don't want to specify the language every time, you can simply type HILITE AUTO and let the editor figure it out on its own.

This is all well and good, but what happens if you are working on a language the ISPF editor is unfamiliar with? Well, to edit or change keyword sets, there is a member you need to update, but finding it can be tricky. Get your utility belt ready; we're going in there after it.

Your challenge: Find data sets and members when you don't know exactly where they are.

First, let's play with the HILITE command so we can see what it does. In your Z9#####.JCL data set, edit the member TESTC, which contains a sample program written in C. Looks pretty green in there, doesn't it?

Now enter the primary command HILITE AUTO. Ahhhhh. That's a lot easier on the eyes, isn't it? If you prefer things monochromatic, you can turn off HILITE using the HILITE OFF command at any time.

Now let's take a look at your favorite book again, ISPF Edit and Edit Macros. You DID look at it back in the ISPFGURU challenge, right?)

In this document, you'll find the member name that you need to update in order to update the HILITE dialog to add or remove keywords that will enable the highlighting of previously unrecognized languages.

Hint: The discerning mainframer might want to begin searching, oh, say, around section, then look at the HILITE dialog subtopic.

Got the member name? Great! Wondering what you're going to do with only the member name and no idea what data set it's in? Even better!

The author of the documentation does not give you the name of the data set where this member resides, possibly because that location is customizable. So what's a mainframer to do? Well, here's another hint: all of the ISPF data sets on this system have a high-level qualifier (HLQ) of ISP.

So we know that our wayward member has to be in a data set that starts with ISP. Now you're getting closer, but if you do a search for all data sets with that HLQ, you'll find there are a lot of them, and you certainly don't want to go through each of them looking for one member. Fortunately, there is a shortcut.

At ISPF option 3.4, search for "ISP.**". The two asterisks are wildcards. We want to see every data set that starts with "ISP". Once you get your listing, type the following at the command line:

MEMBER member name you want to find

This is a feature that allows you to search through data sets quickly and find specific members. You should now have a message telling you two data sets that have the member you're looking for. Enter one of the data sets. From the command line inside the data set, you can run the command F member name you want to find to quickly Find the member.

Open the member and look at the first line. It should begin with: "Keyword lists for ISPF enhanced edit color." At long last, you found it! You can scroll down to see the various language definitions for the HILITE function.

Use the Move/Copy Utility (ISPF option =3.3) to copy this member into your COMPETE.PARTTWO data set with a member name of ISPFHI. There are two fields you need to fill in correctly on the first panel, and one field on the second panel to successfully copy this member using the utility.

That's it! You just learned some helpful navigation tips and proved you were up to the challenge. Nice work.
Return to the top
(8.) RACF permissions challenge

Background: Just like any other operating system, z/OS provides a means to protect data from unauthorized access. It's called the Resource Access Control Facility, or RACF for short (pronounced RACK-F). Specifically, RACF allows the mainframe to:

* identify and verify system users
* identify, classify, and protect system resources
* authorize the users who need access to the resources you've protected
* control the means of access to these resources
* log and report unauthorized attempts at gaining access to the system and to the protected resources
* administer security to meet your installation's security goals

Your challenge: Learn to use RACF commands to permit another user ID various levels of access to your data.

Let's look at how RACF works. Go to the data sets associated with the user ID Z900009, which is the user ID used in the screenshots for Part 1. Now try to view the data set Z900009.COMPETE.PARTONE.

Oops! You're not allowed to look at that data set. You'll get a message telling you that you have INSUFFICIENT ACCESS AUTHORITY. Your intent was to READ, but your access level for that data set was NONE. Now it's time for you to learn how to set the access authority for your own data sets.

You have four datasets available to you for this challenge:


Your challenge will be to create a discrete (not generic!) RACF profile for each of the four data sets, then permit a user on the system with an ID of ZUSERID various levels of access to the four data sets that belong to you.

Permit ZUSERID READ access to Z9#####.RACF.READ
Permit ZUSERID UPDATE access to Z9#####.RACF.UPDATE
Permit ZUSERID ALTER access to Z9#####.RACF.ALTER
Permit ZUSERID NONE access to Z9#####.RACF.NONE

Your completion of this challenge will be unsuccessful if:

1) UACC (universal access) is not set to NONE for all the data sets. This would result in a failure to protect your data sets from all other IDs on the system.

2) You permit ID * access to the data sets. This would result in a failure to protect your data sets from all other IDs on the system.

3) You create generic profiles, rather than discrete profiles, for these data sets. RACF has many, many features and capabilities. Generic profiling is beyond the scope of this challenge.

A description of the RACF commands you will need are available in the z/OS Security Server RACF General User's Guide.

Hint: That heading for section 3.1 sure looks promising, doesn't it? If you need to search further on any of the commands listed in that table, click the flashlight icon at the top of the screen to enter the search panel.

RACF commands can be entered from ISPF option 6. Using the commands you found in the RACF General User's Guide, set the appropriate access levels for each of the four data sets listed above.

Finished? Excellent! Now that you've created your RACF profiles and permitted the appropriate access levels, you need to validate your work. Let's do that now.

From ISPF Command Shell (option 6) enter:


The above REXX routine will check your RACF data set profiles and update your COMPETE.PARTTWO data set with a member named RACFOUT. Open this member and have a look.

You will see the following message if you were successful:
RACF PERMISSIONS SET CORRECTLY! If you see that message, congratulations! You just finished another challenge.

If you were not successful, use the RACF commands LISTDSD and DELDSD to list and delete data set profiles as needed until running that REXX routine tells you that you've set the permissions correctly. Good luck!

Return to the top
(9.) Disk storage management

Background: Data management on high-availability systems entails a lot more than just making sure you have a big enough hard drive. A single instance of z/OS may be accessing several hundred different volumes (you can think of a volume as a logical hard drive) of storage at any given time. Obviously, keeping track of storage like this is an enormous task, so mainframe systems programmers make use of IBM's DFSMS, the Data Facility Storage Management Subsystem. Through the facilities provided by DFSMS, storage becomes much more flexible and manageable.

You may be familiar with the concept of Storage Area Network (SAN), where storage devices can be attached to systems over a low-level network such as SCSI or FICON. Storage virtualization allows for logical "chunks" of storage to be represented as individual drives to the systems they are attached to, regardless of how much space they actually take up on the physical drives in the array.

Managed storage in z/OS is very similar, and allows for the same virtualization at the hardware level. The 3390s that are attached to your system that you will see in the exercises below are not actually 3390s, but rather emulated or virtual 3390s that have been carved out of a storage unit. These virtual Direct Access Storage Device (DASD) volumes allow for flexibility with high capacities and speeds while allowing for legacy applications to keep using their access methods and terminology. Additionally, by using DFSMS, we can organize these logical drives into what are known as storage groups.

A storage group is a grouping of volumes, defined by the storage administrator, that will form a single larger entity. For example, say you have a DB2 (database) application that requires lots of space to write out its records. It requires so much space, in fact, that the content would span several of your largest storage volumes. With DFSMS, you could define a storage group called DB2OUT, and allocate enough volumes to contain the output. Now your DB2 application simply has to specify that its output will be written to DB2OUT, and everything will fit in that group. If more space is needed later on, additional volumes can be added, without the need to re-initialize the existing volumes.

You can interface with DFSMS through the ISMF (Interactive Storage Management Facility) panels of ISPF. Let's check them out.

Your challenge: Explore the ISMF panels and demonstrate your understanding of storage concepts.

Edit the member DFSMS in your COMPETE.PARTTWO data set. This member has been prepped with the questions below. Follow the instructions and answer all of the questions in your DFSMS member.

From the ISPF Primary Option menu, choose option IS to enter the ISMF panels.

Select Option 2 (Volume), then Option 1 (DASD). This will bring you to the VOLUME SELECTION ENTRY PANEL, where you can enter search criteria for the storage volumes you want to find out more about.

Specify "Y" in the Acquire Physical Data and Acquire Space Data fields, and put * in the Storage Group Name field. This ensures that you'll be able to find the information about all disk volumes with disk volume labels beginning with SMS.

Look at the volume with the serial number (name) SMS001. Use F10 and F11 to scroll left and right on the panel that shows the details for SMS001.

Question #1
What is the physical address (Device Number) of this volume?

Now go back to the VOLUME SELECTION ENTRY PANEL. Find all volumes that start with SMS (SMS*) that are in the 0D00-0DFF address range.

Question #2
How many volumes are there?

Now, through ISPF Option 3.4, figure out which disk volume ZOS.CONTEST.SMS.BIG3 resides on. Look this volume up in ISMF.

Question #3
What storage group is ZOS.CONTEST.SMS.BIG3 in?

Question #4
What other volumes are in this same storage group?

Question #5
Are there any volumes in this storage group with over 50% capacity remaining? If so, which one(s)?

Users may want to further classify their data according to how readily it needs to be available, how fragmented it can be, and how frequently it should be backed up. To address this, a storage administrator can create Storage Classes for data.

From the first ISMF panel, enter into option 5 for Storage Class. Using the same methods that you learned above, list the storage classes in the active Control Data Set (CDS).

Question #6
What are the names of the storage classes on this system?

Question #7
What two storage classes have Guaranteed Sync Write?

Press F1 (help) while you're on this panel and go to (6) "Data Column Descriptions" to learn more.

The Storage Class Availability attribute can be changed by the storage administrator. The values for the Storage Class Availability attribute can be Continuous, Standard, Preferred and NOPREF.

Question #8
If an application is writing out data to a dataset on a volume that suffers a device failure, what is the result when the Availability attribute is set to Continuous?

Question #9
If an application is writing out data to a dataset on a volume that suffers a device failure, what is the result when the Availability attribute is set to Standard?

Once you've answered all nine questions above, you are capable of handling basic storage management tasks that a systems programmer or storage administrator will regularly need to perform.

You also just finished another challenge! Congratulations. Let's keep motoring.

Return to the top
(10.) z/OS data set organization: catalogs

Background: As you've seen throughout the contest, z/OS data is stored in data sets. Data sets reside on volumes (disk volumes and tape volumes). Each disk and tape volume is identified to the operating system by a unique six-character alphanumeric label (like your friend SMS001). Of course, now that you're a storage expert, you already knew all that.

To locate data within a data set , a user needs to know the data set name, the volume label and the volume device type (either disk or tape).

Typical z/OS systems at large companies have many disk and tape volumes, which are used to store a massive number of data sets. A systems programmer can't be expected to remember the volume name for each data set.

z/OS has a mechanism to remember the location (volume label and volume device type) of each data set name. This is called the z/OS Catalog Structure. The z/OS Catalog Structure includes special system data sets called 'catalogs'. A catalog contains data set names, along with their respective volume labels and volume device types (which typically represent types of disk or tape).

The z/OS Catalog Structure consists of one mastercatalog and one, none or many usercatalogs:

* The mastercatalog contains data set name entries for system-level data sets, with their respective volume labels and volume device types.
* The usercatalogs contain data set name entries for user-level data sets names, with their respective volume labels and volume device types.

The mastercatalog has a special type of entry called an alias. An alias is the first segment of a data set name, which you've learned to call the HLQ. When an alias is defined in the mastercatalog, the alias entry is related to a usercatalog. The name of the usercatalog is just another entry stored in the mastercatalog, so the mastercatalog always knows the location of the usercatalog.

Heavy stuff. Let's look at an example. Suppose a company wants to maintain employee payroll data in one data set, and year-end bonus data in another data set.

The mastercatalog may contain two alias entries called PAYROLL and BONUS. These two alias entries both relate to the same usercatalog data set of CATALOG.PAYROLL. Therefore, all data set names that have a first segment (also known as an alias or HLQ) of PAYROLL or BONUS are stored in the usercatalog CATALOG.PAYROLL, with their respective volume labels and volume device types.

The usercatalog CATALOG.PAYROLL could then contain data sets such as these: PAYROLL.LASTYEAR, PAYROLL.THISYEAR, BONUS.LASTYEAR, BONUS.THISYEAR.

When a program requests to read BONUS.THISYEAR, the system goes to the mastercatalog. The mastercatalog has an alias entry BONUS, which refers the program to the related usercatalog, CATALOG.PAYROLL, to retrieve the data set name with respective volume label and volume device type. Once the data set name BONUS.THISYEAR is located on the volume, then the program can then read the data within BONUS.THISYEAR.

The beauty of the z/OS Catalog Structure is that the program only needed to provide the data set name (BONUS.THISYEAR). The z/OS Catalog Structure then located the data set among the vast number of disk and tape volumes contained within the system.

Generally, all the system-level data set entries are in the mastercatalog and the user-level data set entries are in usercatalogs. All the mastercatalog knows about the user-level data sets is their first segment (alias or HLQ) and which usercatalog has the volume label and volume device type necessary to locate the data set.

Catalogs facilitate good management of z/OS data sets. For example, all data sets associated with a particular application, such as a payroll application, can have a defined set of associated high-level qualifiers and usercatalogs, which makes it easier to identify and secure all the data associated with the application.

z/OS provides a utility called IDCAMS to list and manage catalogs and their contents. Many of the catalog commands can be issued as TSO line commands from ISPF.

Did you get all that? Great! Let's get on with the challenge already.

Your challenge: Use system utilities to learn about and explore catalogs on the z/OS system.

Edit the member IDCAMS located in Z9#####.JCL. Change all occurrences of ##### to the last 5 digits of your user ID, then submit the job. Finally, some JCL that worked on the first try!

The IDCAMS job runs two instances of the LISTCAT command and concatenates their output in SDSF. If at any time you need help with the LISTCAT command, from ISPF panel 6, enter TSO HELP LISTCAT to get a description of the command and its syntax.

The command LISTCAT LEVEL('ZOS.CONTEST') lists all the catalog entries for 'ZOS.CONTEST' data sets. You can get the same information by using this command:


Use SDSF to review your output and answer the first four questions below. The member CATALOG in your COMPETE.PARTTWO data set has been prepped with these questions:

1. What usercatalog contains the entry for your COMPETE.PARTONE data set?

2. What volume does the catalog entry for your COMPETE.PARTONE point to?

3. What is the device type (DEVTYPE) in the catalog entry for your COMPETE.PARTONE data set?

4. What usercatalog contains entries for 'ZOS.CONTEST' data sets?

Now edit the IDCAMS member to list the catalog entry for 'OMVS'. Use SDSF to review the JCL job output.

Note: Be aware that 'OMVS' is a special entry, called an ALIAS entry, that is related to an associated usercatalog.

5. What usercatalog contains entries for 'OMVS' data sets?

Now edit IDCAMS again using the LISTCAT command with appropriate operands to answer the following questions:

6. What is the volume and DEVTYPE for the usercatalog that contains OMVS data set entries?

7. How many aliases are associated with the usercatalog containing OMVS data set entries, and what are they?

For the final question of this challenge, you will list the catalog entries for a VSAM data set (a VSAM data set is a special type of direct-access data set).

A VSAM data set is also known as a CLUSTER because it may consist of one or more component data sets presented to the system as a single set of data records. The VSAM cluster name components may include an INDEX component data set name, an ALTERNATE INDEX component data set name and a DATA component data set name. The VSAM cluster DATA entry gives information about the data and associated volumes containing the data. If the VSAM data set is indexed then there would also be other entries such as the INDEX data set name entry.

Edit IDCAMS one last time to list the catalog entries for the VSAM cluster data set names that start with 'ZOS.USSFILE'.

8. What is the CLUSTER data set name and physical record size (PHYREC-SIZE) in the DATA component for one of the VSAM data set name clusters whose name starts with 'ZOS.USSFILE'?

Did you survive all the questions? Excellent. That was a long challenge, and a tough one. You're coming down the home stretch, though! One tough challenge left, one easy one. Let's power through this.

Return to the top
(11.) Executing JCL on the mainframe

Background: Have a look at Z9#####.JCL(BADJCL2). As you're probably expecting, it won't run correctly as is. There is an error in the JCL. Luckily, fixing JCL errors is your specialty!

Your challenge: Fix more complicated JCL errors. In BADJCL2, change the #### in JCL#### to match the last four digits of your user ID. Submit the job.

This time, you should see two errors. Does one of them look familiar? Be careful! Just because the error is the same does not necessarily mean that the cause is exactly the same. Actually, the programmer who made this error had a different intent when coding this particular JCL statement.

Now is the time to go look at the z/OS MVS JCL Reference book. Scroll through the Table of Contents, looking for the chapter on JES2 Control Statements. Find the JES2 control statement that looks like the one that was intended. Pay attention to the correct syntax. While you are at it, read the description for the parameter specified on the statement.

Fix the syntax error and resubmit the job. Check the output carefully! If the job ran successfully, check the $HASP373 message, which indicates the system the job ran on. Does it match the sysname in the JES2 control statement? If not, check if you accidently coded a JES2 comment statement rather than a JES2 control statement.

However, if you are now faced with yet another dreaded JCL error, look for the cause of the error. This time, the error message is near the top of the output. Using what you learned in the System z mainframe operating system commands challenge, fix the JCL so the job must execute on a different system than the one you are logged on to.

Hint: To determine which system you are logged on to, use SDSF to view your active TSO session, which has a jobname equal to your userid.

When it runs correctly, this job lists information about modules. If you are interested in application programming, you might want to look into what this AMBLIST job does.

Once you get the job to run correctly, use SDSF to save all of the output to a member named FIXJCL2 in your COMPETE.PARTTWO data set.

You're almost there! To reward you for all the hard work you've put in to get this far, we saved an easier challenge for last. Let's plunge in and knock this one out.

Return to the top
(12.) z/OS POSIX-compliant UNIX services

Background: The z/OS environment includes a POSIX-compliant UNIX operating system as a core component. UNIX? Really? You bet. The inclusion of UNIX offers enhanced application programming and communication flexibility on the mainframe.

Your challenge: Learn to interact with the z/OS UNIX shell prompt.

To begin, you will need to telnet directly into the UNIX shell on the contest system. You can do this using any telnet client. In Windows, you simply need to bring up a command prompt (the default location in Windows XP is Start -> Programs -> Accessories -> Command Prompt. For Mac users, your terminal program can be found in Applications -> Utilities -> Terminal). Alternatively, you can use your favorite SSH client (such as PuTTY) if you prefer.

From a Linux, UNIX or Windows environment command prompt, enter the following command to invoke the telnet client:


This is the same IP address you have been using to connect to the contest system with your 3270 emulator. At the login prompt, enter your Z9##### user ID. At the password prompt, use the same password that you have been using to log into the contest system. Weird using the Enter key again, isn't it?

The shell prompt will be displayed in the following format:
Z9#####: /u/z9##### >

The UNIX commands below will redirect your command output to a file named "USS" (for UNIX System Services).

Important note on telnet: The telnet client uses the key, not the Ctrl key. In the exercise below, it is important not to mix these buttons up. If you accidentally press Ctrl and then after a UNIX file name, you may receive an error message in the format FSUMxxxx after you submit the command. If this happens to you, enter this command:

rm uss*

and start over again with the echo command.

Enter the following commands at your z/OS UNIX shell prompt:

1. echo 'I can now say I know something about z/OS' >> uss
2. who >> uss
3. date >> uss
4. uname -Irsva >> uss
5. exit

You can now close your telnet window; we won't be using it again in Part 2. You're probably missing your 3270 emulator by now. Let's get back to it. If you're not already logged onto the contest system, logon using your 3270 emulator.

From the ISPF Primary Option Menu, head to the ISPF Command Shell panel. Enter the following command:

OGET '/u/z9#####/uss' Z9#####.COMPETE.PARTTWO(USS)

Take a peek into your COMPETE.PARTTWO data set. You'll have a new member there called USS.

Browse it to have a look at what you just put in there.

Many wise old mainframe folks who used the z/OS granddaddy operating system (MVS) are unaware that z/OS includes a POSIX-compliant UNIX. You're one step ahead of the game now. You're also done with the final technical challenge of the contest! Let's get your work turned over to IBM.

Return to the top
(13.) Send all your hard work to IBM

Congratulations! If you made it this far, you are just about finished with the "Part 2: Practical Experience" section of the contest, a most impressive accomplishment. If you followed all the steps correctly, you should have 13 members in your Z9#####.Z9#####.COMPETE.PARTTWO data set:

13. USS

Review your work carefully! In order to win the $100 pre-paid debit card, you must be among the first sixty contestants to have every challenge from this part of the contest completed 100% correctly. In previous contests, the students who took their time and reviewed their answers have had more success than those who rushed to get their answer turned in the fastest.

When you are confident in your answers, XMIT your entire COMPETE.PARTTWO data set to JUDGES:


There, you did it!

IBM will contact you via email within 15 business days of your submission to let you know if you were among the first 60 contestants to correctly complete all the steps and XMIT your data set to JUDGES. Congratulations on getting this far!

Return to the top
(14.) What's next?

Regardless of whether or not you successfully finish among the first sixty contestants, you really have demonstrated some significant mainframe skills to get this far, and you should be proud of your work. Employers will want to hear about your experience! Be sure to let them know about it on your resume.

If you'd like more mainframe education, but your college, university or high school doesn't currently offer any, talk to your educators about IBM's Academic Initiative. IBM offers free course materials and mainframe access for students and professors. See the Academic Initiative System z program for more information.

The "first one to the finish" element of the contest concludes here. For Part 3, contestants have until December 29 to finish their work. Only students who are very serious about putting in many of hours on the mainframe over the next few months should attempt Part 3. For details, see the Part 3 instructions.

Thanks for competing in Part 2 of the Master the Mainframe Contest, and good luck if you choose to compete in Part 3!

This looks fun!


1 comment:

Anonymous said...

cigarette brands cohiba [url=]the best smokeless cigarettes[/url] hsbc bukannya waiverq ziar [url=]can i sell cigarettes online[/url] cigarette singapore cigarette prices france calais tattoo smokeless cigarette [url=]cheap cigarettes phoenix az[/url] dipusatkan vebas lichamelijke ecartament [url=]cigarettes online free shipping canada[/url] impus appreso aaneton malfur [url=]buy camel frost cigarettes[/url] dissecting themecherry criticism [url=]cigarette prices australia[/url] buy cigarette age in montreal cigarette inventory excel cigarette grinder cigarette flickr [url=]cigarette prices in quebec[/url] eggsperience zwei suddenly [url=]cigs ibm[/url] dirmi netpeoplein madame [url=]best pall mall cigarettes[/url] denrika ostatnich growth [url=]best brand of smokes[/url] jeep purok managera [url=]cigarette brands in america[/url] pageon erekonsumsi periode [url=]cigarettes brands review[/url]
combatute bombercrash [url= ]crowded cuvin [/url] unfoldings mopps [url= ]abctogo addig [/url]