COBOL DISSERTATION

I am currently studying for a masters degree in IT. This is after 20
years experience mainly as a COBOL developer. I have been doing this
as well as a full time job self employed looking after a small number
of COBOL systems running on PC architecture.

For my dissertation I have decided to do something with COBOL. I have
had to prove that this is still a relevant subject in todays IT world
and that is now all done. The tiny piece of IT I have now decided to
focus on is about rescuing old SCREEN SECTION based systems to add a
GUI. Whilst this has been covered for lots of systems before and
methods already established these seem to me to be more form based
systems where it is easier to convert them (thats an assumption) There
does not appear to be anything written about how to rescue these other
type of systems where interaction with the screen is at quite an
atomic level. For example, a piece of existing code may appears as
follows (roughly, do NOT correct my code, you will be missing the
point):

A100.
DISPLAY SS-PRODUCT-CODE.
ACCEPT SS-PRODUCT-CODE.

MOVE WS-PRODUCT-CODE TO PROD-CODE.
READ PROD-FILE
INVALID KEY
DISPLAY "ERROR, PRODUCT NOT FOUND" AT 2401
GO TO A100.
DISPLAY SS-PROD-DESC.

A110.
DISPLAY SS-QTY.
ACCEPT SS-QTY.

The point here, is that the two ACCEPT statements are separate. There
will be many instances where the interaction is not as simple as this
example. The challenge is how do I convert this type of code to work
with a GUI. So what I have decided to try and do is some sort of
guidelines on how to convert this code to
allow a call to some form of GUI.

I am using ScreenIO for it but it could be anything.

At first glance it seems that this should then be replace with a small
form containing product code, description and a quantity. Then the
user would click an OK button and control returns to the program. I
think its a bit more complicated than that. What if I do not want to
introduce too many changes to the actual keystrokes performed by the
user? Do they really want to have to go and search for the mouse
cursor when performing repetitive tasks like keying invoices, delivery
notes, etc.

My question is, Does anybody have any links to any interesting sites
that may have already looked at this kind of thing? Has anybody been
around this loop before? All comments welcome.

Many thanks

"razor" <iruddock@blueyonder.co.uk> wrote in message
news:1174298650.286769.91370@d57g2000hsg.googlegroups.com...
>I am currently studying for a masters degree in IT. This is after 20
> years experience mainly as a COBOL developer. I have been doing this
> as well as a full time job self employed looking after a small number
> of COBOL systems running on PC architecture.
>
> For my dissertation I have decided to do something with COBOL. I have
> had to prove that this is still a relevant subject in todays IT world
> and that is now all done. The tiny piece of IT I have now decided to
> focus on is about rescuing old SCREEN SECTION based systems to add a
> GUI. Whilst this has been covered for lots of systems before and
> methods already established these seem to me to be more form based
> systems where it is easier to convert them (thats an assumption) There
> does not appear to be anything written about how to rescue these other
> type of systems where interaction with the screen is at quite an
> atomic level. For example, a piece of existing code may appears as
> follows (roughly, do NOT correct my code, you will be missing the
> point):
>
> A100.
>    DISPLAY SS-PRODUCT-CODE.
>    ACCEPT SS-PRODUCT-CODE.
>
>    MOVE WS-PRODUCT-CODE TO PROD-CODE.
>    READ PROD-FILE
>        INVALID KEY
>        DISPLAY "ERROR, PRODUCT NOT FOUND" AT 2401
>        GO TO A100.
>    DISPLAY SS-PROD-DESC.
>
> A110.
>    DISPLAY SS-QTY.
>    ACCEPT SS-QTY.
>
> The point here, is that the two ACCEPT statements are separate. There
> will be many instances where the interaction is not as simple as this
> example. The challenge is how do I convert this type of code to work
> with a GUI.

It is indeed a challenge. I went through this loop when converting a number
of COBOL programs with Screen Sections to the Windows 3.1 GUI many years
ago.

The first thing for a COBOL person to get their head around is that true GUI
processing is interrupt driven. It's a different model. In the normal
procedural model the COBOL programmer has total control and can decide WHEN
to initiate I/O; with a GUI, that isn't the case. The user clicks a button
or presses a key and the program MUST respond immediately. There have been
many attempts to simulate standard COBOL processing in this environment
(with varying degrees of success) but if the User Interface is to become
GUI, the COBOL response needs to be different from that used with Screen
Section.

Currently a Forms based approach is probably the most viable.  The Form is
displayed and the program dequeues (sleeps or continues other tasks), until
awoken by an interrupt. This is the basis of mainframe CICS processing and
Windows Forms processing on the PC.

Depending on the type of interrupt, a particular piece of code will be
executed (the process is switched to, or "vectored").

There is another consideration here as to whether full screen processing or
field-by-field processing will be used. Too much to go into here, but worth
bearing in mind when designing the user interface.

The point is that validation of input and display of corresponding output
occurs in a separate layer from the business logic. Only when the complete
form has been validated, should the business logic be activated. There are a
number of ways to achieve this but integrating the user interface with the
business logic (one program driving the lot, as is usual in COBOL) is not
one of them.

With CICS and IMS, a message buffer is presented to the business logic; with
Windows  and Web based Forms, each control or input field on the form
represents an object that can have its own validation methods. (For Web
based forms this is complicated further by the need for validation on the
server (if this is required), but that's much further away from COBOL Screen
Section.)  The important thing, as mentioned above, is the separation
between User Interaction and business logic. That typically doesn't happen
with programs that utilise a Screen Section in COBOL, so converting them is
a good opportunity to introduce it.

When I did my conversions I isolated all the Screen Section stuff into it's
own layer.  Fields were collected into a buffer as they were validated, and
the buffer  of valid data was presented to the Business layer as if it had
come from a Screen ACCEPT. (The business logic became a series of CALLable
modules which had the buffer as a common parameter.)

I was using MicroFocus DIALOG and PANELS at the time, so this allowed
validation in the interface layer, just as PowerCOBOL did later, and as
Windows and Web based Forms do today.


> So what I have decided to try and do is some sort of
> guidelines on how to convert this code to
> allow a call to some form of GUI.
>
> I am using ScreenIO for it but it could be anything.
>
> At first glance it seems that this should then be replace with a small
> form containing product code, description and a quantity.

Yes, the GUI allows fields to be grouped logically. It is good to
conceptually group stuff as this is more intuitive for the user and more
efficient for the Interface.

> Then the
> user would click an OK button and control returns to the program.

Ideally, you want the OK click to grab all the fields on the form, validate
any that require "back end" validation, then either call a business layer,
or re-present the form with error message(s). The object should be to
present ONLY valid data to the business layer.

>I
> think its a bit more complicated than that. What if I do not want to
> introduce too many changes to the actual keystrokes performed by the
> user? Do they really want to have to go and search for the mouse
> cursor when performing repetitive tasks like keying invoices, delivery
> notes, etc.

You can address this with Keyboard shortcuts. Every control that is mouse
clickable, should also have its own keyboard shortcut. It is also possible
to organise "workflow" on the form using the Tab key. This makes sure that
each field is entered in the order required for validation (if there are
field validation dependencies) and it doesn't require using the mouse. For
things like invoices, delivery notes, etc. you are absolutely right that the
mouse should be avoided. Group these input fields together and use Tab to
move backwards and forwards between them. (Autoskip can also help here).  It
is a popular misconception that a GUI interface REQUIRES a mouse; they can
be designed and written not to, depending on the application...(Even the OK
button can be activated by the keyboard; the mouse is simply an option.)
>
> My question is, Does anybody have any links to any interesting sites
> that may have already looked at this kind of thing? Has anybody been
> around this loop before?

I've been around this loop many times, but not for a decade or so... :-)

> All comments welcome.
>
> Many thanks
>

Some suggestions for your dissertation...

1. Recognise the importance of the interrupt driven (Object based), as
opposed to Procedural, models when dealing with User Interfaces.

2. Explore the "opportunities" ("challenges"? :-)) presented when converting
from a Screen Section integrated solution, to a layered one.

3. Identify and discuss the advantages and divantages of "Full Screen" vs
"Field-by-field" processing when using a GUI and a non-GUI approach.

4. Identify and discuss differences between User Interfaces on a centralised
mainframe, and a Client Server network. How does this affect validation in
the presentation layer? How does a web based forms solution deal with this?
What are the implications for users and for performance?

Just some ideas... :-)

Good Luck!

Pete.