Comment lines: Reginaldo Barosa: Why is your screen black?

Is there a better mainframe interface than TSO/ISPF?

Reginaldo Barosa (rbarosa@us.ibm.com), Senior Certified Application Development Specialist, IBM

Reginaldo W. Barosa is an IBM Senior Certified Application Development Specialist. He provides sales support, helping customers with application transformation solutions and development tools such as WebSphere Studio Enterprise Developer. Before joining IBM US more than six years ago, Reginaldo worked for 27 years in IBM Brazil. He has co-authored IBM Redbooks and has written two books, as well as other articles for IBM developerWorks. He holds a degree in Electrical Engineering from Instituto Maua de Tecnologia, Sao Paulo, Brazil. You can reach Reginaldo at rbarosa@us.ibm.com

Summary: IBM® WebSphere® Developer for zSeries bridges the gap between today's visual programming environment and yesterday's mainframe culture.

Tag this!

Date: 21 Jun 2006
Level: Introductory
Activity: 307 views

From the IBM WebSphere Developer Technical Journal.

When the world was black and white -- and green

Two years ago I was writing an IBM® Redbook for a project related to the mainframe. I was using TSO to perform some mainframe DB2® activity, when a young person who was working near me on another project related to Java™ stopped by my desk and asked, "Why is your screen black?"

That made me think. I was emulating the old IBM 3270 screen on my PC, but PC screens are usually all colors, not just solid black. I answered, "Because I am emulating the mainframe black screen and using TSO."

"What is TSO?" he asked.

"TSO is one way to interact with the mainframe."

Then he asked again, "But why is the screen black?"

I really didn't know the answer, but using the emulator I change the background to another color, since it's just matter of settings. But this question hit me very deep. It is not just matter of color; everyone recognizes that mainframe screens, also known as "green screens," are not known for being user friendly.

Shouldn't there be a better way to communicate with the mainframe?

The answer is: Yes, and there is. We do have a better way to communicate with the mainframe, and it is IBM's product called IBM WebSphere® Developer for zSeries®, which is based on the Eclipse framework. I have decided use this column as an opportunity to give you a brief introduction to this helpful and practical product.

"I can edit COBOL stored on the mainframe!"

Not so long ago, I had another interesting experience while teaching WebSphere Developer for zSeries near Boston. I had two smart professionals from the same company in the class, during which students had to write Java and COBOL assets to interact with z/OS®. One was a young Java expert, the other was a mature developer very experienced in COBOL, CICS®, DB2, and so on.

The young person had never worked with TSO, but had experience with the Eclipse framework. The mature developer had never seen Eclipse, but was an experienced TSO/ISPF user. They were able to work together on the same exercise, which involved compiling, executing, and debugging a COBOL program using the mainframe and traditional partitioned data sets (PDS). Interestingly, it was easier for the young person to navigate in the tool and perform the activities. In fact, he commented, "This is the first time in my life that I can edit COBOL that is stored on the mainframe."

During the class I noticed the young person explaining several times how to start a wizard -- but I also saw the mature developer explaining why JCL was required to run a COBOL batch program.

It was very easy for this young person to learn the new wizards of WebSphere Developer for zSeries and perform mainframe activities, like a data set allocation, but it would not be that easy to learn the basic TSO/ISPF operations.

Will TSO/ISPF die?

I would not say that TSO/ISPF is destined to die, at least not in the short term. There are many operations that only TSO can perform, especially operations executed by z/OS systems programmers, DB2 database administrators, and others. There are also some installations that depend on ISPF interactive CLISTs to perform z/OS development. However, young developers do not need to learn TSO and ISPF to develop or maintain mainframe programs. Today we have many efficient ways to interact with the mainframe.

So why not use TSO for only those activities that are a "must" and WebSphere Developer for zSeries for all other activities?

I am sure that many of you readers still remember the old days when the way to talk to a computer was with a punch card of 80 columns (96 for the IBM System/3). When the first interactive terminals were born, I remember a similar question about the life of punch cards. Some developers would not rely on the TSO/ISPF and keep decks of cards handy as a backup just in case.

The dawn of programming: A look back

I remember very well when a COBOL program was measured by the number of cards. I remember a programmer once saying, "My program is big, it has two full boxes."

Yes, boxes. Each box contained about 2,000 cards, so his program had 4,000 cards or 4,000 statements; each card usually contained one COBOL statement line. The best practice was to number each card in columns 1 to 6, and add an identification mark on columns 73 to 80. There were even IBM machines (like the IBM 129) that had a way to create special programs to perform automatic numbering without human intervention.

At this time a developer could take few days or even a week to clean the compilation of a large program, depending on of the quality of the card puncher that usually made mistakes with COBOL verbs and names. The process to create a program was:

The programmer filled paper templates with the COBOL statements.
The program templates were sent to the key puncher (sometimes for small programs or small modifications the programmer punched his own cards).
The deck of cards was sent for compilation.
The programmer received the error compile listing report. Many of those errors were due to bad punch quality and misspelled COBOL words.
The errors were either fixed by the programmer or sent again to the key puncher until the compile listing was clean.
After a clean compile and link, the first tests were run. (At that time most of the programs were batch and printed reports.)
For debugging, the programmer usually used simple COBOL statements like DISPLAY. IF statements were also heavily used; for example: IF BRANCH = 074 DISPLAY FIELD-VALUE.
When the program was okay, those statements were removed and the program was sent to be installed in production.

Yes, it was very painful. It was rare to create a program and get it running in the same day.

It was also difficult to keep program versions. Usually the cards were duplicated and special notations written on columns 73 to 60 to denote another version. Later, special tools were available on the market, like LIBRARIAN, that provided the ability to keep program versions on PDS instead of cards, but most installations still kept the card decks and computer printer listings as a backup. I was a COBOL programmer in 1972 and I remember that the company that I worked for had lots of physical space dedicated to keeping program card decks, computer listings, and so on.

I would need more space here to write about how programming evolved, but when TSO/ISPF and MVS were born, these helped developers to compile, test, and even debug much more easily.

That was in the 70's. How have we evolved since then?

Why not emulate a mainframe on PCs?

When PCs were born, we had some solutions and non-IBM products that were designed to help developers build COBOL programs to run on PCs and emulate the mainframe. But was that the best solution? Can we really emulate a mainframe operating system and all its components in a PC?

This infrastructure has problems with application development involving maintenance and significant integration to existing processing and data environments. It can be quite costly to set up emulated environments while actually increasing overall testing time -- testing both on the workstation and mainframe.

Today, mainframe products are also changing very fast. For example:

COBOL has a new verb to parse XML. Does this emulated environment have this new statement in its local COBOL?
CICS, IMS™, and DB2 have many new features and capabilities. CICS Version 3.1 has the capability of implementing services to help with SOA. Is it possible to emulate all those capabilities in the workstation?

Emulating a mainframe could in fact cost more than the savings with the CPU cycle. We need a way to simplify the mainframe interaction and use the power of the workstation to perform some trivial activities like editing, syntax checking, and local tests. It would also be nice to have local CICS and DB2 for syntax checking and simple local tests.

What is WebSphere Developer for zSeries?

IBM WebSphere Developer for zSeries V6.0.1 includes capabilities that make traditional mainframe development, Web development, Web services development, and integrated composite development faster and more efficient. People that need to code Java, HTML, JSP, and so on, can use also WebSphere Developer for zSeries, since it expands the capability of IBM Rational® Application Development and Rational Software Architect. WebSphere Developer for zSeries is not only for mainframe; it's a tool that can be used for distributed development and mainframe development as well.

WebSphere Developer for zSeries has many new wizards and capabilities to implement new industry standards, such as service-oriented architecture (SOA) on z/OS, and many installations could justify the usage of WebSphere Developer for zSeries, just considering basic and traditional mainframe development.

For the rest of this article, though, we will focus just on the traditional development that would replace TSO. (For more details on WebSphere Developer for zSeries, please refer to the documentation in Resources.)

How can WebSphere Developer for zSeries improve developer productivity?

WebSphere Developer for zSeries is powered by the Eclipse open source platform so developers can adapt and extend their development environment to match their needs and increase their productivity. How? I will list here just few examples of where productivity will improve. (This assumes a scenario where the programmer is performing COBOL program maintenance.)

1. During the coding phase (Code assist)

Suppose the programmer needs to use the CALL CICS statement in COBOL but forgot the syntax. He just types the part of the statement that he does remembers, then presses Ctrl + Space to completion. All the possible statement combinations are listed (Figure 1).

Figure 1. Code assist for command syntax
Suppose the programmer needs to code a MOVE statement to a field defined in working storage. He doesn't remember the field name, but he knows that it starts with the letter C. He types C and presses Ctrl + Space. All possible COBOL user-defined data names for program usage that starts with C will be listed (Figure 2).

Figure 2. Code assist for variable names
Suppose the programmer accidentally deleted a few lines of code and saved the modifications. He can replace the damaged edition with the modifications that are kept on the workstation, even though the program is located in the z/OS PDS (Figure 3).

Figure 3. Replace from local history

How do you do that with ISPF? You can't, because the file was saved; there is no UNDO here, so the programmer would need to either recover the backup copy or retype it.
Suppose the programmer needs to use a statement he is not very familiar with, like the new XPARSE COBOL statement. He types XPARSE, then presses F1. The statement from the COBOL documentation that explains the command displays on the Help feature. The full COBOL (or PL/1) manual is available online along with other documentation.

2. During syntax checking (Compilation)

This is one area where not only will you increase productivity, but you will also likely save some CPU cycles.

Since WebSphere Developer for zSeries has either COBOL or PL/1 compilers installed on the workstation, it is not necessary to submit a job for compilation on z/OS. The programmer just has to perform local syntax checking for the program before submitting a mainframe compilation, and the errors will be listed in the WebSphere Developer for zSeries Problems view. Also, if you double-click on the error message, the COBOL program that is located in the mainframe is edited and an indication of the line in error will be shown (Figure 4). Even someone not familiar with COBOL syntax will be able to locate the error. This is exactly the same behavior that Eclipse uses for all syntax errors in other file types, like HTML, JSP, Java, XML, and others.

Figure 4. Syntax checking

3. JCL generation

WebSphere Developer for zSeries can generate JCL based on models that we define. When this is done, as an option, the local TCP/IP address of your workstation is captured, since it is required for the interactive debug. In Figure 5, the segment of JCL generated by WebSphere Developer for zSeries with the workstation TCP/IP address was generated in the mainframe PDS.

Figure 5. Generating JCL

Although optional, this feature can also benefit those who are already familiar with JCL. The smart editor can help find syntax errors, and possibly even save some JCL submissions and mainframe CPU time.

4. z/OS interactive remote debug

Although you may already have tools to help you in this area, this is probably the most interesting area -- and the one where productivity could increase substantially.

With the interactive remote debugging feature, you will be able to run a program on z/OS and have the ability to view and change data contents, establish breakpoints, jump backward and forward in the execution, recover data exceptions, and more. This can be done for batch, CICS, COBOL or PL/1, DB2 stored procedures, debug-called subroutines, and so on. Plus, it is extremely easy to use. Figure 6 shows an example of debugging a COBOL/CICS program.

Figure 6. Interactive remote debugging

5. Get z/OS listings with JES monitor

When programmers need to access program listings, most use the known SDSF command to do so. Wouldn't it be nicer and easier if you could access the job listings as if they were located on your own workstation, so you could use local commands like Print? The JES monitor in WebSphere Developer for zSeries lets you do just that (Figure 7).

Figure 7. JES monitor

Given the five areas described above, the collective increase in productivity with WebSphere Developer for zSeries could be upwards of 15% on the conservative side -- although some people have reported 30% to 50%. Of course, this is not an easy area to measure, and will depend on many individual and environmental factors.

What is an "end to end" debug?

Remember that WebSphere Developer for zSeries is an extension of Eclipse and Rational Application Developer, and so a developer would be able to use this same tool to develop and debug composite applications. For example, if you have an application that is written with HTML/JSP/Java that connects to COBOL/CICS via Java connectors, you could perform what we called an "end to end" debug: the same debug perspective will show all the different language types, and you could make breakpoints in any of those languages.

Another example would be a Web page calling a z/OS COBOL DB2 stored procedure in z/OS, in which case, there is a need to debug using the application server components as well the COBOL stored procedure.

To view and animated example, see End-to-End debug in 11 minutes

There are currently no other tools on the market today that would let the user perform this type of extensive "end to end" debugging within the same development product (IDE).

How easy is it to replace TSO/ISPF with WebSphere Developer for zSeries?

There is no simple answer here, since a similar question would be, "How easy is it to adopt a new technology?" For some users this could be very easy, and for others, it could be very difficult, or almost impossible. I still remember how hard it was for some programmers to move from the punch card to interactive terminals.

However, one interesting feature of WebSphere Developer for zSeries is its ability to emulate mainframe screens, which could make adoption easier; if you ever need to jump to TSO/ISPF, or even to CICS terminals, you can connect to either without ever leaving WebSphere Developer for zSeries. You could also record and play macros that would make this connection very easy (for typing a user ID and password, for example), which would avoid extra typing each time that the mainframe green screen was required.

In Figure 8, you can see the mainframe screen being emulated using a WebSphere Developer for zSeries view.

Figure 8. Green screen emulation

In situations where the developer really needs TSO/ISPF for interactive CLISTS execution, for example, this could be the best solution.

Conclusion

We discussed some of the beneficial productivity aspects that could result from using WebSphere Developer for zSeries in this article. This product has many more features not mentioned here. I believe that WebSphere Developer for zSeries will soon be a standard interface for the mainframe, much the way TSO/ISPF is today -- unless the developer has an IBM 3270 type of terminal.

The main problem that I see at customer locations around the world is that most mainframe developers today have a PC and use it just for mail and zOS screen emulation. Why not make better use of those workstations? Will they need more memory? Probably yes, but how much does 512MB of memory cost today? It's cheaper than a dinner, and adopting WebSphere Developer for zSeries is easy to justify.

I believe that everything in this life has advantages and disadvantages. We should never say "no" to new technology, without understanding it. If we did, then languages like Java would never have been born and Assembler would still be the primary programming language.

However, if you are a mainframe shop, then be forewarned: new programmers like the ones just released from university will hate TSO/ISPF -- but they will love WebSphere Developer for zSeries!

Resources

About the author

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=WebSphere

ArticleID=129305

ArticleTitle=Comment lines: Reginaldo Barosa: Why is your screen black?

publish-date=06212006

author1-email=rbarosa@us.ibm.com

author1-email-cc=