Home > Archive > Cobol > May 2004 > XML and OO COBOL
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]
|
|
| Peter E. C. Dashwood 2004-05-21, 3:30 am |
| I have been receiving a few mails lately, requesting some light on XML
in COBOL.
And I understand the Standards Committee are looking at including XML
support into a future version of COBOL. I don't see any need for this
(fashions change and the "replacement" for XML is already in the
pipeline) but I guess if it keeps them off the streets, I have to vote
for it <G>
When it comes to XML you COULD write copious COBOL code to parse it
and extract tagged data from it, but why would you?
Those of us who use OO will simply use components to process it
anyway.
(Those of you who haven't embraced OO yet: "Welcome to Earth in the
21st Century!" Now, while you're waiting for Nursie to change your
poultice, enlarge the print below and read it carefully. Try not to
move your lips as you read, and for Christ's sake, stop dribbling and
moaning... You were advised to get into OO nearly 7 years ago...<G> )
The following code demonstrates the use of COM components (supplied
free, as part of my Operating System, by those nice people at
MicroSoft...) to handle XML. For those poor souls who get a convulsion
and need to turn immediate widdershins when the name of the Seattle
Serpent is mentioned, there are a plethora of similar components
appearing in the market place.
The code is snipped from an actual working Web Based application that
needs to validate credit cards and take money as part of its
functionality.
To everyone's surprise, it is written in COBOL. To everyone's further
amazement, it is stable and works well.
Gosh! Fancy writing a commercial application in a commercial
programming language!
The code is in Fujitsu NetCobol. It does NOT require the .NET
framework. It DOES use the Fujitsu Automation server class (COM,
previously OLE...) that gives a standard interface to ActiveX and COM
compliant components.
(I seriously recommend a browse through the XML Document Object Model
(DOM) to see what Methods and Properties are available as standard (MS
actually exceed this spec.) GOOGLE is your friend...)
If you have questions or need clarification, please mail me privately.
These days I don't get to CLC very often.
Pete.
....
DATA DIVISION.
WORKING-STORAGE SECTION.
01 XMLProgID pic x(20) value "Microsoft.XMLDOM".
01 objXMLReceived OBJECT REFERENCE COM.
*
* XML returned data
*
01 strReplyXMLStr pic x(2048).
01 XMLerrorCode pic s9(9) comp value 111.
01 ItemIndex pic s9(9) comp value zero.
01 XMLField pic x(512).
01 objNodeRef OBJECT REFERENCE COM.
01 objItemRef OBJECT REFERENCE COM.
01 objParseError OBJECT REFERENCE COM.
01 APIReplyCodeText pic x(14) value "API_REPLY_CODE".
01 APIAuthorityText pic x(13) value "API_AUTHORITY".
01 ReplyTestBuffer. *> this has been set here for debugging
*> and to demonstrate the use of XML
*> component processing.
*> I have replaced some field contents with
asterisks
*> for the sake of confidentiality.
12 filler pic x(74) value
"<API><API_REPLY_CODE>50</API_REPLY_CODE><API_FTR_NUM>*******</API_FTR_NUM>".
12 filler pic x(74) value
"<API_REQUEST_TYPE>SALE</API_REQUEST_TYPE><API_CREDIT_CARD_TYPE_CODE>VI</AP".
12 filler pic x(74) value
"I_CREDIT_CARD_TYPE_CODE><API_CREDIT_CARD_NUMBER>****************</API_CRED".
12 filler pic x(74) value
"IT_CARD_NUMBER><API_CREDIT_CARD_EXPIRY_DATE>0405</API_CREDIT_CARD_EXPIRY_D".
12 filler pic x(74) value
"ATE><API_PAYEE_CODE>******</API_PAYEE_CODE><API_AMOUNT>100.00</API_AMOUNT>".
12 filler pic x(74) value
"<API_COMMISSION_AMOUNT>2.50</API_COMMISSION_AMOUNT><API_REFERENCE>Standalo".
12 filler pic x(74) value
"neTest0000001</API_REFERENCE><API_REFERENCE_NAME>HUGH
GEDETTS</API_REFERE".
12 filler pic x(74) value
"NCE_NAME><API_REFERENCE_DATE>2004-05-17</API_REFERENCE_DATE><API_AUTHORITY".
12 filler pic x(74) value
">999999</API_AUTHORITY><API_STATUS>FD</API_STATUS><API_REJECT_REASON></API".
12 filler pic x(74) value
"_REJECT_REASON><API_CREDIT_FEE_AMOUNT>0.00</API_CREDIT_FEE_AMOUNT><API_STA".
12 filler pic x(74) value
"TUS>FD</API_STATUS><API_REJECT_REASON>
</API_REJECT_REASON><API_CREDIT_FEE".
12 filler pic x(74) value
"_AMOUNT>0.00</API_CREDIT_FEE_AMOUNT><API_PAYER_CODE>******</API_PAYER_CODE".
12 filler pic x(7) value
"></API>".
etc.
....
PROCEDURE DIVISION.
etc.
....
*----------------------------------------------------------------------
analyse-response section.
ar000.
*
* On entry to this section the ThirdPartyBanking server will have
analysed
* the XML sent in the Credit Card validation request and returned a
* buffer full of XML in strReplyXMLstr.
*
* We now need to parse the XML to make sure it is valid, then check
the
* Bank server API reply code to ensure that the request processed
* successfully. If it did, we can get the authorization for the
* credit card and pass it to the CGI code.
*
* Create the XML parser object...
invoke COM "CREATE-OBJECT" using XMLProgID
returning objXMLReceived
end-invoke
if objXMLReceived not = NULL
display "XML parser object was instantiated..." upon syserr
else
display "Could not create XML Parser Object..." upon syserr
move '906' to ErrorCode
go to ar999
end-if
move ReplyTestBuffer to strReplyXMLstr *> debugging only...
*
* Analyse the XML buffer returned from ThirdPartyBanking
*
*
invoke objXMLReceived "LoadXML" *> use the standard MicroSoft XML
parser
*> component that everybody else
uses.
*> Why re-invent the wheel?
USING strReplyXMLstr
end-invoke
invoke objXMLReceived "GET-parseError" *> traverse the XML object
RETURNING objParseError
end-invoke
invoke objParseError "GET-errorCode" *> Traverse the XML object
RETURNING XMLErrorCode
end-invoke
if XMLerrorCode NOT = zero
move '907' to ErrorCode *> return "Failed Bank Connection"
to the CGI code
go to ar999
end-if
*
* The returned string is valid XML
*
* Now grab the API Reply Code. '50' Means the request was processed OK
* by the Bank's servers.
*
invoke objXMLReceived "getElementsByTagName" *> How  is
that?!
*> Standard in the
XML DOM.
*> No writing
intricate code
*> to find tags, and
it's
*> free!
USING APIReplyCodeText
RETURNING objNodeRef
end-invoke
*
* The XML DOM sees each 'level' Of XML as a node. These are exactly
like
* standard collections and can be processed with indexes just like any
* other collection...
*
invoke objNodeRef "item"
USING ItemIndex *> Index 0 for the first item in the
collection
*> In this case there is only one item
anyway...
RETURNING objItemRef
end-invoke
invoke objItemRef "GET-Text"
RETURNING XMLField
end-invoke
if XMLField (1:2) NOT = '50'
move '906' to ErrorCode *> Return 'Transaction failed' to
CGI code
go to ar999
end-if
*
* Valid XML has been returned and there is no problem with the
* ThirdPartyBanking server or the string we sent it.
*
* Check for Authorization...
*
invoke objXMLReceived "getElementsByTagName" *> Extract the
*> Authorization
code
USING APIAuthorityText
RETURNING objNodeRef
end-invoke
invoke objNodeRef "item" *> traverse the XML object
USING ItemIndex
RETURNING objItemRef
end-invoke
invoke objItemRef "GET-Text"
RETURNING XMLField
end-invoke
if XMLField NOT = 'REJECT'
move XMLField to CCAuthzCode *> Pass Authorization back to
CGI code
move zero to ErrorCode *> Return 'Success' to the CGI
code
else
move '905' to ErrorCode *> Return 'Card declined' to
the CGI code
end-if
| |
| Joe Zitzelberger 2004-05-21, 10:30 pm |
| In article <b3638c46.0405202206.67b5b6e6@posting.google.com>,
dashwood@enternet.co.nz (Peter E. C. Dashwood) wrote:
> When it comes to XML you COULD write copious COBOL code to parse it
> and extract tagged data from it, but why would you?
XML was designed to be easy to parse. Thus, XML parsers are quite easy
to write. Even in Cobol it only takes a few hundred lines and a few
days to get one working.
> Those of us who use OO will simply use components to process it
> anyway.
> (Those of you who haven't embraced OO yet: "Welcome to Earth in the
> 21st Century!" Now, while you're waiting for Nursie to change your
> poultice, enlarge the print below and read it carefully. Try not to
> move your lips as you read, and for Christ's sake, stop dribbling and
> moaning... You were advised to get into OO nearly 7 years ago...<G> )
>
> The following code demonstrates the use of COM components (supplied
> free, as part of my Operating System, by those nice people at
> MicroSoft...) to handle XML. For those poor souls who get a convulsion
> and need to turn immediate widdershins when the name of the Seattle
> Serpent is mentioned, there are a plethora of similar components
> appearing in the market place.
I don't especially feel the need to turn widdershins, but you should
look into the SAX model. Much lighter weight than DOM, faster, less
resource intensive, and easier to use.
| |
| Richard 2004-05-22, 2:30 am |
| Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote
> XML was designed to be easy to parse. Thus, XML parsers are quite easy
> to write. Even in Cobol it only takes a few hundred lines and a few
> days to get one working.
I had posted one in this group earlier this year that had been written
by the Miami-Dade Community College. If you google in clc for that
name you should find it. It may be useful for testing purposes before
implementing a real parser.
| |
| Joe Zitzelberger 2004-05-22, 10:30 am |
| In article <217e491a.0405212132.41aedbdf@posting.google.com>,
riplin@Azonic.co.nz (Richard) wrote:
> Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote
>
>
> I had posted one in this group earlier this year that had been written
> by the Miami-Dade Community College. If you google in clc for that
> name you should find it. It may be useful for testing purposes before
> implementing a real parser.
I've seen that one -- it looks interesting, but they left a few things
out the last time I looked. I think it was missing namespace support
circa 2000 when we were deciding to write our own or use someone elses.
| |
| Peter E. C. Dashwood 2004-05-22, 12:30 pm |
| Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote in message news:<joe_zitzelberger-A1177F.21443221052004@corp.supernews.com>...
> In article <b3638c46.0405202206.67b5b6e6@posting.google.com>,
> dashwood@enternet.co.nz (Peter E. C. Dashwood) wrote:
>
>
> XML was designed to be easy to parse. Thus, XML parsers are quite easy
> to write. Even in Cobol it only takes a few hundred lines and a few
> days to get one working.
>
<<<
As opposed to no lines at all and 20 minutes reading for the component
I used.
:-)
Seriously, Joe, I do take your point. The point of my post was that
there is a comprehensive arsenal of existing XML components and they
can be used with COBOL...easily.
>
>
> I don't especially feel the need to turn widdershins, but you should
> look into the SAX model. Much lighter weight than DOM, faster, less
> resource intensive, and easier to use.
Yes, I heard something about that and have it on my list. Thanks for
the "heads up". One of these days somebody might pay me to do
something that is not on a MicroSoft platform...<sigh>
Pete.
| |
| David Sands 2004-05-24, 9:30 am |
| If your a Micro Focus Net Express user you can also leverage the MSXML
parser using COM Automation.
I have posted example code below. If you want the full example project then
send me a note.
With Net Express V4 it gets far easier as it has added COBOL Syntax for
handling XML. You can use READ/WRITE type statements direct from COBOL (Non
Object Oriented syntax). Using this syntax you can run the code on Win32 ,
Unix (Server Express V4) and .Net platforms. There are docs and a tutorial
supplied with V4 of Net Express.
If your not on V4 then the code below should work OK for you.
Hope this helps
David.
---------->>>>>>>>>>>>>>>>>>>>>>
$SET OOCTRL(+P) MFOO ANS85 CASE mf defaultbyte"00" case align"8"
****************************************
**************************
* Author - Micro Focus - e-Business Support EMEA (davs)
*
* Purpose - Manipulate and parse data using Microsoft
* XML Parser.
*
* MSXML4 is removing version independant progids
* so this version now checks to see what is
* registered before setting up the progid.
* Please consult Microsoft documentation for
* MSXML 4 for more details.
*
****************************************
**************************
CLASS-CONTROL.
OLEVariant is class "olevar"
XMLErr is class "$OLE$MSXML.IXMLDOMParseError"
olesup is class "olesup"
CharArray is class "chararry"
mfoleapi is class "mfoleapi"
XMLDoc is class xmlprogid
| |
| Howard Brazee 2004-05-24, 11:30 am |
| The following article might be of interest:
http://search390.techtarget.com/qna...i920032,00.html
QUESTION & ANSWER
Catching up with COBOL
By Mark Brunelli, Site Editor, Search390.com
18 Aug 2003 | Search390.com
Historically, things have moved rather slowly in the world of COBOL. But over
the last two years, IBM has picked up the pace by introducing and then updating
a new version of the programming language - Enterprise COBOL for z/OS and OS/390
Version 3 - that includes several new time saving features. Developers using
older versions of COBOL may not yet be aware of all the recent advancements
available to them. Enter Tom Ross, an IBM Software Engineer with more than 18
years of experience in COBOL development. At last w 's SHARE conference in
Washington D.C., Ross went before a group of COBOL developers with the goal of
bringing them up to date. In this excerpt from that very conference session,
Ross answers audience questions about COBOL's new capabilities in the areas of
multi-threading, XML and Unicode support.
Is multi-threading only available in object oriented COBOL?
Tom Ross: The answer is no. Multi-tasking in Version 2.01 got re-implemented,
not with tasks, but threads under LE. So, yes, you can use multi-threading
anywhere. Just compile them in thread option, put recursive on the program ID,
and use local storage instead of working storage and you're off to the races.
You mentioned that the XML parser now available in COBOL is streamlined, as
compared to Java and C++ XML parsers. Why is this the case?
Tom Ross: The full function XML parser was not fast enough for our COBOL
customers. Ten or twenty transactions per second is not going cut it. The most
we could get out of Java and C++ XML parsers was about forty or fifty
transactions per second. So, we wrote a stripped down, high speed, racing
version of XML parser and we got up to two thousand transactions per second. We
felt that was more in line with what our COBOL customers needed. Being
streamlined, it does not validate XML documents and it does not process
document-type definitions (DTVs). In the past we've had customers ask us for
that capability, but now the XML world has turned away from DTVs and their
moving toward schemas. So, it's kind of a good thing that we didn't add that
functionality. We are working towards supporting schemas and having more
flexibility. By the way, when we wrote our stripped down parser, the Java and
C++ people thought it was a good idea and they copied it into their products as
well.
Have XML protocols been written into the COBOL standard?
Tom Ross: We didn't want to wait for the standards committee. We needed to get
this thing out now to respond to our customers. Our customers want to do XML
today, not when the standard committee decides what that will look like in the
COBOL standard. No, it's not in the standards. We just did it and now it's
available to you.
Can you tell us a little about Unicode support in the latest version of COBOL?
Tom Ross: Unicode provides a unique character code for every character in every
major language in the world. And it really, really does. (The creators of
Unicode) even considered Klingon. (laughs) But they determined that 99 percent
of users of the Klingon language actually use the English code page. They really
studied everything. They studied many Chinese dialects and Japanese and all the
major European languages and of course, English. But, sorry, no Klingon. What
Unicode support allows you to do is handle any language efficiently. You don't
have to use this code page stuff anymore. With Unicode, you decide up front
exactly what language it is, and it has identifiers to tell you what Unicode
CCSID an application is written in. You could possibly have a single application
executable working for a global audience.
"Our customers want to do XML today, not when the standard committee decides
what that will look like in the COBOL standard. No, it's not in the standards.
We just did it and now it's available to you." -- Tom Ross
Are Unicode conversion services included in the most recent releases of z/OS?
Tom Ross: Unicode conversion services are part of the operating system starting
with z/OS release 2 or later. Before that you had to download conversion
services from the Web. DB2 uses them as well but there are some differences
between the way you customize them for DB2 and the way you customize for COBOL.
If you're going to use Unicode in DB2 and COBOL, make sure you check out the DB2
and COBOL documentation. Actually, the program directory for COBOL now has
everything you need. In 3.1 it was a little shaky but in 3.2 we really nailed
it. The program directory shows exactly what you need to do between COBOL and
DB2, and how to specify the search method for the conversion tables you're going
to use. I just want to give you a warning, though. When you're using conversion
services make sure you coordinate between COBOL and DB2.
What is the minimum set-up for using object-oriented COBOL with conversion
services?
Tom Ross: The minimum set-up for using object-oriented COBOL is a conversion
from the default CCSID to CCSID 1200 and 1208. Those have to be configured
before you can compile an object oriented COBOL program. If you run the object
oriented installation verification, it will fail unless conversion services are
there and configured properly.
| |
| Frank Swarbrick 2004-05-24, 12:30 pm |
| Interesting. I can't see where you've shown what the XMLPARSE.WS copybook
contains. Could you post that?
This is a SAX-like parser, correct?
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote
[color=darkred]
> XML was designed to be easy to parse. Thus, XML parsers are quite easy
> to write. Even in Cobol it only takes a few hundred lines and a few
> days to get one working.
I had posted one in this group earlier this year that had been written
by the Miami-Dade Community College. If you google in clc for that
name you should find it. It may be useful for testing purposes before
implementing a real parser.
| |
| James J. Gavan 2004-05-24, 2:30 pm |
| Howard Brazee wrote:
>The following article might be of interest:
>
>http://search390.techtarget.com/qna...i920032,00.html
>
>
>
Excellent extract Howard. Right down to the meat and potatoes stuff from
Tom Ross - design XML NOW :-
" racing version of XML parser and we got up to two thousand transactions per second. We
felt that was more in line with what our COBOL customers needed."
>"Our customers want to do XML today, not when the standard committee decides
>what that will look like in the COBOL standard. No, it's not in the standards.
>We just did it and now it's available to you." -- Tom Ross
>
>
There's the rub. Customers need it now; competitively COBOL vendors have
to provide additions as a new IT feature is introduced, particularly if
they appear in other languages - otherwise they are going to slip off to
those languages, further decreasing the COBOL base.
So far as J4 is concerned, perhaps there should be a more general
re-think - and they shouldn't try to define a COBOL feature to the nth
degree. Possibly, to qualify as complying to the official COBOL standard
they should have a check-list :-
"To be COBOL 20?? compliant your compiler must have these features :-
- a
- b
- c
- XML
- OO
- OO Collection classes .
- OLE support etc.......
Add to that some text where the Vendors can indicate they are compliant
(to a degree) but specifically excluding the following modules : -
- Module 5 .......
- Module 9 .....
The pace of changes in IT zooms along - can a Standards committee ever
catch up ? I think it's roughly around '93 there were the first OO COBOL
compilers. Along comes Russell Clarke (Australia) with a voluminous
paper on Standard classes/collections in '96. It was passed from J4 to
the ISO folks who made comments. Then it sat on ice - until Bill Klein
pointed out, around 2001 (?), that Russell's paper existed. As a
developer - first I knew of it. Some activity about two years back and
then a 'stall' situation. A fair amount of effort put in by Thane on
behalf of Fujitsu. Recent months a paper from Bob Karlin suggesting a
'broad outline' - ignoring specifics. What's going on currently in the
background, no idea.
Somebody wrote to me once he was optimistic that standard
classes/collections could be ready by 2006, before COBOL 2008. Given
current momentum, ( and we are already at mid-2002),
In case I've got the dates wrong above, substitute following :-
"Somebody wrote to me once he was optimistic that standard
classes/collections could be ready by 2004, before COBOL 2006. Given
current momentum, ( and we are already at mid-2002)",
I f the second set of dates is the correct one, then it is even more
unrealistic.
I just don't see that happening. Bearing in mind at this juncture
there are only three *working* implementations of this topic, (IBM uses
Java to cover this), Hitachi, Fujitsu and Micro Focus. - and the fact
that their developers will have written a considerable amount of code
between say 1996 - 2006 or 2008, ( or - 2004 or 2006), why would vendors
or developers want to go to the effort of switching to a vanilla
flavoured (collection) standard ?
Jimmy, Calgary AB
| |
| Chuck Stevens 2004-05-24, 5:30 pm |
|
"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:Qqqsc.574985$oR5.345059@pd7tw3no...
> So far as J4 is concerned, perhaps there should be a more general
> re-think - and they shouldn't try to define a COBOL feature to the nth
> degree. Possibly, to qualify as complying to the official COBOL standard
> they should have a check-list :-
As I understand it, J4 had little choice in this matter. ANSI X3.23-1985
allowed the implementors to describe an implementation that had only the
most basic levels of the Nucleus, Sequential I-O and Inter-Program
Communication modules as "fully conforming" with that standard, albeit with
the "minimum subset", ignoring altogether the other modules (Relative and
Indexed I-O, SORT-MERGE, and Source Text Manipulation) as well as higher
levels like, for the Nucleus, SET 88-LEVEL TO TRUE, STRING, and nested
REDEFINES (Level 2), and from Sequential I-O, the LINAGE clause and CLOSE
.... NO REWIND (also Level 2).
The national bodies expressed the opinion through ISO/IEC JTC1/SC22/WG4 (as
a direct mandate) that implementations would either conform to the standard
or they would not be in conformance, period. There are certain areas in
which WG4 relented -- the Screen Section and related language elements
being the most notable, allowing such language elements to be "processor
dependent" -- but they are few and very limited (see ISO/IEC 1989:2002 pp.
696-697 for the list of such elements).
> "To be COBOL 20?? compliant your compiler must have these features :-
>
> - a
> - b
> - c
> - XML
> - OO
> - OO Collection classes .
> - OLE support etc.......
Bottom line is this: Aside from the aforementioned Processor-Dependent list
on pages 696-697, a COBOL compiler that claims to conform to this standard
must conform to this standard, not "except for OO", not "except for
VALIDATE", not "except for INITIALIZE WITH FILLER". Be in conformance, or
be not in conformance. If an implementor decides that providing
table-format VALUE clauses or support for record-level locking syntax is
Just Too Hard, too bad; that compiler doesn't conform to the standard.
If you don't like this approach of having "compliance" mean the same thing
to everybody, then it's ISO/IEC you're going to have to convince through
your national bodies. Moreover, as WG4 has expressly *not* allowed such a
major change in philosophy in the standard currently under development, the
chances of reinstating the concept of "optionality" prior to the publication
of the *next* standard -- currently planned for late 2008 -- is pretty much
out of the car until development starts on the standard after that.
> Somebody wrote to me once he was optimistic that standard
> classes/collections could be ready by 2006, before COBOL 2008. Given
> current momentum, ( and we are already at mid-2002),
There are two projects being handled as Technical Reports by J4:
"Collection class library" and "
"Native COBOL syntax for XML". Both are expected to apply against the 2002
standard, to be published well before the next standard (much as the two
Amendments to the '85 standard were), and *also* to be incorporated into the
2008 standard when it is published. Work continues on both of these
Technical Reports.
Incidentally, the "class library" approach (as distinct from the "native
syntax" approach) to XML was discussed at some length. The direction given
by WG4 to J4 was that the current requirements for XML handling were
orthogonal to the requirements for classes, and that existing COBOL users
were better served by having support for XML using syntax already familiar
to them than by making extensive use of object-oriented design features in
the program a prerequisite.
This is similar to the issues involving dynamic-capacity tables, which can
clearly (and easily) be handled within implementor-defined (as well as
user-defined) classes; the requirement here is that the changes to the
Procedure Division of an existing program with a fixed-capacity table to
turn that table into a dynamic-capacity table would be at most minimal, and
preferably nonexistent, which a dynamic-capacity table (or, for that matter,
an XML-handling) implementation requiring the use of classes would not
fulfill.
-Chuck Stevens
| |
| Warren Simmons 2004-05-24, 6:30 pm |
| James J. Gavan wrote:
> Howard Brazee wrote:
>
> Excellent extract Howard. Right down to the meat and potatoes stuff from
> Tom Ross - design XML NOW :-
>
> " racing version of XML parser and we got up to two thousand
> transactions per second. We
> felt that was more in line with what our COBOL customers needed."
>
>
> There's the rub. Customers need it now; competitively COBOL vendors have
> to provide additions as a new IT feature is introduced, particularly if
> they appear in other languages - otherwise they are going to slip off to
> those languages, further decreasing the COBOL base.
>
> So far as J4 is concerned, perhaps there should be a more general
> re-think - and they shouldn't try to define a COBOL feature to the nth
> degree. Possibly, to qualify as complying to the official COBOL standard
> they should have a check-list :-
>
> "To be COBOL 20?? compliant your compiler must have these features :-
>
> - a
> - b
> - c
> - XML
> - OO
> - OO Collection classes .
> - OLE support etc.......
>
> Add to that some text where the Vendors can indicate they are compliant
> (to a degree) but specifically excluding the following modules : -
>
> - Module 5 .......
> - Module 9 .....
>
> The pace of changes in IT zooms along - can a Standards committee ever
> catch up ? I think it's roughly around '93 there were the first OO COBOL
> compilers. Along comes Russell Clarke (Australia) with a voluminous
> paper on Standard classes/collections in '96. It was passed from J4 to
> the ISO folks who made comments. Then it sat on ice - until Bill Klein
> pointed out, around 2001 (?), that Russell's paper existed. As a
> developer - first I knew of it. Some activity about two years back and
> then a 'stall' situation. A fair amount of effort put in by Thane on
> behalf of Fujitsu. Recent months a paper from Bob Karlin suggesting a
> 'broad outline' - ignoring specifics. What's going on currently in the
> background, no idea.
>
> Somebody wrote to me once he was optimistic that standard
> classes/collections could be ready by 2006, before COBOL 2008. Given
> current momentum, ( and we are already at mid-2002),
>
> In case I've got the dates wrong above, substitute following :-
>
> "Somebody wrote to me once he was optimistic that standard
> classes/collections could be ready by 2004, before COBOL 2006. Given
> current momentum, ( and we are already at mid-2002)",
>
> I f the second set of dates is the correct one, then it is even more
> unrealistic.
>
> I just don't see that happening. Bearing in mind at this juncture there
> are only three *working* implementations of this topic, (IBM uses Java
> to cover this), Hitachi, Fujitsu and Micro Focus. - and the fact that
> their developers will have written a considerable amount of code
> between say 1996 - 2006 or 2008, ( or - 2004 or 2006), why would vendors
> or developers want to go to the effort of switching to a vanilla
> flavoured (collection) standard ?
>
> Jimmy, Calgary AB
Why? The only way to grow is to extend, and with that experience,
standardize. Who says the result will be vanilla? In my opinion, the
extensions of COBOL must result from market requirements, and to do
it faster, there needs to be a front line effort. Why in the world
wait until a standard arrives? Do something when it's needed, and
work on making it uniform at a later date. Many things can change
between the times negating many needs. Think about it, and you
will remember a few things that have disappeared since 1960. It took
years to get the vendors to include SORT. Up until it was proposed
most vendors did their sorting as a separate step. None had versions
of sort, to my knowledge. Report writer has been a small step, and
now XML can do something to extend resources a great deal.
Warren Simmons, NewJersey
| |
| Warren Simmons 2004-05-24, 6:30 pm |
| Chuck Stevens wrote:
> "James J. Gavan" <jjgavan@shaw.ca> wrote in message
> news:Qqqsc.574985$oR5.345059@pd7tw3no...
>
>
>
>
> As I understand it, J4 had little choice in this matter. ANSI X3.23-1985
> allowed the implementors to describe an implementation that had only the
> most basic levels of the Nucleus, Sequential I-O and Inter-Program
> Communication modules as "fully conforming" with that standard, albeit with
> the "minimum subset", ignoring altogether the other modules (Relative and
> Indexed I-O, SORT-MERGE, and Source Text Manipulation) as well as higher
> levels like, for the Nucleus, SET 88-LEVEL TO TRUE, STRING, and nested
> REDEFINES (Level 2), and from Sequential I-O, the LINAGE clause and CLOSE
> ... NO REWIND (also Level 2).
>
> The national bodies expressed the opinion through ISO/IEC JTC1/SC22/WG4 (as
> a direct mandate) that implementations would either conform to the standard
> or they would not be in conformance, period. There are certain areas in
> which WG4 relented -- the Screen Section and related language elements
> being the most notable, allowing such language elements to be "processor
> dependent" -- but they are few and very limited (see ISO/IEC 1989:2002 pp.
> 696-697 for the list of such elements).
>
>
>
>
> Bottom line is this: Aside from the aforementioned Processor-Dependent list
> on pages 696-697, a COBOL compiler that claims to conform to this standard
> must conform to this standard, not "except for OO", not "except for
> VALIDATE", not "except for INITIALIZE WITH FILLER". Be in conformance, or
> be not in conformance. If an implementor decides that providing
> table-format VALUE clauses or support for record-level locking syntax is
> Just Too Hard, too bad; that compiler doesn't conform to the standard.
>
> If you don't like this approach of having "compliance" mean the same thing
> to everybody, then it's ISO/IEC you're going to have to convince through
> your national bodies. Moreover, as WG4 has expressly *not* allowed such a
> major change in philosophy in the standard currently under development, the
> chances of reinstating the concept of "optionality" prior to the publication
> of the *next* standard -- currently planned for late 2008 -- is pretty much
> out of the car until development starts on the standard after that.
>
>
>
>
> There are two projects being handled as Technical Reports by J4:
> "Collection class library" and "
> "Native COBOL syntax for XML". Both are expected to apply against the 2002
> standard, to be published well before the next standard (much as the two
> Amendments to the '85 standard were), and *also* to be incorporated into the
> 2008 standard when it is published. Work continues on both of these
> Technical Reports.
>
> Incidentally, the "class library" approach (as distinct from the "native
> syntax" approach) to XML was discussed at some length. The direction given
> by WG4 to J4 was that the current requirements for XML handling were
> orthogonal to the requirements for classes, and that existing COBOL users
> were better served by having support for XML using syntax already familiar
> to them than by making extensive use of object-oriented design features in
> the program a prerequisite.
>
> This is similar to the issues involving dynamic-capacity tables, which can
> clearly (and easily) be handled within implementor-defined (as well as
> user-defined) classes; the requirement here is that the changes to the
> Procedure Division of an existing program with a fixed-capacity table to
> turn that table into a dynamic-capacity table would be at most minimal, and
> preferably nonexistent, which a dynamic-capacity table (or, for that matter,
> an XML-handling) implementation requiring the use of classes would not
> fulfill.
>
> -Chuck Stevens
>
>
Chuck is telling it like it is. However, this has to do with defining
the standard, and NOT the evolution of it. In my view, the c.l.c could
do the same job the old COBOL committee did, and much better as there
was no COBOL or HISTORY then.
Warren Simmons, NewJersey
| |
| Richard 2004-05-24, 7:30 pm |
| "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote
> Interesting. I can't see where you've shown what the XMLPARSE.WS copybook
> contains. Could you post that?
Once you've found the code by searching the google group then click on
'View complete thread' and the next two messages are the .WS and a
test program.
> This is a SAX-like parser, correct?
pass.
| |
| Peter E. C. Dashwood 2004-05-24, 8:30 pm |
| David,
thank you for posting this. I have been asking for some time for
someone to post a MF COM solution.
I found it very interesting and am glad to have confirmation that the
standard components are available and can be used easily in the MF
environment.
Pete.
(no more, top post only.)
"David Sands" <david.sands@microfocus.com> wrote in message news:<c8suk4$qj2$1@hyperion.microfocus.com>...
> If your a Micro Focus Net Express user you can also leverage the MSXML
> parser using COM Automation.
>
> I have posted example code below. If you want the full example project then
> send me a note.
>
> With Net Express V4 it gets far easier as it has added COBOL Syntax for
> handling XML. You can use READ/WRITE type statements direct from COBOL (Non
> Object Oriented syntax). Using this syntax you can run the code on Win32 ,
> Unix (Server Express V4) and .Net platforms. There are docs and a tutorial
> supplied with V4 of Net Express.
>
> If your not on V4 then the code below should work OK for you.
>
> Hope this helps
> David.
> ---------->>>>>>>>>>>>>>>>>>>>>>
>
> $SET OOCTRL(+P) MFOO ANS85 CASE mf defaultbyte"00" case align"8"
> ****************************************
**************************
> * Author - Micro Focus - e-Business Support EMEA (davs)
> *
> * Purpose - Manipulate and parse data using Microsoft
> * XML Parser.
> *
> * MSXML4 is removing version independant progids
> * so this version now checks to see what is
> * registered before setting up the progid.
> * Please consult Microsoft documentation for
> * MSXML 4 for more details.
> *
> ****************************************
**************************
> CLASS-CONTROL.
>
> OLEVariant is class "olevar"
> XMLErr is class "$OLE$MSXML.IXMLDOMParseError"
> olesup is class "olesup"
> CharArray is class "chararry"
> mfoleapi is class "mfoleapi"
> XMLDoc is class xmlprogid
> .
>
> working-storage section.
>
> copy mfole.
>
> copy typelib.
>
> 01 crlf pic x(3) value x"0d0a00".
>
> 01 xmldocument object reference.
> 01 xmlParseError object reference.
> 01 xmlChildnodeList object reference.
> 01 xmlroot object reference.
> 01 xmlsinglenode object reference.
> 01 xmlfirsttracks object reference.
> 01 xmlnewtrack object reference.
> 01 xmlCD object reference.
> 01 xmlCDs object reference.
> 01 xmlartist object reference.
> 01 xmltitle object reference.
> 01 xmlattribute object reference.
> 01 xmltracks object reference.
> 01 xmltrack object reference.
> 01 ws-reason pic x(80).
> 01 ws-spaces object reference.
> 01 ws-space pic x(300) value spaces.
>
> 01 async olebool.
> 01 ws-success olebool.
>
> 01 ws-Result bool.
> 01 hres HRESULT.
>
> 01 ws-olevariant object reference.
>
> 01 theStringLength PIC 9(9) COMP-5.
> 01 theString PIC X(10) value "sample.xml".
> 01 ws-pointer usage is pointer.
> 01 ws-nodename object reference.
> 01 ws-nodenameX pic x(10).
> 01 ws-nodevalue object reference.
> 01 ws-string object reference.
> 01 ws-string2 object reference.
> 01 ws-indent pic s9(9) comp-5 value 0.
> 01 ws-dt pic x(4) comp-5.
> 01 ws-tracks-list pic x(6) value "tracks".
> 01 ws-len pic x(4) comp-5.
>
> 01 ws-nodetypename pic x(50).
>
> 01 ws-XMLDOMNamedNodeMap object reference.
>
> 01 ws-size pic 9(9) comp-5.
>
> 01 Element-flag pic 9 value 0.
> 88 element-listing value 1.
>
> ****** COBOL Data Structure for the XML
>
> 01 ws-compact-discs.
> 03 ws-compact-disc occurs 50.
> 05 ws-artist pic x(50).
> 05 ws-title pic x(50).
> 05 ws-no-of-tracks pic 9(5).
> 05 ws-tracks occurs 50.
> 07 ws-track pic x(50).
> 05 ws-price pic x(20).
>
> 01 ws-trackname pic x(50).
>
> 01 ws-current-disc pic 9(9) comp-5.
> 01 ws-current-track pic 9(9) comp-5.
>
> 01 wx-sub1 pic 9(9) comp-5.
> 01 wx-sub2 pic 9(9) comp-5.
>
> ****************************************
**************************
> * Local Storage is required to support recursive browsing of the
> * XML Document Object Model (DOM)
> * The XML DOM is a tree structure and hence lends itself to
> * using recursion.
> ****************************************
**************************
>
> local-storage section.
>
> 01 wl-IXMLDOMNode object reference.
> 01 ws-nodetype tagDOMNodeType.
> 01 ws-haschildren bool.
> 01 ws-childnodelist object reference.
> 01 ws-parentnode object reference.
>
>
> linkage section.
>
> 01 wl-reason object reference.
>
> 01 wl-node-list object reference.
>
> 01 wl-indent pic s9(9) comp-5 value 0.
>
> procedure division.
> main-control section.
>
> ***** Create the XML DOM Object
>
> ***** If MSXML4 is installed the use the PROGID for that
> ***** otherwise use a version indepentant progid that works
> ***** with versions up to 4.
>
> invoke olesup "isServerRegistered"
> using z"MSXML2.DOMDocument.4.0"
> returning hres
> if hres = 0
> move z"$OLE$MSXML2.DOMDocument.4.0" to xmlprogid
> else
> move z"$OLE$MSXML.DOMDocument" to xmlprogid
> end-if
>
> invoke XMLDoc "New" returning XMLDocument
>
> ***** Load the document syncronously
>
> move OLEFALSE to async
>
> invoke XMLDocument "setasync" using by value async
> returning ws-result
>
> invoke OLEVariant "New" returning ws-OLEVariant
>
> move length of thestring to theStringLength
> invoke ws-OLEVariant "setStringAsBytes" using
> by value theStringLength
> by reference theString
> returning ws-result
>
> ***** Now load the document
>
> invoke XMLDocument "load" using by reference thestring
> returning ws-result
>
> if ws-result = OLEFALSE
> perform XML-Load-Error
> end-if
>
> if ws-result = OLETRUE
> display "Loaded XML DOM"
> end-if
>
> ***** We have the DOM so lets add in a compact disc on the fly
> ***** before we parse the data
>
> perform insert-CD
>
> invoke XMLDocument "getchildNodes" returning xmlChildnodeList
>
> call "DisplayNode" using xmlChildnodeList
> by value ws-indent
>
>
>
> ***** Single Node selection and replacechild
>
> perform single-node-select
>
> *> Set a flag to prevent parsing to working storage twice
> set element-listing to true
> perform DisplayListofElements
>
> ***** Now get some required Elements
>
> call "GetCDData" using XMLDocument
> end-call
>
> ***** Save the amended XML
>
> invoke xmldocument "save" using z"newxmlsample.xml"
>
> invoke XMLDocument "Finalize" returning XMLDocument
>
> perform list-COBOL-structure
>
> stop run.
>
>
>
> XML-Load-Error section.
>
> ***** Use the XML DOM Error Object to get some information
> ***** on the Error.
>
> invoke XMLDocument "getparseError" returning XMLParseError
>
> invoke XMLParseError "getreason" returning ws-reason
>
> display "Error Parsing XML----->"
>
> display ws-reason
>
> stop run
> .
>
> entry "DisplayNode" using wl-node-list
> by value wl-indent.
>
> DisplayNodeMain Section.
>
> compute wl-indent = wl-indent + 1
>
> invoke wl-node-list "nextnode" returning wl-IXMLDOMNode
> perform until wl-IXMLDOMNode = null
> move spaces to ws-nodetypename
>
> invoke wl-ixmldomnode "getnodetype"
> returning ws-nodetype
>
> evaluate true
> * when NODE-INVALID of ws-nodetype
> * display "NODE-INVALID"
> when NODE-ELEMENT of ws-nodetype
> * display "NODE-ELEMENT"
> perform process-element
> * when NODE-ATTRIBUTE of ws-nodetype
> * display "NODE-ATTRIBUTE"
> * when NODE-TEXT of ws-nodetype
> * display "NODE-TEXT"
> * when NODE-CDATA-SECTION of ws-nodetype
> * display "NODE-CDATA-SECTION"
> * when NODE-ENTITY-REFERENCE of ws-nodetype
> * display "NODE-ENTITY-REFERENCE"
> * when NODE-ENTITY of ws-nodetype
> * display "NODE-ENTITY"
> * when NODE-PROCESSING-INSTRUCTION of ws-nodetype
> * display "NODE-PROCESSING-INSTRUCTION"
> * when NODE-COMMENT of ws-nodetype
> * display "NODE-COMMENT"
> * when NODE-DOCUMENT of ws-nodetype
> * display "NODE-DOCUMENT"
> * when NODE-DOCUMENT-TYPE of ws-nodetype
> * display "NODE-DOCUMENT-TYPE"
> * when NODE-DOCUMENT-FRAGMENT of ws-nodetype
> * display "NODE-DOCUMENT-FRAGMENT"
> * when NODE-NOTATION of ws-nodetype
> * display " NODE-NOTATION"
> * when other
> * display "Not Known=" ws-nodetype
> end-evaluate
>
> invoke wl-IXMLDOMNode "getnodetype"
> returning ws-nodetype
> if NODE-TEXT of ws-nodetype then
> invoke wl-IXMLDOMNode "getparentnode"
> returning ws-parentnode
> perform display-node
> end-if
>
> invoke wl-IXMLDOMNode "haschildnodes" returning
> ws-haschildren
> if ws-haschildren = OLETRUE
> invoke wl-IXMLDOMNode "getChildNodes"
> returning ws-childnodelist
> call "DisplayNode" using ws-childnodelist
> by value wl-indent
> end-if
>
> invoke wl-node-list "nextnode" returning wl-IXMLDOMNode
>
> end-perform
>
> exit program
> .
>
>
> display-node section.
> ****************************************
**************************
> * Display The Node Details
> ****************************************
**************************
>
> invoke ws-parentnode "getNodeName" returning ws-nodename
> invoke wl-IXMLDOMNode "getNodeValue" returning ws-nodevalue
>
> invoke chararray "withLength" using wl-indent
> returning ws-spaces
>
> invoke ws-spaces "setValue" using ws-space
>
> invoke ws-spaces "concat" using ws-nodename
> returning ws-string2
>
> invoke ws-string2 "concatZ" using z" = "
> returning ws-string
> invoke ws-string2 "finalize" returning ws-string2
> invoke ws-string "concat" using ws-nodevalue
> returning ws-string2
>
> invoke ws-string2 "concatZ" using crlf returning ws-string
>
> invoke ws-string "display"
>
> if not element-listing
> perform parse-to-COBOL-elements
> else
>
> ***** Tidy up unwanted objects
>
> invoke ws-nodename "finalize" returning ws-nodename
> invoke ws-nodevalue "finalize" returning ws-nodevalue
> invoke ws-string "finalize" returning ws-string
> invoke ws-string2 "finalize" returning ws-string2
> .
>
>
> process-element section.
> ****************************************
**************************
> * Display The Element Attributes
> ****************************************
**************************
>
> invoke wl-IXMLDOMNode "getattributes" returning
> ws-XMLDOMNamedNodeMap
> call "DisplayNode" using ws-XMLDOMNamedNodeMap
> by value wl-indent
> .
>
>
> DisplayListofElements section.
>
> ***** Here is how to use the getElementsByTagName method
>
> ****** Force a Method Call rather than property fetch
>
> move 0 to ws-dt
> invoke olesup "setDispatchType" using by value ws-dt
>
> invoke XMLDocument "getElementsByTagName" using
> by reference ws-tracks-list
> returning xmlChildnodeList
>
> ***** Now Lets List Out the Tracks we have got
>
> display " "
> display "Track List"
> display "----------"
>
> move 0 to ws-indent
> call "DisplayNode" using xmlChildnodeList
> by value ws-indent
> .
>
> parse-to-COBOL-elements section.
>
> ***** Lets ADD the data to a COBOL Data Structure
>
> initialize ws-nodenameX
> move length of ws-nodenameX to ws-size
>
> invoke ws-nodename "getvaluewithsize" using ws-size
> returning ws-nodenameX
> evaluate ws-nodenameX
> when "artist"
> add 1 to ws-current-disc
> move 0 to ws-no-of-tracks(ws-current-disc)
> move length of ws-artist to ws-size
> invoke ws-nodevalue "getvaluewithsize" using ws-size
> returning ws-artist(ws-current-disc)
> when "title"
> move length of ws-title to ws-size
> invoke ws-nodevalue "getvaluewithsize" using ws-size
> returning ws-title(ws-current-disc)
> when "track"
> add 1 to ws-no-of-tracks(ws-current-disc)
> move length of ws-track to ws-size
> invoke ws-nodevalue "getvaluewithsize" using ws-size
> returning ws-track(ws-current-disc
> ws-no-of-tracks(ws-current-disc))
> when "price"
> move length of ws-price to ws-size
> invoke ws-nodevalue "getvaluewithsize" using ws-size
> returning ws-price(ws-current-disc)
> when other
> continue
> end-evaluate
> .
>
>
> list-COBOL-structure section.
>
> display " "
> display " "
> display "XML parsed to COBOL Structure"
> display "-----------------------------"
> perform varying wx-sub1 from 1 by 1
> until wx-sub1 > ws-current-disc
> display "ARTIST=" ws-artist(wx-sub1)
> display "TITLE=" ws-title(wx-sub1)
> display "PRICE=" ws-price(wx-sub1)
> perform varying wx-sub2 from 1 by 1
> until wx-sub2 > ws-no-of-tracks(wx-sub1)
> display " TRACK=" ws-track(wx-sub1 wx-sub2)
> end-perform
> end-perform
> .
>
> single-node-select section.
>
> display " "
> display " "
> display "Select a Single Node and then replace it"
> display "----------------------------------------"
>
> ***** First we need the ROOT Element
>
> invoke xmldocument "getdocumentelement"
> returning xmlroot
>
> ***** Pick up the first track
>
> invoke xmlroot "selectSingleNode" using z"//track"
> returning xmlsinglenode
>
> invoke xmlsinglenode "getText" returning ws-trackname
>
> display "First Track = " ws-trackname
>
> ***** Now we will show how to replace a node
>
> ***** We will replace the first track with a new one
>
> ***** First get the tracks element as this is the parent
>
> invoke xmlroot "selectSingleNode" using z"//tracks"
> returning xmlfirsttracks
>
> invoke xmldocument "createelement" using "track"
> returning xmlnewtrack
>
> invoke xmlnewtrack "setText" using
> z"Banned from the Roxy"
>
> invoke xmlfirsttracks "replacechild" using xmlnewtrack
> xmlsinglenode
> invoke xmlsinglenode "finalize" returning xmlsinglenode
>
> ***** Read back the first track to make sure we changed it
>
> move spaces to ws-trackname
> invoke xmlroot "selectSingleNode" using z"//track"
> returning xmlsinglenode
>
> invoke xmlsinglenode "getText" returning ws-trackname
>
> display "Amended First Track = " ws-trackname
>
> invoke xmlroot "finalize" returning xmlroot *> Clean Up
> invoke xmlsinglenode "finalize" returning xmlsinglenode
> invoke xmlfirsttracks "finalize" returning xmlfirsttracks
> invoke xmlnewtrack "finalize" returning xmlnewtrack
> .
>
>
> insert-CD section.
>
> ***** Create the CD
>
> invoke xmldocument "createelement" using z"compactdisc"
> returning xmlCD
>
> ***** create an ARTIST and make it a child of the CD
>
> invoke xmldocument "createelement" using z"artist"
> returning xmlartist
> invoke xmlartist "setText" using z"CRASS"
> invoke xmldocument "createattribute" using z"type"
> returning xmlattribute
> invoke xmlattribute "setvalue" using z"band"
> invoke olesup "setDispatchType" using by value 0 size 4
> invoke xmlartist "setattributenode" using xmlattribute
> invoke xmlattribute "finalize" returning xmlattribute
>
> ***** create an title
>
> invoke xmldocument "createelement" using z"title"
> returning xmltitle
> invoke xmltitle "setText" using z"Feeding of the 5000"
> invoke xmldocument "createattribute" using z"numberoftracks"
> returning xmlattribute
> invoke xmlattribute "setvalue" using z"1"
> invoke olesup "setDispatchType" using by value 0 size 4
> invoke xmltitle "setattributenode" using xmlattribute
> invoke xmlattribute "finalize" returning xmlattribute
>
> ***** Create tracks element
>
> invoke xmldocument "createelement" using z"tracks"
> returning xmltracks
>
> ***** Create a track
>
> invoke xmldocument "createelement" using "track"
> returning xmltrack
> invoke xmltrack "settext" using z"Do they owe us a living ?"
>
> ***** Add these elements to the CD
>
> invoke xmlcd "appendchild" using xmlartist
> invoke xmlcd "appendchild" using xmltitle
> invoke xmltracks "appendchild" using xmltrack
> invoke xmlcd "appendchild" using xmltracks
> invoke xmlartist "finalize" returning xmlartist
> invoke xmltitle "finalize" returning xmltitle
> invoke xmltracks "finalize" returning xmltracks
> invoke xmltrack "finalize" returning xmltrack
>
> ***** Get the first cd and insert the new one at the start
>
> invoke xmldocument "getdocumentelement"
> returning xmlroot
>
> invoke xmlroot "selectSingleNode" using z"//compactdisc"
> returning xmlsinglenode
> invoke xmlroot "selectSingleNode" using z"//compactdiscs"
> returning xmlcds
>
> invoke xmlcds "insertbefore" using xmlcd xmlsinglenode
>
> invoke xmlroot "finalize" returning xmlroot
> invoke xmlsinglenode "finalize" returning xmlsinglenode
> invoke xmlcds "finalize" returning xmlcds
> invoke xmlcd "finalize" returning xmlcd
> .
| |
| Frank Swarbrick 2004-05-24, 8:30 pm |
| Should have known. Thanks.
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote
[color=darkred]
> Interesting. I can't see where you've shown what the XMLPARSE.WS
copybook
> contains. Could you post that?
Once you've found the code by searching the google group then click on
'View complete thread' and the next two messages are the .WS and a
test program.
> This is a SAX-like parser, correct?
pass.
| |
| James J. Gavan 2004-05-24, 9:30 pm |
| Warren Simmons wrote:
> Chuck Stevens wrote:
>
> Chuck is telling it like it is. However, this has to do with defining
> the standard, and NOT the evolution of it. In my view, the c.l.c could
> do the same job the old COBOL committee did, and much better as there
> was no COBOL or HISTORY then.
>
> Warren Simmons, NewJersey
For the minute I couldn't tell whether you were agreeing with me or not
Warren :-)
Quite right - Chuck is spelling it out like it is, constrained by rules,
initially set by a bureaucratic structure - largely to cover their
asses. (Not the J4 people but ANSI and ISO). Now Pete Dashwood had a
bloody good laugh when I said a guy got pulled in with a speeding ticket
- "Exceeding the speed limit on a bicycle, on a public footpath". Well
the same wise city council here in Calgary has introduced a whole set of
irritating by-laws just recently, barbecues - party-time finishes at
midnight, no letting smoke drift into your neighbour's place, etc.,
etc., and the really best one "You CANNOT put doggy poop in your garden
compost". Now with a population getting up there close to one million
and ONLY 46 by-law inspectors for the city - you can imagine how
effectively that last one is going to be controlled ! (Visions of
surreptitious people creeping into your backyard/garden in the wee small
hours, with a set of weighing scales - weight is important evidence).
Let's try a hypothetical on you Chuck. Unisys God bless 'em. Your think
tank comes up with a super duper idea on an OO Data Base - whatever
that means, (they are talked about but I'm not aware of any). Management
buys into it, and as you pursue the idea it truly firms up and is going
to be a winner. Dah, Dah ! 'Unisys is proud to announce that as of
....ccyy/mm/dd. we have the Unisys OO Database with all the following
glowing features". You are going to sell it like hell - and you ain't
waiting for nobody, but nobody !
Hmmm.... interesting say the other J4 guys (and girl). "You crafty SOB
Chuck, you kept that tight-lipped". To them it makes real sense this
should be another module in COBOL. Committee pores over what you have,
does a bib and tuck here and there and hopefully come up with something
which is close enough to your original that it doesn't involve you in
major change. However, not likely I know (or hope !), you deliver a
horse and by consensus J4 turns it into a camel. Aren't you,
(well I'm assuming it wont be 'You' but guys further up the Unisys totem
pole) going to tell IBM et al to "Go take a hike ! We've got 20,000
installations using what we dreamed up".
Take that hypothetical - COBOL conforming or not - and your initial one
isn't 'cos it doesn't have J4 blessing, it might just make more sense
for each to produce their own OO Database - the competitiveness will
engender new techniques. Perhaps some 10 years down the road , the
participants in J4 could have a meeting on this topic - do some horse
trading - and then perhaps come up with the conforming model..
(Meanwhile - I await intrigued until there's some documentation - I'm
hoping my M/F "collections" don't get revamped as a zebra or camel !)
By 'horse trading", making concessions, conceding certain things remain
intact even though all participants don't buy into some of the smaller
features. Horse trading - not putting a blank sheet of paper on the
table and starting from scratch, which so far has happend several times
with collections. If Bill Klein hadn't 'resurrected' Russell's proposal,
at this stage there wouldn't even be a piece of blank paper on the table !
Your off the hook Chuck - happend way before you got involved - for your
sins :-)
Jimmy, Calgary AB
| |
| Howard Brazee 2004-05-25, 11:30 am |
|
On 24-May-2004, Warren Simmons <wsimmons5@optonline.net> wrote:
> Why? The only way to grow is to extend, and with that experience,
> standardize. Who says the result will be vanilla? In my opinion, the
> extensions of COBOL must result from market requirements, and to do
> it faster, there needs to be a front line effort.
Even with the standards, I don't see mainframe shops moving towards new
compilers without Y2K type needs - and mainframe manufacturers are reluctant to
spend much in upgrading their compilers without a perceived market for their
product.
Of course, if the mainframe manufacturers were serious about selling their
products as web servers, then they should re-think this strategy. But how
likely is that?
| |
| Warren Simmons 2004-05-25, 2:30 pm |
| Howard Brazee wrote:
> On 24-May-2004, Warren Simmons <wsimmons5@optonline.net> wrote:
>
>
>
>
> Even with the standards, I don't see mainframe shops moving towards new
> compilers without Y2K type needs - and mainframe manufacturers are reluctant to
> spend much in upgrading their compilers without a perceived market for their
> product.
>
> Of course, if the mainframe manufacturers were serious about selling their
> products as web servers, then they should re-think this strategy. But how
> likely is that?
Good point.
Yet the subject should be not what someone uses, but what someone is
planning to use, or sing to use, and the support for that. All I'm
saying is that the compiler does not support such and such, and thus
removes some new device or method from consideration, vendors and users
should expect to be asked to or required to extend the interface in some
manner. Those extensions can take place in a preprocessor with simulated
current Cobol substitution OR, by creating an extension to service the
needs, and let the market and the demand forge the future standard of
that feature in COBOL. The standards group(S) do not need to be involved
unless one or more of them want something and propose it to their
vendors, and submit it to be standardized at some point.
A great deal of space is being used here to debate the time it takes to
do this or that, and which is best. If the output is right, the time it
takes in the realm of pico seconds or whatever, is not as important as
trying to cooperating on some point of possible development.
Warren Simmons NJersey
| |
| Howard Brazee 2004-05-25, 2:30 pm |
|
On 25-May-2004, Warren Simmons <wsimmons5@optonline.net> wrote:
> Yet the subject should be not what someone uses, but what someone is
> planning to use, or sing to use, and the support for that. All I'm
> saying is that the compiler does not support such and such, and thus
> removes some new device or method from consideration, vendors and users
> should expect to be asked to or required to extend the interface in some
> manner.
I don't like library based languages. We can learn all of CoBOL, but we can't
learn all of a library. But libraries are easy to add to. Want an XML
parser? There must be scores of them written that look like native parts of
C++.
We can do this with CoBOL, but our mindset is wrong. Write an XML parsing
object and try to get a mainframe CoBOL shop to use it. They are much more
likely to add another computer, export the data from the mainframe to that Unix
server, and use Java on that server. We categorize things too much.
| |
| Warren Simmons 2004-05-25, 2:30 pm |
| Howard Brazee wrote:
> On 25-May-2004, Warren Simmons <wsimmons5@optonline.net> wrote:
>
>
>
>
> I don't like library based languages. We can learn all of CoBOL, but we can't
> learn all of a library. But libraries are easy to add to. Want an XML
> parser? There must be scores of them written that look like native parts of
> C++.
>
> We can do this with CoBOL, but our mindset is wrong. Write an XML parsing
> object and try to get a mainframe CoBOL shop to use it. They are much more
> likely to add another computer, export the data from the mainframe to that Unix
> server, and use Java on that server. We categorize things too much.
You well may be right. I don't like data files that can not be passed
down to new systems without the source code. My solution to that is to
bring back the Labels are Standard and add a definition of what is
expected with that declaration. None was ever created so the idea is
wide open. My suggestion is to say something like this:
The Labels are Standard clause must be present to qualify as a standard
COBOL program. The purpose of this clause is to provide a means to
declare that data files , both, input and output will have labels and
what they consist of for the standard. My suggestion would be aimed
at removing the problem of trying to convert from one media to another
without the source program. I'd do that by requiring each FD's complete
description would be a part of the data file as both the beginning file
label, intermediate file label, and if deemed a good idea, the ending
file label. That would close one of the loopholes in the current
standard that should not occur if the objective is to make the effort
to clarify the system definition really work.
And now that I've had some time to do some research, I'd replace the
DataBase feature with the Berkley DB system. It would be a great system
to standardize on, and allow users to choose a method that fit the
problem instead of the current data base method.
However, as most people are aware, there is little influence unless you
have big dollars to back you up. COBOL users have no central
involvement with the development today, and in my view, COBOL is getting
lost in the sands of time.
Warren Simmons NJersey
| |
| Robert Wagner 2004-05-25, 6:30 pm |
| Warren Simmons <wsimmons5@optonline.net> wrote:
> I don't like data files that can not be passed
>down to new systems without the source code. My solution to that is to
>bring back the Labels are Standard and add a definition of what is
>expected with that declaration. None was ever created so the idea is
>wide open.
XML files meet your requirement. They're self-defining. They are widely used for
data interchange, for example in the data warehousing industry. They have
largely replaced EDI, which requires a document describing a 'standard' layout.
There were hundreds of 'standards' and variations thereon, which is no standard
at all.
XML will soon be added to the Cobol Standard.
| |
| James J. Gavan 2004-05-25, 10:30 pm |
| Robert Wagner wrote:
>Warren Simmons <wsimmons5@optonline.net> wrote:
>
>
>
>
>
>XML files meet your requirement. They're self-defining. They are widely used for
>data interchange, for example in the data warehousing industry. They have
>largely replaced EDI, which requires a document describing a 'standard' layout.
>There were hundreds of 'standards' and variations thereon, which is no standard
>at all.
>
>XML will soon be added to the Cobol Standard.
>
>
Boy with all those years in COBOL, when it comes to the Standards you
are a real newbie at the game. Care to put your money on what "soon" means ?
Jimmy, Calgary AB
| |
| James J. Gavan 2004-05-25, 11:30 pm |
| Warren Simmons wrote:
>
> However, as most people are aware, there is little influence unless you
> have big dollars to back you up. COBOL users have no central
> involvement with the development today, and in my view, COBOL is getting
> lost in the sands of time.
>
> Warren Simmons NJersey
Warren,
This thread has sure got you out of any Rip van Winkle mode. You're
rarin' to go :-) . Just to take your last comment. Any participation
is not gong to come from this group. God knows, Bill has continuously
urged people to get involved. Sadly it wont happen I would suggest most
of the recommendations to J4 come from people who never frequent c.l..c.
Let's try this on our two legal-beagles, Bill and Chuck - to see if
they can fault it.. First think on the phrase :-
"What the Lord giveth, the Lord taketh away".
I'm going to use "J4" to represent the various committee names,
including the one you sat on. (It really serves no purpose, other than
historical accuracy, quoting the individual names). Nor am I going to
quote dates as milestones - just the sequencing.
Back in late '50s, J4 did first standard in something like six months.
DOD wanted a COMMON language approach. certification to this standard
meant vendors could get DOD contracts.. (Sobering thought - some 30
years after inception the syntax for Smalltalk can and has been printed
on one page. Agreed you have to supplement that with a knowledge of
classes and methods you can use).
Initially J4 had some 20 participants the objective being to arrive at
a specification that compiler vendors could use as a working document.
Subsequent to that it made sense to get ANSI approval, GHC (Good
Housekeeping Certification). Having the ANSI GHC meant your product had
credibility.
Subsequent to that, around '88 the US ANSI (J4 team) submitted a
proposal to the ISO for universality. Jerome Garfunkel refers to that as
the Vienna "St Valentine's Day Massacre". Problems with the 'honeymoon'
but WG4 Committee came into being as an offshoot of ISO - the purpose to
give a universal blessing to the COBOL standard.
Good liaison between WG4 and J4 because Ann Bennett/Wallace who chaired
WG4 (as a US representative) is also an active participant in J4
(representing IBM). Ann resigned from the WG4 chair but still sits on
J4. So now we have Don Schricker as joint chair of both WG4 (US
representative) and J4 (Micro Focus representative). Being chair of
both suggests to me there is a good meld.
Government at any level from the village pump all the way up to a
national government, (and this includes commercial organizations with
some 4 to 5 decades of existence), arrive at formalised procedures - a
bureaucracy which creates inertia..
"The rules are the rules and it can't be done any other way". So both J4
and WG4 have to follow the rules for ANSI and ISO respectively. Do it
right, then HQ approval and their recommendations become the ANSI/ISO
standard. Note - I doubt there is very little interference from above -
our two COBOL committees are the specialists and ANSI and ISO accept
their recommendations.
There's more involved with feedback both directions, but as I currently
understand it, on behalf of the international community WG4(ISO) sets
the criteria as to what the J4(ANSI) team should study, including
prioritizing. However, J4 have recently performed this exercise for
themselves slotting all the 'bumph' into (a) Now, (b) Later (c) Hmmm
Well... maybe later - or perhaps never.
The specification cycle is (1) J4 designs (2) has re-thinks, (3) settles
on a draft (3) submits to WG4 for comment. From (3) onwards, probably a
fair bit of to-ing and fro-ing. Eventually the spec is clean enough that
J4 can submit to ANSI as the
current COBOL Spec. Then it goes to WG4 for comment by their machinery,
and is eventually submitted upwards to ISO.
We now have a spec for COBOL 2XXX which is ANSI/ISO compliant.
Note like any good chain of command, military or commercial, there is
delegation to specialists. So both WG4 and J4 are the two specialist
teams for COBOL. As the specialists they set the stage for what the
COBOL standard will be. (I did a check against RM/COBOL '74 which shows
a FIPS Table of what I would call modules, 12 of them. Of course there
are now more, plus currently XML and "standard OO classes" in the pipeline.
Within the 'rules' J4/WG4 can set what COBOL is about, what is included
as a *MUST* and what can be optional. Nor do
J4/WG4 need to impede development of individual modules promoted by
individiual vendors. So they can set a pattern like :-
- This is a MUST ( the truly basic set to be called COBOL )
- This is an optional
- You are working on your own. Let us know some way down the road if you
want to offer it as a proposal as part of Standard COBOL
Insisting everything has to be a *MUST* for ANSI/ISO conformance
indirectly implies a 'group monopoly' The vendors who make machines can
gamble on a large staff to support development of software. As Bill
pointed out frequently in the past it is killer for the compiler-only
vendors - which has led in the past to 'freebies', to get developers
hooked, and subsequently up the price, or even charge runtime fees. As
developers we don't like it - but how are they to survive. I haven't yet
mentioned the cost to the Open Source/GNU developers like Tim Josling in
Australia or Kevin with KOBOL.. An insistence on a rigid set of rules
that says all modules must be implemented to be COBOL 2002 compliant is
regressive.
I'll accept what Chuck wrote - "Rules are rules". He was working from
the DA's office as a prosecuting lawyer. He decides to go off into
private practice - now as a defence lawyer - same rules but he sees them
in a different light.. We don't want vendors shooting off, (forgotten
their name), and substituting completely different words for READ,
WRITE, REWRITE etc.
But nor do we want something that is so inflexible it stifles our
compiler vendors.
"What the Lord Giveth, the Lord Taketh Away".
WG4/J4 have the mandate as the specialists to change the pattern,
within existing ISO/ANSI rules. Remember the name of the game is a
*realistic* specification for vendors to produce compilers, to OUR, (
the COBOL communities satisfaction - quite simple; if they please us
then their cash registers start to ring). If a vendor chooses to opt out
of certain features that is largely based on a money consideration. They
do of course face the danger of being bypassed as developers move to
wider-ranged compilers.( Note that even within the existing rules,
modules can be removed, albeit as a two-stage process)..
If you persist by starting out with a negative mindset then you can
give me all sorts of excuses why it can't be done. Some years now since
I checked - go to the ANSI site; their prime objective is to protect
U.S. consumes from poor quality/dangerous products, say lousy
specifications for wiring resulting in consumers getting eltrocuted.
Plus specifics for nuts and bolts and Material Types that I use in my
corrosion application. Languages can fit into the ANSI family for
'administrative' reasons , but there is absolutely no way a language
should be treated like nuts and bolts.
(1) Can it be done? Has it been done ? The answer is 'YES' to both.
Show me the Communications module in COBOL 2002.
(2) When are we going to see the first 100% COBOL 2002 compiler -
perhaps never ?
Meanwhile I'll continue to use my non-conforming compiler. Still, that
has whistles and bells that 2002 doesn't even include.
Jimmy, Calgary AB
| |
| Richard 2004-05-26, 12:30 am |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> XML files meet your requirement. They're self-defining.
They are only 'self defining' to the extent that they can have tag
names and attribute names which are _human_ readable, mostly.
> They are widely used for
> data interchange, for example in the data warehousing industry. They have
> largely replaced EDI, which requires a document describing a 'standard' layout.
> There were hundreds of 'standards' and variations thereon, which is no standard
> at all.
The XML also needs a 'standard', called an application. While the
names can be read, that does not make them 'understandable' to the
computer. There still needs a document to define what terms must be
used and what they mean.
| |
| Peter E. C. Dashwood 2004-05-26, 6:30 am |
| An interesting and colourful attempt to rewrite history, Jimmy.
However, some of us who were there and actually remember events (and
Warren was certainly even closer than I was) know that what you
describe is not what happened.
There was no "J4" in 1958. It was the Conference on Data Systems
Languages (CODASYL) who created COBOL 59. And what an exemplary job
they did of it.
ANSI had nothing to do with COBOL until 15 years after that, and it
was COBOL 74 that could first be described as ANSI COBOL.
"What the Lord giveth , the Lord taketh away..."
is a gross misquotation from the funeral service of various Christian
churches.
"The Lord giveth, and the Lord taketh away. Blessed be the name of the
Lord."
Removing "What" changes the meaning significantly and attempting to
equate J4 with God, is ludicrous even to an Atheist like me.:-)
Having corrected (some of) the inaccuracies, let's look at the ideas
you are trying to get across.
Your main theme: J4/ANSI have the final say about what is or is not
COBOL.
Only if we let them. For many of us, J4 is an anachronistic
irrelevance. I buy COBOL based on the features it provides. I couldn't
care one iota whether it is ANSI compliant or not. Witness the recent
quotes here from an IBM spokesman regarding XML (oops, accidentally
back on topic...<G> ), if the market place want something, vendors will
provide it because it makes economic sense to do so. J4 lost the right
to call these shots when they took 17 years to produce a standard.
Warren has it right when he says the vendors should do what the market
require and let the standardization happen later, if it needs to...
Thankfully, that is what has really happened and the only reason that
COBOL is alive today is because vendors saw there was a requirement
and met it. Nothing to do with J4, who were too busy deciding whether
the next boondoggle should be in Las Vegas or Miami to do anything as
mundane as prepare a COBOL a standard.
Bugger! I thought I had let this go, and you started me again!
OK, I'm calm now. No more posts about J4...
<snip>
> So now we have Don Schricker as joint chair of both WG4 (US
> representative) and J4 (Micro Focus representative). Being chair of
> both suggests to me there is a good meld.
<<<
It suggests to me that MicroFocus COBOL is likely to become the
"approved" standard... fortunately, it really doesn't matter because
it is all bullshit anyway.
> Government at any level from the village pump all the way up to a
> national government, (and this includes commercial organizations with
> some 4 to 5 decades of existence), arrive at formalised procedures - a
> bureaucracy which creates inertia..
> "The rules are the rules and it can't be done any other way". So both J4
> and WG4 have to follow the rules for ANSI and ISO respectively. Do it
> right, then HQ approval and their recommendations become the ANSI/ISO
> standard. Note - I doubt there is very little interference from above -
> our two COBOL committees are the specialists and ANSI and ISO accept
> their recommendations.
>
> There's more involved with feedback both directions, but as I currently
> understand it, on behalf of the international community WG4(ISO) sets
> the criteria as to what the J4(ANSI) team should study, including
> prioritizing. However, J4 have recently performed this exercise for
> themselves slotting all the 'bumph' into (a) Now, (b) Later (c) Hmmm
> Well... maybe later - or perhaps never.
>
> The specification cycle is (1) J4 designs (2) has re-thinks, (3) settles
> on a draft (3) submits to WG4 for comment. From (3) onwards, probably a
> fair bit of to-ing and fro-ing. Eventually the spec is clean enough that
> J4 can submit to ANSI as the
> current COBOL Spec. Then it goes to WG4 for comment by their machinery,
> and is eventually submitted upwards to ISO.
> We now have a spec for COBOL 2XXX which is ANSI/ISO compliant.
>
> Note like any good chain of command, military or commercial, there is
> delegation to specialists. So both WG4 and J4 are the two specialist
> teams for COBOL. As the specialists they set the stage for what the
> COBOL standard will be. (I did a check against RM/COBOL '74 which shows
> a FIPS Table of what I would call modules, 12 of them. Of course there
> are now more, plus currently XML and "standard OO classes" in the pipeline.
>
> Within the 'rules' J4/WG4 can set what COBOL is about, what is included
> as a *MUST* and what can be optional. Nor do
> J4/WG4 need to impede development of individual modules promoted by
> individiual vendors. So they can set a pattern like :-
>
> - This is a MUST ( the truly basic set to be called COBOL )
> - This is an optional
> - You are working on your own. Let us know some way down the road if you
> want to offer it as a proposal as part of Standard COBOL
Nightmare isn't it?
Can you blame people (vendors and developers) from giving up on it?[color=darkred]
>
> Insisting everything has to be a *MUST* for ANSI/ISO conformance
> indirectly implies a 'group monopoly' The vendors who make machines can
> gamble on a large staff to support development of software. As Bill
> pointed out frequently in the past it is killer for the compiler-only
> vendors - which has led in the past to 'freebies', to get developers
> hooked, and subsequently up the price, or even charge runtime fees. As
> developers we don't like it - but how are they to survive. I haven't yet
> mentioned the cost to the Open Source/GNU developers like Tim Josling in
> Australia or Kevin with KOBOL.. An insistence on a rigid set of rules
> that says all modules must be implemented to be COBOL 2002 compliant is
> regressive.
>
> I'll accept what Chuck wrote - "Rules are rules". He was working from
> the DA's office as a prosecuting lawyer. He decides to go off into
> private practice - now as a defence lawyer - same rules but he sees them
> in a different light.. We don't want vendors shooting off, (forgotten
> their name), and substituting completely different words for READ,
> WRITE, REWRITE etc.
>
Why not? The market place will vote with its feet. If one vendor
decided "PERUSE" was a better verb than "READ", I would have no
problem with him implenting that. Unless he had some outstanding,
unique, other features, and I was convinced they were worth doing a
precompile pass and changing all my exiating source READs to PERUSEs,
I would be unlikely to buy his product. But I don't need a standard to
mandate that he MUST use READ.
> But nor do we want something that is so inflexible it stifles our
> compiler vendors.
>
> "What the Lord Giveth, the Lord Taketh Away".
>
> WG4/J4 have the mandate as the specialists to change the pattern,
> within existing ISO/ANSI rules. Remember the name of the game is a
> *realistic* specification for vendors to produce compilers, to OUR, (
> the COBOL communities satisfaction - quite simple; if they please us
> then their cash registers start to ring). If a vendor chooses to opt out
> of certain features that is largely based on a money consideration. They
> do of course face the danger of being bypassed as developers move to
> wider-ranged compilers.( Note that even within the existing rules,
> modules can be removed, albeit as a two-stage process)..
>
> If you persist by starting out with a negative mindset then you can
> give me all sorts of excuses why it can't be done. Some years now since
> I checked - go to the ANSI site; their prime objective is to protect
> U.S. consumes from poor quality/dangerous products, say lousy
> specifications for wiring resulting in consumers getting eltrocuted.
> Plus specifics for nuts and bolts and Material Types that I use in my
> corrosion application. Languages can fit into the ANSI family for
> 'administrative' reasons , but there is absolutely no way a language
> should be treated like nuts and bolts.
<<<
I agree wholeheartedly. So much so that I don't even think a
commercial computer programming language NEEDS to have an ANSI
standard. I would buy a version of COBOL whether it was ANSI compliant
or not, provided it did what I need and want.
> (1) Can it be done? Has it been done ? The answer is 'YES' to both.
> Show me the Communications module in COBOL 2002.
>
> (2) When are we going to see the first 100% COBOL 2002 compiler -
> perhaps never ?
>
> Meanwhile I'll continue to use my non-conforming compiler. Still, that
> has whistles and bells that 2002 doesn't even include.
>
I rest my case...
Pete.
| |
| Howard Brazee 2004-05-26, 11:30 am |
|
On 25-May-2004, "James J. Gavan" <jjgavan@shaw.ca> wrote:
> Boy with all those years in COBOL, when it comes to the Standards you
> are a real newbie at the game. Care to put your money on what "soon" means ?
LOL!
Or better yet, when big CoBOL shops decide to upgrade to a "new" standard
without Y2K like urgency?
| |
| Chuck Stevens 2004-05-26, 1:30 pm |
| A couple of quibbles, procedural and technical:
"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:eWSsc.556744$Pk3.494339@pd7tw1no...
> So now we have Don Schricker as joint chair of both WG4 (US
> representative) and J4 (Micro Focus representative). Being chair of
> both suggests to me there is a good meld.
I agree, but technically Don (and Ann before him) was *convener* of WG4.
> Do it
> right, then HQ approval and their recommendations become the ANSI/ISO
> standard.
There is a law -- I forget the name of it -- that basically says that if
there's an ISO standard on a subject, that standard is presumed to be in
effect for the US. That law took effect after the '85 standard, but before
the 2002 standard. For the '85 and prior standards the US adopted the
standard and ISO followed suit; the laws are different now. I believe it
(literally) takes an act of congress for the US to decide to come up with a
different standard on a topic from one that ISO has already adopted.
> There's more involved with feedback both directions, but as I currently
> understand it, on behalf of the international community WG4(ISO) sets
> the criteria as to what the J4(ANSI) team should study, including
> prioritizing. However, J4 have recently performed this exercise for
> themselves slotting all the 'bumph' into (a) Now, (b) Later (c) Hmmm
> Well... maybe later - or perhaps never.
No, that's not right. J4 has suggested such priorities to WG4, but it is
WG4 that established the final rankings. And the distinction between "must
have" and "would be nice if J4 has time" in the priority list for the 2008
standard was established *by WG4* at the WG4 meeting last year from a much
longer list of candidate features.
> The specification cycle is (1) J4 designs (2) has re-thinks, (3) settles
> on a draft (3) submits to WG4 for comment.
There's a step before that: (0) WG4 specifies.
> Eventually the spec is clean enough that
> J4 can submit to ANSI as the
> current COBOL Spec.
> Then it goes to WG4 for comment by their machinery.
> and is eventually submitted upwards to ISO.
No, I think the steps are "committee draft", "final committee draft", "draft
international standard", "final draft international standard",
"international standard". It doesn't become an *ANSI* specification until
after it's been adopted by *ISO*. At no point does J4 limit comments to US
participants; the comments on any draft, whether part of the formal process
(DIS and FDIS in particular) or the less-formal (CD, FCD) are welcome from
anywhere. Ballots on whether an FDIS becomes an IS are by participant
nation.
> We now have a spec for COBOL 2XXX which is ANSI/ISO compliant.
As indicated above, we *first* have a spec defining what is ISO compliant,
and barring an act of Congress that spec then automatically becomes the
defining document for what is ANSI compliant.
> Note like any good chain of command, military or commercial, there is
> delegation to specialists. So both WG4 and J4 are the two specialist
> teams for COBOL. As the specialists they set the stage for what the
> COBOL standard will be.
WG4 says what it will contain; it's J4 that works out the technical details,
and WG4 again that decides whether that's what they wanted. E.g., WG4
wanted longer alphanumeric literals for the 2008 standard; J4 has proposed
raising that limit from 160 characters to 8191 and the associated
pseudo-text limit from 322 to 65,535. It remains to be seen whether WG4
will agree that these new limits as meeting their (foreseen and unforeseen)
requirements; I expect such matters will be discussed at the WG4 meeting in
October.
>(I did a check against RM/COBOL '74 which shows
> a FIPS Table of what I would call modules, 12 of them. Of course there
> are now more, plus currently XML and "standard OO classes" in the
pipeline.
There are indeed modules in the 1974 standard. There are also modules in
the 1985 standard (and one more was added in '89). There are *no modules*
in the 2002 standard.
> Within the 'rules' J4/WG4 can set what COBOL is about, what is included
> as a *MUST* and what can be optional. Nor do
> J4/WG4 need to impede development of individual modules promoted by
> individiual vendors. So they can set a pattern like :-
>
> - This is a MUST ( the truly basic set to be called COBOL )
> - This is an optional
That was once the case, but is no more. The only "optional" parts of 2002
COBOL that I know of are those associated with the Communications Facility,
which is also marked as "obsolete".
There are "processor dependent" elements, but the list is quite short; the
most prominent ones on it are the "green-screen-oriented" Screen Section and
the binary and packed-decimal USAGEs -- the idea being that if the
"operating environment" doesn't support these particular features, an
implementation for that environment need not support the syntax associated
with them. For instance: it is possible to write a conformant COBOL
program for an operating environment that has no mass storage I/O device.
Need a compiler for such an environment support the DELETE statement? The
standard says it needn't.
> Insisting everything has to be a *MUST* for ANSI/ISO conformance
> indirectly implies a 'group monopoly'
It is my belief and my understanding that the sentiment against
"optionality" and modularization in the COBOL standard did *not* come from
the COBOL compiler vendors but rather from some of the national standards
bodies.
It is also my belief that the specific stimulus for this change was the
optionality of the Report Writer module, and the *failure* of a number of
significant compiler vendors to implement the module (in part or in whole),
despite the presence of the specifications in the '68, '74 and '85
standards. It's not the compiler vendors that fought for non-optionality,
it's the users speaking through their national standards bodies.
> The vendors who make machines can
> gamble on a large staff to support development of software.
Could, but that doesn't mean they will, particularly if they aren't getting
a big push from their users to provide that feature content.
> As Bill
> pointed out frequently in the past it is killer for the compiler-only
> vendors - which has led in the past to 'freebies', to get developers
> hooked, and subsequently up the price, or even charge runtime fees. As
> developers we don't like it - but how are they to survive. I haven't yet
> mentioned the cost to the Open Source/GNU developers like Tim Josling in
> Australia or Kevin with KOBOL.. An insistence on a rigid set of rules
> that says all modules must be implemented to be COBOL 2002 compliant is
> regressive.
I could be convinced they went too far, maybe, but I think having a STRING
statement receive a syntax error simply because of its presence in the
program from a "compliant" COBOL compiler (as was permissible in both '74
and '85 standards) is WAY too far the other way.
> I'll accept what Chuck wrote - "Rules are rules". He was working from
> the DA's office as a prosecuting lawyer. He decides to go off into
> private practice - now as a defence lawyer - same rules but he sees them
> in a different light.. We don't want vendors shooting off, (forgotten
> their name), and substituting completely different words for READ,
> WRITE, REWRITE etc.
There's nothing to prevent the vendors from doing that now, or in the
future, *so long as* they *also* provide the specified functionality for
READ, WRITE, REWRITE, etc. All the standard requires is that the user be
able to ask the compiler to "flag" such syntax as nonconformant.
> If a vendor chooses to opt out
> of certain features that is largely based on a money consideration.
If a vendor chooses to opt out of certain features, they cannot claim
compliance with the standard.
> They
> do of course face the danger of being bypassed as developers move to
> wider-ranged compilers.( Note that even within the existing rules,
> modules can be removed, albeit as a two-stage process)..
There are no modules in the current rules. And features can be "deprecated"
without being removed. J4 and WG4 are very sensitive to the costs *to
users* of changing existing programs; it is for that reason that the 2002
standard suggests that "MOVE QUOTES TO NUMERIC-ITEM" be avoided, but does
not forbid the user from compiling programs that contain such statements.
> (1) Can it be done? Has it been done ? The answer is 'YES' to both.
> Show me the Communications module in COBOL 2002.
It's "Communications facility", and it's "obsolete" as well as "optional".
Justification was, so far as I know, that *nobody* had an implementation of
the "pure" syntax that anybody had actually used in practice. (I would
contest that, as the Burroughs B1000 SMCS and GEMCOS environments both
supported fully-compliant ANSI-74 communications syntax, but as a practical
matter those systems are no longer supported, so the justification is
accurate for 2002 COBOL if the verb phrase is changed to "was actually
using").
> (2) When are we going to see the first 100% COBOL 2002 compiler -
> perhaps never ?
Oh, I think you will, and fairly soon. I know of more than one compiler
vendor who is *actively* striving to do so.
> Meanwhile I'll continue to use my non-conforming compiler. Still, that
> has whistles and bells that 2002 doesn't even include.
So do most. Implementor extensions aren't forbidden by the standard.
-Chuck Stevens
| |
| James J. Gavan 2004-05-26, 5:30 pm |
| Peter E. C. Dashwood wrote:
>An interesting and colourful attempt to rewrite history, Jimmy.
>
>
You stupid bugger !. Re-read my message. I said I was using the term
"J4" to represent ALL predecessor organisations. I wasn't writing a
thesis to get a doctorate - which WOULD have required me referencing the
specific committee names, dates, blah, blah. Like it or not I was using
a shorthand version to convey the background. in summary form -
particularly to the younger members of this group who wouldn't be aware
of the history - the prime purpose being to suggest things could be
changed within existing rules. (If I read Chuck correctly - seems like
you now have to go to the US Supreme Court, with a challenge, to change
anything. Your chances of success in the Supreme Court = "failure" -
it's inconceivable they would contradict an international body like ISO)..
>However, some of us who were there and actually remember events (and
>Warren was certainly even closer than I was) know that what you
>describe is not what happened.
>
>
>
Young folks might be impressed with the fact you were there at the
begiining. But the repetiion of that fact and how programming worked
back then did get a little tiresome. I did note at least one 'mature'
user took you to task with, "Well that might have been the case when
your were working on mainframes in nineteen-canteen. But it's a
different ballpark with mainframes in the here and NOW". Then you went
silent.
With your passionate dislike of ANYTHING to do with the Standards - it
is impossible to expect you to be rational.
I sometimes think you have a problem being rational about a number of
topics. I recall you saying years ago, "I did belong to the NZ Computer
Society. But I left - they were a bunch of ......!" , (the word didn't
begin with an "a"). How many other "bunch of ......", have you come
across in your career. You remind me of the seaside postcard of a
platoon with one guy grinning, "Hello Mum. They are all out of step
except me".
I am *NOT* happy either with the Standards procedures, but I do think
there has been an attempt to make amends.. I consider the following a
particularly asinine comment :-
><<<
>It suggests to me that MicroFocus COBOL is likely to become the
>"approved" standard... fortunately, it really doesn't matter because
>it is all bullshit anyway.
>
>
You will recall I was at Newbury in 2000 for the J4 meeting - and I
conveyed my feelings back then. Now I don't recall whether I indicated
this to that "group" back then - if not - here's a repeat of my
observations. Acting as the chair for J4, (and generally speaking, for
any committee, a chairman has to try and be impartial), I *felt* that
if anything, Don was 'over impartial', perhaps to the detriment of his
employers. My wording, but as somebody once observed as regards the J4
team, "There is a mutual respect of one another for their
professionalism, but at the same time don't expect buddy-buddy
relationships; after all, they are there representing competitive
companies". I would suggest from that, none of them is going to let
anybody, including the current chairman, try and slip a fast one in
front of them.
The driving force, (prioritizing), now that Chuck has corrected the
sequencing, are those ISO members. In large part, without any
statistics, I expect it will be 'Europeans' using mainframes - primarily
IBM and maybe Unisys users. (Think on that - the small guys in Europe,
PC users, don't have the time or money to get involved in ISO-claptrap).
It would follow from that the 'task' or 'driving force' within J4 will
follow that pattern - not some guy from a PC-oriented company. (BTW - I
scratched out from my previous message.... "Don got the other job
Covernor (chair) of WG4 in all probability because no other bugger
wanted it ! ...." . Not difficult to guess that there wont be too many
takers for the job that Chuck is doing - Secretary - possibly more
onerous than the Chairman's job !).
Certainly at this point in time the J4 empahsis is on Mainframe features
- of which XML is one. Yes the features are not restricted just | | |