Re: What could J4 (or WG4) do (was: INSPECT and TRAILING syntax

I read and considered this at length, Chuck. You make some good points, but
the overall case is not persuasive.

Some comments below...

"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:e4l8g3$2kjv$1@xxxxxxxxxxxxxxxxxxxxxxx
Whether there are things "that COULD be done to improve the chances of
either the '02 or '08 Standards being implemented" is at least somewhat
orthogonal to the question as to whether I, or the other members of J4, or
the National Body representation to WG4, have the resources to carry out
such tasks.

Then the first priority of the committee should be to get properly resourced
in order to do the job, right?

With the Unisys-related duties I have as an employee of that company, I
consider myself lucky to fit my *current* duties for J4 and WG4
accomplished. I am quite sure the same is true for the other
"corporate-sponsored" members of J4, and doubly true for those members of
J4 who are CEO's of the companies they represent.

While it is important to have senior management on the committee, that does
explain why very little actually gets DONE! CEOs are not people who are used
to DOING things... "I'll get my people to talk to your people..." They will
happily sit on a committee and protect their strategic COBOL interests but
none of that will get a new construct in the language or a poll done or a
paper written...

I know of nobody on J4 whose sole responsibility to their companies is the
COBOL standardization process, much less anyone whose primary financial
support stems from participating in that process.


So why are they there?

As to your suggestions: paraphrasing a certain official in the ISO/IEC
hierarchy: "You shot it, you drag it home!" ;-)

A colourful aphorism. See my comments on it elsewhere in this thread.

For your item 1, I for one do not have the resources to perform such a
survey, nor do I believe any of the other five members of J4 have them.

What resources? It involves sending an email to all the COBOL vendors.
(presumably, J4 has a list of contacts?)

It is a very good and useful idea and it SHOULD be done. It might be a bit
unrealistic to expect them to tick boxes for every facility, but it could be
worded so as to elicit the functions that they perceive as being most
difficult, and therefore unlikely to be implemented.


Since you have clear ideas as to how this can be accomplished, maybe you'd
be the appropriate person to carry out such a survey? If not, why not,
and more particularly, why any individual member of J4 or the committee as
a whole more than you?

Because the COMMITTEE are the people who SHOULD be interested in the result.
Bill is not on the committee so he has NOT volunteered his time and energy
into doing this. The members of the committee have, it is in their interests
to do it, and that is why the committee SHOULD do it, rather than Bill.


Likewise, for your item 2, I have *even less* resources to allocate to the
development of a complete validation test suite for the 2002 standard, or
for the 2008 draft.

So, given that you cannot produce a yardstick for the proposed standard, why
are you wasting time and effort producing it? It's like printing money
without any way to verify whether it is genuine or not.

Actually, such a yardstick is essential, but there is no requirement that
you or any other member of the committee must produce it personally. The
function of the committee is to facilitiate; so get facilitating... :-) You
already suggested one avenue that might achieve this.


What resources are *you personally*, with or without corporate sponsorship
that you might arrange, be willing to bring to the table? J4 would
welcome *any* volunteers to take this task on; I've already mentioned this
elsewhere.

There, you've already started facilitating :-) A public appeal for some help
and on a specific topic too. Now get some of those CEOs to call in a few
favours and make a few phone calls...:-)


For item 3, I think much of this is already covered by "processor
dependent"; the problem is in getting the National Bodies to agree on what
should be "processor dependent" and what should be mandatory for all
environments.

Give them options and a finite time to consider them. At the end of that
time go with a consensus. No appeals, no arguments. They had time to present
cases and discuss the options; majority rules. Get over it.


For item 4, J4 welcomes guests at its meetings (so long as we have
sufficient notice to provide accommodation for them).
(If I bring my own seat, can I turn up anytime? :-))

We have used teleconferencing methods occasionally, but have found that
there are circumstances in which they are not as effective as face-to-face
discussion.

At the moment it seems to be a corporate toy, preferred by managers who
fancy seeing themselves on a large screen. It IS useful when you need to
have a committee meeting with one or more participants in disjoint
locations. (That's when you are not sure whether they are in 'dis joint' or
'dat joint'....). It is used regularly where I work, to have conferences
with Australia, and it is very effective. As for "circumstances in which
they are not as effective as face-to-face discussion" the only cases I can
think of are where you need to have a confidential discussion with an
individual, or to physically pass documents or other instruments.

Perhaps more to the point: of the six attendees at the J4 meeting just
completed, *four* were representatives of end users, and only two
represented vendors.

Good! (Although there is nothing wrong with vendors being on J4...)

In what way is J4 discouraging participation by end
users?

By not facilitating such participation. It isn't enought to put processes in
place. You need to actively encourage and make it easy for interested
parties to attend. Alternatively, (maybe as well) get a web presence and a
bulletin board where interested parties can discuss meeting agendas and
points arising out of J4 meetings.

When was the last time you made the effort to attend a J4 meeting (as a
guest or otherwise)?

Hardly a fair question... the person it was directed at is not currently on
J4 and has bad past experience with the red tape involved. If I were him I
wouldn't want to attend either. If the question is directed to the community
at large, I can say, speaking only for myself, I wouldn't attend a meeting
where 6 people who have no clear agenda or idea of what they SHOULD be
doing, are sitting round discussing COBOL. It's a big subject. You could
discuss it for hours...

It isn't discussion that gets standards produced, it is drafts and revisions
in the light of feedback. (It's called INTERACTION and ITERATION;
fundamental to the RAD process... People who have been raised throughout
their careers on SDLC and the Waterfall will struggle with this.



<< Besides the "mainframe-thought-process" of the 60's and 70's (and
80's), that made COBOL so common (and portable), there is no doubt in MY
mind that the US government requirement for "conforming COBOL compilers"
in some types of contracts was what gave the previous Standards some
"power". >>

I agree with you there. I've made that clear on numerous occasions. I
think the relaxation of that requirement was a disaster to the entire
language standardization process, not just that for COBOL.

Why do you suppose they relaxed it?


< <It would seem to me that J4 (or WG4) *could* research what it would
take to communicate to various government (US, European Union, etc) the
need for Standard conforming COBOL compilers for *SOME* applications that
they still maintain, enhance, and develop. >>

There are lots of things that J4 *could* do, if it had any resources to
speak of beyond that which is necessary to providing standard
specifications for features demanded of it, alongside the processing of
interpretation requests and technical corrigenda. But the resources of J4
are very limited in that respect.

We happen to agree that standardized languages protect the investments
businesses make in programs developed using them. Convincing people that
this is a Nice to Have is not the problem.

The only real clout is exerted by *businesses* who insist on conformance
to such standards in all respects, and from all I've seen so far, what
businesses are requesting is *features* from the later standards, and it
becomes difficult for a *vendor* to justify the significant investment
required to produce, say, the entirety of, say, 2002 COBOL if their entire
current and potential user base responds with a loud yawn to all but a
limited subset of the feature content of that standard.

Simple resolution to that problem... give them what they want and drop what
they don't.

I know *I* would have a real struggle convincing *my* management to invest
compiler-development resources in providing full support for, say,
"free-form reference format" -- either as part of a full 2002-compliant
compiler or as a Unisys-extension to our COBOL85 implementation -- unless
*at least* one user has indicated to Unisys that it's a real hot-button
for them -- and so far as I know, none has done so. I don't think that
lessens the value of the standard itself, because I don't think having the
standard be a guide to "If you're thinking of doing something like this,
here's the way you should really consider doing it." is such a terrible
thing. I've said that many times in this forum.

I don't think the National Standards bodies are going to be convinced by
us Techies. I think they're going to have to be convinced by CEO's of
Very Large Corporations as to how this affects *their* bottom lines.

Then you might as well quit now. NO CEO is going to bet the corporate farm
on COBOL. It cannot be justified and no suitable Business Case can be made
for it in this day and age. If you take a 3 year view, have extensive
applications already developed in it, and a very static environment with
little likleihood of Business or technology change, you MIGHT be able to
prepare a suitable Business Case for upgrading or maintaining it in the
short term. Long term, you can't. And astute CEOs know it. It isn't about
the technical merits or otherwise, it is about the future of procedural
programming in house as a solution to commercial IT requirements. The world
has moved on, the network is becoming ever mightier, and tools and computer
literacy are becoming exponentially greater than was the case in COBOL's
heyday.

Furthermore, I don't think it's us Techies that are going to convince the
CEO's of Very Large Corporations.

You got that right :-) Count on the bean counters... :-)


And even if either approach succeeded, I'm not convinced it's either WG4 or
J4 that would be in a position to produce a regression suite -- in fact,
I'd argue that the production of such a suite should be *entirely* outside
the purview of either organization, so as to avoid the syndrome of the fox
guarding the henhouse!

Nope. Strongly disagree. It ain't the fox guarding the henhouse, it is the
hens ensuring every egg has a little lion on it (sometime UK system of
quality assurance for eggs).

Pete.



.

Quantcast