Mainframe systems

Bi-curiosity at the Share mainframe conference

Last year the award for best session title went to “‘Pimping’ Your FICON Ride: How Advanced Cisco Features Enhance Your SAN.”

This year it goes to a session taking place Thursday morning:”Being Bi-JESual: Understanding the other JES.” Here’s the full description, which is not nearly as sexy as the title implies:

Do you run both JES2 and JES3 in your shop and want to become more comfortable using the ‘other’ JES? Perhaps you just want to get a better understanding of the other JES regardless of which JES you are most familiar. The first speaker will cover operator commands, JCL, exits, and some processing differences. The second speaker will discuss the practical application of running both JESes in her company’s environment.

No word on whether Anne Heche will make an appearance.

Historic IT trends and ideas, and the impact on mainframe operations

SearchDataCenter.com mainframe columnist Robert Crawford wrote the following column on “Futures of the Past”. The big ideas in IT over the years and how they affected mainframe operations.

Through the years I’ve seen many things touted as “the future of IT.” Some worked out, some didn’t. Here’s a partial list of what I’ve seen come and go. If you don’t see one of your favorites, please post a comment.

1. Structured Programming
The idea of structured programming grew out of frustration with spaghetti code that no-one, not even the guy who wrote it thirty minutes ago, could understand. Structured programming imposed rules including neat IF/THEN/ELSE statements, DO loops, no procedures longer than 30 lines and no, I mean absolutely no, GOTO’s.

I would claim that structured programming is so deeply embedded in everything we do and the new languages we use that it no longer needs a special name. Mark this one a success.

2. Fourth Generation Languages (4GL)
The idea was to create languages so simple your end-users could write their own programs. Some 4GL’s went so far as to be non-procedural, meaning that one didn’t write logic so much as “describe the problem.”

Unfortunately 4GL’s performed poorly because they were interpreted and had to make too many assumptions. Besides, the end-users had better things to do than write their own programs. The end came with the arrival of spreadsheets and GUI report generators.

3. Personal Computers (PC)
In the middle 1980’s the much heralded PC was going to bring processing to the people. Not only were they easier to use, they wrested the power from the IT glass house and put it on everyone’s desk. By everyone I mean mainly executives who used their PC’s for e-mail and the occasional game of Snake. Before long, every Fortune 500 company was going to be running the whole corporation from a bank of PC’s.

Twenty years later we can say the deaths of the mainframe and UNIX were greatly exaggerated. However, I don’t think any of us are ready to relinquish our PC’s with graphical interfaces and powerful tools.

4. Relational Database Management Systems (DBMS)
IBM started it in the 80’s in announcing DB2 on the mainframe. Some of us shook our heads over the extra direct access storage device (DASD) space and processing relational databases required, but these were supposed to be offset by ease of use, easier programming and retrieval. Relational DBMS’ are now ubiquitous on every conceivable platform and have all but routed their hierarchical and network brethren. Definitely a winner here.

5. Client Server
The PC revolution made processing cheap and brought on the idea of distributed computing involving loosely coupled machines asking for information from each other. If done intelligently, data and software could be shared across the enterprise in manageable pieces. In addition, if the network was quick enough the distance between the computers wouldn’t make a difference. IBM also embraced this notion and built powerful distributed capabilities into CICS.

This is another one that’s so deeply embedded in IT that it no longer has a name. The dream is not fully realized as islands of computing and machines that can’t talk to each other, but the hope is still alive in web services (see below).

6. Object-Oriented Programming (OOP)
OOP changed the way we think about programming. Older programs had main procedures that called subroutines, passing static structures and working linearly from top to bottom. Now we had classes, attributes and methods and, best of all, reusability.

OOP is definitely the dominant programming model of today. It still has a few snags (for instance, just because the CalculatePi class has a square root method doesn’t mean you should include it in the general ledger system) but has more than delivered on its promises.

7. Graphical User Interface (GUI)
A great leap forward for usability, but sometimes you have to wonder if it’s worthwhile to click on the pull-down menu for “copy” when it’s easier to hit control-C

8. Java
Not only was a Java a more pure implementation of an object oriented language, it was designed from the git-go to run on any platform supporting a java virtual machine (JVM). It quickly became a standard and a handy way to poke Microsoft in the eye. By the turn of the 21st century our colleges were churning out Java programmers by the thousands.

No question Java is the language to use if you can. It still has a few problems with portability (“write once, debug everywhere”) and performance, but its universality makes it hard to resist.

9. The Internet
The Internet was not only going to revolutionize IT, it was going to change the way the world worked. Shopping, socializing, business were all going to be done over the Internet. Start-ups popped up like mushrooms amid dire predictions that any brick and mortar company bereft of a web presence was going to be out of business by next year.

It’s easy to be smug after the tech bubble burst earlier this century, but I am still a big fan of the Internet. Enormous amounts of information are at my fingertips and nearly anything can be bought online. Few of us would dare think of a world without it. The key is having reasonable expectations and remembering we still need the human touch.

10. Web Services
Web services are the latest twist on the client-server concept from the 80’s. Now the idea is to communicate through simple object access protocol (SOAP) messages written in eXtensible Markup Language (XML). If done properly, the disparate machines needn’t worry about the implementation or platform of the other.

This is the current future of IT and we can’t know how successful it’s going to be while we’re in the heat of battle. My notion is this will be another great idea that will become second nature to the next generation of programmers.

A list of things all mainframers should know

SAN JOSE - One of the more popular sessions I attended this week at the Share user group conference was called “Things a Mainframer Needs to Know, But No One Ever Tells You.” The panel was a group of mainframe professionals who had been in the industry a while. A lot of the audience members, meanwhile, were newbies to the platform.

So here’s a quick rundown of their suggestions:

Documentation. From Mickey Scott, a senior IBM WebSphere software engineer (sarcastically): “So you’re the new guy. Ideally your environment is well documented by everyone there.” The reality is that may not be the case. So you need to start examining where everything is. One key suggestion from Scott was to look at the syslog.

“That’s all you need,” he said. “You should go through the whole log and see what happens when things are normal, so when you are asked to look at a problem, you don’t go chasing some message that is normally there.”

Start building your libraries. This doesn’t just mean manuals, although it does include that. It should also include MVS system codes, printouts of IBM Redbooks, JES2 commands, and JCL scripts. The list goes on and on. And the panelists recommended at least downloading them to a place that you can access even if you’re network connection is down.

Monique Conway, a technical lead for Tivoli software products, added that it’s a good idea to start saving all your JCL scripts. If (and she stressed if ) your company allows it, take those scripts home with you. Why?

“If you’re new to the mainframe, and this is your first job as mainframer and you’re spending all this time building up your JCL, then you go to another job, all that work is gone,” she said. “So when you build it up, take a copy and bring it home.” Again, she said, if your company allows it. If it doesn’t and you do it anyway, you may soon be looking for a new job.

Learn your acronyms. One of the audience members suggested this, saying that you should document all your acronyms and how to pronounce them. You’ll want to know that RACF is pronounced “Rack F” and not “R-A-C-F.” Scott chimed in that IBM tends to have a RAG in their organization — that is, a Random Acronym Generator. Yes, that sounds about right.

Learn how to work with IBM and other vendors. It’s probably best if the first thing you say to a vendor is something that I can’t print here. As one panelist put it: “A large part of what we do is deal with vendor problems, or problem vendors, depending on how you think of it.” Some key points to having a successful session with vendor support:

• Determine the true severity level of your problem, and not just the severity level that you (or your manager) thinks it is. You don’t want vendors to think you’re crying wolf all the time.
• Have your information at the ready: problem type, what happened, when it happened, and anything you’ve already tried to do before contacting them.
• Play nice, but at the time, be persistent if need be. The vendor might tell you that no one else has told them of the problem you’re having. A good answer, according to Steve Conway, the lead sysprog at Freddie Mac? “Somebody’s got to be the first to find the stuff.”

Learn Assembler. Although you don’t absolutely need to learn Assembler to be a mainframe system programmer, it can help when doing problem resolution because you’ll be able to read the system dumps and, as one panelist put it, can be the difference between being a systems administrator (which he likened to a janitor) and a great systems programmer.

Join Toastmasters. Eventually you’re going to have to give a presentation. Eventually you’re going to have to convince a manager to buy new hardware, or upgrade your software release. So it’s probably a good idea if you learned how to speak in public.

And finally: Get a big monitor. In this day and age of multitasking, the bigger the monitor, the better. In fact, get two monitors if you can get away with it.