IBM Mainframe Journal

Fin

2011-07-29T15:20:00.000-07:00

To my few and loyal readers,

I will no longer be updating this blog. I have enjoyed writing and learning all about mainframes, but both the universe and IBM decided it was time for me to move onto bigger and better things. I, like many other IBMers, have been 'resource action-ed' (ie, laid off). Rather than get another job in the industry and thus expose myself to future resource actions, I have decided to go back to school and get my phd, with a focus on the social and ethical implications of the creation of artificial intelligence.

I truly hope this blog saves you some of the pain and trouble I experienced when learning about z/OS, and please feel free to post or contact me if you have questions about z.

cheers

David

HOW TO GET A WORKSTATION APPLICATION TO INTERFACE WITH Z/OS

2011-04-27T11:08:00.000-07:00

I hope this post saves you some aggravation. If you are creating an application and need to interface with z/OS via TCP/IP, there IS an API for that. The book you want is called "IP Sockets Application Programming Interface Guide and Reference" and can be found here. Note - depending on the age of this post, you may want to find a more recent version of the pub. The link takes you to communication pubs for z/OS v1r12.

HOW TO SERIALIZE A JAVA TABLE THAT HAS ROWS OF VARIABLE HEIGHT

2010-09-28T12:03:00.000-07:00

Not strictly a mainframe topic, I know, but this has been such a pain in the ass to figure out that I want to save others from the nonsense I had to go through to work this out.

-=THE SITUATION=-

You have a Java table with a custom renderer that allows for the text in cells to word-wrap, thus altering the height of some of the table rows. You want to serialize this table model and you get a java error regarding a sizeSequence.

-=WHAT'S GOING ON=-

Basically, the problem is that Java is dumb. When you execute the setRowHeight method for the table in question, it should be updating the SizeSequence (the thing that keeps track of where one row ends and another begins), but it's not. Not a problem until you try to serialize the table and Java freaks out because there is a discrepancy.

-=THE FIX=-

Put this line:

[table model].fireTableDataChanged();

just prior to your attempt to serialize. It'll force Java to do what it should've done in the first place, which is update SizeSequence, and allow you to serialize your table.

HOW TO CLEAR THE SCREEN IN TSO, CLIST, OR REXX

2010-08-29T09:28:00.000-07:00

I did some digging and found a forum thread with the answer. It seems that you can't do it from TSO. You can, however, write a simple assembler module that will do it for you.

here is the thread with the source for the asm module

here is a link to the IBM pub that describes the STLINENO macro

HOW TO REMOVE SYSTEM MESSAGES FROM THE CONSOLE

2010-08-12T09:33:00.000-07:00

You can use PF1 to remove them one at a time. Does someone know how to clear them all at once?

HOW TO COMPILE AND LINK EDIT MULTIPLE ASSEMBLER MODULES AT THE SAME TIME

2010-08-05T08:22:00.001-07:00

This is the best way I could come up with. If someone has something better (a way to do it from within the JCL perhaps?) please let me know. We are going to create three files:

1) a text file that contains the names and locations of the modules you are going to work with

2) JCL that will compile and link edit the modules

3) a REXX exec that will read data from the environment file, edit the JCL accordingly, then submit the JCL for each member in the environment file. Essentially, you are going to submit a job for each module you want compiled, and the REXX will do that for you automatically via the parameters you specify in the environment file.

Here is the environment file sample:

/*********************************************************************/
/* ASMCLENV - ENVIRIONMENT FILE USED BY ASMCLREX */
/* */
/* 04AUG10 */
/* */
/*********************************************************************/

*1
[location of source module to be compiled]
[where to put the compiled module]
[where to put the link edited load module]

*2
[same format as above]

The REXX exec is going to look for an '*' in column one as it reads this file to tell it where the data it's looking for is. Also, make sure to include the high-level qualifier in the data set name.

Here is the JCL:

//ASMCL JOB 'COMPILE AND BIND ASSY',MSGLEVEL=(1,1),
// NOTIFY=&SYSUID,MSGCLASS=H,CLASS=1
//*
//*** HLASMCL
//*
//* THIS PROCEDURE RUNS THE HIGH LEVEL ASSEMBLER
//* AND LINK-EDITS THE NEWLY ASSEMBLED PROGRAM
//*
//*********************************************************************
//* COMPILE STEP *
//*********************************************************************
//C EXEC PGM=ASMA90,PARM=(OBJECT,NODECK)
//SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR
//*
//SYSUT1 DD DSN=&&SYSUT1,SPACE=(4096,(120,120),,,ROUND),UNIT=SYSDA,
// DCB=BUFNO=1
//*
//SYSIN DD DSN= LOCATION OF SOURCE ASSY PGM **
//*
//SYSLIN DD DSN= WHERE OBJECT MODULE SHOULD BE WRITTEN **
//*
//SYSPRINT DD SYSOUT=*
//*********************************************************************
//* LINK STEP *
//*********************************************************************
//L EXEC PGM=HEWL,COND=(8,LT,C),
// PARM='NOMAP,NOLET,NOLIST,NCAL'
//*
//SYSLIN DD DSN= LOCATION OF MODULE TO BE LINKED **
//*
//SYSLMOD DD DSN= WHERE LINKED MODULE SHOULD BE WRITTEN **
//*
//SYSUT1 DD DSN=&&SYSUT1,SPACE=(1024,(120,120),,,ROUND),UNIT=SYSDA,
// DCB=BUFNO=1
//*
//SYSPRINT DD SYSOUT=*

This you shouldn't have to do anything with, just cut and paste, but be careful! JCL is very picky about operands being in the correct row/column. Make sure the lines that are continuations (the part of the statement that is continued on the next line) begins in column 16 or you'll get a big fat error!

Here is the REXX that drives the whole thing:

/* REXX */
/*********************************************************************/
/* CREATED 04AUG10 */
/* */
/* THE PURPOSE OF THIS EXEC IS TO DRIVE ASMCL (JCL TO COMPILE AND */
/* LINK EDIT AN ASSEMBLER MODULE). ASMCLREX WILL READ ASMCLENV TO */
/* GET A LIST OF ASSEMBLER SOURCE FILES TO COMPILE AND LINK. IT WILL */
/* THEN UPDATE ASMCL WITH THE DATA FROM ASMCLENV, SUBMIT THE JOB, */
/* AND REPEAT FOR EACH ENTRY IN ASMCLENV. THIS WAY WE CAN COMPILE AND*/
/* LINK MULTIPLE SOURCE FILES AT A TIME. */
/* */
/*********************************************************************/

ADDRESS TSO

/*READ ENVIRONMENT DATA***********************************************/
"ALLOC DD (INDDENV) DA('LOCATION OF ENVIRONMENT FILE') SHR REUSE"
'EXECIO * DISKR INDDENV (STEM ENVDATA. FINIS'
"FREE DD(INDDENV)"
ENVSIZE = ENVDATA.0
SYSIN = "//SYSIN DD DSN="
SYSLIN = "//SYSLIN DD DSN="
SYSLMOD = "//SYSLMOD DD DSN="
DISP = ",DISP=SHR"

/*LOOP THROUGH ENVIRONMENT DATA TO PULL OUT RELEVANT INFORMATION*****/
DO I = 1 TO ENVSIZE

/*IF ENTRY MARKER IS FOUND, UPDATE ASMCL AND SUBMIT THE JOB**********/
IF(SUBSTR(ENVDATA.I,1,1)) = '*' THEN DO
"ALLOC DD (INDDACL) DA('LOCATION OF TEMPLATE JCL') SHR REUSE"
'EXECIO * DISKR INDDACL (STEM ACLDATA. FINIS'
"FREE DD(INDDACL)"

ACLSIZE = ACLDATA.0
K = I + 1
ENVDATA.K = STRIP(ENVDATA.K)
ACLDATA.18 = SYSIN || ENVDATA.K || DISP
K = K + 1
ENVDATA.K = STRIP(ENVDATA.K)
ACLDATA.20 = SYSLIN || ENVDATA.K || DISP
ACLDATA.29 = SYSLIN || ENVDATA.K || DISP
K = K + 1
ENVDATA.K = STRIP(ENVDATA.K)
ACLDATA.31 = SYSLMOD || ENVDATA.K || DISP

"ALLOC DD (OUTDD) DA('LOCATION OF TEMPLATE JCL') SHR REUSE"
'EXECIO * DISKW OUTDD (FINIS STEM ACLDATA.'
"FREE DD(OUTDD)"

"SUBMIT 'LOCATION OF TEMPLATE JCL'"
END

END

A QUICK WAY TO CREATE A MEMBER IN AN EMPTY DATASET

2010-07-30T08:26:00.000-07:00

Normally, if you are working with a PDS that is populated with members, you can create a new member by going to ISPF option 3.4, entering the data set name, then typing S [new member name] and the command line. Unfortunately, this doesn't work if the PDS is empty. To get around this, go to ISPF option 2 (EDIT), and enter the data set name with the name of the member you want to create like this:

OTHER PARTITIONED OR SEQUENTIAL DATA SET:
   DATA SET NAME ===> 'data.set.name(newmemb)'

I found this gem and some other neat ISPF tricks here.

HOW TO TRANSFER AN ENTIRE PDS FROM ONE SYSTEM TO ANOTHER WHEN THEY AREN'T DIRECTLY CONNECTED

2010-06-22T13:12:00.000-07:00

Ran into this issue the other day:

I had a need to move a PDS from one mainframe to another and the two systems were not connected. I tried a simple FTP to my workstation then up to the other system, but the PDS members became malformed. A coworker suggested I XMIT (see this post if you need help on how to XMIT) the PDS to myself, FTP the XMITed PDS to my workstation, up to the target system, then unload it there.

I know that's a bit confusing so let's break this down:

1) XMIT the PDS from the source system to a new dataset on the source system. This will package the PDS into a format that can be transported. Let's say you called it (DSX)

2) FTP the packaged PDS from the source mainframe to your workstation (your PC, MAC, LCARS, whatever)

3) FTP the packaged PDS from your workstation to the target mainframe.

4) issue a RECEIVE INDS(dsx) command on the target system.

That should do it, hope it helps :-)

How to Get Rid of the Right-Hand Column of Numbers in the ISPF Editor

2010-02-16T14:51:00.001-08:00

UNNUM will do the trick nicely :-)

2009 Master the Mainframe Contest!

2009-08-28T10:26:00.001-07:00

The 2009 contest is just around the corner. If you are a high school or college kid and want to participate (no experience necessary, I promise!), click here.

Notes on How to Create a RACF Database

2009-07-22T12:07:00.000-07:00

First, here is a quick list of some of the RACF utilities and what they do:

IRRMIN00 RACF database initialization utility
IRRUT400 RACF database split/merge/extend utility
IRRDBU00 RACF database unload utility
IRRUT200 RACF database verification utility
IRRUT100 RACF cross-reference utility
IRRRID00 RACF remove ID utility
IRRADU00 RACF SMF data unload utility

To create a new RACF database, you're going to use IRRMIN00. Just whip up some JCL (check out 'z/OS Security Server RACF System Programmer's Guide' if nobody in your shop has some canned JCL you can cut and paste) and the utility will create a fresh database for you to use. Note that you have to reIPL before you can use this new database, as it is completely empty. At IPL time, a user entry for IBMUSER will be added so you can log in and start populating your new database.

After you've done this, there are two commands you probably want to issue against your new database. They are:

SETR GENERIC(DATASET)

and

SETR EGN

The first activates generic profile checking (see this post for a bit more on RACF profiles) and the second activates Enhanced Generic Naming. "When you activate this option, RACF allows you to specify the generic character ** (in addition to the generic characters * and %) when you define data set profile names and entries in the global access checking table. " (Security Server RACF Command Language Reference).

Some Random Goodies

2009-04-07T07:58:00.000-07:00

I've picked up a few tricks I thought I'd share:

1) In a previous post I talk about sending messages and data sets to other users. The command requires you to know the node name of the system the recipient is on. You can find out what the node name is by going into SDSF and typing NODE on the command line.

2) From within SDSF, after you've run a job and you are reading the results, if you want to edit and or reissue the same JCL, you can do so from within SDSF. When you are looking at the job output, type SJ at the command field to access your job. From there you can edit and resubmit. Here are a few screen shots of what to put where:

3) Recalling migrated data sets can be a pain in the arse, especially when you need several of them to perform a particular task. If you want to recall a bunch of stuff at once, you can do so from within the ISPF data set listing (option 3.4) by typing HRECALL on the command field then = at every subsequent data set you want recalled. The equals sign tells ISPF that you want to repeat the previous command you've entered. Here's another screen shot that illustrates what I'm talking about.

Quick and Dirty Guide to Adding Users and Groups to the RACF Database

2009-02-19T12:53:00.000-08:00

On occasion you may have the need to give a new user access to your system. As with anything else on the mainframe, there are about a million options but thankfully you really only need to concern yourself with a few of them. The first thing you need to understand is the concept of groups. RACF groups are a collection of users, grouped together to allow the system programmer (that's you!) an easy way to manage access lists. In other words, if you have 50 users that require access to a data set, rather than grant them access individually, you can put them in a group and give the group access to the data set. Cool, huh?

When creating a group, there are two attributes that you need to think about. They are

1) who the group owner is (can be another group)

2) whether or not this is a Unix System Services group (if it is, you may need to specify a GID)

It should be noted that it is not required that a group is created when a new user is added to the RACF database. Use the ADDGROUP command to add a RACF group. Here are a few examples from the RACF Security Administrator's Guide (ch 3, pg 59)

For example, to create a group for Department A called DEPTA whose owner and superior group is to be a group called ALLDEPT, enter:

ADDGROUP DEPTA OWNER(ALLDEPT) SUPGROUP(ALLDEPT)

To then connect users to that group, use the CONNECT command. For example, to connect department members SUE, LIZ, and GENE to the DEPTA group and also give LIZ and SUE authority to add new users to the group, enter:

CONNECT (SUE LIZ) GROUP(DEPTA) OWNER(DEPTA) AUTHORITY(CONNECT)

CONNECT GENE GROUP(DEPTA) OWNER(DEPTA)

If the group is to own group data sets create a top generic profile for the group data sets in the DATASET class. For example:

ADDSD ’DEPTA.**’ UACC(NONE)

If the group requires access to RACF-protected resources, give the group the required access using the PERMIT command. For example:

PERMIT ’RACF.PROTECT.DATA’ ID(DEPTA) ACCESS(READ)

If the group requires access to z/OS UNIX resources, alter the profile to include an OMVS segment with an z/OS UNIX group identifier (GID). For example:

ALTGROUP DEPTA OMVS(GID(100))

The next thing you need to dig is the concept of profiles. RACF is made up of profiles, and profiles are composed of segments. The base segment is composed of RACF specific stuff. Products also have segments in the profile. When you define a user to the RACF database, you also can define segments of that profile that specify what kind of access that user has to various products that are installed on the system. For example, when you define a new user to RACF, you may also want to define a TSO segment so TSO knows to use RACF (as opposed to its own UADS (User Attribute Dataset) dataset) to authenticate said user at login time. Use the ADDUSER command to add a user. Here are some things to remember when adding a new user:

1) Unless you specify a default password, the password for the new user will be the name of the group to which you add the user make sure you use a valid logon proc (IKJACCNT and ISPFPROC are good basic ones to start with)

2) You can apply the attributes SPECIAL, OPERATIONS, and AUDIT to a new user to give them access to protected system resources.
- SPECIAL does not automatically give the user access to data, but does give him/her the ability to grant him/herself permission to said data. Another way to look at the SPECIAL user is someone who has the ability to execute protected system commands.
- OPERATIONS has access to data, but not to protected system commands
- AUDIT gives the user the ability to view logs, and specify logging options

Here's more of the ADDUSER command, again from RACF Security Administrator's Guide (ch3 pg 92)

To create the user profile, you can use any of the following methods:

1) Issuing the ADDUSER command.
2) Enrolling the user through the TSO/E Information Center Facility (ICF) panels.

Here is an example of using the ADDUSER command to create a user profile. Suppose you want to create a user profile for user Steve H., a member of Department A. You want to assign the following values: STEVEH for the user ID DEPTA for the default connect group DEPTA for the owner of the STEVEH user profile R3I5VQX for the initial password Steve H. for the user’s name Steve H. does not require any of the user profile segments except TSO. The TSO segment values that you want to set to start with are 123456 for the account number and PROC01 for the logon procedure. To create a user profile with these values, enter:

ADDUSER STEVEH DFLTGRP(DEPTA) OWNER(DEPTA) NAME(’Steve H.’) PASSWORD(R315VQX) TSO(ACCTNUM(123456) PROC(PROC01))

You then want to create a top generic profile for the user in the DATASET class using the ADDSD command. For example, if the user’s user ID is STEVEH, enter:

ADDSD ’STEVEH.**’ UACC(NONE)

Well, that's about it. Note that you can use generic RACF profiles to protect more than one resource. This can be done with the use of the '*' wildcard (also known as the splat). Generic profiles saves you the trouble of having to create a unique profile for every little thing on the system. Last but not least, if you want RACF to protect all non-defined system resources, issue the command:

SETROPS PROTECTALL(FAIL)

What Does ABEND 414-04 Mean?

2009-02-19T11:55:00.000-08:00

Ran into this one recently and I thought I'd share. Essentially, a volume can be set to READ ONLY. This is something outside the scope of any security product that might be running on the system, meaning you may have RACF permissions to a data set, but if the volume on which that data set resides is READ ONLY, you'll get the 414 abend. The solution is to get your system programmer to un-read only the volume so you can write to it.

RANDOM APF AUTH GOODNESS

2009-02-19T10:42:00.000-08:00

From the console (or from SDSF), use this command to display a list of data sets that are currently APF authorized:

D PROG,APF

From the console (or from SDSF), to dynamically APF authorize a data set:

SETPROG APF,ADD,DSNAME=dsname,VOLUME=volser

Note that if you are using the TSO 'CALL' command to execute your compiled programs, you'll get an error if the program you're attempting to execute is APF authorized. To rectify this, you need to either execute the program via JCL, or add the module to TSO Parmlib member IKSTSOxx and re IPL.

How to set AC=1 when using ISPF foreground processing

2009-02-18T08:39:00.000-08:00

When you are writing APF authorized code (see this post for more details on what APF is), you may want to link-edit the module using the handy-dandy ISPF panels (option 4.7). Unfortunately, the pubs are not as clear as they could be as to the syntax of how to set the AC = 1 option when using the panels. Well, here's a screen shot of what you need to put there and what it looks like.

APF AUTHORIZED, SUPERVISOR STATE, AND KEY 0

2009-02-12T09:08:00.000-08:00

Understanding how the mainframe manages authorized and non-authorized code is crucial for anyone performing system-level tasks. The concepts are simple, but understanding how they relate to one another can get dicey. This post is geared towards someone who needs to write authorized mainframe code.

The system considers a task authorized when the executing program has the following characteristics:

It runs in supervisor state (bit 15 of the program status word (PSW) is zero).
It runs with PSW key 0 to 7 (bits 8 through 11 of the PSW contain a value in the range 0 to 7).
All previous programs executed in the same task were APF programs.

Here are the three things you need to know about:

APF AUTHORIZED: APF stands for A.uthorized P.rogram F.acility. It allows for the system programmer (for those of you who are new to the field, in mainframe-land a system programmer is like a system-administrator) to identify data sets and programs that are allowed to perform sensitive system functions. There are two components to APF authorization. The first is link-editing a module (program) with the AC 1 option set. By using the AC 1 option, we are making the module eligible to be APF authorized. The second component is to place the module into an APF authorized library. APF-authorized programs must reside in one of the following authorized libraries (data set):

SYS1.LINKLIB
SYS1.SVCLIB
SYS1.LPALIB
Authorized libraries specified by your installation.

Now that we've got our module properly link-edited and placed in an authorized library, we can move onto PSW key and system state. Normally, the system will run in what's referred to as “problem state”. This means there is a set of instructions that are unavailable. Only when the user is in supervisor state are these privileged instructions available. APF authorized programs are permitted to put the system into supervisor state. THIS IS IMPORTANT ---> APF AUTHORIZED PROGRAMS DO NOT RUN IN SUPERVISOR STATE AUTOMATICALLY! APF AUTHORIZATION ONLY ALLOWS FOR THE SYSTEM TO BE PLACED SUPERVISOR STATE.

So now that we're in supervisor state, there's one more thing we need to think about. Every page of storage (a page is 4 kilobytes) has a key associated with it. Keys 0-7 are considered protected, and 8-15 are considered unprotected. If a page of storage is protected, module attempting to access it must be authorized. The system needs to be in supervisor state in order to change the default PSW key from 8 to one that is authorized.

So, let's review. To create a program that is capable of executing privileged instructions and accessing protected storage, it needs to be APF authorized (link edited with the AC 1 option and placed in an APF authorized library), it needs to use the MODESET macro to place the system in supervisor state, and it needs to use the SPKA instruction to change the PSW key to 0-7 (whatever is appropriate).

Well, that's about it. I hope it helps. Here's a link that provides a bit more info if you need it.

Random TSO Goodness

2009-01-26T11:52:00.000-08:00

Lately I've been missing MS-DOS. Not because DOS was amazing, but because I know where things are and how to get things done. The PATH command is a good example. In DOS, you could use the PATH command to help DOS find programs you wanted to run. It created a list of directories to search through before it gave up and said something like BAD COMMAND OR FILENAME. You could put this command inside a file called AUTOEXEC.BAT, which was the name of a program that would get run every time the computer started. This way, you could save time as you didn't have to type out or go to the directory in which the program you wanted to execute resided.

In mainframe land, however, things are a bit more complicated.

In mainframe land, the equivalent of a BAT file (short for BATCH) is something called a CLIST. CLIST stands for Command Listing, and is a lot like a DOS batch file in that it provides a user the means to execute several commands at once. In other words, instead of issuing ten commands separately, you could make a list and all you had to do was type in the name of the list. So how do we save ourselves time like we did on our old DOS system?

There are two commands that you can issue on the mainframe that are roughly equivalent to the DOS PATH command. They are TSOLIB and ALTLIB.

TSOLIB is used for load modules, which are programs that have been compiled and link-edited. We issue this command against load modules to have it added to the STEPLIB data set. STEPLIB is a library that will be at the head of a load module search. So, when we want to run our "hello world!" program we lovingly wrote in C, we add it to the STEPLIB so the mainframe knows where to find it, thus saving us the trouble of pecking out it's location in the file system.

ALTLIB will do basically the same thing, but is used for CLISTs and uncompiled REXX programs. These are scripting languages and thus don't have load modules. By default, the mainframe will look in a dataset called SYSPROC for CLISTs. ALTLIB will add other data sets to that search, thus saving us time.

Now, it's important to remember that, like the PATH command in DOS, these changes all go away the minute you log off (or in the case of DOS, reboot the system). So, we need to find a way to have the system re-implement these changes every time we log in. We need a mainframe equivalent to AUTOEXEC.BAT.

On the logon screen , there is a field labeled COMMAND. From there you can issue any TSO command you want, including a CLIST that contains all your ALTLIB and TSOLIB statements in it.

There ya go. Hope it helps :-)

How to search for PDS members in ISPF

2008-08-21T12:04:00.000-07:00

I've just discovered a really simple way to find stuff on the mainframe. Let's say you are looking for a file called INDEX and you only know the high level qualifier of the dataset it's in. After you do your DLIST (ISPF option 3.4) of the HLQ (hlq.** for example), you type

member index

at the command line. The system will show you all the data sets where a file called INDEX resides. You can also use wildcards. So, for example, let's say there are lots of files you want to find, all starting with INDEX (INDEX00, INDEX01, INDEX02, etc). Then you'd type

member index*

and you'll be shown all the files that begin with the word index. Cool huh? The only thing I've noticed is that if your data set has been migrated, this won't work. You'll have to recall the data set before you do your search.

Hope you find it useful :-)

Master the Mainframe and GDDM

2008-08-06T18:24:00.000-07:00

The Master the Mainframe contest is just around the corner and as I'm on the contest team this year, I was asked to come up with a coding challenge. The one I came up with last year was a simple ISPF macro challenge I ripped from the pubs (ISRBOX) and added a few bugs too. This year I wanted to do something spectacular so I dug deep and dove into IBMs Graphical Data Display Manager, or GDDM for short.

What's so cool about GDDM? Well my friends, it allows the mainframe to display graphics and interact with things like mice and light pens and all sorts of other cool peripherals. ISPF can be made to act like a simple GUI with a point and click interface. It is also the means by which OS/2 displayed it's windows and such. With the advent of the web, however, this feature became somewhat depricated and nobody, to my knowledge, really uses it anymore.

So what am I doing messing around with this thing? Well, as fun as looking at endless streams of green text can be (and believe me, it's a hoot), I figured some colorful graphics might be a nice change of pace. I decided to create an implementation of Mandelbrot Set. The man who discovered this method, Benoît Mandelbrot, was an IBM fellow so it seemed fitting.

So I got to coding, pestered my co-workers when I got stuck or when the math got over my head, and finally I was able to get the thing working. It should be noted that I got some help, especially with the zooming bit, from here.

So I get the stupid thing working,

it looks amazing, it zooms (sortof) at the click of a mouse, I get my ooohs and aaaahs. After all that, it can't be included in the contest because none of the TN3270 emulators on the market (save the IBM one) can handle host graphics. No host graphics means no GGDM. The contestants won't be using the IBM TN3270 program so they won't be able to see the image.

...probably should've looked into that before I spent all that time coding the thing.

Oh well. As there isn't much good information on the web about GDDM I thought I'd post the code, written in C, for the Mandelbrot Generator. In order to use GDDM, you're going to have to play with your JCL and include some libraries so this compiles/links properly.

*NOTE* There are [] around the includes so Blogger doesn't think it's some sort of tag

#include [stdio.h]
#include [string.h]
#include [admucina.h]
#include [admtstrc.h]
#include [admucinf.h]
#include [admucing.h]
#include [admucins.h]

#pragma linkage(asread,OS)
#pragma linkage(chhatt,OS)
#pragma linkage(chhead,OS)
#pragma linkage(gsuwin,OS)
#pragma linkage(gschar,OS)
#pragma linkage(gsseg,OS)
#pragma linkage(gssati,OS)
#pragma linkage(gsscls,OS)
#pragma linkage(gsenda,OS)
#pragma linkage(gsarea,OS)
#pragma linkage(gsqcho,OS)
#pragma linkage(gsqloc,OS)
#pragma linkage(gspat,OS)
#pragma linkage(gsenab,OS)
#pragma linkage(gssaga,OS)
#pragma linkage(gsmove,OS)
#pragma linkage(gscol,OS)
#pragma linkage(gsline,OS)
#pragma linkage(gsview,OS)
#pragma linkage(gslw,OS)
#pragma linkage(gsflw,OS)
#pragma linkage(gsarc,OS)
#pragma linkage(fsinit,OS)
#pragma linkage(fsterm,OS)

#define width 320
#define height 200

main ()
{

/*SETUP THE GDDM ENVIRONMENT**********************/
float xoff, yoff, oldcx, oldcy;
int temp;
float scale;
int flag;
int number;
float cx = -0.5;
float cy = 0;
int inwin;
int type;
int val;
int count;
int id_type;
int id_id;
double x,y;
double xstart,xstep,ystart,ystep;
double xend, yend;
double z,zi,newz,newzi;
double colour;
int iter,input;
long col;
int i,j,k;
int inset;
int fd;

fsinit();
flag = 0;
gsenab (1,0,1);
gsenab (1,1,1);
gsenab (2,1,1);
gsuwin(0,640,0,480);
gsms(9);

xstart = -2;
xend = 1;
ystart = -1;
yend = 1;
xoff = 0;
yoff = 0;
iter = 200;
scale = 1;
xstep = ((xend-xstart)/width) * scale;
ystep = ((yend-ystart)/height) * scale;

/*DISPLAY AND ZOOM LOOP***************************/

while (flag == 0)
{
flag = 1;

x = xstart;
y = ystart;

for (i=0; i
{

for (j=0; j
{
z = 0;
zi = 0;
inset = 1;

for (k=0; k
{
/* z^2 = (a+bi)(a+bi) = a^2 + 2abi - b^2 */
newz = (z*z)-(zi*zi) + x;
newzi = 2*z*zi + y;
z = newz;
zi = newzi;

if(((z*z)+(zi*zi)) > 4)
{
inset = 0;
colour = k;
k = iter;
}

}

if (inset)
{
gscol(-1);
}
else
{

while (colour > 7)
{
colour = colour / 8;
}

gscol(colour);
}

x += xstep;

/*DRAW YOUR FRACTAL!******************************/
gsmark (j,i);

}

y += ystep;
x = xstart;

}

/*SEND THE GDDM DATA TO THE SCREEN****************/

gsread(1,&id_type,&id_id);

if (id_type == 2)
{

scale = scale * 0.75;
flag = 0;
oldcx = cx;
oldcy = cy;

gsqloc(&inwin,&cx,&cy);

if (cx > 320)
{
cx = 320;
}

if (cy > 200)
{
cy = 200;
}

cx = (cx * xstep) - 2 + xoff;
cy = (cy * ystep) - 1 + yoff;

xoff = (xoff + (cx - oldcx));
yoff = (yoff + (cy - oldcy));

xstart = cx + (-1.5 * scale);
xend = cx + 1.5 * scale;
ystart = cy + (-1 * scale);
yend = cy + 1 * scale;

xstep = xstep * scale;
ystep = ystep * scale;

}

}

fsterm();
}

Enjoy (and good luck to this years Master the Mainframe contestants!)

What are the PA keys for?

2008-06-02T08:31:00.000-07:00

If you're used to dealing with PCs and you suddenly find yourself working with a mainframe, there is a lot you have to get used to. Hitting the [ctrl] key instead of [enter] is a big one. Another is getting used to the fact that historically, the mainframe terminal keyboard had keys that aren't included on your AT-style PC keyboard. So what are those keys and what are they for?

Well, to start, let's talk a bit about what you're really doing when you log into a mainframe. When you log in, regardless of what terminal program you're using, you are emulating an IBM 3270 terminal. Here's a pic:

This machine was sometimes called a "dumb" terminal because it didn't have any computational power on it's own. Its purpose was to provide an interface between the mainframe and the user. So, let's take a look at that keyboard layout:

Looks a bit different, huh? Most of these keys you're already familiar with. Let's start on the right:

PF1-PF12, are Program Function keys. They are identical to the "F-keys" on your PC keyboard.

The "PA" keys are Program Attention keys, and are defined by whatever program you are running. For example, under TSO, PA1 will interrupt a command, and PA2 will redisplay the current screen. Under SDSF, PA1/2 will both redisplay the screen contents.

DUP places the DUP Field symbol on the screen and the cursor moves to the first position of the next unprotected field. Handling of the symbol is dependant on the application program.

INS MD Queries the session's operator information area to determine if the keyboard is in InsertMode mode.

CLEAR, or "CLR", sets all buffer locations to nulls and all character attributes to X'00'. The cursor moves to the top left corner of the screen.

ERASE INPUT erases the contents of all input fields in the screen and moves the cursor to the beginning of the first unprotected field. If the screen has no unprotected field, the cursor moves to the top left corner; no data is erased. If the screen is unformatted, this function clears the screen and moves the cursor to the top left corner.

ERASE EOF erases all characters (the characters are replaced with NULL) from the cursor position to the end of the field while the cursor is in an unprotected field. The cursor does not move. On an unformatted screen, this function erases all characters from the cursor position to the end of the screen.

TEST RQ sends a test request to the host system.

Well, that's about it. I hope that helps :-)

How to Write to or Read from a File in REXX

2008-04-14T07:49:00.000-07:00

I found a great article on the web that explains how to do this. I'm just going to link to it, rather than reiterate the whole thing. It's pretty simple, just a bit awkward (what on MVS isn't? :-)

click here for the article

RACF, XMIT, and RECEIVE Basics

2008-03-05T05:46:00.000-08:00

Oy! It's been a while since I've updated this thing. In all fairness though, I've been in class learning the mysteries of PL/X and Basic Assembler Language so I haven't had a lot of free time as of late.

So like everything else on the mainframe, performing simple tasks like sharing, sending, or receiving data sets can become a real pain in the tookus. There are about a million options for each command, most of which you really don't need to worry about. What follows is a quick-and-dirty guide to performing these basic tasks:

1) SETTING PERMISSIONS IN RACF

So here's the scenario. You've got a data set and you want your colleague to be able to view it so you can collaborate. How do you give him/her the ability to access your files?

In order to set a specific level of access to a data set, you need to create either a generic or discrete profile. A generic profile is used to set permissions on several data sets at once. For the purposes of this guide, we will only work with discrete profiles, which sets the permission level on a specific data set.

The first thing you need to do is determine whether or not the data set is already defined to RACF. You do this by issuing the following TSO command:

LISTDSD DA(dataset name) ALL

This will tell you if and in what manner the data set is defined to RACF. If the data set is covered by a generic profile, there will be a (G) next to the data set name. If there is no profile, or the data set is covered by a generic profile, you'll want to create a discrete profile to allow a specific user access to a specific, single data set. In the case where a data set is defined to RACF with both a generic and discrete profile, the discrete profile will take precedence. To create a discrete profile, use the following command:

ADDSD dataset UACC(NONE)

UACC stands for Universal Access Authority. Here are a few of the more useful UACC parameters:

NONE Does not allow users to access the data set.

READ Allows users to access the data set for reading only.

UPDATE Allows users to read from, copy from, or write to the data set.

ALTER Allows users to read, update, delete, rename, move, or scratch the data set.

By setting the default level to NONE, we ensure that nobody but the person(s) we specify have access to the data set. Now that we have the data set defined to RACF, we need to give your colleague access to it. You can do this by issuing the following command:

PERMIT dataset ID(user) ACCESS(level)

Congrats! You've now created a RACF profile to protect your dataset, and have allowed your coworker(s) access to it. I should note that there are lots of other fun things you can do with RACF, and that this is just a few basic commands. If you want to know more, the IBM publication z/OS Security Server RACF General User’s Guide is an excellent resource.

2) TRANSMITTING A DATA SET

This is actually pretty simple. You need to issue the following TSO command:

XMIT (node.user) DATASET(data set)

The node name is going to be specific to your system. Just ask around, one of your coworkers will be able to tell you what it is :-)

3) RECEIVE

When someone sends you a data set, you use the receive command to, well, receive it. This is another one of those commands with a lot of options that 99% of the time you don't need. This is a TSO command, and the following options are the ones that I find the most useful:

RESTORE: SPECIFIES THE TRANSMITTED DATA SHOULD BE RESTORED TO ITS ORIGINAL FORMAT. RESTORE IS THE DEFAULT.

DELETE: SPECIFIES THE FILE BE DELETED WITHOUT RESTORING IT.

DATASET(data set name): SPECIFIES THE NAME OF THE DATA SET TO BE USED TO CONTAIN THE RECEIVED DATA SET. IF THE NAME DOES NOT EXIST ALREADY, THE SYSTEM CREATES IT.

So when someone sends you a data set and you want to receive it, the command looks like this:

RECEIVE RESTORE/DELETE/DATASET(data set name)

That's it for now, hope you found this helpful!

Real Programmers don't eat Quiche

2008-01-29T12:47:00.000-08:00

Well, it's January and you know what that means? Time to compile a new fortran Snoopy calendar!! I'm going to walk you through the process, but you're going to need a few things first:

1) read the article at the following link (don't worry, it's quite amusing)

Real Programmers Don't Use Pascal

2) download the IBM 1130 emulator here

3) download the snoopy calendar card deck here. Save this file to the IBM1130Software sub-directory created by the emulator under the name "snoopy.job".

4) *OPTIONAL* get yourself a dot matrix printer and do this old skool!

All set? Right, lets do this!

First you need to fire up the emulator. You'll see a GUI (which we won't really be using but it looks pretty), and a console window with a sim> prompt. At the prompt, enter the following commands:

attach dsk dms.dsk [ENTER]
att prt snoopy.txt [ENTER]
reset [ENTER]
boot dsk [ENTER]

This will bootstrap the system and create a text file called "snoopy.txt". This will be your calendar! Now type

attach cr snoopy.job [ENTER]
go [ENTER]

It'll run for a second, and afterwards, the Printer icon will change. Double click on it to see the output of your job.

If you scroll down, you should see a 1969 snoopy calendar! Now, as cool as it is to have a calendar from December 1969, you're probably thinking this would be a lot better if the calendar was for this year. Well don't fret, one simple change to the code you'll have an authentic Fortran Snoopy calendar that is current, usable, and will be the envy of all your friends! Open up SNOOPY.JOB in your favorite text editor and find the line that reads

12 1969 12 1969 1

(in my editor, it's line 319)

That line is a date range. What you are really saying to your trusty IBM1130 is "hey pal, print me a calendar containing all the months from at December 1969 to December 1969. So, for example, you want a calendar from January 2008 to March 2008, you would change that line to read:

1 2008 3 2008 1

With that, you should be able to print our own calendars. Enjoy!

More on the x37 Abend (read this one first!)

2008-01-07T11:44:00.000-08:00

Well it turns out that there is, in some cases, a much simpler method of dealing with the x37 abend. As I mentioned before, any x37 means you've run out of space. So dig this, when you save members of a data set, z/OS saves the old copies. After a while, those copies can cause you to run out of space. When you browse the dataset, enter "/" at the command field,

then choose option 12 "Compress Dataset".

This will delete the old copies and hopefully free up some space. This will not work in cases where you've run out of directory space. In other words, if compressing the data set doesn't work, then go ahead and fix it the hard way as described in the previous Abend x37 post.

What the $#@! is does ABEND 0E37 mean?

2007-11-30T14:54:00.000-08:00

Lemmie guess, you were working with a dataset via ISPF and tried to save your work and got an 0E37 abend. Sound about right? Well don't fret, it's an easy fix. Any x37 abend is an error having to do with space. You're going to have to free some space.

One way to do this is to create a new, bigger data set for your stuff. You'll copy the old data set into the new one, and work with the copy. Ready? lets get started!

First, exit out of the dataset by entering CANCEL at the command line. You'll lose any changes you've made since your last save, so cut-and-paste anything critical. Go into the UTILITY menu, then into the DATA SET sub menu (option 3.2 at the command line). Get the attributes of the data set you were using by entering its name on the NAME field under the heading OTHER PARTITIONED, SEQUENTIAL OR VSAM DATA SET. Once you do this, you should see a screen listing the attributes of the Data Set you were working with. Exit out of this screen.

Now we're going to create a new data set. At the same line you entered your data set name, enter a name for your new data set. Before you hit enter, type A at the OPTION line. This tells the mainframe you want to allocate a new data set. Go ahead and hit Enter. You'll see the same attributes screen you saw before. Here's where you are going to make your changes. Increase the size of your data set, then hit enter. You should see a message that says the data set has been allocated. Exit out to the UTILITY menu.

Now we are going to copy your old data into the new data set. Go into the MOVE/COPY sub-menu in the UTILITY menu (option 3.3). Under the heading FROM OTHER PARTITIONED OR SEQUENTIAL DATA SET, on the line entitled NAME, enter the name of the data set from which you want to copy. Don't hit the ENTER key just yet.

*IMPORTANT!* If you do not enter this name in quotes, z/OS will attach your user name as a high-level qualifier. For example, if your username is JSMITH, and you enter PROGRAMS.WORKING as the dataset name (note the lack of quotes), z/OS will change the name you entered to JSMITH.PROGRAMS.WORKING.

Okay, now that you've got the correct data set name entered, go ahead and type C at the OPTION line and hit ENTER. Now the system will want to know where you want to place the copied files. Under the heading TO OTHER PARTITIONED OR SEQUENTIAL DATA SET, on the line entitled NAME, enter the name of the data set from which you want to copy. Hit the ENTER key.

Now you see a list of all the members of the data set from which you want to copy. Select the members you want to copy by entering S next to the member name. You can copy more than one member at a time by selecting multiple members before hitting the ENTER key. When you are done, exit out of this screen. Check your new data set to make sure the copy went alright (ISPF option 3.4). Once you are satisfied with how everything turned out, delete the old dataset and rename the new one (if your old dataset was called PROGRAMS.WORKING and you copied everything into PROGRAMS.WORKING.TEMP, we need to delete PROGRAMS.WORKING and rename PROGRAMS.WORKING.TEMP to PROGRAMS.WORKING).

Deleting and renaming data sets is fairly painless. Via ISPF option 3.4, enter the name of the old dataset on the line titled DSNAME LEVEL and hit ENTER. You should end up at the DSLIST panel. type DELETE at the command field (the space to the left of your dataset name). Once you've deleted the old dataset, you can rename the new one. Return to ISPF option 3.4 and enter the name of the new dataset and hit enter. At the command field type RENAME and hit ENTER. You will be asked to enter a new data set name. Type the name of the data set you just deleted and hit ENTER.

All done! Now you've got a bigger, badder data set to work with and you shouldn't have to worry about Abend 0E37 for a while :-)

ISPF is a harsh Mistress...

2007-11-29T07:28:00.000-08:00

Whew, the past month or so has been more painful than usual. As much as I love the mainframe, there are times where I feel like working on these machines is akin to hammering a nail into a wall with your forehead. Developing an ISPF interface has proven to be one of those times.

Essentially, I'm creating an interface for an in-house tool that reads and parses source code. To do this, I'm using ISPF for the user interface and a bit of REXX to handle the processing. Essentially, a large block of source code gets written into a table which is then displayed to the user. The user is able to view and manipulate the table by removing blocks of code that are irrelevant. The program aids the user in determining what sections of the code are important. When all is said and done, the user then has the option to save the table to a dataset.

The main sticking points have been:

1) Figuring out what defaults get set when you engage ISPF panel services

2) How to create/manage dynamic content

3) How to efficiently manage the interactions between ISPF and the code that is driving it

Before I go on, I'm going to show you what the panel code looks like that drives the main page:

)PANEL
)ATTR
! TYPE (OUTPUT)
+ TYPE (TEXT ) INTENS(LOW) COLOR (WHITE)
@ TYPE (OUTPUT) INTENS(LOW) COLOR (YELLOW) JUST(ASIS)
# TYPE (TEXT) INTENS(LOW) COLOR (GREEN) JUST(ASIS)
* TYPE (OUTPUT) INTENS(LOW) COLOR (WHITE) JUST(ASIS)
% TYPE (TEXT) INTENS(LOW) COLOR(RED) JUST(ASIS)
)BODY WIDTH(132)
+
+COMMAND -=>_CMDFLD +SCROLL -=>_SAMT+
+
+ TYPE "?" FOR ONLINE HELP
+ !MSG
+
# MVS SYSTEM INTEGRITY SCANNER: OUTPUT ANALYSIS TOOL
#
# ROW LOC OFFSET OBJECT CODE ADDR1 ADDR2 STMT SRC STATEMENT
# -----------------------------------------------------------------------------
)MODEL
+>_IN @AA
)INIT
&SAMT=PAGE
)PROC
)END

First off, note the spacing in the ")ATTR" section. That's important. It seems that ISPF, much like JCL, is sensitive to row/column position of code. I should say that there is another way to develop ISPF panels called Dialog Tag Language (DTL). DTL appears to have more functionality, but there is a trade-off. In order to keep everything compatible, you write a panel in DTL, then run it through a conversion program by typing ISPDTLC at the command line. Once you do this, the panel gets converted into something that is non-human readable, but is compatible with ISPF. I found this to be problematic, as I have no idea what my DTL is getting turned into. True, the conversion utility has error checking, but it's not able to find logic errors. So there are instances where you attempt to develop a dialog via DTL, you wash it through the conversion utility, run the panel, and find out it's not doing what it's supposed to be doing. Now you can't tell if the problem is the DTL you wrote, or the manner in which ISPDTLC interpreted your DTL.

So why bother with it you ask? Well, from the looks of it, DTL provides functionality that the normal ISPF panel language does not provide. If you look at the panel code I showed you (go ahead and scroll up, I'll wait), you'll see that there is only one line of code in the "(MODEL" section. that line, specifically the "@AA" part, is what displays the table information. Every row of the table is displayed in the same way. This means that I can't dynamically change the color of a particular row of the table based on context. DTL would, in theory, allow me to do that. The problem is that DTL will ignore the profile keylist (the thing that defines what the PFKeys are set to). This means that you have to define them yourself, but the figuring out how to define the APPL that would drive that is akin to learning Mandrin Chinese in an hour. So in the end, it seems that the ISPF Panel language is the best way to go.

So let's take a quick tour of the panel code I showed you:

)PANEL

Panel section. Specifies a keylist to be used during the display of the panel, and identifies where to find the keylist

)ATTR

Attribute section. Defines the special characters in the body of the panel definition that represent attribute (start of field) bytes. ISPF panels are defined line-by-line with control characters. So in the case of + TYPE (TEXT ) INTENS(LOW) COLOR (WHITE), a line that starts with the control character "+" will be displayed as plain text, low intensity (brightness), and will be white.

)BODY

Body section. Defines the format of the panel as seen by the user and defines the name of each variable field on the panel. In the case of the sample above, WIDTH(132) pertains to the number of character columns that will be displayed when the panel is shown.

Now is a good time to note that there are built-in control characters. One of them is "_". This denotes an input field. So by saying _CMDFLD, I am defining an input field with the variable name CMDFLD.

In the sample above, you'll also note a message field. This is where any messages will be displayed in the panel.

)MODEL

Model section. Defines the format of each row of scrollable data. This section is required for table display panels. Only one )MODEL section is allowed per panel.

In the sample panel I've shown you, I've defined +>_IN @AA in the model section. This means a table will be displayed here. Each row will start with a ">", which will be displayed with the characteristics mapped to control character "+". Then, an input field called "IN" will be created, then the table row called "AA". Note that "IN" and "AA" have different control characters, and thus are displayed differently.

)INIT

Initialization section. Specifies the initial processing that is to occur before the panel is displayed. This section is typically used to define how variables are to be initialized.

)PROC

Processing section. Specifies processing that is to occur after the panel has been displayed or redisplayed. This section is typically used to define how variables are to be verified and translated.

)END

End section. Specifies the end of the panel definition, and consists only of the )END statement. ISPF ignores any data that appears on lines following the )END statement.

That about covers the ISPF end of things. The next post will go over the REXX that's driving everything. I hope this has been helpful :-)

---------------------------------------------------------------------------------------
The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.