Home > Archive > Cobol > December 2005 > Cobol books & experiences
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cobol books & experiences
|
|
|
| LS,
I'm at the point of buying one or two books on COBOL development. I've
found lots of books on this language, and from the outline they all
seem interesting. Some of those are a bit older (from the mid '80s)
which tend to be a bit 'out-dated'. But as always, one book is better
than the other. So I'm interested in your view on books on COBOL. Which
topics are discussed? Does the author seem to be 'on top of things' or
just writing along?
The main topic of the books should be focused on 'modern' COBOL (not to
offend anyone: not focused on mainframe); on new tech like .NET,
webbased and object oriented programming. I work with NetCOBOL, but a
general, non-compiler specific book would be equally fine.
If we can structure this topic nicely it might be a good reference for
others interested in COBOL, so i'd like to propose an outline for
replies:
Title:
ISBN:
Author:
Publisher:
General topic:
General application: (e.g. client-server, .NET, ASP, etc.)
Your opinion: (of course, with arguments)
Kind regards,
Rik Hendriks
| |
| charles hottel 2005-11-19, 6:55 pm |
| For .NET
Title: COBOL and Visual Basic on .Net: A guide for the Reformed mainframe
Programmer
ISBN: 1-59059-048-1
Author: Chris Richardson
Publisher: Apress 2003
Title: Microsoft .NET for COBOL Programmers
ISBN:
Author: Howard E. Hinman
Publisher: Fujitsu 2003
Comments: I started on the first one but never finished because my mom died
and I had to settle her estate and I never got back to either one. My
motivation has been low because I know I will never spend the money required
for the compiler. I will not comment further because at the time I had sleep
apnea and my memory is a little fuzzy. The second title is really two CD's
with a small book that contains mostly an outline/bullet points.
For web programming:
Title:Elements of COBOL Web Programming with Micro Focus Net Express
ISBN: 0-9655945-1-3 (without Micro Focus Net Express University Edition)
ISBN: 0-9655945-2-1 (with Micro Focus Net Express University Edition)
Author: Wilson Price
Publisher: Object-Z 1999
Comments: I remember really enjoying this book a lot.
For Object Oriented COBOL:
Title: Elements of Object-Oriented COBOL
ISBN: 0-9655945-6-4 (without Micro Focus Net Express University Edition)
ISBN: 0-9655945-7-2 (with Micro Focus Net Express University Edition)
Publisher: Object-Z 2001
Comments: I learned a lot from this book but I remember having a hard time
following along at times. IIRC it seemed like some of the example code did
not quite match what the text was saying. I remember sending an errata sheet
to Mike Murach Inc. (the publisher that I bought it from) but now I cannot
seem to find it. In all fairness it could have just been me and my sleep
apnea. I do remember that if you are motivated and stick with it you can
eventually figure out and learn the concepts.
<top post no more follows>
"RH" <R.Hendriks@hotmail.com> wrote in message
news:1132391727.534963.214830@z14g2000cwz.googlegroups.com...
> LS,
>
> I'm at the point of buying one or two books on COBOL development. I've
> found lots of books on this language, and from the outline they all
> seem interesting. Some of those are a bit older (from the mid '80s)
> which tend to be a bit 'out-dated'. But as always, one book is better
> than the other. So I'm interested in your view on books on COBOL. Which
> topics are discussed? Does the author seem to be 'on top of things' or
> just writing along?
>
> The main topic of the books should be focused on 'modern' COBOL (not to
> offend anyone: not focused on mainframe); on new tech like .NET,
> webbased and object oriented programming. I work with NetCOBOL, but a
> general, non-compiler specific book would be equally fine.
>
> If we can structure this topic nicely it might be a good reference for
> others interested in COBOL, so i'd like to propose an outline for
> replies:
>
> Title:
> ISBN:
> Author:
> Publisher:
>
> General topic:
> General application: (e.g. client-server, .NET, ASP, etc.)
>
> Your opinion: (of course, with arguments)
>
>
>
> Kind regards,
>
> Rik Hendriks
>
| |
| Dan Nagle 2005-11-19, 6:55 pm |
| Hello,
Let me ask this the other way around,
I've recently bought
%T Teach Yourself Cobol in 24 Hours
%A Thane Hubbel
%P SAMS 1999
It has the Fujitsu Cobol v3 compiler.
Is this a good way to proceed?
Is the compiler "close to standard"
(obviously, not 04 standard :-( )
TIA
charles hottel wrote:
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| James J. Gavan 2005-11-19, 6:55 pm |
| Charles hotel wrote:
Rik and Dan,
Let me use the response from Charles as a template to reply against -
good references.
Now neither of you indicate whether or not you are newbies to COBOL.
Assuming you are, then it wouldn't hurt to go 'backwards' and pick up
copies of older texts which specifically are titled 'Structured
Programming" - one author I can think of is Dan McCracken. It's likely
he is up-to-date for COBOL 85.
Dan asked about Thane Hubbell's "Teach Yourself COBOL in 24 Hours". Good
choice - not that I'm interested in Procedural code as such, but unless
somebody can suggest a later book - still # 1 for me in the 'starter'
category. Thane's book contains CD with early version of Fujitsu and
reference to Flexs SP2 which he uses for GUI-ing. No OO in this book.
I'm going to switch Charles's text around a bit to put it in sequence :-
> For .NET
>
> Title: COBOL and Visual Basic on .Net: A guide for the Reformed mainframe
> Programmer
> ISBN: 1-59059-048-1
> Author: Chris Richardson
> Publisher: Apress 2003
>
> Title: Microsoft .NET for COBOL Programmers
> ISBN:
> Author: Howard E. Hinman
> Publisher: Fujitsu 2003
>
> Comments: I started on the first one but never finished because my mom died
> and I had to settle her estate and I never got back to either one. My
> motivation has been low because I know I will never spend the money required
> for the compiler. I will not comment further because at the time I had sleep
> apnea and my memory is a little fuzzy. The second title is really two CD's
> with a small book that contains mostly an outline/bullet points.
Didn't know about above, but from titles, geared to PCs ? The emphasis
with the second book is of course in using Fujitsu's approach to dotNet
with their compiler.
Before we move on to the Wilson Price books, and from here on in we are
talking OO and Micro Focus.
*>---------------------------------------------------------------------
Title: Object Oriented COBOL
ISBN : SIGS Books 1-884842-34-8 and Prentice Hall 0-13-261140-6
Author : Edmund C. Arrange & Frank Coyle
Publisher : SIGS Books & Multi Media
Comments : Surprisingly using the ISBNs you wont get the correct
reference! ( came up with an entirely different book using one of those
or both ISBNs for a search). You can only get second-hand copies, if
there are any still available. Ignore the ISBNs and do a search on
"Edmund Arrange" in amazon.com.
My starting point and would never have got a hang on OO COBOL without
this. Text develops concepts and an appendix has a very simple and clear
example of OO for an in-house company library. Avoids file handling by
using Working-Storage Tables and GUI-ing using simple ANSI displays.
(Tried to get a diskette containing that Appendix source. Had lost Ed's
e-mail but picked up on Frank. Reply "Don't know where you would get it;
glad book was useful to you, Ed and I have moved on from COBOL...."
*>-----------------------------------------------------------------------
Now to Will Price - a trio in sequence
*>-------------------------
For Object Oriented COBOL:
Title: Elements of Object-Oriented COBOL
ISBN: 0-9655945-6-4 (without Micro Focus Net Express University Edition)
ISBN: 0-9655945-7-2 (with Micro Focus Net Express University Edition)
Publisher: Object-Z 2001
Comments: I learned a lot from this book but I remember having a hard
time following along at times. IIRC it seemed like some of the example
code did not quite match what the text was saying. I remember sending
an errata sheet to Mike Murach Inc. (the publisher that I bought it
from) but now I cannot seem to find it. In all fairness it could have
just been me and my sleep apnea. I do remember that if you are motivated
and stick with it you can eventually figure out and learn the concepts.
*>----------------------------------------------------------------------
Charles's reference above. It is an excellent text, with a tremendous
number of tips and pointers; numerous ones added in the Second Edition.
However, Arranga/Coyle took the traditional approach developing themes
and adding to them. Not that Will's book doesn't do the same, but having
been a tutor at universities many years, presents material as separate
modules - his preferred style as he himself has said. He builds on a
fictitious company renting out rooms for education/training purposes. I
found it a little difficult to follow his references to RoomDriver1,
then later RoomDriver2 etc. - difficult to explain - but nevertheless an
excellent text.
As to Charles's comments about contacting Murtach - that wouldn't do any
good. Originally Will had the books privately printed, then presumably
passed over the residual stock for Murtach to sell. Will has moved on a
bit, somewhat disappointed at the lack of interest by COBOL users.
Hardly likely, to oblige somebody like Charles, that he is going to
produce a Third Edition.
***** Charles - Donald, Pete Dashwood, Thane and I have copies, so if
***** there are any points you want to clarify - sing out.
*>-----------------------------------------------
> For web programming:
>
> Title:Elements of COBOL Web Programming with Micro Focus Net Express
> ISBN: 0-9655945-1-3 (without Micro Focus Net Express University Edition)
> ISBN: 0-9655945-2-1 (with Micro Focus Net Express University Edition)
> Author: Wilson Price
> Publisher: Object-Z 1999
> Comments: I remember really enjoying this book a lot.
>
The title is a little deceptive - primarily about Web using the Micro
Focus 'Forms' module, a pull down from the IDE. But thrown in for good
measure, (and already having been advised to go from COBOL files to
(R)DBMS) - some good simple stuff on SQL Statements, and which made me
look closer at the Micro Focus IDE where they have ESQL Assistant - to
the complete novice to SQL, an absolute dream. Figure out your table in
the appropriate Database and use the ESQL Assistant to generate your SQL
statements - then just copy/paste into your COBOL source.
*>----------------------------------------------------------------------
For dotNet :
Title: COBOL and .Net
ISBN: 0-9655945-8-0
Author: Wilson Price and Wayne Rippin (ex-Micro Focus employee and a
university instructor in UK, Nottingham or Manchester ???)
Publisher: Micro Focus
On-Line Ordering : www.microfocus/com/shopr - e-mail academic@microfocus.com
Comments: I have a copy which Micro Focus sent if you indicated you
would like it, when they were promoting their dotNet. Only had a casual
read and see that Will uses Visual Basic as the 'other language' plus of
course reference to Visual Studio. Looks good, but I have no immediate
need to 'talk' to other languages.
*>------------------------------------------------------------------------
Well, before you get all wound up that's not the whole story. Check
messages here where Bill Klein posts on the "COBOL FAQ" - as Bill writes
not updated for quite a while, but fairly accurate. References to
complers available, other useful COBOL sites etc.
If starting completely from scratch, go with Thane's book.
PROCEDURAL COBOL : check Bill's FAQ - Acu COBOL, HP/Compaq,
Liant(RM/COBOL), Relia etc. don't have OO but use other tools for GUI-ing.
OBJECT ORIENTATION : only three compilers -
Mainframe :-
IBM Enterprise - has the ability to handle bare bones creation of OO
Classes but any COBOL Class inherits form JavaBase. Java controls
creation of objects and is also responsible for destroying them - auto
garbage collection. Plus it's Java you use for collections/dictionaries,
(variable length lists) and GUI-ing
Fujitsu-Siemens in Germany - has or is developing an OO-oriented compiler.
PCs : just the two for OO
Fujitsu and Micro Focus; both have in-built GUIs particular to their
compiler - note GUIs are not part of the COBOL standard and highly
unlikely they will ever be - so you can use in-built GUIs or dotNet or
other vendors GUI products.
Both also have collections/dictionaries, again different in style, but
ahead of the COBOL standard which is due for release 2006-2008.
COSTS :
Well nothing is free. Take the whole gambit of PC compilers. I don't
know prices but both Fujitsu and Micro Focus are around $3,000-3,500.
(KOBOL - check Bill's FAQ - about $100). I believe they both now come
with cheaper tutorial editions, but there's a lock so that you don't try
to market using your cheapie tutorial - not unreasonable. Hang on until
spring/summer of next year and you can get the M/F University Edition of
Net Express V 5.0 for around $100 - includes dotNet.
RUNTIMES : i.e. you pay the vendor a royalty each time you distribute,
selling a copy of the software you have produced.
- Fujitsu - none
- Micro Focus - yes.
Firstly what's your intended career path - to join a small to medium
sized software house having come up to snuff on COBOL ? Want to go it
alone, or perhaps some years after having cut your teeth at somebody
else's expense, branch out and do your own thing with a buddy ? This is
only relevant if YOU are picking up the tab.
How much do you want to charge for your software ?. Now ask Micro Focus
before figuring out what you want to do, how much they are going to want
as royalties and when. Good luck !!!!
DOT NET ;
You understand the grand design, Microsoft providing the ability to
communicate between different languages. Of course MS provide some of
the components like Visual Basic, #C and Visual Studio, all dedicated to
using one operating system - Windows. Their products, so Visual Basic
and #C are no doubt tightly interwoven to the background API calls -
very probably you never have to directly code APIs.
My own personal gut feeling - Fujitsu and Micro Focus have made a
blooper getting involved. Firstly, Fujitsu produced their dotNet; to
stay competitive against them Micro Focus introduced their dotNet.
I pick up some possibles reading between the lines of messages in the
Micro Focus Forum.
(a) "I'm using Visual Basic and want to return.... to COBOL.... how do I
do this ?", or vice versa. So why is he using COBOL - because he likes
it as a mechanism to do his Business coding, plus he likes the COBOL
file system. So we'll assume he's using Visual Basic in dotNet for
preference as his GUI-tool. Suppose he latches on to the advantages of
using SQL in preference to the COBOL file system. ADO.Net is already
available as part of the dotNet family. Little while later, says to
himself, "Wait a minute, I'm using dotNet for GUI-ing, ADO.Net for my
database - why do I need to keep hopping backwards and forwards between
dotNet and COBOL". Perhaps....., "Bye, bye COBOL".
(b) Somebody very adept at OO and GUI-ing in Micro Focus. As of May this
year :-
"I find the class inheritance tree asscociation quite useful. I use it
all the time under Visual Studio. I don't tend to do much new
development under Net Express".
Haven't heard from him since but I would like clarification on WHAT HE
IS DOING in Net Express.
Same possibilities with the Fujitsu product.
*>---------------------------------------------------------------------
It's your career - research as carefully as you can and come back here
asking more, and more, and more questions.
Jimmy, Calgary AB
| |
| James J. Gavan 2005-11-19, 9:55 pm |
| James J. Gavan wrote:
> Charles hotel wrote:
>
> Rik and Dan,
There was a typo in my previous - it should read Edmund ARRANGA, not
'Arrange', just in case you go searching amazon.com
Well there were a few other typos - but it's the one above which could
have thrown you.
Jimmy
| |
|
| In article <2112a$437f4c80$4f9c6a8$13616@DIALUPUSA.NET>,
charles hottel <jghottel@yahoo.com> wrote:
[snip]
>For web programming:
>
>Title:Elements of COBOL Web Programming with Micro Focus Net Express
>ISBN: 0-9655945-1-3 (without Micro Focus Net Express University Edition)
>ISBN: 0-9655945-2-1 (with Micro Focus Net Express University Edition)
>Author: Wilson Price
>Publisher: Object-Z 1999
>Comments: I remember really enjoying this book a lot.
Wow... this sounds like some of the Book Reports I tried to get away with
lo, those many years ago!
DD
| |
|
| Everyone thanks for the replies!
James,
I've been working with Fujitsu NetCOBOL for some years now, ain't no
newbie anymore. The COBOL language is clear and easy to learn and
understand, and NetCOBOL is easy to use. Now I'm at the point of
stepping up. I have experience with OO (in Java, ** no ..positive..
comment on that language **) and want to read more about the way in
which others have combined COBOL with OO. Also, Web developing is
becoming more intresesting and with to see how COBOL is used in a web
environment. That's in short my background and why I posed this topic
here. PS. I'm fully PC/x86 oriented. Mainframes are not in the picture
for me.
With regard to your statement on Fujitsu jumping on the .NET bandwagon.
You feel it's a mistake, I don't agree. Surely the introduction of .NET
(especially the new 2.0) will reduce COBOL development. New languages
like C# close the gaps that C++ created years ago. Look at the new
Express editions of VS2005; anyone can created **some sort of**
application (it doesn't make them professionals just like that). But
for the greater part this will be development of new applications, new
systems etc. With creating a COBOL 'extension' of the MIL one can still
use COBOL as the language to develop applications, and for instance you
can still use indexed files for data storage. With the reduced number
of new COBOL developers it's a good thing you can hook up your COBOL
application to a C# application. In earlier years a company had to
choose 1 language; now a company can combine many 'thanks' to Microsoft
and .NET.
When you look at legacy (mainframe) systems, they will need some sort
of rewriting sometime in the future. Companies will have to choose:
scale up to COBOL for .NET of rewrite the whole thing in another
language. If the first option wouldn't be available what would they
choose? I've seen a big company use Fujitsu NetCOBOL to rewrite
mainframe COBOL systems allowing them to connect it to their Windows
enviroment.
I think that when you isolate COBOL, it will have a less chance of
surviving than when you allow it to go along with new technologies. I
also think that COBOL as a language will stay interesting enough, and
powerful enough to stay with us for many many years.
| |
| charles hottel 2005-11-20, 6:55 pm |
| Dang it! Dang you for mentioning a book that I have not heard about! :-)
Well I did not buy it but I got to searching for books and bought 3 more
Java books.
<snip>
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:SNPff.538553$1i.244696@pd7tw2no...
> *>----------------------------------------------------------------------
>
> For dotNet :
>
> Title: COBOL and .Net
> ISBN: 0-9655945-8-0
> Author: Wilson Price and Wayne Rippin (ex-Micro Focus employee and a
> university instructor in UK, Nottingham or Manchester ???)
> Publisher: Micro Focus
> On-Line Ordering : www.microfocus/com/shopr - e-mail
> academic@microfocus.com
> Comments: I have a copy which Micro Focus sent if you indicated you would
> like it, when they were promoting their dotNet. Only had a casual read and
> see that Will uses Visual Basic as the 'other language' plus of course
> reference to Visual Studio. Looks good, but I have no immediate need to
> 'talk' to other languages.
>
> *>------------------------------------------------------------------------
<snip>
| |
| James J. Gavan 2005-11-21, 6:55 pm |
| RH wrote:
> Everyone thanks for the replies!
>
> James, <snip>
Don't disagree with what you wrote and was being purely speculative as
to what could occur - i.e. *perhaps* a preference for dotNet tools as
opposed to COBOL. The other side of the coin, non-COBOL users *could*
become interested in COBOL because of its availability through dotNet -
although I think the price of COBOL would be a deterrent.
Before I respond further now that I know you are not a newbie, fill in
some blanks :-
- have you yet used OO in Fujitsu - i.e. ignoring the dotNet feature and
specifically for what.
- Fujitsu dotNet - just cutting your teeth, or already actively using.
Which features of dotNet are you using. Other languages and out of
curiosity any additional costs involved to complete your own design
environment.
Part of your template answer was "Experience". Was that the usefulness
of the particular book or are you looking more for background on how
COBOL users have approached design using OO COBOL. At this time there
are three of us who have done it, but each in a slightly different
approach, Donald (F/J), Pete Dashwood (F/J), but as his interest is
primarily 'Components' I think he has moved to Java, and of course yours
truly using M/F (Net Express).
Now I'm not remotely suggesting the above three names are hot-shots,
just brave folks who have from time-to-time, stuck their necks out to
explain what they are doing :-). Obviously other 'success' stories
around, but with a new concept a modest reluctance to spell out what
they are doing. Lots of folks 'indirectly' (GUI design), and a minority
'directly' use OO, from messages in the M/F Forum. I just don't think
there is a F/J equivalent - is there ?
Jimmy
| |
| Dan Nagle 2005-11-21, 6:55 pm |
| Hello,
Thanks to all who replied.
I am a newbie with Cobol.
I take it that there's a marked divide between
pre 2004 Cobol and post 2004 ? Specifically OO stuff?
I'm happy to learn the basics first. I'm not overly
enthused by .Net, too many eternal standards du jour.
But eventually, learning the OO stuff is part
of the plan.
James J. Gavan wrote:
<snip>
I'll try this one after I get the procedural stuff learned.
> *>---------------------------------------------------------------------
> Title: Object Oriented COBOL
> ISBN : SIGS Books 1-884842-34-8 and Prentice Hall 0-13-261140-6
> Author : Edmund C. Arrange & Frank Coyle
> Publisher : SIGS Books & Multi Media
> Comments : Surprisingly using the ISBNs you wont get the correct
> reference! ( came up with an entirely different book using one of those
> or both ISBNs for a search). You can only get second-hand copies, if
> there are any still available. Ignore the ISBNs and do a search on
> "Edmund Arrange" in amazon.com.
>
> My starting point and would never have got a hang on OO COBOL without
> this. Text develops concepts and an appendix has a very simple and clear
> example of OO for an in-house company library. Avoids file handling by
> using Working-Storage Tables and GUI-ing using simple ANSI displays.
> (Tried to get a diskette containing that Appendix source. Had lost Ed's
> e-mail but picked up on Frank. Reply "Don't know where you would get it;
> glad book was useful to you, Ed and I have moved on from COBOL...."
>
> *>-----------------------------------------------------------------------
<snip a bunch>
> It's your career - research as carefully as you can and come back here
> asking more, and more, and more questions.
Thanks, I've been lurking a while. Sounds like
a nice friendly newsgroup, with an occasional rant. :-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Chuck Stevens 2005-11-21, 6:55 pm |
| "Dan Nagle" <dannagle@verizon.net> wrote in message
news:Htqgf.449$F%3.49@trnddc05...
> I take it that there's a marked divide between
> pre 2004 Cobol and post 2004 ? Specifically OO stuff?
Actually, it's 2002, at least as far as the standards are concerned.
ISO/IEC 1989:2002 was published December 1 of that year and is the standard
currently "in force" for the COBOL language.
Some vendors provided some OO features reflecting drafts of that standard
before then (I believe Hitachi, Fujitsu, Unisys 1100 series, M/F and IBM
offerings fall into that category; Committee Draft 1.4 from June 1998 seems
to have been a particularly popular base for these features), but in any
event because the features weren't yet officially standardized they were
technically implementor-defined extensions to the then-current standard.
The US standard in force at that point was ANSI X3.23-1985, also released as
the international standard ISO 1989-1985. Two amendments came out
afterward: the Intrinsic Function amendment of 1989 and the Corrections
amendment of 1993. The biggie for '85, as I see it, was the nested program
feature, and as amended, a group of useful intrinsic functions.
Before that came ANSI X3.23-1974 (which added inter-program communications
and indexed and relative I/O) and before that, ANSI X3.23-1968 (also known
as "first standard COBOL", but actually a development of earlier efforts
starting with Grace Hopper and CODASYL in 1959).
Trivia note: The 2002 COBOL standard was built first as an International
Standard and then adopted as a US standard as a consequence of international
approval; previous COBOL standards were US standards first.
-Chuck Stevens
| |
| James J. Gavan 2005-11-21, 6:55 pm |
| Dan Nagle wrote:
> Hello,
>
> Thanks to all who replied.
>
> I am a newbie with Cobol.
Dan,
For you, without question, start with Thane's "Teach Yourself COBOL in
24 Hours". You can supplement with other books later if you wish.
>
> I take it that there's a marked divide between
> pre 2004 Cobol and post 2004 ? Specifically OO stuff?
Correction it is COBOL 2002; the next one likely to be COBOL 2008. Back
in early 90s the OCTG (Object COBOL Technology Group), a sub-committee
of J4 (the ANSI (American) COBOL Standards Committee), discussed OO
COBOL and Raymond Obin produced a paperback printed by Micro Focus.
Interesting, but you don't need it now. With a few refinements current
OO COBOL is close to that original book.
The first OO compilers were IBM's Visual Age for the OS2 Operating
System (IBM's own) along with Micro Focus (for Windoze) and Hitachi,
(for ????); the latter only useful if you speak or can read Japanese
;-). Not sure about Visual Age, but taking the basis of the OCTG design,
and looking at Smalltalk for how they handled collections and GUIs, both
Micro Focus and Hitachi produced their own version to handle those
specific features.
A little later, Fujitsu jumped in on the act. J4 having further refined
the OO specification, the F/J approach was closer to the eventual
specification - COBOL 2002. So my M/F compiler at the top of a
program/class has :-
Class-id. MyClass inherits from Base.
Class-Control. Editcustomers is class "edtcust"
CustomerDialog is class :dlgcust"
| |
| William M. Klein 2005-11-21, 9:55 pm |
| What Chuck is talking about is the "divide" in the Standard.
Personally, in the "real world" I see a more significant divide between
"mainframe" and "workstation" COBOL applications.
The former (tend to be) more "conservative" (see another post from Chuck on
Unisys and their '74 Standard compiler) . For mainframe applications, there
is USUALLY some "user-interface" code that is language independent. (For
example, IMS and CICS on IBM - but most other mainframes have comparable
features. I remember DEC had their FIMS product.)
For workstation COBOL products, having an OO feature - as well as C, C++,
and Java interoperability is much more important. Therefore, the compilers
either have add-on products (separate like sp2 or COBOL-vendor provided like
Fujitsu PowerCOBOL and Micro Focus Dialog systems). As MOST such
applications need to interface with Java and/or C++ (or possibly .NET),
having built-in OO functionality to the COBOL is more important.
This note is a GROSS generalization and there are many, MANY exceptions on
both the mainframe and the workstation side (and there are some fairly
significant differences between the Unix/Linux COBOL world and the Windows
world - on the workstation side). However, I thought this MIGHT be of some
relevance to the thread
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dltf02$12dg$1@si05.rsvl.unisys.com...
> "Dan Nagle" <dannagle@verizon.net> wrote in message
> news:Htqgf.449$F%3.49@trnddc05...
>
>
> Actually, it's 2002, at least as far as the standards are concerned.
> ISO/IEC 1989:2002 was published December 1 of that year and is the
> standard currently "in force" for the COBOL language.
>
> Some vendors provided some OO features reflecting drafts of that standard
> before then (I believe Hitachi, Fujitsu, Unisys 1100 series, M/F and IBM
> offerings fall into that category; Committee Draft 1.4 from June 1998
> seems to have been a particularly popular base for these features), but in
> any event because the features weren't yet officially standardized they
> were technically implementor-defined extensions to the then-current
> standard.
>
> The US standard in force at that point was ANSI X3.23-1985, also released
> as the international standard ISO 1989-1985. Two amendments came out
> afterward: the Intrinsic Function amendment of 1989 and the Corrections
> amendment of 1993. The biggie for '85, as I see it, was the nested
> program feature, and as amended, a group of useful intrinsic functions.
>
> Before that came ANSI X3.23-1974 (which added inter-program communications
> and indexed and relative I/O) and before that, ANSI X3.23-1968 (also known
> as "first standard COBOL", but actually a development of earlier efforts
> starting with Grace Hopper and CODASYL in 1959).
>
> Trivia note: The 2002 COBOL standard was built first as an International
> Standard and then adopted as a US standard as a consequence of
> international approval; previous COBOL standards were US standards first.
>
> -Chuck Stevens
>
| |
| Dan Nagle 2005-11-21, 9:55 pm |
| Hello,
James J. Gavan wrote:
> Dan Nagle wrote:
<snip>
>
>
> No you don't ! Buy it now, even if you don't currently read it. Same
> goes for Charles and Ron. No longer published, but about 21 copies at
> amazon - second-hand $23. Those copies are not going to hang around for
> ever. Amazon have cluttered their Home Page with all sorts of junk, as
> they no longer solely sell books - hadn't been there for some time.
> Easiest way, which is what I did before writing this - the first Search
> box you see at the top, enter 'Edmund ArrangA' and takes you straight to
> the book.
OK, Amazon claims it's on it way.
<snip>
>
>
> Well you should enjoy it. Obviously you have a sense of humour.
I try to keep informed with the standards stuff,
IIRC, I've met someone from the Cobol committee at INCITS.
A sense of humor is a necessary defense.
At my last Officer Training at INCITS, I had just concluded it was the
most meaningless morning of my life when there was a fire drill. :-)
Thanks for the hints, and all the history of the standards.
(In this and other posts.)
There's so many Cobol standards, the ANSI webstore
is a bit confusing.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Chuck Stevens 2005-11-21, 9:55 pm |
|
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:Sjsgf.565096$1i.549327@pd7tw2no...
> The first OO compilers were ... and Hitachi, (for ????); the latter only
> useful if you speak or can read Japanese ;-).
Depends on where you're getting your documentation from! OOCOBOL for the
Unisys 2200 system line was developed in cooperation with Hitachi. Get a
manual (in English) for that product, and I'm pretty sure you've got
documentation for the guts of Hitachi's implementation.
> Meanwhile J4 has a TR(Technical Report) for Collections/Dictionaries,
> which supplements the COBOL 2002 Standard. They've made it a TR so that it
> can be slipped in as quickly a possible to get around the bureaucracy that
> is part of ANSI.
It's not so much the ANSI processes that take the time and energy ...
> The whole thing has such a formalized approach before anything gets an
> imprimatur. (Same applies to ISO (International Standards Organization)).
.... as it is the international review and balloting procedures for each
interested national body that result in its adoption as an ISO/IEC TR or
Standard that take the time. At this point, by law, the US adopts
*international* standards, not vice versa. The 2002 standard is ISO/IEC
1989:2002, it's not a US standard ANSI X3.23-2002 that ISO subsequently
adopted (as ISO 1989-1985 was).
> Our friend Chuck is an American on J4 representing Unisys - but they are
> quite amenable - you don't have to be a Yank :-).
> From something Bill Klein wrote, Chuck will be heading up the COBOL ISO
> team.
Yes, alas, I'm now the "convener" of ISO/IEC JTC1/SC22/WG4 (as well as the
secretary of INCITS/J4), effective at the end of the SC22 Plenary at the
beginning of October. Somebody's gotta do it. Don Schricker of MF has
stepped down from the WG4 convenership after a three-year term Both Don and
his predecessor as convener Ann Bennet of IBM continue active in both J4 and
as US delegates to WG4, and Don continues as chair of J4.
> Clear as mud - search COBOL PORTAL part of the M/F site and if interested
> you can gt a handle on how the ANSI J4 and ISO (used to be called WG4)
> work; so they kind of work hand in glove. J4 does the donkey work on
> behalf of the American ANSI and ISO gives the final blessing for the
> World.
WG4 isn't gone; it's a Working Group within ISO.
The full acronym is ISO/IEC JTC1/SC22/WG4. Its parts are ISO =
"International Standards Organization", IEC = "International
Electrotechnical Commission", JTC1 = "Joint Technical Committee 1", SC22 =
"Subcommittee 22" (which deals with "Programming languages, their
environments and system software interfaces", and WG4 = "Working Group 4"
(which deals with COBOL, alongside WG3 for APL, WG5 for FORTRAN, WG9 for
ADA, WG11 for Binding Techniques, WG14 for C, WG16 for ISLisp, WG17 for
Prolog, WG19 for Formal Specification Languages [like BNF], and WG21 for
C++).
ISO/IEC JTC1/SC22/WG4 ("WG4" for short) tells INCITS/J4 ("J4" for short)
what feature content they want, and INCITS/J4 is responsible for following
their overall direction in producing the standard. WG4 is also responsible
for presenting the drafts for international review. It's the National
Standards Bodies (like ANSI, DIN, BSI, ITSCJ, etc.) with the "advise and
consent" processes that they have with *their* COBOL interest groups that
have the real vote on whether a draft standard or draft TR as a whole
ultimately gets "blessed" or not. Usually the National Bodies follow the
advice of their COBOL specialists as a practical matter, but whether they do
or not is subject to the rules of the individual National Bodies.
Thus, here's a summary of the way I see it happening (there may be errors in
the details; I'm painting with a very broad brush here): WG4 tells J4 what
they want, J4 goes off and does it, ships the draft to WG4 who submits it
for international review; comments come in from national bodies, WG4
forwards the comments to J4, who responds to them and sends the responses
back to WG4 for review. That cycle continues until WG4 is happy that the
draft is ready for its final review, which is subjected to a final "yes/no"
vote with no comments allowed. If that passes, it becomes an approved
document.
There's a whole 'nother subset of that which deals with INCITS/J4 processing
of technical documents that go into the production of the draft standard (or
technical report), but by comparison that process is much less formal and
(most of the time) handled with more alacrity.
-Chuck Stevens
| |
| James J. Gavan 2005-11-21, 9:55 pm |
| Chuck Stevens wrote:
> "Dan Nagle" <dannagle@verizon.net> wrote in message
> news:Htqgf.449$F%3.49@trnddc05...
>
>
>
> The US standard in force at that point was ANSI X3.23-1985, also released as
> the international standard ISO 1989-1985. Two amendments came out
> afterward: the Intrinsic Function amendment of 1989 and the Corrections
> amendment of 1993. The biggie for '85, as I see it, was the nested program
> feature, and as amended, a group of useful intrinsic functions.
>
Been so long away from Procedural COBOL I had forgotten about nested
programs - can't recall if I ever used them with M/F's DOS Version. I
recall a comment from Will Price where he was surprised COBOL users
didn't jump up and down with joy at new goodies, from '85 onwards.
My list of pluses -
- Lower/Uppercase for source
- the floating comments *> here it is *> here's the next one
- Intrinsic functions - don't use all the mathematical ones. Would have
loved Square Root way back in the dark days using RM/COBOL ('74)
- END terminator - you can do it without, but tricky with IFs if you
have a preference for code indentation. I've very rarely seen it but you
can have end-invoke - but never seen a need to use it in that context.
- in-line PERFORMS of course
- BIG TIME - the EVALUATE
And for the Luddite called Judson McClendon - correction the 'heretic'
- couldn't believe it where he dismissed Decision Tables as
'ancy-fancy'. No I don't generate code from Decision Tables as Richard
has suggested can be done. But I get my thoughts clear with simple
Decision Tables and then code EVALUATES based on those - so simple -
True or False and absolutely no 'maybes' - and the conditions that don't
just apply, Action = Not Applicable and doesn't go into my source code.
Jimmy
| |
| Chuck Stevens 2005-11-21, 9:55 pm |
| "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:%xtgf.569775$tl2.232439@pd7tw3no...
> Would have loved Square Root way back in the dark days using RM/COBOL
> ('74)
Ummmm ... I'm having some difficulty understanding how, aside possibly (and
only possibly) from performance, the results of
COMPUTE X = FUNCTION SQRT (Y) ...
would be all that different from what I would get from
COMPUTE X = Y ** 0.5 ...
In fact, if the logic uses a numeric literal, as here, I'm at somewhat of a
loss to see why an implementation wouldn't choose to generate identical code
for both ... That's not a terribly arcane optimization ...
Are you suggesting that your RM/COBOL ('74) didn't allow ** as an arithmetic
operator?
-Chuck Stevens
| |
| James J. Gavan 2005-11-21, 9:55 pm |
| Dan Nagle wrote:
>
> OK, Amazon claims it's on it way.
>
> <snip>
>
>
> I try to keep informed with the standards stuff,
> IIRC, I've met someone from the Cobol committee at INCITS.
> A sense of humor is a necessary defense.
>
> At my last Officer Training at INCITS, I had just concluded it was the
> most meaningless morning of my life when there was a fire drill. :-)
Oh how I loved that :-). Because I kept chirpping about OO some years
back, one independent member Stephen Spiro couldn't attend the J4 at
Newbury in 2000, Bill Klein jumped in, 'Here's your chance Jimmy,
substitute for Stephen". Attractive idea, first time back to UK since
'75, see some of the Micro Focus folks at Newbury whom you e-mail and
natch, an English vacation back to Somerset and see my favourite female
cousin up in the Lake District, Cumbria - extreme N.W., just below
Scottish Border. Right near the Roman Hadrian's Wall which she never
took me to see !!!!!
As a Systems Manager I have had more than any body's fair share of
committee meetings. I speculated in advance to Bill - Somewhat like the
local Town Council ? An agenda full of meaningless references to an
outsider. Up each item comes, perhaps a minor discussion and a show of
hands. He's devoted to COBOL, name is Wim E....... from the Netherlands;
retired now. As Chuck pointed out he was honoured by the Dutch
government for his efforts. But to see him expound on the meaningfulness
of a space in a particular piece of syntax - Gimmie a Break !
Useless with cameras but I took one with me. Knowing I was going, Ed
Arranga, he used to head up the now defunct (?) COBOL Report.com.,
suggested I do an article and take some photos. (Will Price and Ed were
partners in COBOL Report at the time). Firstly I was there in 'Third
World' mode - they all had laptops, except Bill Klein, to look up
references. I had zilch.
I came away thinking this is as exciting as watching a rice pudding come
to the boil. Never took any photos and never wrote the article. Just not
my scene. (I could have BS'd and produced the article for a few bucks -
but seemed to me sheer dishonesty).
> Thanks for the hints, and all the history of the standards.
> (In this and other posts.)
> There's so many Cobol standards, the ANSI webstore
> is a bit confusing.
I don't know what you are reading - there is a ONE and ONLY COBOL
Standard - gets initiated by J4 then passed to ISO (WG4) and becomes the
ISO COBOL 2002 - as Chuck explained in a more technical vein.
Jimmy
| |
| James J. Gavan 2005-11-21, 9:55 pm |
| Chuck Stevens wrote:
>
Eileen and I are always saying to our doctors, when we need to meet
them, "Could you please say that for me in English". Your next for me
says it very nicely.
> Thus, here's a summary of the way I see it happening (there may be errors in
> the details; I'm painting with a very broad brush here): WG4 tells J4 what
> they want, J4 goes off and does it, ships the draft to WG4 who submits it
> for international review; comments come in from national bodies, WG4
> forwards the comments to J4, who responds to them and sends the responses
> back to WG4 for review. That cycle continues until WG4 is happy that the
> draft is ready for its final review, which is subjected to a final "yes/no"
> vote with no comments allowed. If that passes, it becomes an approved
> document.
>
> There's a whole 'nother subset .....
Furgetit ! I'll stick with your translation above. You do it better than
Babelfish :-)
Jimmy
| |
| James J. Gavan 2005-11-21, 9:55 pm |
| Chuck Stevens wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:%xtgf.569775$tl2.232439@pd7tw3no...
>
>
>
>
> Ummmm ... I'm having some difficulty understanding how, aside possibly (and
> only possibly) from performance, the results of
> COMPUTE X = FUNCTION SQRT (Y) ...
>
> would be all that different from what I would get from
> COMPUTE X = Y ** 0.5 ...
>
> In fact, if the logic uses a numeric literal, as here, I'm at somewhat of a
> loss to see why an implementation wouldn't choose to generate identical code
> for both ... That's not a terribly arcane optimization ...
>
> Are you suggesting that your RM/COBOL ('74) didn't allow ** as an arithmetic
> operator?
>
> -Chuck Stevens
>
All right for you me Boyo, probably starting with a background of
programming and if like me you were mathematically challenged, could
always lean over the desk and ask the next guy. Next guy to me - I'm
CEO, chief cook and bottle washer.
Only came up once - asked the particular company's Chief Accountant.
They should *know* shouldn't they - after all they have initials after
their names. Well like me he struggled to try and remember how he
learned at school, and a couple of decades between us. Never do recall
out it got resolved.
No not suggesting anything about RM - it would have been '74 compliant.
Exponentiation the ** - meaningless to me at the time and never had need
for it since, unless I've 'missed' a goodie somewhere.
Now mere 'youth' at 61, go off and do penance !
Jimmy
| |
| Dan Nagle 2005-11-21, 9:55 pm |
| Hello,
James J. Gavan wrote:
> Dan Nagle wrote:
<snip a bunch>
>
>
> I don't know what you are reading - there is a ONE and ONLY COBOL
> Standard - gets initiated by J4 then passed to ISO (WG4) and becomes the
> ISO COBOL 2002 - as Chuck explained in a more technical vein.
OK, there's a standard, with INCITS, DIN, and ISO/IEC numbers.
Then there's a corrigendum and a function module, also three numbers.
So that's 3 times 3 entries.
I know enough to buy the $18 ones, not the $192 ones.
I suppose I want one standard, one corrigendum and one function module.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Donald Tees 2005-11-21, 9:55 pm |
| James J. Gavan wrote:
> Dan Nagle wrote:
> World' mode - they all had laptops, except Bill Klein, to look up
> references. I had zilch.
>
I expect that was because Bill knew them from memory ...
Donald
;< )
| |
| James J. Gavan 2005-11-21, 9:55 pm |
| Donald Tees wrote:
> James J. Gavan wrote:
>
>
>
>
>
> I expect that was because Bill knew them from memory ...
>
> Donald
> ;< )
That make you feel good Bill. What a nice compliment.
Actually a laptop would be just no use for Bill with his failing eyesight.
Jimmy
| |
| James J. Gavan 2005-11-21, 9:55 pm |
| Dan Nagle wrote:
> Hello,
>
> James J. Gavan wrote:
>
>
>
> <snip a bunch>
>
>
>
> OK, there's a standard, with INCITS, DIN, and ISO/IEC numbers.
> Then there's a corrigendum and a function module, also three numbers.
> So that's 3 times 3 entries.
>
> I know enough to buy the $18 ones, not the $192 ones.
> I suppose I want one standard, one corrigendum and one function module.
>
Bill or Chuck, clarify for Dan please.
I only know the term DIN because as part of what I program, Corrosion
Testing, each Vessel, (think of the hot water tank in your basement/or
attic), at an oil/gas plant, is constructed from a particular metal
specification. The tables used here in N. America are published by the
ASME (Mechanical Engineering) - and the metal descriptions are
meaningless ANSI codes like AW 2564 6, or SA2345 J etc... We
independently have in Canada CSA; have no idea whether that is ISO
compatible.
(As an example we have a US-made Maytag stove/cooker. Apparently fuses
not required in the States, but as an additional safety measure, CSA
insists anything here, including imports, must have fuses. Discovered
where the fuses were a few years ago when it went on the fritz.
Auto-mechanic style, remove the bottom warming draw and getting on my
back shove my head underneath to the very back of the device - LUVERLY !)
Now in the rest of the world those Metals I refer to, there are :-
British = BS or BSI, French = AFNOR, German = DIN, Italian = UNI, Japan
= JIS and I have UNS = ??????
There's a move to try and get the above set of codes into an agreed ISO
list - when, don't know.
I can only assume your 'DIN' references to a German written version of
the COBOL Standard ?
Jimmy
| |
| William M. Klein 2005-11-22, 3:55 am |
| What Dan is talking about WAS "third Standard COBOL" (aka the "'85
Standard") which is no longer a recognized COBOL Standard.
It had a "base document" (originally approved as an ANSI Standard, then
adopted by ISO)
Then there was the first Amendment (Intrinsic Functions) - also adopted by
ISO
Then there was a "Corrections Amendment" - Also adopted by ISO.
For the '02 (current) COBOL Standard, things are QUITE different.
It went thru the ISO process and ANSI then adopted it. There has been one
approved TR (Technical Report - for "Object Finalization").
I *believe* that the first two "technical corrigenda" documents are either
approved or close to approved thru the ISO process.
There are two more TR's relatively close to finished
Native XML support
Collection Classes
(Chuck could tell us EXACTLY where all the TR's and Corrigenda are in the
process).
Just as ANSI can adopt the current ISO Standard, so can "DIN" (the German
Standards body; so can BSI (?) British Standards Institute, etc)
Again, the '85 Standard (and earlier COBOL Standards) started as US
Standards and were then adopted as ISO Standards (and by various other
national standards bodies). For the '02 Standard (its TR's and Corrigenda -
it is ISO first).
There *are* procedures for ANSI to adopt ISO TR's - but to the best of my
knowledge (and again Chuck can correct me) there has been no attempt for
ANSI to adopt the Finalizer TR - or either of the two following ones.
Does this make things any clearer?
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:8uwgf.563516$oW2.81119@pd7tw1no...
> Dan Nagle wrote:
> Bill or Chuck, clarify for Dan please.
>
> I only know the term DIN because as part of what I program, Corrosion
> Testing, each Vessel, (think of the hot water tank in your basement/or
> attic), at an oil/gas plant, is constructed from a particular metal
> specification. The tables used here in N. America are published by the
> ASME (Mechanical Engineering) - and the metal descriptions are meaningless
> ANSI codes like AW 2564 6, or SA2345 J etc... We independently have in
> Canada CSA; have no idea whether that is ISO compatible.
>
> (As an example we have a US-made Maytag stove/cooker. Apparently fuses not
> required in the States, but as an additional safety measure, CSA insists
> anything here, including imports, must have fuses. Discovered where the
> fuses were a few years ago when it went on the fritz. Auto-mechanic style,
> remove the bottom warming draw and getting on my back shove my head
> underneath to the very back of the device - LUVERLY !)
>
> Now in the rest of the world those Metals I refer to, there are :-
>
> British = BS or BSI, French = AFNOR, German = DIN, Italian = UNI, Japan =
> JIS and I have UNS = ??????
>
> There's a move to try and get the above set of codes into an agreed ISO
> list - when, don't know.
>
> I can only assume your 'DIN' references to a German written version of the
> COBOL Standard ?
>
> Jimmy
| |
| Howard Brazee 2005-11-22, 6:55 pm |
| On Tue, 22 Nov 2005 00:23:23 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:
>Been so long away from Procedural COBOL I had forgotten about nested
>programs - can't recall if I ever used them with M/F's DOS Version. I
>recall a comment from Will Price where he was surprised COBOL users
>didn't jump up and down with joy at new goodies, from '85 onwards.
I have never seen a mainframe shop use them.
| |
| Howard Brazee 2005-11-22, 6:55 pm |
| On Tue, 22 Nov 2005 01:54:29 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:
....
[color=darkred]
>
>All right for you me Boyo, probably starting with a background of
>programming and if like me you were mathematically challenged, could
>always lean over the desk and ask the next guy. Next guy to me - I'm
>CEO, chief cook and bottle washer.
Square root isn't a common function in business applications. Where
it is used one would expect the programmer had some mathematical
background.
Someone with math background has no problem with the above - and a
good CoBOL programmer will document any and all math algorithms for
the maintenance programmer who has no idea why there's actual math in
a CoBOL program.
| |
| Howard Brazee 2005-11-22, 6:55 pm |
| On Mon, 21 Nov 2005 23:00:02 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:
>GUIs will never be a COBOL standard at this late stage.
I'm not quite sure that GUIs are a standard even with GUI based
languages. At least not the way old time CoBOL programmers think of
as standards.
| |
| Judson McClendon 2005-11-22, 6:55 pm |
| "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>
> And for the Luddite called Judson McClendon - correction the 'heretic' -
> couldn't believe it where he dismissed Decision Tables as 'ancy-fancy'. No
> I don't generate code from Decision Tables as Richard has suggested can be
> done. But I get my thoughts clear with simple Decision Tables and then
> code EVALUATES based on those - so simple - True or False and absolutely
> no 'maybes' - and the conditions that don't just apply, Action = Not
> Applicable and doesn't go into my source code.
Oh, I use decision tables in that sense, Jimmy, but that's not what I meant.
:-)
If you remember, there was once (70's?) a wild rush towards programming
Decision Tables into the systems themselves, rather than using discrete
logic. Almost every book and article cried out the mantra "Decision Tables
are taking over the world! Use them or become a dinosaur!" It was touted to
be the be-all-end-all programming paradigm of the future, destined to
replace discrete logic in all major applications. As far as I know, this is
still done on a few systems, maybe for good reasons, but it certainly isn't
wholesale, that I can see. This is what I was referring to.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Chuck Stevens 2005-11-22, 6:55 pm |
| *Very* frequently used on Unisys MCP systems, where "bilingualism" in COBOL
and ALGOL is common, as nested INITIAL programs map almost directly onto
nested procedures in ALGOL (or in Pascal, which got the concept from ALGOL).
Its absence from COBOL74 was sorely missed; PERFORM just didn't hack it for
people who were used to "local data".
Also heavily used by those who have explored and embraced the other features
of COBOL85 (e.g., EVALUATE, INITIALIZE, reference modification and scope
delimiters) rather than staying with '74-compatible syntax while using the
'85 compiler.
-Chuck Stevens
"Howard Brazee" <howard@brazee.net> wrote in message
news:pka6o191jvj8r6tvv664641ridkf8guo6f@
4ax.com...
> On Tue, 22 Nov 2005 00:23:23 GMT, "James J. Gavan"
> <jgavandeletethis@shaw.ca> wrote:
>
>
> I have never seen a mainframe shop use them.
| |
| Chuck Stevens 2005-11-22, 6:55 pm |
| Dan Nagle wrote:
> I know enough to buy the $18 ones, not the $192 ones.
> I suppose I want one standard, one corrigendum and one function module.
You're right, this could be confusing. But no, the function and corrigendum
amendments are against the *previous* standard, not the current one.
If you go to www.ansi.org , click on "eStandards Store", enter COBOL in the
search window and click on "go", at the moment you'll get a list of ten
items.
The *first* three on the list are the *US* versions of the *1985* standard,
the intrinsic function amendment to that standard, and the technical
corrigenda to that standard respectively. And if you did order the first
of these, you'd get the other two along with it.
The *next* three on the list are the *German* versions of the same three
documents (so far as I know, these are in English; they just happen to bear
DIN numbers and DIN cover pages).
The one you're looking for is the *seventh* one, "INCITS/ISO/IEC 1989-2002"
in the left column and "ANSI Information Technology -- Programming
languages -- COBOL" in the second column. Note that this is the *US
publication* with technical content identical to the ISO version (the cover
pages differ, and I think that's all). The price is $18.00.
The eighth item in the list is the official ISO-published version of the
2002 standard. Again, the technical content is the same as the INCITS/ANSI
version; however, they want $288 for it, as compared to $18 for the one with
the INCITS cover pages. You can also get this one from the ISO standards
store for 352 Swiss francs (about $267 today) either as a PDF download or on
CD-ROM.
The ninth item on the list isn't directly related to COBOL.
The tenth item on the list is the TR, Object finalization for COBOL, now in
force. This is as published by ISO. Unless you have a particular interest
in finalization, you probably don't need this one yet. You can get it here
as a download for $62; you can also get this from the ISO standards store
for 75 Swiss francs (about $57 today) either as a PDF download or in printed
form.
So it's the *seventh* one that's likely of most interest to you.
-Chuck Stevens
| |
| Chuck Stevens 2005-11-22, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:I8ygf.34424$Ys5.15167@fe12.news.easynews.com...
> There *are* procedures for ANSI to adopt ISO TR's - but to the best of my
> knowledge (and again Chuck can correct me) there has been no attempt for
> ANSI to adopt the Finalizer TR - or either of the two following ones.
I don't know for certain that this is as true for TR's as it is for the
standards themselves, but there's a US law from I think it's 1993 that says
something like if it's adopted by international standards bodies by
consensus then it's in force in the US. ANSI doesn't have to adopt it; if
the US were to *disagree* with the standard then they'd have to take
specific action to make it *inapplicable* in the US.
Now, there are several reasons for taking a TR approach to an issue; one,
already discussed, is to get it in force quickly -- in this case, more
quickly than would be the case were it simply incorporated into the next
revision of the standard. Another reason is, to use the ancient Madison
Avinue cliche, to "run it up the flagpole and see if anyone salutes".
As it happens, WG4 voted to include all the TR's into the draft that's in
preparation for international ballot.
The status of the various TR's, as I recall it, is:
ISO/IEC TR 19755, Object finalization for programming language COBOL:
APPROVED and in force
ISO/IEC wDTR 24716, Native COBOL syntax for XML support: Still in working
draft state; distribution for international ballot expected early next year.
ISO/IEC wDTR 24717, Collection class library for programming language COBOL:
Distribution for international ballot imminent pending minor changes
requested by WG4.
In addition, two Technical Corrigenda have been written and are in
preparation for forwarding to SC22. The corrections in them have already
been folded into the 2008 draft.
-Chuck Stevens
| |
| James J. Gavan 2005-11-22, 6:55 pm |
| Judson McClendon wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
> Oh, I use decision tables in that sense, Jimmy, but that's not what I meant.
> :-)
>
> If you remember, there was once (70's?) a wild rush towards programming
> Decision Tables into the systems themselves, rather than using discrete
> logic. Almost every book and article cried out the mantra "Decision Tables
> are taking over the world! Use them or become a dinosaur!" It was touted to
> be the be-all-end-all programming paradigm of the future, destined to
> replace discrete logic in all major applications. As far as I know, this is
> still done on a few systems, maybe for good reasons, but it certainly isn't
> wholesale, that I can see. This is what I was referring to.
OK - in the game since '63 but didn't program until about '79. In the
sense that you are talking, I can see your objections. "Here's the best
thing since sliced bread, let's all do it". Like so many things, it is
yet one more technique, and appeals to different people in different ways.
Might possibly get some current clarification on this. Donald, are
Decision Tables, or a comparative technique used in generating Clarion
programs ? You didn't actually use it yourself - but from your knowledge
of SAP - is that another one ?
Jimmy
| |
| James J. Gavan 2005-11-22, 6:55 pm |
| Howard Brazee wrote:
> On Mon, 21 Nov 2005 23:00:02 GMT, "James J. Gavan"
> <jgavandeletethis@shaw.ca> wrote:
>
>
>
>
> I'm not quite sure that GUIs are a standard even with GUI based
> languages. At least not the way old time CoBOL programmers think of
> as standards.
Let me clarify that. GUIs cannot be a part of the COBOL Standard in the
same manner as COBOL file handling, particularly as any GUI-ing has to
recognize an operating system.
Possibly, way back in late '70s, (and I'm not knocking them), if the
then "J4" people had the vision to see the advantages of both OO and
GUIs - COBOL could well have set the standard for GUI-ing. Quite simply,
Steve Jobs and Bill Gates might have been two 'events' that never
happened. Sure there would have been people with a touch of the smarts -
they could produce something and it could have been a hang-on feature to
COBOL.
On the downside - if COBOL had been all powerful, might it also have
been cumbersome enough, (long committee deliberations), to negate an
attempt at the Internet ?
Jimmy
| |
| Dan Nagle 2005-11-22, 6:55 pm |
| Hello,
Chuck Stevens wrote:
> Dan Nagle wrote:
>
>
>
>
> You're right, this could be confusing. But no, the function and corrigendum
> amendments are against the *previous* standard, not the current one.
<snip>
> The one you're looking for is the *seventh* one, "INCITS/ISO/IEC 1989-2002"
> in the left column and "ANSI Information Technology -- Programming
> languages -- COBOL" in the second column. Note that this is the *US
> publication* with technical content identical to the ISO version (the cover
> pages differ, and I think that's all). The price is $18.00.
Thanks! Just what I needed to know. I might be able to get it free
through my school's contracts with the standards bodies.
<snip>
> The ninth item on the list isn't directly related to COBOL.
Good. No deck is complete without a joker. :-)
> The tenth item on the list is the TR, Object finalization for COBOL, now in
> force. This is as published by ISO. Unless you have a particular interest
> in finalization, you probably don't need this one yet. You can get it here
> as a download for $62; you can also get this from the ISO standards store
> for 75 Swiss francs (about $57 today) either as a PDF download or in printed
> form.
I'll wait for the ANSI version unless I can wrangle a free download.
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| William M. Klein 2005-11-22, 6:55 pm |
| "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dlvj2g$2bju$1@si05.rsvl.unisys.com...
<snip>
> Also heavily used by those who have explored and embraced the other
> features of COBOL85 (e.g., EVALUATE, INITIALIZE, reference modification
> and scope delimiters) rather than staying with '74-compatible syntax while
> using the '85 compiler.
>
> -Chuck Stevens
>
Chuck,
I am not sure if you are talking only about Unisys COBOL programmers in
this paragraph or not.
INITIALIZE, SET TO TRUE, VALUE on items under OCCURS, EXTERNAL and *lots* of
other things have "caught on" in IBM mainframe shops. However, I am with
Howard in that I have rarely (if ever) seen nested programs used there.
At one time, there was even a GUIDE (IBM user requirement) to IBM for a
compiler option to "disallow" nested programs (in otherwise '85 Standard
programs). The IBM "solution" was a little "odd" - see:
http://publibz.boulder.ibm.com/cgi-.../IGY3C130/1.4.1
I *believe* (but won't swear to it) that this was because several "3rd
party" COBOL tools people were slow in providing support for this - and (as
previously discussed) most IBM mainframe shops use a LOT of 3rd party
products to interact with COBOL applications.
| |
| Donald Tees 2005-11-22, 6:55 pm |
| James J. Gavan wrote:
> Judson McClendon wrote:
>
>
>
>
>
> OK - in the game since '63 but didn't program until about '79. In the
> sense that you are talking, I can see your objections. "Here's the best
> thing since sliced bread, let's all do it". Like so many things, it is
> yet one more technique, and appeals to different people in different ways.
>
> Might possibly get some current clarification on this. Donald, are
> Decision Tables, or a comparative technique used in generating Clarion
> programs ? You didn't actually use it yourself - but from your knowledge
> of SAP - is that another one ?
>
> Jimmy
Sap uses them, but not clarion ... at least not as an intregal part of
the design.
Donald
| |
| Donald Tees 2005-11-22, 6:55 pm |
| James J. Gavan wrote:
> Howard Brazee wrote:
>
>
>
> Let me clarify that. GUIs cannot be a part of the COBOL Standard in the
> same manner as COBOL file handling, particularly as any GUI-ing has to
> recognize an operating system.
hmmm. I could make the claim that the screen section was the *first* GUI.
Donald
>
> Possibly, way back in late '70s, (and I'm not knocking them), if the
> then "J4" people had the vision to see the advantages of both OO and
> GUIs - COBOL could well have set the standard for GUI-ing. Quite simply,
> Steve Jobs and Bill Gates might have been two 'events' that never
> happened. Sure there would have been people with a touch of the smarts -
> they could produce something and it could have been a hang-on feature to
> COBOL.
>
> On the downside - if COBOL had been all powerful, might it also have
> been cumbersome enough, (long committee deliberations), to negate an
> attempt at the Internet ?
>
> Jimmy
| |
| Judson McClendon 2005-11-22, 6:55 pm |
| "Donald Tees" <donald_tees@sympatico.ca> wrote:
>
> hmmm. I could make the claim that the screen section was the *first* GUI.
I didn't think SCREEN SECTION was a standard item before COBOL 2002. It was
implemented by several vendors, including Micro Focus, and I've used it
since the early 80's on PCs. But I don't believe it was standard.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Chuck Stevens 2005-11-22, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:ZNKgf.42549$xh2.33510@fe04.news.easynews.com...
> I am not sure if you are talking only about Unisys COBOL programmers in
> this paragraph or not.
No, I wasn't even talking about that broad a group -- for I have no clue as
to the coding styles used by Unisys 2200 COBOL programmers. I thought I'd
been explicit in limiting the comment to *Unisys MCP systems*. Last I heard
they counted as "mainframes".
In fact, I'd say the *most eagerly anticipated* feature of COBOL85 for the
Unisys MCP-based systems (the A Series, at the time) was nested programs,
because A Series programmers were very familiar with the concept and
disliked the "single flat program" approach implicit in COBOL74.
The architecture of the Unisys MCP system is very nicely suited to the
concept of COBOL nested programs, having been developed and refined over
nearly five decades to support ALGOL nested procedures with stacks local to
the procedure such that the information simply disappears as the procedure
is exited.
-Chuck Stevens
| |
| Richard 2005-11-22, 6:55 pm |
| > I could make the claim that the screen section was the *first* GUI.
Well it wasn't GUI in that the 'G' is 'Graphics'.
Also by 'screen section' you are referring to a particular aspect of
the X/Open extensions. In fact I never liked the actual 'screen
section' but did use most the rest of the X/Open screen handling and
this was available before the 'screen section'. For example MF CIS
Cobol (1978) and Level II Cobol (1982?3?) had all the ACCEPT/DISPLAY AT
and key handling that was necessary but no 'screen section' which was
later in Cobol/2 (1985).
| |
| Donald Tees 2005-11-22, 6:55 pm |
| Judson McClendon wrote:
> "Donald Tees" <donald_tees@sympatico.ca> wrote:
>
>
>
> I didn't think SCREEN SECTION was a standard item before COBOL 2002. It was
> implemented by several vendors, including Micro Focus, and I've used it
> since the early 80's on PCs. But I don't believe it was standard.
I thought was was *dropped* is 2002. It always was a "non-standard"
standard, and Richards point that it is not really graphic is certainly
true. However, it was probably one of the earliest screen/keyboard
handling facilities built into a computer language.
There was also enough commonality in it through the 80's that the
methodology was reasonably convertable accross compilers. The point is
that Cobol use to *lead* with this stuff.
Donald
| |
| Chuck Stevens 2005-11-22, 6:55 pm |
| Donald Tees wrote, of the SCREEN SECTION:
<<I thought was was *dropped* is 2002. It always was a "non-standard"
standard, and Richards point that it is not really graphic is certainly
true. However, it was probably one of the earliest screen/keyboard handling
facilities built into a computer language.>>
SCREEN SECTION was introduced in the '02 standard and is still there in the
draft for '08 without deprecation. It is, however, a "processor-dependent"
feature of the language.
It's the COMMUNICATION SECTION and the associated SEND and RECEIVE
statements, introduced in the '74 standard, that are now marked obsolete and
that are absent from the draft for '08.
-Chuck Stevens
| |
| Judson McClendon 2005-11-22, 6:55 pm |
| "Richard" <riplin@Azonic.co.nz> wrote:
>
> Also by 'screen section' you are referring to a particular aspect of
> the X/Open extensions. In fact I never liked the actual 'screen
> section' but did use most the rest of the X/Open screen handling and
> this was available before the 'screen section'. For example MF CIS
> Cobol (1978) and Level II Cobol (1982?3?) had all the ACCEPT/DISPLAY
> AT and key handling that was necessary but no 'screen section' which was
> later in Cobol/2 (1985).
My Microsoft COBOL 2 manual, copyright 1980, '83 & '84, has screen section.
Version 2.1 was released in 1985. IIRC, Microsoft COBOL 3 was a relabeled MF
COBOL 2. I was a beta tester of Microsoft COBOL 4, which was definitely a
relabeled MF product (COBOL 3?). Microsoft dropped the COBOL compiler and
they had an arrengement with MF that allowed me to easily (free or cheap)
get a license for MF COBOL 3, which I later upgraded to Net Express 3.0.
That last upgrade cost me $2,500. Ouch!
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| James J. Gavan 2005-11-22, 6:55 pm |
| Donald Tees wrote:
> James J. Gavan wrote:
>
> hmmm. I could make the claim that the screen section was the *first* GUI.
>
> Donald
Well you coulddddd..... I used a 'Screen Section' with RM/COBOL ('74).
They had a screen section syntax, but I believe it was specifically
their own. Having pulled the RM Manual for V2 and M/F Manual for DOS V
3.1 - there are distinct differences. I confirmed the one I remembered :-
RM : ACCEPT LINE xxx POSITION xxxx
MF : ACCEPT LINE xxx COLUMN/COL xxx
I'm showing the above 'bare bones'; some syntax options available. And
the MF version Format 4 has little balloons all over the place
containing "MF" - i.e. M/F extensions to COBOL '85.
Had no significance to me back then, the Standards. (Apologies to the
new 'Guv'ner' for ISO COBOL ;-) ). But from above appears there was a
COBOL Screen Section '85 Standard.
However, your reference to 'GUI' is pushing it a bit :-
Three Tier Systems :
1- Business Logic (or the ugly academic 'Problem Domain')
2- UI = User Interface
3- DBI = Database Interface
GgggUI = GRAPHIC User Interface. None that I recall back when we started.
*>------------------------------------------------------------------
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.
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 ????
Jimmy
| |
| Richard 2005-11-22, 6:55 pm |
| >> For example MF CIS
[color=darkred]
> My Microsoft COBOL 2 manual, copyright 1980, '83 & '84, has screen section.
> Version 2.1 was released in 1985.
I am not sure whether you are agreeing with me or arguing.
Your 'Microsoft COBOL 2' is MS Cobol _version_ 2. MF Cobol/2 the
product name and this came in various versions, such as 1.3, 2.1, 2.4,
2.5, 3.1, 3.4. I notice however that they dropped the '/2' from the 3.x
versions.
I believe that the MS Cobol 1980 copyright is for version 1, and that
version 2 is the '83 or '84. In the same way MF Level II Cobol has a
1978 copyright as some material derives from the CIS Cobol introduced
at that date.
> Microsoft COBOL 4, which was definitely a relabeled MF product (COBOL 3?).
MS Cobol _version_ 4.5 was a rebadged MF Cobol/2 version 2.5 and MS
Cobol version 5.0 was MF Cobol version 3.0
Both MicroFocus and Microsoft had 'Screen Section' by 1983 or so but
earlier (1978/1980) had ACCEPT/DISPLAY AT nnnn or LINE/COLUMN.
| |
| Chuck Stevens 2005-11-22, 6:55 pm |
|
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:G%Mgf.570118$oW2.515137@pd7tw1no...
<<But from above appears there was a COBOL Screen Section '85 Standard.>>
Ummm ... no ... just double-checked. Not in ANSI X3.23-1985 / ISO
1989-1985. May have been an extension common to more than one vendor's
implementation of '85 COBOL, but neither the ACCEPT/DISPLAY extensions nor
the SCREEN SECTION are mentioned in the '85 standard.
In fact, that was one of the complaints about the '02 standard by the time
it came out: it was still essentially a text-screen design, and by the time
the standard actually came out GUI was standard practice and "green-screen"
techniques (regardless of the background color) were considered hopelessly
old-fashioned by botyh programmer and user.
That's also why it's "processor dependent"; the implementors aren't forced
to include a feature that *their* target market won't ever use.
-Chuck Stevens
| |
| Richard 2005-11-22, 6:55 pm |
| > Not in ANSI X3.23-1985 / ISO 1989-1985. May have been an extension common to
> more than one vendor's implementation of '85 COBOL,
It was a standard of X/Open which is why several vendors had somewhat
compatible implementations.
| |
| James J. Gavan 2005-11-22, 6:55 pm |
| Judson McClendon wrote:
> "Richard" <riplin@Azonic.co.nz> wrote:
> My Microsoft COBOL 2 manual, copyright 1980, '83 & '84, has screen section.
> Version 2.1 was released in 1985. IIRC, Microsoft COBOL 3 was a relabeled MF
> COBOL 2. I was a beta tester of Microsoft COBOL 4, which was definitely a
> relabeled MF product (COBOL 3?). Microsoft dropped the COBOL compiler and
> they had an arrengement with MF that allowed me to easily (free or cheap)
> get a license for MF COBOL 3, which I later upgraded to Net Express 3.0.
> That last upgrade cost me $2,500. Ouch!
Used the MicroSOFT compiler, possibly their last V 3 and came in smaller
manuals than the M/F remember ? Thing I liked was that their tech
writers took info from the Standard and 'translated' it into English.
Then the re-badged jobs V 4 and 5 I think but still with Programmer's
Workbench for compiling etc. I can't remember prices, but they weren't
exorbitant, otherwise I wouldn't have bought them. (These re-badged
versions, like RM/COBOL previously, I'm back to this Standard's
'jargonese').
Not too subtly MS pointed us at Micro FOCUS 'cos they were getting out
of the COBOL game. So I duly order my new M/F compiler DOS V 3.1. From
memory price tag was around $1,000. Confronted with that big set of grey
books - my technique - give them a series of three swift reads to
memorize highlights so I know where to go referencing later on. Through
the second read, I'm getting a bit puzzled. Penny drops on the third
read. For my money I was getting the bare bones compiler which worked
just fine. But many of the tools I was reading about were extras, I
think some graphic interface for development or some such.
Hey then we have VISOC to truly get into Winders and that funny thing
called "OO". (Note : As Dialog System was not part of VISOC, you had
three choices (a) Dialog Editor and GUIs which "forced" you to learn OO,
(b) use APIs or (c) Screen Section - text). $800 bucks - go for it.
In the Compuserve days I see an M/F meet coming up in California, usual
exciting stuff about new technology. The blurbs keep talking about
something called 'Net Express'. So I query with some sales guy through
the Forum, "Why no mention of VISOC - is this Net Express a replacement
?". He replies, "Well I suppose you could call it that.....".
Da ! Da ! "You can have Net Express for #3,000". (Can't remember
exactly). "But as you jokers are already using VISOC we'll give it to
you for a discounted price". Grumble, mumble, mumble we pay up.
Then V 3.1 of Net Express - runtime fees ........ but we've been this
route before.
The only consolation - it is a superb development tool.
Jimmy
| |
| Judson McClendon 2005-11-22, 9:55 pm |
| "James J. Gavan" <jgavandeletethis@shaw.ca> 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. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| HeyBub 2005-11-23, 3:55 am |
| Judson McClendon wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>
> 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.
First, the amount of resources a data-entry process consumes is irrelevant.
Whether GUI or character, it can never consume more than a minscule and
unmeasurably small fraction of that which is available.
Further, a GUI interface can EXACTLY emulate a character-based screen. For
massive data entry a GUI screen can be as functional as a character-based
one. And it is the GUI screen that is more robust in its ability to handle
exceptions, informative error messages, pop-up enhancements such as
graphical calendars and calculators, hooks to other data elements (ZIP code
directories, parts listings, directories of similar names), interactions
with other applications such as internet look-ups, and displays of graphics
(perhaps the customer's picture or parts explosion).
No, character-only displays or data entry screens are as archaic as spats,
positively antediluvian. And its easier to sell a GUI system, even if it
only displays letters.
I'll give you "cheaper and quicker to write" - but a Big Chief tablet and a
crayon is cheaper still.
| |
| Richard 2005-11-23, 3:55 am |
| > Not too subtly MS pointed us at Micro FOCUS 'cos they were getting out
> of the COBOL game.
Actually it was the other way around. MF cancelled the agreement when
they opened their own office in USA.
| |
| James J. Gavan 2005-11-23, 3:55 am |
| Richard wrote:
>
>
> Actually it was the other way around. MF cancelled the agreement when
> they opened their own office in USA.
>
Ahhhh... Didn't realize that.
As always you are a MINE of information when it comes to Microsloth. See
they've just hit their twenty years ? Comments I read yesterday Longhorn
will come out as Vista (?) - schedule like mad to be ready for the Xmas
rush December 2006. Speculation, folks are going to say, "Well we are
quite happy with what we have now. Why do we need to upgrade ?" Will be
interesting to see.
Now my speculation - the U. of Bellingham wont be able to resist the
chance to make a few more bucks. "So all you guys using dotNet - we've
put a few new hooks into dotNet - better upgrade". Watch the lemmings
run over the cliff in a breathless hurry. And Bill and Balmer will be
rushing bags of loot to their banks.
Jimmy
| |
| James J. Gavan 2005-11-23, 3:55 am |
| Judson McClendon wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>
>
>
> 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.
>
>
>
>
> 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
| |
| William M. Klein 2005-11-23, 3:55 am |
| Richard,
Not certain what made you think this - but it was NOT this way.
"historically" when Microsoft and IBM were together developing OS?2, then
Micro Focus was the "official" IBM COBOL/2 provider.
When IBM and Microsoft "split" up (regarding OS/2), Micro Focus provided
*both* a "rebadged" COBOL/2 product for IBM *and* the Microsoft COBOL
compiler.
All of this was WELL after Micro Focus had US offices.
NOTE:
There was an IBM/Microsoft COBOL compiler *before* COBOL/2 that was not a
Micro Focus product, but that was before I became involved with Micro Focus
(in the late 80's) so I can't tell you who actually developed that product.
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1132720592.353627.177800@f14g2000cwb.googlegroups.com...
>
> Actually it was the other way around. MF cancelled the agreement when
> they opened their own office in USA.
>
| |
| William M. Klein 2005-11-23, 3:55 am |
| Both the Screen Section and the "extended DISPLAY at column/position" were
part of the X/Open COBOL specification, not any ANSI (or ISO) Standard
before '02. The X/Open COBOL Standard was medium-universally implemented on
Unix (and some other "workstation") platforms in the 80's and 90's.
Therefore, Screen Section was "standard" but NOT ANSI Standard.
P.S. During the development of the '02 Standard, there was serious work to
maintain compatibility with the X/Open Standard for both Screen Section
*and* file sharing/record locking. Other '02 Standard features "adopted" by
the '02 Standard included "literal concatenation" and SOME of the PIC N
"stuff".
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dm07ju$2nue$1@si05.rsvl.unisys.com...
>
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:G%Mgf.570118$oW2.515137@pd7tw1no...
>
> <<But from above appears there was a COBOL Screen Section '85 Standard.>>
>
> Ummm ... no ... just double-checked. Not in ANSI X3.23-1985 / ISO
> 1989-1985. May have been an extension common to more than one vendor's
> implementation of '85 COBOL, but neither the ACCEPT/DISPLAY extensions nor
> the SCREEN SECTION are mentioned in the '85 standard.
>
> In fact, that was one of the complaints about the '02 standard by the time
> it came out: it was still essentially a text-screen design, and by the
> time the standard actually came out GUI was standard practice and
> "green-screen" techniques (regardless of the background color) were
> considered hopelessly old-fashioned by botyh programmer and user.
>
> That's also why it's "processor dependent"; the implementors aren't forced
> to include a feature that *their* target market won't ever use.
>
> -Chuck Stevens
>
| |
| Richard 2005-11-23, 3:55 am |
| > See they've just hit their twenty years ?
That would be Windows with the 20 years. They announced Windows when
they saw DRI demonstrate GEM in 1983 and then delivered version 1.0 2
years later. MS had been around since 1976 or so.
> Comments I read yesterday Longhorn will come out as Vista (?) -
_Some_ of Longhorn will survive to make Vista and even Longhorn was to
be a cut down version of Cairo announced 10 years ago.
> "Well we are quite happy with what we have now. Why do we need to
> upgrade ?"
Especially when most machines in use today aren't enough to run
Longhorn. Well actually by the time the feature list is cut down to
make it deliverable it probably won't be much more than XP.
I have the idea that MS does not want to eliminate viruses and spam
that run rampant on current Windows so that they can 'solve all your
problems' with Vista. Part of the 'solution' may be related to the so
called 'trusted computing' and DRM so that you only get to be virus
free by trusting everything to MS.
> schedule like mad to be ready for the Xmas rush December 2006.
If you recall 1995 when Windows 4 was supposed to be out in April '95.
It was delayed, and delayed, and Gates stated "it _will_ be out by
Christmas, but we may have to delay December for 3 months".
| |
| Richard 2005-11-23, 3:55 am |
| > When IBM and Microsoft "split" up (regarding OS/2), Micro Focus provided
> *both* a "rebadged" COBOL/2 product for IBM *and* the Microsoft COBOL
> compiler.
Certainly there was an 'IBM Cobol/2' that was a rebadged Microfocus
Cobol. I recall that it was MF Cobol/2 1.3 around 1989 for PC-DOS. Note
that MF Cobol/2 has nothing to do with OS/2 (I have MF manuals marked
Cobol/2 and it is for DOS). For OS/2 the IBM Cobol was VisualAge and
not MF.
> There was an IBM/Microsoft COBOL compiler *before* COBOL/2 that was not a
> Micro Focus product, but that was before I became involved with Micro Focus
> (in the late 80's) so I can't tell you who actually developed that product.
Microsoft had written a Cobol for CP/M-80 back in 1980 or so and it
ported this to MS-DOS in 1982 as version 1. They developed this
further to version 2. While this was sold for use on IBM PC it was not
an IBM product.
| |
| Rick Smith 2005-11-23, 7:55 am |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1132733585.177063.266640@f14g2000cwb.googlegroups.com...
>
> Certainly there was an 'IBM Cobol/2' that was a rebadged Microfocus
> Cobol. I recall that it was MF Cobol/2 1.3 around 1989 for PC-DOS. Note
> that MF Cobol/2 has nothing to do with OS/2 (I have MF | | |