Re: Cobol books & experiences

Judson McClendon wrote: 
"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote:

Let's have a little stir of the pot :-)

Judson (a) You promote Screen Section as being a proficient way of doing things, rather than gawdawful GUIs and OO, and secondly (b) Stick with the COBOL '85 Standard a la William Klein - i.e., program according to something that is now 21 years old.


I think Screen Section is a good way to do *some* things, and GUI is a good way to do *some* things. Neither are best for *everything*. There are thousands and thousands of clerks out there who sit day after day, keying in the same data screens, taking the data directly from customers or taxpayers. For the vast majority of those people, GUI and a mouse interface are a complete waste, even counterproductive. For those types of applications, character based interfaces are cheaper and quicker to write, consume less system resources, and are more robust. As long as this is the case, and it will be the case until someone comes up with a way to eliminate the clerk altogether (i.e. teller machines), removing the character based interface from COBOL would be a bad idea.


In accordance with COBOL '85 did you ignore ALL the M/F Screen Section extensions - 'cos without checking all/most only got sanctioned with COBOL 2002 ????


As I pointed out, I've been using Screen Section since the early 80's, when I started writing COBOL applications for the PC. I'm glad they *finally* included it in the standard :-)

In any case, I always target my systems to what the client wants/needs. If the text/GUI question comes up, I point out the pros and cons of each and do what the client wants. After all, it's their money. :-)

I think Heybub jumped in and answered it pretty well. Honestly, it's the first time I've seen you use the qualifier "Can be either Screen or GUIs" - I definitely had the impression you were staunchly Screen Section and used that as a selling point - you could do it cheaper. Like Heybub, without reiterating same points GUI approach can be just as effective and you can design to ignore the mouse - <ENTER> = your Default Button (PB-OK).

Now marginally only, Screen might be useful for a data-entry intensive application. Can you think of one. Your Kentucky (?) Licensing System - isn't that a come as you go person system.

Banking - there's a joint Clearing House here in Calgary for ALL Canadian banks operating in Alberta and parts of BC. Time-critical banks have to get paperwork to the Centre for an 18:00 hours start - must be transmitted back east to Toronto no later than 02:00 following morning.
The operation cheques - OK they've already got MICR coding at the bottom - the missing ink the dollar amount written by the customer - that they have to keypunch into MICR format so that the finals can go through an MICR reader prior to transmission to Toronto.

As of two years ago, as told to me by the former lady supervisor, because of plastic, direct debit - volumes are now only a THIRD of what they used to be. The problem OCR - Character Recognition - IBM hadn't got it licked 40 years ago. Yes there are some applications that use say OCR in preference to OMR, but on specially designed input forms blue boxes on white where you carefully write in the digits, ensuring say, the character "4" is centered in the box. But you can hardly do that with consumers who are writing cheques in random writing styles.

Even something as fairly straight-forward as Accounts Payable is now advantageously done with GUIs. Example Amoco has a particular play on a well site; to cover costs, they co-opt with Exxon, Mobil, Petro Canada or whoever. Contractually they figure out how to percentage share costs etc. As HeyBub said this can be covered by Dropdowns, Listboxes etc. Invariably as invoices come in they are looking for an AFE Number (Authorized for Expenditure) - probably you use the same term below the 49th. The AFE identity can bring up an already authorized set of Chart-of-Account numbers applicable for G/L allocation. Obviously the percentage splits occur i the background, and so on......

Now I know you could do this with Screen Section emulating the GUI approach - I did it myself with M/F Screen Section before getting involved in Windows using their CBL_ routines for chars and mouse. No doubt you still have copies of Admouse.cbl and Logper.cbl - never understood what the latter name is an acronym for - but that's the one which lets you jiggle the prime set of colours around, on the fly.

Still more flexible with GUIs. A little bit too colourful for my liking, but Kellie did a neat job using API calls in N/E. Similarly, ever looked at Michael M's medical system. BASIC of course - again APIs I think - but very elegant. What else would you expect from a master house decorator :-)

Jimmy
.