Re: interesting use of NEXT SENTENCE vs. CONTINUE


"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:d9cn8q$1s7e$1@xxxxxxxxxxxxxxxxxxxxxxx
>
> "William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
> news:6Djue.102745$yp5.68075@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Chuck may or may not know this, but others may be interested.
> >
> > Almost ALL the "extensions" to the '85 Standard used by Pete and pointed
> out by
> > Chuck are valid in IBM COBOL(s) and those PC or workstation compilers
that
> > support "compatibility" with such.
>
> I understood that from the beginning.
>
> I believe strongly that the best way to write *portable* code using
> implementations that purport to conform to a COBOL standard is to write
> using *standard* COBOL rather than write to make use of
> implementor-specific -- or even implementor-initiated -- extensions.
Pete
> seems to have posted his program with the idea that any old COBOL85
compiler
> ought to be able to compile it, and 'tain't so. Some of the things he
used
> have made it into '02 COBOL, some didn't.

That is absolutely correct. I DID think any old compiler would be able to
compile it WITH MINOR MODIFICATIONS for a specific platform.

And I mean MINOR.

I am not optimistic enough to expect 100% compatibility and I'm certainly
not going to go to the Standard to see what SHOULD work. In the time I've
done that (always assuming I'm prepared to buy a copy of the standard from
ANSI (and I am most definitely NOT)), I could've compiled the code, read the
diagnostics, corrected whatever is wrong, and got it working.

Unlike you Chuck, I am uninterested in the standard. My only concern is what
works on the target platform. The fact is that code, even when it IS
completely portable, would need to be modified for the target platform in
order to optimize it anyway.

You mentioned the arithmetic formats and lengths preferred on your platform.
I ran tests on mine with lengths from s9(4) up to S9(18) using comp and
comp-5. Obviously the very short tests don't mean much.

You should have your discussion about 01 levels and 77 levels with a system
programmer who uses a machine where memory synchronization is important, and
chastising me for defining a subscript that wasn't used, is so petty it's
unbelievable. It WAS used in another version of the code that wasn't
published. I simply paste a block of subscripts in the format shown, into
every program I write. The block ends at P (with O being skipped to avoid
confusion with zero). I usually remove the ones that are not used after the
code is debugged and working (exactly as I did this time, but not for the
version I posted). And yes, I do use INDEXED BY and indexes also.

I never went to any pains to make this code suitable for any purpose OTHER
THAN the one I stated so I feel that much of your commentary was really just
cheap shots.

If your point was that the code, as written, was not portable, then I have
no issue with that. If your point was it needed to comply with the standard
to be portable, then my response is "Bollocks!". The only thing that would
make it run on the target platform is if it fits the implementation on that
platform, as defined by the compiler vendor.

I am well aware of the overheads in using DISPLAY UPON and in using ACCEPT.
The original code had a comment saying something to the effect of 'do this
any way you like'. I NEVER use ACCEPT and DISPLAY in production environments
and would write the results to a log file and use FUNCTION CURRENT-DATE
rather than ACCEPT from TIME.(I think the last time I used that was 20 years
ago in an IBM environment where there were no intrinsic functions.)

But, at least as far as I'm concerned, all of that is beside the point.

You can sidetrack the real issue all you like with a display of pedantry
based on the standard. It cuts no ice with me whatsoever.

I have written working COBOL code for at least seven platforms and never
once referred to the X23 or any other standard in order to do so. I have
maintained my own and other people's code without this 'Bible' as well. So
exactly what use is it to the coal face programmer? Absolutely none. They do
their jobs perfectly well without it.

I really do appreciate the time you put into explaining the assembler and
architecture for your platform and I found it interesting. But I'm simply
appalled at your reponse to a trivial code snippet, intended for a specific
purpose (which it achieved), and the fact that you would then take it apart
based on compliance with 'Holy Writ'.

I don't care. The exercise was about the relative speed of branch and
compare instructions, on most platforms. I changed some of my ideas after
running tests.

(When is the last time you changed one of yours?)

>
> A couple of points:
>
> << Program name in quotes (allowed in '02 Standard)>>
>
> Don't think so. "PROGRAM-ID. program-name-1 [AS literal-1] ...".
> "Program-name" is a form of user-defined word; the rules say "literal-1,
if
> specified, is the name of the program that is externalized to the
operating
> environment". ISO/IEC 1989:2002 pages 67 and 186.
>
> <<Some paragraphs in sections, some not (I *think* allowed in '02
> Standard)>>
>
> Don't think so. The syntax diagram on ISO/IEC 1989:2002 page 377 seems to
> me to show a couple of things. If Declaratives exists it consists of
> Sections, and in that case the nondeclarative code that exists begins with
a
> Section header. If Declaratives don't exist, there's executable
> nondeclarative code, and a Section exists anywhere in that code, there
must
> be one at the beginning of the nondeclarative code. If there's no
> nondeclarative code, neither Section nor paragraph is required. And it's
> *paragraphs* that are optional in any case (with or without Sections, with
> or without Declaratives, with or without nondeclarative code).
>
> > Bottom-Line:
> > Portability depends on where you plan to port (or more likely where
you
> end-up
> > porting to but did NOT plan on <G>)
>
> True. But if your goal is to provide "portable" code to the COBOL
community
> at large, presuming that that set of users is identical to the set of
users
> to which the code would be portable is a little disconcerting to those to
> whose implementations don't share the same set of extensions. I had to
> spend time weeding out a bunch of extensions from COBOL code that I was
led
> to believe was supposed to be portable to any implementation by someone
with
> a wide variety of architecture backgrounds. As far as I'm concerned,
only
> *standard-compliant* COBOL merits the presumption of portablility to
> *standard-compliant* implementations.
>

I am sorry for the inconvenience you incurred. You didn't HAVE to spend time
doing anything. If you had posted to me privately or publicly stating that
there was difficulty in getting it to run on a Unisys platform, I might have
taken another look at it or got a friend who has access to such a platform
to run it for me. I said I believed the code was portable because I did
believe that. (Still do...). However, I would expect a reasonable person to
make minor modifications for their platform where necessary. My point is
that SOME amendment would be needed to optimize it for a given platform
anyway...

The fact is that you PREFERRED to make thunder about standard compliance
than to address the issue. That's OK.

It simply diminishes my opinion of you.

Michael said it all when he said: "Some things are obvious
(unnecessary buffer copies, for example), but empirical data is
really the way to go."

Amen to that.

Pete.



.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... These days I don't do compiler maintenance, but I HAVE done in the past, so ... You had a chance to point out how adherence to the standard can improve ... >> compile it WITH MINOR MODIFICATIONS for a specific platform. ... > platform-specific extension to COBOL ...
    (comp.lang.cobol)
  • Re: Standard Ada Preprocessor
    ... because Ada cannot deal with the portability issues. ... > you are interfacing directly to some special-purpose hardware. ... by their nature not compiler ... one platform you get 3 members back, and on another you get 5, ...
    (comp.lang.ada)
  • Re: C portability is a myth
    ... portability has to do with availability, ... I am not convinced yet that it isn't a compiler bug (I saw ... >> was the C standard itself which was the culprit in causing the ... Porting requires effort regardless of whether or not I have conformed ...
    (comp.lang.c)
  • Re: <ctype.h> toLower()
    ... I need to link in the standard C library. ... > know what the target platform is, your compiler doesn't. ... at it -- it might not explain portability, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: <ctype.h> toLower()
    ... See the C Standard. ... >> tolower() is implemented. ... >> platform, without even having to know which character set is used on that ... is, however, an error in portability for me to *call* that macro. ...
    (alt.comp.lang.learn.c-cpp)