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

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
news:4d8hb3F199vo6U1@xxxxxxxxxxxxxxxxx

"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:e4l9bk$2l1s$1@xxxxxxxxxxxxxxxxxxxxxxx
In the general case, Pete, I don't disagree with the suggestions; what I
disagree with is the premise that what *I*, or anybody else on J4 or WG4
needs to do is add anything more to their plate of things to do!

You can't really say: "Hey, we have a committee, COBOL is alive and well!"

No, Pete, that's not my point. And I wasn't even saying "COBOL is alive and
well!", my intent was "The reports of the demise of the COBOL *standards
process* are slightly premature!"

then in the next breath, when members of the COBOL community start
offering positive ideas, say: "There's a HUGE amount of work to do, stop
adding to our burdens...!!".

My response to positive ideas like this is more along the lines of "That's a
really excellent idea upon whose details you seem to have a firm grasp.
We've got a particular schedule we're trying to meet, and don't have a lot
of time or resources to tackle what you suggest right now. Why don't you
take it on? If you don't, it's going to go on the list and wait a while,
and if you think it ought to be done sooner, then maybe you can help
identify and allocate the resources to get it done."

Bill, was trying to be positive and his suggestions are reasonable and
probably worth doing. If I was on this committee, I would be seriously
considering them and encouringing him to join. (He was once a very active
member of the committee.

He was, his ideas have been seriously discussed and considered (recently and
otherwise), and we have encouraged him to join and participate in the past.
I was there when he was an active voting member. It was his choice to
change his status to observer.

I think he could be again if the goals were clear, worthwhile, and
attainable.

I'm not convinced the goals the committees have established are anything but
all of these. I know there have been arguments about the usefulness of XML,
but there's a whole lot of Good Stuff in the 2008 draft (and technically the
XML TR hasn't even been folded into it yet). What some people don't seem
to realize is that formalized international standards require formalized
international consensus, and there's a process for that which takes some
time. Was the 2002 standard later than anybody wanted it to be? Yes. Was
there stuff in it that was obsolete before the standard even came out? Yes,
unquestionably. That's why the committee (with SIGNIFICANTLY fewer
resources now than went into the 1985-to-2002 transition!) is putting so
much energy and focus into getting the 2008 draft out *on time* (or as close
to on-time as possible) with very little more feature content than was
agreed to when WG4 first initiated it (the new arithmetic features were not
on the original list; they were added at the meeting in The Hague; I'm
pretty sure everything else that's in the draft but not in 2002 was on the
original list from WG4).

Of course, I don't want to talk about Bill like he isn't in the room, and
he is quite capable of deciding his involvement for himself :-). I just
don't think it is wrong for someone to offer positive suggestions to the
committee without necessarily being on it.

Well, Pete, I for one have maybe six or seven weeks a year (five in
meetings, the remainder in administrative stuff) that my company permits me
to devote to the standards process. For those of us employed by large
companies, the resources *they* permit us to devote to the process are
limited. For those who are smaller companies, the resources they can bring
to the table are also limited, for different reasons.

And I have already said that I think it's a *bad* idea for the committee to
be the author of the validation suite -- having an independent individual,
group, organization or company take on this task helps to ensure its
impartiality.

So, (and I say this with the utmost respect and not in a hostile way) if
you are finding that your committee involvement is clashing with your main
job, maybe you should reconsider the reasons you are on the committee. (Or
reconsider whether you need/want to be employed in your main job... :-))

No, what I am saying is that being on J4 is not my full-time job, it is one
of the many things I am called upon to do as part of my duties. I
participate on the committee because Unisys has put me there as their
representative for a variety of reasons, and I serve in that position at
*their* pleasure, devoting the energies and resources to it that Unisys
permits me to devote. I am not in a financial position to resign from
Unisys, to cover the various membership and meeting fees associated with
voting participation in J4 and with being a delegate to (to say nothing of
convener of) WG4, or to absorb the cost of travel to the meetings not held
in my immediate vicinity.

Bottom line is that if there a major conflict, then something has to give.
You volunteered for the committee;

If you're talking about J4, not exactly. Unisys selected me as their
representative in 2000; although I did not object and in fact was honored by
their choice, I did not volunteer; in fact, I was not Unisys' first choice
at the time. With their support I *did* volunteer for the position of WG4
convener (in part because I believe that position should be held by a member
of the American delegation which is responsible for the technical details of
the standard, but perhaps more importantly because nobody else seemed
willing to take it on). My participation in both J4 and WG4, and the
resources I bring to that participation, are at the pleasure of Unisys.

I've already addressed the issues of bringing my *personal* resources to
participation in these committees; at this point I am not in a position to
do so.

your main job is not exactly voluntary..., right? :-))

I've already addressed the issues of bringing my *personal* resources to
participation in these committees; at this point I am not in a position to
do so, so no, it's not.

Moreover, part of the whole "main job" includes doing what Unisys supports
me doing on J4 and WG4 -- not less, but also not more. I don't have the
resources to go beyond that, and if I did, Unisys would almost certainly
expect me to devote those resources to supporting languages *products*
rather than the J4/WG4 processes, particularly if to do so causes support
for languages products to suffer (any more than it already does because I
can't devote full time to it).

I'd not heard this before but I think you could argue as follows...
"Well, yes, I DID shoot it, but it's a hunting party, right?

Not necessarily, because I don't think it's a hunting party. See below.

Anyone of us COULD have shot it.

The purpose of the expedition is to shoot things.

No, I don't think so. The purpose of the expedition is to *solve problems*,
not merely identify them and then sit back and wait for someone else to
tackle them. If you think whatever *you* shot is a problem that needs
solving, then the first candidate for solving it is you. The rest of us are
already dragging home all we can carry.

If one of YOU had shot it, I would n't hesitate to give you a hand in
dragging it home (or cutting it up for easier transport); is it
unreasonable for me to expect the same?

Well, that helps, but ...

If you go into the bush on your own and you shoot something, then you KNOW
it is YOU who will bring it home. (I know from personal experience that
this can have a defintie bearing on exactly what you shoot and how much of
it.

Bingo. We do what we can. What we're supposed to shoot and drag home has
already been identified for us, through about the end of 2008 or into 2009.
I happen to think, for example, it would be a *huge* help to the committee
if someone were to take on the task of developing a validation test suite.
I'm booked. The rest of the committee is booked.

I have never shot more than I (and friends and family) could eat, and I
have never gone hunting for the thrill of killing something; it has always
been because we needed the food. And I don't hunt any more as we no longer
need the food... The point in the analogy is that if you are going to go
hunting, alone or in a party, it is good to know why you are doing so.)

At this phase in the process, at least, I think we're trying to get the meat
into refrigeration. The suggestions that we need to drop what we're doing
and go after more game are not coming from within the "hunting parties"!

1.There has been a very bad track record for this committee. For my part,
I'd be more than happy to see it die. But it hasn't.

Is your complaint with the current membership of "this committee", a
personal gripe about the person who has chaired it, or a complaint about the
fact that what J4 has done is what WG4 has delegated to it to be done, and
that WG4's priorities were incorrect? There are two committees involved
here, one responsible for the overall direction and one responsible for the
technical details.

2. Being a basically fair man, I would hope that the new incarnation of
the committee doesn't make the same mistakes the old one did. And I'm
prepared to start them with a clean slate.

This isn't a "new incarnation" of the committee. We will have a different
chair, which may lend a different "flavor" to the proceedings, but the
fundamental changes came when ISO/IEC took over the basic direction of the
COBOL standard and when the American effort was concentrated in J4 rather
than in two separate processes. As far as the Convener of WG4 goes, the
best I can hope for there is that the current leadership doesn't turn out to
be an unmitigated disaster!

My observation is that what soured you on J4 is that the time frame between
the publication of the 1985 and 2002 standards was unconscionably long. I
don't disagree. Part of that delay was "feature creep", and part of that
delay was some political infighting among national standards bodies on
particular language details (and since the 2002 standard was first and
foremost an *international* standard, those *international* disputes had to
be resolved to everyone's satisfaction. We still have that international
process, and it's still going to take a fair chunk of time from the point at
which *J4* deems the draft ready for publication and that at which *WG4*
submits it to ISO for publication.

3. Should I say nothing because I am not on the committee?

No, I certainly invite your active participation. "Woulda, coulda ,
shoulda" is not really a positive contribution. What are *you* willing to
*contribute* to the technical content -- for example, the regression test
suite? We process documents from outside the committee all the time!

(I'm sure you will understand there is virtually no chance of that...
:-)).

A problem offerred without a viable solution is not a problem, it's a
complaint.

Can I not support this committee by offering advice?

Whether it is supportive or not depends a whole lot on how it's presented,
and what you're willing to do to help the committee *follow* that advice (or
at least move in the direction you think it should be going)!

It is only advice; if the committee don't like it, don't take it.

In case you didn't know, written advice, if it's formally presented to the
committee, must be formally acted on, the actions must be recorded in the
minutes, and the submitter must receive a formal response from the committee
.... Do it all the time (wrote one of the latter during the last J4 meeting,
in fact ...)

But don't whinge because people offer positive advice in a spirit of
helpfulness.

I'm not convinced that what's being offered here is "positive advice" when
it comes across as a demand for more dedication and more effort on the part
of those actually trying to accomplish the task, from those who insist that
their proper role is to sit on the sidelines and complain about how lazy and
incompetent the "grunts" are, and how much *more* they should be doing!

And speaking of "whinging", how else should I interpret your continued
expressed resentments about what happened *ending* four years ago with the
publication of ISO/IEC 1989:2002?

And it isn't fair to say they have no right to offer advice unless they
are serving on it.

I agree that wouldn't be fair -- but I didn't say that. I did say that the
committee would be *delighted* if somebody or some organization from outside
the committee took on some of these tasks. J4 accepts, and has *always*
accepted so far as I know, technical documents -- and assistance -- from
outside the committee. Why do you think that it is necessary to serve on
the committee to contribute effort and resources to it?

I also note that much depends on presentation, and like anyone else, the
committee does not respond well to "whinging".

A wise committee would listen to all the comments it gets and seek to
improve things.

And we do. If the two committees manage to pull off the 2008 draft in
something approaching the desired schedule, I think that's patent evidence
on their efforts to "improve things" that you felt were an issue. Other
issues there's not much the *members* can do anything about -- for example,
I'm not in a position to *tell* Unisys that they *must* devote the resources
necessary to develop a 2008-compliant -- or even 2002-compliant -- compiler.
More on this later.

As to "improving things", the period you seem most concerned about is that
which led to the 2002 standard. From 1985 to 2002 there were two
amendments -- the Intrinsic Function amendment of 1989 and the Corrections
Amendment of 1993.

In contrast, since the publication of the 2002 standard, one TR has been
published, one TR is entering the international approval process, one TR is
in its final drafting stages, two Technical Corrigenda are ready for
publication, and a third Corrigendum is entering the international approval
process, all while the draft that we hope to get published in 2008 is being
prepared, with significant new feature content.

Thus, if "improve things" includes responding more quickly, well, I think J4
and WG4 have demonstrated that admirably. Did they provide the features
*you* wanted? Well, maybe not, but they seem to have provided the features
New Zealand, The Netherlands, Germany, the United Kingdom and the United
States wanted ...

The only thing Unisys (or IBM or Micro Focus or Hitachi or Fujitsu or anyone
else) is likely to listen to in terms of developing new conformant compilers
is *market pressure*. If you're dealing in the COBOL marketplace, it's the
CIO's and CEO's of the people for whom you are working -- or contracting or
consulting -- that you need to convince.

Neither Bill nor anybody else here is going to be offended if the advice
offered isn't taken, but what harm can it do to encourage comment?

We process comments all the time. We do what we can do. And sometimes it's
really frustrating (as for the example of a validation suite) that there are
things we *can't* do because the *people* who do the work on the committees
don't have the resources to do them, which is why I suggest that if you feel
strongly enough that something needs to be done, and J4 and WG4 agree, the
committees would *welcome* the resource contribution.

Advice can be to *change fundamental direction*, which is the purview of WG4
and requires consent from the various national bodies, and it can also be to
add some sort of feature content or functionality. The best way to
accomplish this latter is by identifying and helping to provide the specific
resources required for the task. Without the resources, the "advice"
becomes a "whinge".

It was exactly this supercilious attitude (like, there is nothing the
committee can learn from the community) that led to the marked lack of
success of the previous lot.

I was involved in the very end of the 2002 standards development process,
and my opinion about that standard was that a large part of the delay was
the result of *feature creep* -- one after another of community suggestions
that were incorporated into the standard over the too-long lifetime of its
development. Another part was the new process of developing it first as an
international standard.

And don't tell me there is 'due process' and 'procedures' for making
representation to the committee.

*Representation on* the committee is one thing. Presenting ideas to the
committee for their consideration is quite another.

If the committee was genuinely interested in what the community thought,
it would be very easy to submit ideas and there would be a genuine
discourse.

There is such a process, and it can be initiated by something as simple as
sending the J4 chairperson an E-mail. There are face-to-face meetings five
times a year, and sometimes there's even internal correspondence on such
suggestions between meetings. We also do use scheduled teleconferencing,
but we have found through experience that this works better for specific
issues, not as well for "general" meetings with lengthy agendas.

For example, an informal paper was received from a non-J4-member in Germany
back in April. We went through it at our most recent face-to-face meeting,
and suggested changes to the draft and the production of a formal response
document. A teleconference is scheduled for 26 June to discuss the
revisions and the response document.

(God knows, the technology exists to do it from around the planet...)

And we do use it; we just haven't found that it works very well as a blanket
substitution for face-to-face meetings.


Your priorities are a matter for you, Chuck. I fully empathise with what
you are saying, but remember this is a kitchen that no-one forced you to
go into; don't complain about the heat.

I'm fine with the process. The kitchen can process just so many meals a
day, and if there's a waiting line outside the restaurant door, well, the
people in that waiting line will have to wait. Suggesting that the chefs
crank all the ovens up to 600 degrees Fahrenheit so the food cooks faster
might not be all that helpful ...

In my opinion, they shouldn't. Family first, every time.

That's kinda what I thought, too.

Hmmm... why not include Bill's suggestions on the next agenda and at least
consider them jointly?

Bill's first suggestion requires J4 to take a "vendor-independent" survey as
to what features will NEVER be implemented by each vendor. While J4 could
indeed consider that, the J4 members who represent vendors would have to
recuse themselves from any discussions.

More to the point, "NEVER" is pretty strong. I think there are LOTS of
features to which vendors would respond "Not scheduled unless, and until,
there's sufficient demand from the marketplace to make the investment
worthwhile." And that might -- or might not -- be a meaningful list, and
indeed might change based on what implementors provided the feature, and
whether that feature provided a competitive edge!

The idea of avoiding optional features or "modules" in the standard was a
specific direction *from WG4*, and rather a hot topic at that level. J4
could discuss this all day long, but if something like that were initiated
at the J4 level, WG4 would almost certainly shoot it out of the sky at its
next meeting, with probably lots and lots of strong words directed at J4 for
daring to do such a thing while knowing full well that that was a flagrant
disobedience by J4!

Bill's second suggestion was for the J4 members to allocate the resources
needed to build a validation test suite. This approach relies on the fact
that the *members* of J4 are actually corporate members, with
*representatives* on the committee, and that these corporate members have
both the resources to dedicate to this task and the motivation to dedicate
those resources.

I can only speak for myself as Unisys' representative, and I can state
without a whole lot of fear of contradiction that Unisys would not support
*my* committing the resources to develop, or provide significant assistance
in developing, a validation suite.

I've said before and I'll say again here, I think the right resource for the
development of a validation test suite would be something *outside* of the
membership of J4, preferably something in Academia.

Bill's third suggestion is to divide the standard into "subsets" or to
divide it into multiple versions with a common base. The idea of avoiding
optional features or "modules" in the standard was a specific direction
*from WG4*, and rather a hot topic at that level. J4 could discuss this all
day long, but if something like that were initiated at the J4 level, WG4
would almost certainly shoot it out of the sky at its next meeting, with
probably lots and lots of strong words directed at J4 for daring to do such
a thing while knowing full well that that was a flagrant disobedience by J4!
I have *been there* for two such discussions. I have no reason to believe
WG4 would find the subset argument convincing.

Bill's fourth suggestion is about communications and improved use of
technology in meetings. J4 has tried various telecommunications
methodologies in the past with limited success. And J4 welcomes, and always
has welcomed, comments, questions, suggestions from outside the committee.
A simple E-mail to the chair will suffice. We spent a good part of the last
J4 meeting discussing comments received on the Collection Class library TR
from a non-J4-member from Germany, and another on the same TR from a
non-J4-member from Canada. We continue to explore this issue.

My participation in this very forum is evidence of *my* willingness, as a J4
member and as the convener of WG4, to participate in discussions of
technical direction outside the framework of the J4 document submission
procedures (or even simply E-mailing the chair). Other members of J4 (and
WG4) avoid this particular forum precisely because so frequently the sincere
efforts of the members of J4 (present *and past*) have been repeatedly and
roundly denigrated herein.

Would it REALLY require such a lot of resource?

Considering the size of the validation suites for the '74 and '85 standards
and the idea that your specific reference *here* is the validation suites,
yeah, I think it would. I think they need to be redone from scratch, and I
also they need to be more comprehensive. In all honesty, I'm not impressed
with the *fundamental quality* and *comprehensiveness* of the validation
suites for either '74 or '85 as they stand right now. I'm not optimistic
that they should even be used as a base for a new set except as a reference.

Maybe the returns in doing so would be worth it.

No doubt they would. I don't have the resources to do it, and I don't see
my company offering it without a marketing incentive to do so (and more
particularly a marketing incentive that increases Unisys' competitive edge).
I think it'd make a *great* project for a university with J4 and/or WG4
monitoring the results.

If you (as a group) don't consider it, you won't know whether it would
have been feasible and worthwhile. Perhaps it might be more useful to set
up a mechanism for feedback from the community (All it needs is a web site
and a bulletin board...) than it is to consider the syntactic details of
the new unnecessary XML construct... (just an example).

Our priorities and our timetables are established by WG4. We have discussed
just such feedback mechanisms, but haven't had a lot of resources to pursue
it much beyond that. As it stands, E-mail to the J4 chair is welcome.
(Spam and trolling, of course, are not).

But then we wouldn't need a committee, would we?

*For that particular task*, maybe not. I've already said I think having the
validation suite developed by a group *outside* of J4 is a good idea.

Let me ask you something...

Would you personally be prepared to bring your not inconsiderable
experience and talent to bear on solving certain COBOL Standard issues,
and then have the committee tell you that you hadn't complied with some
obscure rule or procedure known only to people on the committee,

I don't think I've argued that, but there are two committees involved here,
and their procedures are quite different. To get official WG4 attention you
*must* go through the National Standards Bodies. If (like Canada) you don't
have a National Standards Body participating in WG4, J4 will carry forward
comments (and we have done exactly that in the past). J4 will, and has,
done what it can to carry the content of some pretty informal communications
forward for formal J4 (and WG4) consideration. But if the demand is to do
something, for example, that WG4 has already made it clear to us that they
will not tolerate, or if the demand is to accomplish something in a
timeframe that the various (admittedly sometimes obscure) procedures simply
will not allow, it's a bit frustrating for the committee to be called to
task for failing to comply with the request!

or that they had decided that what you did was really not a priority for
them so they wouldn't be taking it on board,

J4's priorities are established by WG4. Sometimes J4 will bring a feature
to WG4's attention to see if they'll add it to the already-established list
for the *current* draft (they did this for IEEE 754r arithmetic). Sometimes
WG4 will say "great idea, but not for the current draft" and J4 will put it
on the candidates list. Sometimes J4 will put such things on the candidates
list because they need further exploration. And sometimes J4 will find that
the feature is technically flawed in some way and reject it altogether.

In terms of what's in the draft *now*, J4 proposed a list of features at WG4
Meeting #24 in Las Vegas, in conjunction with a COBOL futures workshop, in
June 2003, and WG4 went through each of them and discussed them at some
length. Since then, IEEE 754r arithmetic was added to, and a couple of
items dropped from WG4's "must-have" list (the latter simply because nobody
had the time, resources or inclination to tackle them). Examining and
updating the "candidates list" has not been a priority at recent J4
meetings; we're dealing with the list of stuff that WG4 has said "That ain't
a candidate for inclusion, that's gotta be there, and by last year ..." and
the "gee, wouldn't it be keen if ..." list isn't on the radar these days

or "Thanks very much, but we need to get this other stuff done before we
can look at what you did for us...",

That's a reality, Pete. If something's on the agenda, we can process it,
and all that's involved there is to get the chair to put it on the agenda.
What you might regard as "helpful", J4 and even WG4 might regard as
"distracting". We went through a whole Big Deal about increasing the use
of symbols instead of words in standard COBOL back at WG4 meeting #24.
There was considerable discussion in this very forum on the subject. What
the 2008 draft includes is the addition of "<>" for "not equal", parallel to
the already-present ">=" and "<=" symbols, but the WG4 minutes make clear
that that's not the direction COBOL should go in general. My opinion is
that the introduction of ">=" and "<=" was a bad idea in the '85 standard;
adding "<>" finishes out the group, but the WG4 minutes are clear that
"That's IT!!" when it comes to APL-izing COBOL.

or worst of all..."Thanks for doing that but we've now decided it isn't
necessary."

Well, that happens too. We've already got COMPUTE A = A + B + C, ADD B C TO
A, ADD B C TO A GIVING A, and MOVE FUNCTION SUM (A B C) TO A that accomplish
pretty much the same thing with a few minor semantic widgets. Is it
*really* that high a priority *for COBOL* to have *yet another* way of doing
this? This isn't a "new feature", it's a new way of doing something you can
already do. Does COBOL *need* a new way to express this when there are
alrready at least four ways of doing that that are likely to produce, for
the examples given, very nearly the same object code (presuming some sort of
optimization in Function SUM)?

The committee needs to have very clear goals and aspirations. It should
communicate these to the community and elicit support.

Right now J4's goal and aspiration is to get the XML and Collection Class
TR's out for international ballot, and to get the 2008 draft *with its
current feature content* ready for international ballot. We can blue-sky
all we want about what happens after the 2008 draft gets approved, but now
is not the time for that.

If this support is not forthcoming, then it is fair to assume that there
is no real need for what is being proposed and it should be descoped to
the point where it is manageable by the committee.

There are two committees. Descoping the feature content of the 2008 draft
is out of the question because the feature content has been defined, and
confirmed twice, at the WG4 level.

1. Find out what is needed and wanted. (Don't just assume you know this,
or let interest groups and lobbies drive it.)

What J4 does is what the National Standards Bodies, through WG4, tells it
that interest groups and user groups and vendors and end-users have told it
they want. J4 knows this because it's in the WG4 minutes, and it's WG4's
standard.

2. Confirm that the perceived needs and wants are the actual needs and
wants.(Communicate the proposal back to the user community)

....Which is why the working draft standard and the last two years' worth of
J4 documents detailing the technical issues and changes are available on the
internet ...

3. Work out how many of these can be delivered with the available
resources.

Done in June 2003 at WG4 Meeting #24 in Las Vegas.

4. State what you propose to deliver and when.

Done in June 2003 at WG4 Meeting #24 in Las Vegas.

5. Do it.(Communicate with the community while you are doing it and
encourage comment. You might actually get people to help you if you do
this.

Been doing that since WG4 Meeting #24 in Las Vegas, and before ... ;-)

THEN, you may accept awards and bunfights for the great job you did, if
that is what lights your candle...:-)

I'm not interested in kudos. I happen to think a COBOL standard has value
whether or not a fully-conforming implementation (with or without
"processor-dependent" features) is ever produced.

A COBOL85 implementation that also supports the formatted-time and
formatted-date functions, and does so in a manner strictly conformant with
the 2008 draft, has made appropriate use of the standard. A COBOL85
implementation that supports "free-form reference format" instead of, or in
addition to, a "proprietary" source format has made some step toward the
goal of industry compatibility. The implementor has done *his* part; it's
now up to the others to follow that example. If they don't, it's a shame,
but no flies on him for having done it right.

-- back to "You shot
it, you drag it home."

"I shot it on behalf of the group and any one of us could have pulled the
trigger. If the kill is acceptable to the group then it is a group
responsibility to transport it. That's what 'teamwork' means..."

Well, it depends on whether the group was out there to cull the herd, and
whether they'd reached their limit or not. "Hey guys, I know you're
cleaning and skinning, and we've already reached the limit that the Fish and
Game Service had set for us, but I've just shot two does and a fawn, and I
need you to haul them in and transport them because I've run outta time
....". If you offer advice to the group, it is not particularly helpful if
that advice goes counter to the stated goals and the priorities of that
group, particularly if those goals and priorities are established for them!

One of the frustrating aspects of the fourth-class year (including Plebe
Summer) at Annapolis was the fact that every fourth-classman was required to
be responsible for following the orders of every upper-classman, even when
those orders conflicted directly.

Given that J4 already has its "marching orders" (from WG4), complaining that
when a user says "JUMP!" J4 responds with "well, we'll have to look into
that, but I doubt that's going to be happening anything like soon" instead
of "how high, SIR!?!?!" doesn't strike me as all that productive, either,
Pete. That's not what teamwork means *to me*.

-Chuck Stevens


.

Relevant Pages

  • Re: What could J4 (or WG4) do (was: INSPECT and TRAILING syntax
    ... my intent was "The reports of the demise of the COBOL ... If I was on this committee, ... Was there stuff in it that was obsolete before the standard ... draft but not in 2002 was on the original list from WG4). ...
    (comp.lang.cobol)
  • Re: what happened to hash-tables
    ... >> You already need hashtables anyway internally for implementing Common ... Many of the people on the committee had much more experience ... The ANSI standard is about memorializing the "Common" practice ... Suppose that the winning extensible hash table protocol is based ...
    (comp.lang.lisp)
  • Re: What could J4 (or WG4) do (was: INSPECT and TRAILING syntax
    ... the National Body representation to WG4, have the resources to carry out ... Then the first priority of the committee should be to get properly resourced ... COBOL standardization process, much less anyone whose primary financial ... So, given that you cannot produce a yardstick for the proposed standard, why ...
    (comp.lang.cobol)
  • Re: Function designator implicit conversion
    ... If the Committee had meant for the parameter list to be part of the ... it's not the intent. ... Standard says which is what my comment accurately reflected. ... This response seems to support the position I have presented. ...
    (comp.std.c)
  • Fortran 2008 (was Re: Statement function host association)
    ... Has the committee voted to remove any other features from Fortran 2008? ... committee has still not begun work on a new version of the C standard. ... the progressives having moved to C++ long ago. ...
    (comp.lang.fortran)