Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Screen Handling with mainframe COBOL 2

Status
Not open for further replies.
M

Member 310024

Guest
I know that various PC COBOL versions provide for screen handling, but what is "World's Best Practice" as far as IBM mainframe CICS COBOL is concerned?
I have used Bit Maps (I think they are called) but it seems very labour intensive.
It has always struck me as being a weak point for mainframe COBOL, and allowed an "in" for various mainframe software providers to market their languages, based on screen handling issues.
I like everything about COBOL, but how do I defend it's screen handling facilities (or lack thereof) on the mainframe?
 
Simply put, the PC and the mainframe are two different animals. Therefore you have to consider their designs and how the software needs to interact with it. The PC and mainframe are the same in the sense that there is an operator there, but with the PC, every user has operator status.

Therefore it becomes more incumbent to have good screen handling in the PC COBOL, because the average user will need to interact with it more. Now with the mainframe, the typical way things are done is that JCL is submitted in batch jobs where the COBOL programs would run unattended.

But what of the need for user interaction. Since you have multiple users on one system, you need to have a multi-tasking capable system there to handle multiple responses, multiple screens (sending and receiving), multiple accesses to hardware, and so forth. This is where things like CICS come in.

CICS stands for "Consumer Information Control System", which is a bad name for what it does, but does fit. It's a facility that handles all user interactions. It acts as a process started on the mainframe in batch, then the programs written for it act as processes within CICS. If it helps, it's best to think of CICS or any other product that performs the same function (like IMS/DC) as a multi-user interface.

Now as part of this multi-user interface, a way to describe the screens needs to be made. For CICS, that's BMS (or Basic Mapping System). You have to define the scripts some way, so there's a script language for that. Like you point out, it's no surprise that other vendors have gotten into the act of making visual interfaces for making screens (and I don't blame them, BMS can get very laborious and very rough sometimes if you don't plan the screens out first).

It's not a COBOL issue, it's a mainframe issue. Programs written in other programming languages on the mainframe can still run as processes under CICS, but they still make the same calls as CICS and still use the same resources.

Of course, to confuse the issue, there are other multi-user interfaces (like TSO/ISPF and CMS) where you can write straight programs and run them in those interfaces, but these are generally considered to be for programmer use (since they are more for OS function than user function), and not necessarily for general user use.

Hope that clears a few things up.
 
The original mainframe screens tended to accept data in one pass - The user would fill in a screen of information, and press enter or a pf key. This is totally different from PC screens where you have a mouse for clicking and 'events' like tabbing off a field. It is not a deficiency in Cobol, more a feature of the way in which mainframe work.

There are a couple of products in the market which allow you to build mainframe screens in CICS, IMS etc. without having to code them direct, and these were heavily used in the 80's and early 90's. Over the years, as users began to become more accustomed to PC screens, they have wanted PC front ends to as many of their applications as possible. Many sites have taken advantage of the various methods of connecting the PC front end to mainframe and re-worked the legacy systems to cope. Others have taken the opportunity to re-write the legacy systems.

More and more now we are seeing nice gui interfaces on re-worked Cobol legacy applications, so defending the mainframe's poor screen handling packages no longer becomes a problem.

Marc
 
And, to further confuse things, HTML forms (found in ebusiness everywhere) have returned the industry to the "screen at a time" mode.

Tom Morrison
 
You could "accept" and "display" upon/from console. I remember when we converted from VSE to MVS we had to take that out. From batch you still can display upon console to make an entry in the system-log.

By-the-way: a star for Glen-with-the-nines for his excellent explanation.
 
Thanks to everyone.
MarcLodge gets my star award because he provided me with an answer which directly related to my question.
However, all responses were helpful and appreciated.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top