Home > Archive > Cobol > May 2006 > INSPECT and TRAILING syntax
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
INSPECT and TRAILING syntax
|
|
| Roger While 2006-05-08, 9:55 pm |
| Seems weird to me that alongside ALL, FIRST and LEADING
the TRAILING keyword never made it into any standard.
Bill, was it ever considered ?
ACU implements it and I have just put it into OpenCOBOL.
Roger While
| |
| William M. Klein 2006-05-09, 3:55 am |
| Roger (et al),
I think the thought is/was that "Function Reverse" lets you do much of this
(not REPLACING or CONVERTING - but tallying). If you use REVERSE to move a
field to a temporary field, you can even do replacing and converting.
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:e3p2b2$fmv$01$1@news.t-online.com...
> Seems weird to me that alongside ALL, FIRST and LEADING
> the TRAILING keyword never made it into any standard.
> Bill, was it ever considered ?
> ACU implements it and I have just put it into OpenCOBOL.
>
> Roger While
>
| |
| Chuck Stevens 2006-05-09, 7:55 am |
| Yes, as I recall it J4 was of the opinion that anything you'd want to do
with TRAILING you could accomplish with existing syntax, even if it required
a "temporary" and an extra statement.
Adding new syntax for functionality that already exists -- particularly when
the syntax for that functionality is pretty straightforward -- adds
complexity to the language without adding functional feature content, and
for that reason the suggestions to provide TRAILING were not followed.
-Chuck Stevens
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:wqU7g.432129$7i1.140664@fe06.news.easynews.com...
> Roger (et al),
> I think the thought is/was that "Function Reverse" lets you do much of
> this (not REPLACING or CONVERTING - but tallying). If you use REVERSE to
> move a field to a temporary field, you can even do replacing and
> converting.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e3p2b2$fmv$01$1@news.t-online.com...
>
>
| |
| Frank Swarbrick 2006-05-09, 6:55 pm |
| >>>> Roger While<simrw@sim-basis.de> 05/08/06 9:29 PM >>>
>Seems weird to me that alongside ALL, FIRST and LEADING
>the TRAILING keyword never made it into any standard.
>Bill, was it ever considered ?
>ACU implements it and I have just put it into OpenCOBOL.
I totally agree. I'm much more likely to use TRAILING than LEADING. (In
fact I have utilized LEADING with FUNCTION REVERSE in order to simulate
TRAILING. I don't agree with those that think that TRAILING should not be
added just because you can use LEADING with FUNCTION REVERSE. I am all for
so-called "syntactic sugar" when it makes things easier to code and easier
to read.
Of course the (now dead?) COBOL 2008(?) standard appears to support even
more useful things such as FUNCTION TRIM(argument [left/right]) and the ANY
LENGTH clause. For instance:
FD varlen-file.
01 varlen-record PIC X ANY LENGTH LIMIT 120.
01 my-fixed-field PIC X(120).
01 my-varlen-field PIC X ANY LENGTH LIMIT 80 DELIMITED.
ACCEPT my-fixed-field
WRITE varlen-record FROM TRIM(my-fixed-field)
MOVE TRIM(my-fixed-field RIGHT) TO my-varlen-field
CALL c-func USING my-varlen-field
Not sure if I have all of the above correct, but I think the meaning is
fairly obvious.
Feel free to implement it into OpenCOBOL. :-)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Howard Brazee 2006-05-09, 6:55 pm |
| On Tue, 9 May 2006 09:51:41 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>I totally agree. I'm much more likely to use TRAILING than LEADING. (In
>fact I have utilized LEADING with FUNCTION REVERSE in order to simulate
>TRAILING. I don't agree with those that think that TRAILING should not be
>added just because you can use LEADING with FUNCTION REVERSE. I am all for
>so-called "syntactic sugar" when it makes things easier to code and easier
>to read.
Using FUNCTION REVERSE for this purpose grates on me. Sure,
computers are fast and this ugly code doesn't cost as much as it used
to.
I'd much rather use reference modification than use a function to copy
and reverse the string so that we can run a CoBOL command.
| |
| Chuck Stevens 2006-05-09, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4cbs4hF14rcseU1@individual.net...
> Of course the (now dead?) COBOL 2008(?) standard ...
Rumors to that effect are, I think, premature.
J4 plans to continue to meet, even with a vice-chair, for the foreseeable
future and has meetings scheduled next w , at the end of July, in October,
and in December of this year, presuming INCITS doesn't prevent it. Note
that I'm acting vice-chair of J4, so we *can* conduct meetings, and we
expect to have a permanent vice-chair by the beginning of the July/August
meeting (so I won't have to act as host, secretary and chair all at the same
time for that meeting!).
WG4 meets in March 2007, and as far as I'm concerned the main goal of that
meeting is to move the 2008 draft on its path toward adoption, by which
point it is hoped that the work of J4 on that draft will be pretty much
done.
Membership of J4 is still sufficient for quorum -- in fact, because Micro
Focus has a designated alternate representative who is still employed by the
company, they're still a member despite Don Schricker's departure as their
primary representative and as chairperson of the committee, and we do have
more than one person "legitimized" by INCITS to conduct the meetings.
I do intend to lobby at the INCITS level for them to allow J4 to continue
its business even without a designated chairperson.
WG4 has delegated the technical work to J4 in the past. If INCITS decides
(despite our efforts to the contrary) to disband J4 on the sole grounds that
nobody has (yet) stepped up to take on the permanent chairmanship, I don't
see any reason why WG4 can't continue the final editorial cleanup of the
2008 standard, as well as the development of future standards, if they so
chose.
-Chuck Stevens
| |
| HeyBub 2006-05-10, 3:55 am |
| Frank Swarbrick wrote:
> Howard Brazee<howard@brazee.net> 05/09/06 10:07 AM >>>
>
> I assume you mean something like...
>
> COMPUTE TRIMMED-LEN = FUNCTION LENGTH(MY-STRING)
> PERFORM VARYING R FROM FUNCTION LENGTH(MY-STRING) BY -1
> UNTIL R = ZERO OR MY-STRING(R:1) NOT = SPACE
> SUBTRACT 1 FROM TRIMMED-LEN
> END-PERFORM
>
> Is than better than this?
> MOVE ZERO TO TALLY
> INSPECT FUNCTION REVERSE(MY-STRING) TALLYING TALLY FOR LEADING SPACES
> COMPUTE TRIMMED-LEN = FUNCTION LENGTH(MY-STRING) - TALLY
>
> Maybe, maybe not. But I'd definitely prefer
> MOVE ZERO TO TALLY
> INSPECT MY-STRING TALLYING TALLY FOR TRAILING SPACES
> COMPUTE TRIMMED-LEN = FUNCTION LENGTH(MY-STRING) - TALLY
>
> Or, of course, best of all would be:
> COMPUTE TRIMMED-LEN = FUNCTION TRIM(MY-STRING RIGHT)
>
> Frank
Fujitsu has:
COMPUTE TRIMMED-LEN = FUNCTION STORED-CHAR-LENGTH(MY-STRING).
| |
| Roger While 2006-05-10, 3:55 am |
| > Fujitsu has:
>
> COMPUTE TRIMMED-LEN = FUNCTION STORED-CHAR-LENGTH(MY-STRING).
Are these Fujitsu extensions documented anywhere on Internet ?
Re: using FUNCTION REVERSE (or whatever)
Of course, the Cobol runtime has to acquire memory to do this
(as with many other FUNCTION's) which may or may not ever
be free'd/reused.
So be careful using this in a paragraph you are perfoming a
couple of million times :-)
Your sy min might come knocking on your door :-)
Roger While
"HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
news:1262gf5g7m80nbd@news.supernews.com...> Fujitsu has:
>
> COMPUTE TRIMMED-LEN = FUNCTION STORED-CHAR-LENGTH(MY-STRING).
> Frank Swarbrick wrote:
>
> Fujitsu has:
>
> COMPUTE TRIMMED-LEN = FUNCTION STORED-CHAR-LENGTH(MY-STRING).
>
>
>
| |
| Roger While 2006-05-10, 3:55 am |
| "HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
news:1262gf5g7m80nbd@news.supernews.com...
> Fujitsu has:
>
> COMPUTE TRIMMED-LEN = FUNCTION STORED-CHAR-LENGTH(MY-STRING).
>
>
Sounds useful. Just implemented it in OpenCOBOL :-)
Question, does it only check for trailing spaces or does it
also check for low-values ?
Roger While
| |
| Pete Dashwood 2006-05-10, 6:55 pm |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e3q4le$1lf5$1@si05.rsvl.unisys.com...
> Yes, as I recall it J4 was of the opinion that anything you'd want to do
> with TRAILING you could accomplish with existing syntax, even if it
> required a "temporary" and an extra statement.
>
> Adding new syntax for functionality that already exists -- particularly
> when the syntax for that functionality is pretty straightforward -- adds
> complexity to the language without adding functional feature content, and
> for that reason the suggestions to provide TRAILING were not followed.
Interesting.
That being the case...
Why was EVALUATE added to the language when IF was already there?
Why was SEARCH added when the same effect could be obtained with PERFORM?
Why was EXAMINE dropped in favour of INSPECT when they provide the same
functionality?
Why were scope delimiters added when we already had full stops?
Why was CONTINUE included when EXIT would have done?
Why was PICTURE provided in the langage when exactly the same functionality
was available with CLASS, and SIZE?
So much rhetoric, so little time... :-)
Pete.
| |
| Rick Smith 2006-05-10, 6:55 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4ce5dlF15a7qgU1@individual.net...
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:e3q4le$1lf5$1@si05.rsvl.unisys.com...
and[color=darkred]
>
> Interesting.
>
> That being the case...
My best guess for each of the following.
> Why was EVALUATE added to the language when IF was already there?
CODASYL 1978. CODASYL was not J4.
> Why was SEARCH added when the same effect could be obtained with PERFORM?
CODASYL 1965. CODASYL was not J4.
> Why was EXAMINE dropped in favour of INSPECT when they provide the same
> functionality?
CODASYL 1969. CODASYL was not J4.
> Why were scope delimiters added when we already had full stops?
CODASYL 1978. CODASYL was not J4.
> Why was CONTINUE included when EXIT would have done?
CODASYL 1978. CODASYL was not J4.
> Why was PICTURE provided in the langage when exactly the same
functionality
> was available with CLASS, and SIZE?
CODASYL 1968. CODASYL was not J4.
> So much rhetoric, so little time... :-)
| |
| Howard Brazee 2006-05-10, 6:55 pm |
| On Thu, 11 May 2006 00:42:23 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
>Why was EXAMINE dropped in favour of INSPECT when they provide the same
>functionality?
I did a conversion once (from Univac 9030) where I replaced lots of
EXAMINE statements with TRANSFORM statements, on the theory that
TRANSFORM works with both ANSII versions and did what we wanted.
Then they dropped TRANSFORM.
| |
| Howard Brazee 2006-05-10, 6:55 pm |
| On Tue, 9 May 2006 16:37:47 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>I assume you mean something like...
I agree with your whole post.
| |
| Howard Brazee 2006-05-10, 6:55 pm |
| On Wed, 10 May 2006 10:18:50 +0200, "Roger While" <simrw@sim-basis.de>
wrote:
>
>Sounds useful. Just implemented it in OpenCOBOL :-)
>Question, does it only check for trailing spaces or does it
>also check for low-values ?
Just make it easy to add function libraries.
| |
| HeyBub 2006-05-10, 6:55 pm |
| Roger While wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
> news:1262gf5g7m80nbd@news.supernews.com...
>
> Sounds useful. Just implemented it in OpenCOBOL :-)
> Question, does it only check for trailing spaces or does it
> also check for low-values ?
Spaces only.
| |
|
|
| Roger While 2006-05-10, 6:55 pm |
| "HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
news:1263vl5rbif2lda@news.supernews.com...
> Roger While wrote:
>
> http://www.adtools.com/products/windows/cobol.htm
>
> (also available in their FORTRAN compiler, I believe)
No, that's no good.
I don't want version highlights.
I need reference doc.
Just like ACU, Fujitsu do not seem want to put
their reference manuals on the net. Pfui.
At least MF have their complete doc on the web.
Roger While
| |
| Chuck Stevens 2006-05-10, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:1263rv76rk9hh74@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4ce5dlF15a7qgU1@individual.net...
> functionality
>
> CODASYL 1968. CODASYL was not J4.
Actually, from all I can tell, PICTURE was present from the beginning
(1960). If both PICTURE and SIZE were specified, PICTURE was used. I'm not
sure what you mean by CLASS here, but USAGEs could appear in SIZE clauses
between the number of digits and the type of representation
(CHARACTERS/DIGITS).
The SIZE clause does *not* seem to have made it as far as ANSI X3.23-1968
(AKA "first standard COBOL"), though it was included in our COBOL(68)
implementation for upward compatibility with B5000/B5500/B5700 COBOL (an
implementation of COBOL-60).
Personally, I think the fact that you could say either
PICTURE 9(5) USAGE DISPLAY or SIZE 5 DISPLAY CHARACTERS
but there was no corresponding mechanism for alphanumeric data items (SIZE
implies numeric). I find that a strange limitation.
Likewise, I think the fact that you could say
SIZE 5 COMPUTATIONAL CHARACTERS
in implementations in which the format and layout of COMPUTATIONAL wasn't
either "character-oriented" or "digit-oriented" in the first place (e.g.,
binary) was at best misleading.
And the fact that SIZE required the data item to be an *integer* was a real
limitation -- that requires you to code
PICTURE 9(5)V99 DISPLAY
instead of something like
SIZE 7 DISPLAY CHARACTERS SCALE [FACTOR] 2 ...
Yes, lots of people have ways they'd rather code things than the way the
COBOL standard currently allows them to be coded. I'm not convinced that
the language would have been well-served by the retention of the SIZE clause
from the original CODASYL design, nor am I convinced that the language is
well-served by adding different ways to do something you can already do in a
relatively straightforward manner. I'll vote for spending the energy on new
*functionality* every time.
-Chuck Stevens
| |
| Frank Swarbrick 2006-05-10, 6:55 pm |
| Howard Brazee<howard@brazee.net> 05/10/06 8:20 AM >>>
>On Tue, 9 May 2006 16:37:47 -0600, "Frank Swarbrick"
><Frank.Swarbrick@efirstbank.com> wrote:
>
>
>I agree with your whole post.
I feel faint.
Please don't agree with me.
It makes me woozy.
:-)
| |
| Chuck Stevens 2006-05-10, 6:55 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4ce5dlF15a7qgU1@individual.net...
> Why was EVALUATE added to the language when IF was already there?
Users of other languages liked the functionality of CASE, which is what
EVALUATE provides (and much more, I'd say).
> Why was EXAMINE dropped in favour of INSPECT when they provide the same
> functionality?
INSPECT, introduced in a standard published thirty-two years ago now,
provides a superset of the functionality previously available with EXAMINE.
As I see it, EXAMINE does not allow comparison by an identifier, does not
allow combined tallying/replacing in the same statement, does not allow
BEFORE/AFTER clauses, does not allow multiple replacements within the same
data item, and does not allow multiple data items to be handled in a single
statement. I believe the keyword EXAMINE can be replaced by the keyword
INSPECT in all contexts in which the former is superseded by the latter; the
reverse is by no means true.
I wasn't involved in the standards process when this decision was made (it
first shows up in the JOD of 1969), but my best guess as to the *reason*
they used a different verb altogether for this was that some significant
vendor had enhanced EXAMINE in a way that would have made the new features
incompatible with that implementation. Since the feature content of INSPECT
is so much greater than the (standard) feature content of EXAMINE, providing
a new verb was an approach that was actually friendlier to that user base,
and not all that unfriendly to the rest of the EXAMINE-using community.
In the past, it seems to me your main "beef" with the COBOL standards
process has had to do with the fact that in the seventeen years starting in
1985 it only produced two amendments and an updated standard with
significant (perhaps *too much*) feature content, and you have had nothing
negative to say about the standards process *prior to* the introduction of
the '85 standard.
I can't help but wonder why you seem to have begun complaining *now* about
the way the '74 and even the '68 standards evolved from Adm. Hopper's
original ideas as put forth in 1959-1960. I don't think there's a whole
lot I can do about convincing the contributors to ANSI X3.23-1968 (or for
that matter ANSI X3.23-1974 or -1985) that they Did It All Wrong and that
they Need To Do It All Over -- I strongly suspect the great majority of them
are dead now anyway!
-Chuck Stevens
| |
| Howard Brazee 2006-05-10, 6:55 pm |
| On Wed, 10 May 2006 10:01:39 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>INSPECT, introduced in a standard published thirty-two years ago now,
>provides a superset of the functionality previously available with EXAMINE.
>
>As I see it, EXAMINE does not allow comparison by an identifier, does not
>allow combined tallying/replacing in the same statement, does not allow
>BEFORE/AFTER clauses, does not allow multiple replacements within the same
>data item, and does not allow multiple data items to be handled in a single
>statement. I believe the keyword EXAMINE can be replaced by the keyword
>INSPECT in all contexts in which the former is superseded by the latter; the
>reverse is by no means true.
But as this thread shows, it did not add all the functionality people
wanted. And then we lost the TRANSFORM verb, and had to change a
bunch of programs.
It didn't seem to be well thought out.
| |
| Jeff Campbell 2006-05-10, 6:55 pm |
| Roger While wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
> news:1263vl5rbif2lda@news.supernews.com...
>
> No, that's no good.
> I don't want version highlights.
> I need reference doc.
> Just like ACU, Fujitsu do not seem want to put
> their reference manuals on the net. Pfui.
> At least MF have their complete doc on the web.
>
> Roger While
>
>
<http://www.adtools.com/download/index.htm>
Jeff Campbell
n8wxs@arrl.net
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
| Chuck Stevens 2006-05-10, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:bg74625nelojlaasjk44aamdqvltp0dplt@
4ax.com...
> On Wed, 10 May 2006 10:01:39 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
> But as this thread shows, it did not add all the functionality people
> wanted.
I am unaware of any functionality that the standard EXAMINE verb provided
that the INSPECT verb did/does not. What are you referring to?
> And then we lost the TRANSFORM verb, and had to change a
> bunch of programs.
In which *standard* did the TRANSFORM statement appear?
The IBM DOS COBOL (68) manual I have at hand includes it, but the syntax
diagrams and rules for it are clearly marked as an *IBM extension* to '68
COBOL. IBM's decision to eliminate this extension at some point has nothing
to do with the standard or the standards process. That was a business
decision on IBM's part, it seems to me.
Further, it seems to me INSPECT ... CONVERTING provides in *standard* '85
syntax at least as much power as the *extension* TRANSFORM did, and although
it's not a simple single-keyword substitution (as was the case for
EXAMINE/INSPECT), "INSPECT A CONVERTING B TO C" looks equivalent in function
to IBM's extension "TRANSFORM A [CHARACTERS] FROM B TO C".
> It didn't seem to be well thought out.
Well, as someone who doesn't hold that everything IBM does is the way
everybody else ought to do it, I'm not sure I agree as to what it was that
wasn't well thought out ... We've got our share of extensions that later
turned out to get in the way of writing standard COBOL (the availability of
USAGE BINARY in our COBOL74 implementation being a straightforward example
in which users had to change their programs to compile them with COBOL85),
and I think *every* vendor has. TRANSFORM strikes me as falling in that
category ...
-Chuck Stevens
| |
| William M. Klein 2006-05-10, 6:55 pm |
| Pete,
I know that Chuck has responded to a couple of the specifics, but as I agree
with his initial post, I think what was not clear was that the "resistance" to
adding new (redundant) syntax is a POST-2002 (somewhat in that too) development.
The 2002 Standard introduced LOTS and LOTS (too much IMHO) new "syntax" - some
for things one could already do, some they couldn't.
Rightly or wrongly (I think rightly) SOME of the resistance to implementing the
'02 Standard was that it was simply "TOO BIG".
The features that you mention were all introduced in the '85 Standard or
earlier.
The '02 Standard had SOME new "redundant" features (e.g. GOBACK, partial-word
replacement, SET TO FALSE). However, it is my memory that even in the
development of that Standard there was SOME discussion that these facilities
COULD already be accomplished and did the language really need them. In these 3
cases (and possibly most others), the view was (as I recall it) that the new
syntax was "more self-documenting". I am not at all certain that ANY of them
would make it into a post-02 Standard - if they were up for discussion now.
Having said that, I do think that every possible enhancement has (and continues
to be) considered on a "case by case" basis. A (well-discussed in this forum)
feature was the addition of the "<>" operator - which DID make it into the draft
'08 Standard.
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4ce5dlF15a7qgU1@individual.net...
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:e3q4le$1lf5$1@si05.rsvl.unisys.com...
>
> Interesting.
>
> That being the case...
>
> Why was EVALUATE added to the language when IF was already there?
>
> Why was SEARCH added when the same effect could be obtained with PERFORM?
>
> Why was EXAMINE dropped in favour of INSPECT when they provide the same
> functionality?
>
> Why were scope delimiters added when we already had full stops?
>
> Why was CONTINUE included when EXIT would have done?
>
> Why was PICTURE provided in the langage when exactly the same functionality
> was available with CLASS, and SIZE?
>
> So much rhetoric, so little time... :-)
>
> Pete.
>
>
>
>
>
>
>
>
>
| |
| Howard Brazee 2006-05-10, 6:55 pm |
| On Wed, 10 May 2006 11:13:36 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>
>I am unaware of any functionality that the standard EXAMINE verb provided
>that the INSPECT verb did/does not. What are you referring to?
This thread was about TRAILING syntax. If INSPECT was so inadequate
that it needed to be thrown out and replaced, the replacement should
have offered a bigger improvement than it did.
>Well, as someone who doesn't hold that everything IBM does is the way
>everybody else ought to do it, I'm not sure I agree as to what it was that
>wasn't well thought out ... We've got our share of extensions that later
>turned out to get in the way of writing standard COBOL (the availability of
>USAGE BINARY in our COBOL74 implementation being a straightforward example
>in which users had to change their programs to compile them with COBOL85),
>and I think *every* vendor has. TRANSFORM strikes me as falling in that
>category ...
Agreed. That double-change was irritating though for insufficient
increased functionality.
| |
| Chuck Stevens 2006-05-10, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:u9c462p8fcipl5e2tl50kqlo11qqksq46p@
4ax.com...
> On Wed, 10 May 2006 11:13:36 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
> This thread was about TRAILING syntax. If INSPECT was so inadequate
> that it needed to be thrown out and replaced, the replacement should
> have offered a bigger improvement than it did.
And what functionality does EXAMINE provide that INSPECT does not with
respect to TRAILING?
As already pointed out, Function TRIM provides what I think is what people
want in the first place. I actually like it better than expanding INSPECT
to include TRAILING, for two reasons: first, because it's a FUNCTION (and
thus almost peripheral to the language itself, given the availability of
user-defined functions), and second because both the syntax and the
complexity of code generation for INSPECT have gotten WAY out of hand. And
having spent some time examining code generated for INSPECT, I think it'd
almost certainly take some pretty fancy optimization to get the particular
cases of INSPECT ... TRAILING that match the functionality of TRIM exactly
to perform as well, precisely because INSPECT has to account for more
eventualitites than Function TRIM might.
>
> Agreed. That double-change was irritating though for insufficient
> increased functionality.
Point being: Don't blame J4 (or WG4, for that matter) for that one. There
is *no change at all* required to bring a program written to be in
conformance with *standard* COBOL in the first place, because such a program
*would not* contain the TRANSFORM statement to begin with.
If you chose to use an *IBM extension* and then complained because *IBM*
dropped support for it in favor of functionality established as a standard
by vendors *including* IBM, the source of your irritation is IBM, either for
implementing an extension in the first place, or for decommitting it as an
extension in later compilers (presumably without a clear migration
strategy).
In our case, if we were to decommit such a syntactic extension, we'd provide
logic in an automated migration tool to make the appropriate substitution.
The program used to handle '74-to-'85 migration in our environment, for
example, has to account for the fact that USAGE BINARY was a Unisys
extension in '74 COBOL but is standard COBOL in '85, and has different
semantics (the odometer effect is applied only in very limited circumstances
in our '74 implementation, universally in our '85).
-Chuck Stevens
| |
| Howard Brazee 2006-05-10, 6:55 pm |
| On Wed, 10 May 2006 12:00:29 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>
>And what functionality does EXAMINE provide that INSPECT does not with
>respect to TRAILING?
I don't know how I'm messing up, but obviously I am not saying what I
intend to say, because you keep asking the same question which seems
unrelated to what I intended to say.
I hope my statement wasn't that confusing to all, and I apologize for
my inability to communicate clearly.
But rereading the above quote, I have no idea how to say what I meant
any more clearly.
| |
| Robert Jones 2006-05-10, 6:55 pm |
|
Frank Swarbrick wrote:
> Chuck Stevens<charles.stevens@unisys.com> 05/09/06 10:20 AM >>>
> October,
> same
>
> the
>
>
>
> that
>
>
> Tell Bill to stop spreading nasty rumors! :-)
>
> I have a curious question about J4 and the COBOL standards... It looks like
> some (most? all?) of the major COBOL vendors have members on this commitee.
> Yet I haven't heard that any vendor has made any statement with regard to
> supporting the entire COBOL 2002 standard, much less the follow-on standard.
> Is there some commitment there? And if not, why not? I know many vendors
> have implemented parts (some more than others), but I haven't heard of any
> vendor supporting all, or even most, of it.
>
> I did see that Hitachi has something called "The COBOL2002 Family". I
> haven't determined whether or not this implements the entire 2002 standard
> or not. Plus it looks like Hitachi is pretty much focused on the Japanese
> market only, or at least all of the web references seem to be in Japanese!
>
> Anyway, having an IBM compiler I am especially interested to hear what their
> "statement of direction" for COBOL might be. Anyone know?
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
It seems to me that most of the investment in time and money towards
producing the 2002 and 2008 standards came from the vendors themselves,
with relatively minor, though not necessarily insignificant, input from
a few other interested persons. If ISO had not adopted the standard
from CODASYL, it is conceivable that the vendors and other interested
parties could continue to develop it independently with or without a
chairman. Now that the 2002 standard has been created under the
auspices of ISO, it seems unlikely that ISO will allow it to go
"independent" again, what with copyright, etc issues. Ultimately, I
suppose, further development depends on the preparedness of vendors
and perhaps large consumers to provide support, which depends on what
they see in it from expected benefits in the way of sales and need to
support and extend existing systems and develop new ones..
Robert
| |
| William M. Klein 2006-05-10, 6:55 pm |
| All previous info removed - so MAYBE a "fresh" start will help (some).
The ANSI Standard EXAMINE was replaced by the '74 Standard ANSI INSPECT. That
statement did NOT include the "converting" facility which was added in the '85
Standard. The "question" (which seems pretty academic to me NOW) is WHY was the
functionality (available with EXAMINE) not provided with the INITIAL inspect
facility.
"Meanwhile" IBM provided the (extension) TRANSFORM facility which did provide
the same functionality as this part of the EXAMINE (which the '74 Standard
INSPECT did not).
Another (pretty academic now) question then arises whether it would have been
better for J4 to introduce a TRANSFORM statement (which matched the "relatively
common" extension to the '74 Standard) RATHER than introducing the CONVERTING
phrase of the INSPECT statement - into the '85 Standard.
****
MEANWHILE (coming to the present age) the question of whether the TRAILING
phrase (again an existing implemented extension) which "parallels" the existing
STANDARD leading phrase would be a "good thing" is being asked. In most other
places in Standard ('85 or '02) COBOL where a "leading phrase" is supported,
there is also a "trailing phrase". Therefore, this doesn't seem to be
unreasonable. On the other hand, I agree that the INSPECT statement is
sufficiently "complex" today that many of its uses are obscure (and end up with
complex object code).
***
Finally, during the development of the '02 Standard, (possibly before) a
suggestion was officially made to J4 that it ONLY add new syntax which was
already in existence in at least one implementation. This was rejected - and
has been rejected when talked about since. I don't know if this would or would
not have "helped" the history of Standard COBOL, but it does seem at least
somewhat relevant to this discussion.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Roger While 2006-05-10, 6:55 pm |
| Well said Bill, although I might disagree that the INSPECT is "complex".
From a parser point of view it is relatively straight forward.
Especially comparing to the WHEN clause of EVALUATE.
Now that 2002 has added (MF's, I believe) partial-expression, that gets
very very messy. In fact look at the keword NOT following a WHEN and then
ask yourself what a partial-expression can be.
Roger While
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:unr8g.452435$7i1.49099@fe06.news.easynews.com...
> All previous info removed - so MAYBE a "fresh" start will help (some).
>
> The ANSI Standard EXAMINE was replaced by the '74 Standard ANSI INSPECT.
> That statement did NOT include the "converting" facility which was added
> in the '85 Standard. The "question" (which seems pretty academic to me
> NOW) is WHY was the functionality (available with EXAMINE) not provided
> with the INITIAL inspect facility.
>
> "Meanwhile" IBM provided the (extension) TRANSFORM facility which did
> provide the same functionality as this part of the EXAMINE (which the '74
> Standard INSPECT did not).
>
> Another (pretty academic now) question then arises whether it would have
> been better for J4 to introduce a TRANSFORM statement (which matched the
> "relatively common" extension to the '74 Standard) RATHER than introducing
> the CONVERTING phrase of the INSPECT statement - into the '85 Standard.
>
> ****
>
> MEANWHILE (coming to the present age) the question of whether the TRAILING
> phrase (again an existing implemented extension) which "parallels" the
> existing STANDARD leading phrase would be a "good thing" is being asked.
> In most other places in Standard ('85 or '02) COBOL where a "leading
> phrase" is supported, there is also a "trailing phrase". Therefore, this
> doesn't seem to be unreasonable. On the other hand, I agree that the
> INSPECT statement is sufficiently "complex" today that many of its uses
> are obscure (and end up with complex object code).
>
> ***
>
> Finally, during the development of the '02 Standard, (possibly before) a
> suggestion was officially made to J4 that it ONLY add new syntax which was
> already in existence in at least one implementation. This was rejected -
> and has been rejected when talked about since. I don't know if this would
> or would not have "helped" the history of Standard COBOL, but it does seem
> at least somewhat relevant to this discussion.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
| |
| Chuck Stevens 2006-05-10, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:unr8g.452435$7i1.49099@fe06.news.easynews.com...
> "Meanwhile" IBM provided the (extension) TRANSFORM facility which did
> provide the same functionality as this part of the EXAMINE (which the '74
> Standard INSPECT did not).
All I have on TRANSFORM is an IBM DOS reference manual.
As to EXAMINE ... REPLACING, I have the same IBM DOS reference manual, and
the corresponding manuals from Burroughs from the similar period. I don't
see anything in EXAMINE that leads me to believe that it supports TRANSFORM
functionality. The IBM manual allows only one literal pair and it has to be
one byte long. How do you do a "transform" using EXAMINE ... REPLACING?
It is *possible* possible to handle TRANSFORM functionality using standard
'74 INSPECT. The source code is truly hideous (in our implementation the
resulting code can be really, really fast), but it's not impossible to do.
It involves, say, 256 "ALL ... BY ..." sequences after the keyword
REPLACING. INSPECT ... CONVERTING is a *much* clearer syntactic
representation of the same functionality, I think.
> Another (pretty academic now) question then arises whether it would have
> been better for J4 to introduce a TRANSFORM statement (which matched the
> "relatively common" extension to the '74 Standard) RATHER than introducing
> the CONVERTING phrase of the INSPECT statement - into the '85 Standard.
Well, seems to me
INSPECT A-RECORD CONVERTING EBCDIC-CHARLIST TO ASCII-CHARLIST
is at least as clear a description of what's going on as
TRANSFORM A-RECORD FROM EBCD-CHARLIST TO ASCI-CHARLIST.
so I don't see all that much reason, beyond "Well, IBM does it that way, so
it must be good!" to choose the latter over the former.
I must admit, though, that sometimes the "IBM way" does creep in to the
standard -- GOBACK was mentioned somewhere in this thread, and I'm not
thrilled with the semantics of this verb! I'd rather see specific
directions (and runtime failures when they're inappropriate) than the
vagueness of GOBACK. ISTR the final discussions on this took place early
in my tenure on J4, and I lost that argument ... still think GOBACK's a bad
idea ...
-Chuck Stevens
| |
| William M. Klein 2006-05-10, 9:55 pm |
| Chuck,
You are correct (as far as I can find out) that EXAMINE did *not* have the
same functionality as INSPECT CONVERTING (and TRANSFORM). My best *guess* is
that the COBOL (IBM extension) TRANSFORM statement had its origin in the IBM
S/360 "translate" Assembler instruction. See:
http://publibz.boulder.ibm.com/cgi-...z9zr003/7.5.141
but as I wasn't involved when TRANSFORM was first introduce, I certainly can't
swear to this.
P.S. On the subject of IBM providing "conversion assistance" for previously
supported, but later dropped extension, see the CCCA manual at:
http://publibz.boulder.ibm.com/cgi-...CCM02/CCONTENTS
Than product DOES provide automatic conversion support for both EXAMINE and
TRANSFORM.
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e3tj54$mc7$1@si05.rsvl.unisys.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:unr8g.452435$7i1.49099@fe06.news.easynews.com...
>
>
> All I have on TRANSFORM is an IBM DOS reference manual.
>
> As to EXAMINE ... REPLACING, I have the same IBM DOS reference manual, and the
> corresponding manuals from Burroughs from the similar period. I don't see
> anything in EXAMINE that leads me to believe that it supports TRANSFORM
> functionality. The IBM manual allows only one literal pair and it has to be
> one byte long. How do you do a "transform" using EXAMINE ... REPLACING?
>
> It is *possible* possible to handle TRANSFORM functionality using standard '74
> INSPECT. The source code is truly hideous (in our implementation the
> resulting code can be really, really fast), but it's not impossible to do. It
> involves, say, 256 "ALL ... BY ..." sequences after the keyword REPLACING.
> INSPECT ... CONVERTING is a *much* clearer syntactic representation of the
> same functionality, I think.
>
>
> Well, seems to me
> INSPECT A-RECORD CONVERTING EBCDIC-CHARLIST TO ASCII-CHARLIST
> is at least as clear a description of what's going on as
> TRANSFORM A-RECORD FROM EBCD-CHARLIST TO ASCI-CHARLIST.
> so I don't see all that much reason, beyond "Well, IBM does it that way, so it
> must be good!" to choose the latter over the former.
>
> I must admit, though, that sometimes the "IBM way" does creep in to the
> standard -- GOBACK was mentioned somewhere in this thread, and I'm not
> thrilled with the semantics of this verb! I'd rather see specific directions
> (and runtime failures when they're inappropriate) than the vagueness of
> GOBACK. ISTR the final discussions on this took place early in my tenure on
> J4, and I lost that argument ... still think GOBACK's a bad idea ...
>
> -Chuck Stevens
>
>
>
>
| |
| Pete Dashwood 2006-05-11, 6:55 pm |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e3t2ta$cl7$1@si05.rsvl.unisys.com...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:1263rv76rk9hh74@corp.supernews.com...
>
>
> Actually, from all I can tell, PICTURE was present from the beginning
> (1960).
Sorry, the first COBOL compiler I used was COBOL 59 (in 1965, illicitly. I
was not supposed to be using it... ).I didn't formally go on a COBOL course
until 1967.. It had no picture clause. We used SIZE, CLASS and USAGE.
If both PICTURE and SIZE were specified, PICTURE was used. I'm not
> sure what you mean by CLASS here, but USAGEs could appear in SIZE clauses
> between the number of digits and the type of representation
> (CHARACTERS/DIGITS).
CLASS was as used in the Class test to this day. It could be NUMERIC,
ALPHABETIC, or ALPHANUMERIC.
>
> The SIZE clause does *not* seem to have made it as far as ANSI X3.23-1968
> (AKA "first standard COBOL"), though it was included in our COBOL(68)
> implementation for upward compatibility with B5000/B5500/B5700 COBOL (an
> implementation of COBOL-60).
>
> Personally, I think the fact that you could say either
> PICTURE 9(5) USAGE DISPLAY or SIZE 5 DISPLAY CHARACTERS
> but there was no corresponding mechanism for alphanumeric data items (SIZE
> implies numeric). I find that a strange limitation.
>
> Likewise, I think the fact that you could say
> SIZE 5 COMPUTATIONAL CHARACTERS
> in implementations in which the format and layout of COMPUTATIONAL wasn't
> either "character-oriented" or "digit-oriented" in the first place (e.g.,
> binary) was at best misleading.
>
> And the fact that SIZE required the data item to be an *integer* was a
> real limitation -- that requires you to code
> PICTURE 9(5)V99 DISPLAY
> instead of something like
> SIZE 7 DISPLAY CHARACTERS SCALE [FACTOR] 2 ...
>
> Yes, lots of people have ways they'd rather code things than the way the
> COBOL standard currently allows them to be coded. I'm not convinced that
> the language would have been well-served by the retention of the SIZE
> clause from the original CODASYL design, nor am I convinced that the
> language is well-served by adding different ways to do something you can
> already do in a relatively straightforward manner. I'll vote for spending
> the energy on new *functionality* every time.
>
> -Chuck Stevens
>
| |
| Pete Dashwood 2006-05-11, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:9ft362ls6ds3qav80brvonfcdpv21p5ovm@
4ax.com...
> On Thu, 11 May 2006 00:42:23 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> I did a conversion once (from Univac 9030) where I replaced lots of
> EXAMINE statements with TRANSFORM statements, on the theory that
> TRANSFORM works with both ANSII versions and did what we wanted.
>
> Then they dropped TRANSFORM.
LOL! Always the way... just when we learn how to use something...:-)
Well, TRANSFORM WAS an IBM extension and it really did not provide quite the
same functionality as EXAMINE (although some people used it that way,
believing (incorrectly) it was more efficient. TRANSFORM was intended for
translating character sets, originally with different tape formats.
Pete.
| |
| Pete Dashwood 2006-05-11, 6:55 pm |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:e3t2q2$c9u$01$1@news.t-online.com...
> "HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
> news:1263vl5rbif2lda@news.supernews.com...
>
> No, that's no good.
> I don't want version highlights.
> I need reference doc.
> Just like ACU, Fujitsu do not seem want to put
> their reference manuals on the net. Pfui.
> At least MF have their complete doc on the web.
>
> Roger While
>
>
Well, Gee, Roger, if you looked a little harder you'd find the entire
reference manual set on the web at the same site. Pretty decent of them
really. Considering SOME people want to reverse engineer the product... :-)
(I can't imagine why...you'd think they'd let it go with dignity...)
Pfui yourself :-)
Pete.
| |
| Pete Dashwood 2006-05-11, 6:55 pm |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e3t69i$emk$1@si05.rsvl.unisys.com...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4ce5dlF15a7qgU1@individual.net...
>
>
> Users of other languages liked the functionality of CASE, which is what
> EVALUATE provides (and much more, I'd say).
>
>
> INSPECT, introduced in a standard published thirty-two years ago now,
> provides a superset of the functionality previously available with
> EXAMINE.
>
> As I see it, EXAMINE does not allow comparison by an identifier, does not
> allow combined tallying/replacing in the same statement, does not allow
> BEFORE/AFTER clauses, does not allow multiple replacements within the same
> data item, and does not allow multiple data items to be handled in a
> single statement. I believe the keyword EXAMINE can be replaced by the
> keyword INSPECT in all contexts in which the former is superseded by the
> latter; the reverse is by no means true.
>
> I wasn't involved in the standards process when this decision was made (it
> first shows up in the JOD of 1969), but my best guess as to the *reason*
> they used a different verb altogether for this was that some significant
> vendor had enhanced EXAMINE in a way that would have made the new features
> incompatible with that implementation. Since the feature content of
> INSPECT is so much greater than the (standard) feature content of EXAMINE,
> providing a new verb was an approach that was actually friendlier to that
> user base, and not all that unfriendly to the rest of the EXAMINE-using
> community.
>
> In the past, it seems to me your main "beef" with the COBOL standards
> process has had to do with the fact that in the seventeen years starting
> in 1985 it only produced two amendments and an updated standard with
> significant (perhaps *too much*) feature content, and you have had nothing
> negative to say about the standards process *prior to* the introduction of
> the '85 standard.
>
My 'beef's with the COBOL standards committee are a matter of record. I'm
not going through them all again. I do believe it started going to Hell in a
wheelbarrow when ANSI became involved and the original CODASYL committee
(who had vision and the right attitude) were phased out.
> I can't help but wonder why you seem to have begun complaining *now* about
> the way the '74 and even the '68 standards evolved from Adm. Hopper's
> original ideas as put forth in 1959-1960.
Hmmmm... I'm surprised at you Chuck. I thought you of all people whould
understand the word 'rhetoric'.
My post did not require answers; I am well aware of the answers in every
case I mentioned. It was intended to point out the inconsistency of a stated
viewpoint... in a gentle way. As it was intended to be light-hearted and I
was not expecting answers or for it to be taken seriously, I can't see how I
am now "complaining". No complaint was expressed or implied.
> I don't think there's a whole lot I can do about convincing the
> contributors to ANSI X3.23-1968 (or for that matter ANSI X3.23-1974
> or -1985) that they Did It All Wrong and that they Need To Do It All
> Over -- I strongly suspect the great majority of them are dead now anyway!
I agree. Neither is there any requirement for you to do so as far as I'm
concerned.
Pete.
>
> -Chuck Stevens
>
| |
| Pete Dashwood 2006-05-11, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:mbq8g.73852$JV1.55476@fe05.news.easynews.com...
> Pete,
> I know that Chuck has responded to a couple of the specifics, but as I
> agree with his initial post, I think what was not clear was that the
> "resistance" to adding new (redundant) syntax is a POST-2002 (somewhat in
> that too) development.
>
> The 2002 Standard introduced LOTS and LOTS (too much IMHO) new "syntax" -
> some for things one could already do, some they couldn't.
>
> Rightly or wrongly (I think rightly) SOME of the resistance to
> implementing the '02 Standard was that it was simply "TOO BIG".
>
> The features that you mention were all introduced in the '85 Standard or
> earlier.
>
Bill,
I appreciate the response and the sincerity of it, but you are preaching to
the choir.
A position was expressed that it is not good to include in the COBOL
language new facilities, where the same effect can be achieved with existing
constructs.
Here is the original quote:
> Yes, as I recall it J4 was of the opinion that anything you'd want to do
> with TRAILING you could accomplish with existing syntax, even if it
> required a "temporary" and an extra statement.
>
> Adding new syntax for functionality that already exists -- particularly
> when the syntax for that functionality is pretty straightforward -- adds
> complexity to the language without adding functional feature content, and
> for that reason the suggestions to provide TRAILING were not followed.
This struck me when I read it as ludicrous. Given that I don't really care
and it is all now academic anyway, I responded with what were intended to be
examples showing that COBOL has ALWAYS been extended when there were already
facilities in it to do what was being offered as 'new'. Personally, I no
longer care whether INSPECT implements TRAILING or not. But to piously say
it won't get done because there is already facility in the language that can
implement it, is, in the context of the constructs I posted, laughable...
I did not intend to argue it seriously, was not complaining about it, did
not expect detailed discussions about when and how this came about, was not
(for once :-)) having a XXXXX at J4 or implying this was all their fault,
(when I DO have a XXXXX about J4 it is not implicit...I don't think anyone
has any doubts regarding my feelings in this department :-)), and neither
was I posting a response about whether or not COBOL should have TRAILING on
the INSPECT verb.
I believe that any further changes to COBOL now are simply a waste of time
and money. Admittedly that hasn't stopped J4 in the past, and it is ironic
(yet exactly what I would expect...) that their swan song is going to be an
XML facility that is unnecessary, unhelpful, and being given priority over
things like getting the 02 standard implemented.
If they get disbanded it serves them right.
> The '02 Standard had SOME new "redundant" features (e.g. GOBACK,
> partial-word replacement, SET TO FALSE). However, it is my memory that
> even in the development of that Standard there was SOME discussion that
> these facilities COULD already be accomplished and did the language really
> need them. In these 3 cases (and possibly most others), the view was (as
> I recall it) that the new syntax was "more self-documenting". I am not at
> all certain that ANY of them would make it into a post-02 Standard - if
> they were up for discussion now. Having said that, I do think that every
> possible enhancement has (and continues to be) considered on a "case by
> case" basis. A (well-discussed in this forum) feature was the addition of
> the "<>" operator - which DID make it into the draft '08 Standard.
Forgive me being underwhelmed by such an event. :-) I'll look forward to
replacing the writer's cramp inducing, long winded, 'NOT =' with two
characters that have no bearing whatsoever on the original stated purpose of
COBOL to be English like and understandable.
But we gave that up years ago and decided it was more important to emulate
fashion than to stick to our guns and retain the vision of the inventors of
COBOL.
Now let's have a wave of letters telling me how great it is to have an
unequal operator in COBOL, and what a fuddy-duddy I must be for not hailing
it with enthusiasm. (The fact that I use it daily in VB and Java is
irrelevant; these are not COBOL...)
Bugger, now I've responded seriously to something that was written with
tongue in ch, originally.
Gotta love this forum :-)
Pete.
| |
| Chuck Stevens 2006-05-11, 6:55 pm |
| "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4cgs32F15r5a8U1@individual.net...
[color=darkred]
> Sorry, the first COBOL compiler I used was COBOL 59 (in 1965, illicitly. I
> was not supposed to be using it... ).I didn't formally go on a COBOL
> course until 1967.. It had no picture clause. We used SIZE, CLASS and
> USAGE.
I'm going by the "History of COBOL" section of the 1974 standard, which
indicates that the initial meeting was May 28 and 29, 1959; that the initial
specification wasn't done until September 1959; that the specification
wasn't fully fleshed out as a language until December 1959, and that the
first *published* description of COBOL came out in April 1960 ("COBOL -- A
Report to the Conference on Data Systems Languages, including Initial
Specifications for a Common Business Oriented Language (COBOL) for
Programming Electronic Digital Computers").
Are you sure you weren't using one of the "ancestors" of COBOL as listed in
the acknowledgments in older COBOL standards, namely, FLOW-MATIC from Univac
(copyrighted 1958, 1959), the Commercial Translator from IBM (copyrighted
1959), or FACT from Minneapolis-Honeywell (copyrighted 1960)?
>
> CLASS was as used in the Class test to this day. It could be NUMERIC,
> ALPHABETIC, or ALPHANUMERIC.
Your query was "Why was PICTURE provided in the langage when exactly the
same functionality was available with CLASS, and SIZE?".
I understood the availability of SIZE as an alternative for PICTURE, but
couldn't relate to how CLASS was a syntactic/semantic substitute for
PICTURE. And thus I stand by the question: what functionality does the
class test in the PROCEDURE DIVISION provide that duplicates what PICTURE
provides in the DATA DIVISION sufficient to render the latter unnecessary?
-Chuck Stevens
| |
| HeyBub 2006-05-11, 6:55 pm |
| Roger While wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
> news:1263vl5rbif2lda@news.supernews.com...
>
> No, that's no good.
> I don't want version highlights.
> I need reference doc.
> Just like ACU, Fujitsu do not seem want to put
> their reference manuals on the net. Pfui.
> At least MF have their complete doc on the web.
====== begin quote
FUNCTION STORED-CHAR-LENGTH (argument-1)
Argument
1. Argument-1 must be alphanumeric or national characters. It must not be a
group item.
2. Argument-1 must consist of one or more characters.
Function Value
1. The function value is the number of character positions of the effective
characters contained in argument-1.
2. When argument-1 is the alphanumeric class, the function value indicates
the
number of alphanumeric character positions of the effective characters.
3. When argument-1 is the national class, the function value indicates the
number
of national character positions of the effective characters.
4. The characters stored in argument-1 must follow the encoding forms
dictated by
the class of argument-1. Otherwise, the result is undefined.
Function Type
The function type is integer.
===== end quote
http://www.adtools.com/download/v8m...LanguageRef.pdf
(pdf file, 14 megabytes)
| |
| Chuck Stevens 2006-05-11, 6:55 pm |
| "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4cgus9F15np3pU1@individual.net...
> I believe that any further changes to COBOL now are simply a waste of time
> and money. Admittedly that hasn't stopped J4 in the past, and it is ironic
> (yet exactly what I would expect...) that their swan song is going to be
> an XML facility that is unnecessary, unhelpful, and being given priority
> over things like getting the 02 standard implemented.
Neither J4 nor WG4 nor any of its parent bodies have *any* power to *force*
anyone to implement a COBOL compiler compliant with the 2002 standard.
And the reason XML (and the other TR's) are visible is that they were
written to be applicable to the 2002 standard as well as incorporated into
the 2008 draft. Is that such a bad thing? I question the characterization
of the XML TR as J4's "swan song", because I believe XML is but one among
many features to be incorporated into the next standard; it has visibility
because as a TR it's being applied against the *current* standard, largely
as a "trial balloon". There are lots of features, some big, some small,
that are being incorporated into the 2008 draft *without* going through the
"trial-balloon" of a TR because both WG4 and J4 agree they stand on their
own merit!
For example, I think one of the best things J4 and WG4 have done is the new
arithmetic mechanisms in the2008 draft -- I'm prejudiced, of course. I
think having new modes of arithmetic that are based on formats and behaviors
that conform to an internationally-adopted *arithmetic* standard (the
revision to IEEE 754) that is *outside of the COBOL standard* resolves one
of the HUGE issues preventing the very code portability for which COBOL was
designed in the first place. Whether the IEEE standard ends up being
something that can legitimately be cited in an ISO language standard remains
to be seen, but I think that feature is a fundamental improvement to the
internals of the language.
Too little, too late? Well, maybe. I first became aware of the IEEE 754
effort and recognized the importance to COBOL of the Decimal128 and perhaps
the Binary128 formats and their rules, in the summer of 2004, informally
suggested to WG4 at their October 2004 meeting that support for them be
included in the 2008 draft. The first draft of a proposal to that effect
was published in December 2004, and the feature is now described in the
current working draft. It's not clear to me that I could have got it done
much more quickly. I can't even say whether the IEEE 754 proposals will
end up being something that the COBOL standard can legitimately reference
when push comes to shove. What I can say is that I think the feature
content is a Big Improvement at the very core of the COBOL language, and
that I've done my best to make it work. In general, I think I've made some
fairly decent contributions to the COBOL standard given that I'm a relative
newbie to the COBOL standardization process, having attended my first
meeting as Unisys' representative on J4 in December 2000.
And I know you have disagreed with the feature-content priorities of J4 and
WG4 over the years. But if Pete Dashwood says he wants feature "x", and
DIN and BSI have decided that they want feature "y" instead, it's kind of
incumbent on WG4 to instruct J4 to work on feature "y". The whole process
is driven by *national standards bodies*. I know you disagree with that
approach, but neither J4 nor WG4 have any say in whether that's the
appropriate way for formal international standards to be developed and
adopted. Nor do they have any say over whether any implementor decides to
market a product that conforms, in every detail or only in part, to that
standard.
I know of no work that J4 or WG4 can do to force or even encourage everyone
from IBM through TinyCobol, or any subset of that group, to incorporate
every single widget of every single doodad in the 2002 standard, to say
nothing of the 2008 draft, under threat of ... what ...?
-Chuck Stevens
| |
| Karl Kiesel 2006-05-12, 3:55 am |
|
"Chuck Stevens" <charles.stevens@unisys.com> schrieb im Newsbeitrag
news:e3vhio$1rg9$1@si05.rsvl.unisys.com...
>
> I understood the availability of SIZE as an alternative for PICTURE, but
> couldn't relate to how CLASS was a syntactic/semantic substitute for
> PICTURE. And thus I stand by the question: what functionality does the
> class test in the PROCEDURE DIVISION provide that duplicates what PICTURE
> provides in the DATA DIVISION sufficient to render the latter unnecessary?
>
The 'COBOL-61 extended' report specifies as one of various clauses within a
record description in the data division a CLASS clause with 'FUNCTION: To
indicate the type of data being described' and with a syntax
CLASS IS {ALPHABETIC / NUMERIC / APHANUMERIC /AN} (only keywords within
the brackets are underlined)
and several notes, of which the last says: '6. If a PICTURE is given, the
CLASS clause is unnecessary. If both are used, however, the class of
characters shown in the PICTURE must not contradict the CLASS clause of an
elementary item, or of a group to which the item belongs'
K. Kiesel
| |
| Pete Dashwood 2006-05-12, 3:55 am |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e3vlh4$1tuv$1@si05.rsvl.unisys.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4cgus9F15np3pU1@individual.net...
>
>
> Neither J4 nor WG4 nor any of its parent bodies have *any* power to
> *force* anyone to implement a COBOL compiler compliant with the 2002
> standard.
>
So why have standards?
<snip>
> For example, I think one of the best things J4 and WG4 have done is the
> new arithmetic mechanisms in the2008 draft -- I'm prejudiced, of course.
> I think having new modes of arithmetic that are based on formats and
> behaviors that conform to an internationally-adopted *arithmetic* standard
> (the revision to IEEE 754) that is *outside of the COBOL standard*
> resolves one of the HUGE issues preventing the very code portability for
> which COBOL was designed in the first place. Whether the IEEE standard
> ends up being something that can legitimately be cited in an ISO language
> standard remains to be seen, but I think that feature is a fundamental
> improvement to the internals of the language.
>
Gosh, yes. Let's have computers that can do arithmetic. Pity CODASYL never
thought of that...
> Too little, too late? Well, maybe. I first became aware of the IEEE 754
> effort and recognized the importance to COBOL of the Decimal128 and
> perhaps the Binary128 formats and their rules, in the summer of 2004,
> informally suggested to WG4 at their October 2004 meeting that support for
> them be included in the 2008 draft. The first draft of a proposal to that
> effect was published in December 2004, and the feature is now described in
> the current working draft.
4 years huh? And still no sign of it... and if it DOES happen, no way to
ensure anyody implements it.
Why have standards?
> It's not clear to me that I could have got it done much more quickly.
This discussion was never intended to be personal and I state again that I
have nothing but the highest respect for your dedication and ability, Chuck.
If you choose to waste your time with a pointless, toothless, bunch of
wankers who have done no service for COBOL, that is entirely a matter for
you :-)
> I can't even say whether the IEEE 754 proposals will end up being
> something that the COBOL standard can legitimately reference when push
> comes to shove. What I can say is that I think the feature content is a
> Big Improvement at the very core of the COBOL language, and that I've done
> my best to make it work.
Sure, and who knows, maybe your efforts might have made some difference. But
the outcome is the same. No results, and nobody being encouraged to even
implement the 02 standard. It is a pointless exercise. Surely, the past
experience has demonstrated that. I see no changes being implemented.
In general, I think I've made some
> fairly decent contributions to the COBOL standard given that I'm a
> relative newbie to the COBOL standardization process, having attended my
> first meeting as Unisys' representative on J4 in December 2000.
>
Well, that's all right then...:-) As long as YOU think so...
> And I know you have disagreed with the feature-content priorities of J4
> and WG4 over the years.
Yeah, I reckon an unbiased observer could glean that from the tirades I have
repeatedly posted here :-).
Actually, I really am over it now. But it still hurts when I think about it
so, as a general rule, I don't...
>But if Pete Dashwood says he wants feature "x", and DIN and BSI have
>decided that they want feature "y" instead, it's kind of incumbent on WG4
>to instruct J4 to work on feature "y".
Actually, Pete Dashwood has NEVER said he wanted ANYTHING in the COBOL
standard. On the contrary, Pete Dashwood has consistently questioned the
usefulness of and the effectiveness of both the standards committee and the
standard. My position has been (and still is) that COBOL is better off
without a standard, given that the governing standards body is about as
useful as boxing gloves to a watchmaker.
>The whole process is driven by *national standards bodies*. I know you
>disagree with that approach, but neither J4 nor WG4 have any say in whether
>that's the appropriate way for formal international standards to be
>developed and adopted.
Precisely. So what exactly CAN they do? They are part of the ISO/ANSI gravy
train. (Oops, sorry that is a non-profit gravy train of course...) Why can't
they have a word to the Engineer and get a few things changed? It is now far
too late as the COBOL train is headed onto a siding that ends in Oblivion
County. (No one ever goes there unless they're stoned or pissed...) If
people were serious about a COBOL standard it should have been sorted years
ago.
> Nor do they have any say over whether any implementor decides to market a
> product that conforms, in every detail or only in part, to that standard.
>
So why have a standard? What good is a law without enforcement? And nobody
is going to stand for being enforced to implement what a committee that long
ago lost all credibility, is saying COBOL needs to make it viable.
> I know of no work that J4 or WG4 can do to force or even encourage
> everyone from IBM through TinyCobol, or any subset of that group, to
> incorporate every single widget of every single doodad in the 2002
> standard, to say nothing of the 2008 draft, under threat of ... what ...?
>
Threat of not being allowed to call it COBOL for a start...
But I tire of this so I'll not present all the other arguments, that won't
make a jot of difference anyway.
I don't understand why a talented capable person like yourself would lend
your energy to this farce, but that is your prerogative and I'm sure you
have your reasons. (C'mon... level with us... is someone paying you to do
this :-)?)
I honestly wish you luck, Chuck.
Pete.
| |
| Pete Dashwood 2006-05-12, 3:55 am |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e3vhio$1rg9$1@si05.rsvl.unisys.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4cgs32F15r5a8U1@individual.net...
>
>
>
> I'm going by the "History of COBOL" section of the 1974 standard, which
> indicates that the initial meeting was May 28 and 29, 1959; that the
> initial specification wasn't done until September 1959; that the
> specification wasn't fully fleshed out as a language until December 1959,
> and that the first *published* description of COBOL came out in April 1960
> ("COBOL -- A Report to the Conference on Data Systems Languages, including
> Initial Specifications for a Common Business Oriented Language (COBOL) for
> Programming Electronic Digital Computers").
It was referred to within the organisation as "COBOL 59 ". It was an IBM
site running TOS on system 360-32, usually in 1401 compatibility mode.
>
> Are you sure you weren't using one of the "ancestors" of COBOL as listed
> in the acknowledgments in older COBOL standards, namely, FLOW-MATIC from
> Univac (copyrighted 1958, 1959), the Commercial Translator from IBM
> (copyrighted 1959), or FACT from Minneapolis-Honeywell (copyrighted 1960)?
>
I'm not sure of anything from that time :-) It was the sixties, for
Chrissake :-)
>
>
> Your query was "Why was PICTURE provided in the langage when exactly the
> same functionality was available with CLASS, and SIZE?".
>
Because USAGE was used with or without PICTURE as it is to this day.
And, it was a rhetorical question which was not expecting an answer.
However, if someone answers a rhetorical question they might at least get
the answer right...
> I understood the availability of SIZE as an alternative for PICTURE, but
> couldn't relate to how CLASS was a syntactic/semantic substitute for
> PICTURE. And thus I stand by the question: what functionality does the
> class test in the PROCEDURE DIVISION provide that duplicates what PICTURE
> provides in the DATA DIVISION sufficient to render the latter unnecessary?
OK...
01 flip PICTURE 9 USAGE DISPLAY.
01 flip CLASS is NUMERIC, SIZE is 1, USAGE is DISPLAY.
The two definitions above define identical uses of storage.
01 flop PICTURE X(5).
01 flop CLASS is ALPHANUMERIC, SIZE is 5, USAGE is DISPLAY.
So do those 2...
01 flap PICTURE A(7) USAGE DISPLAY.
01flap CLASS is ALPHABETIC, SIZE is 7, USAGE is DISPLAY.
As do those 2...
And finally....
01 prick SIZE is ENORMOUS, CLASS is OLYMPIC, USAGE is INTERNAL FLOATING
POINT.
.....
I never said the CLASS test in the procedure division was used to define
data; I said that CLASS worked the same way that a CLASS test does in the
procedure division...(I was hoping you'd catch my drift... apparently a
forlorn hope as I have now had to spell it out... :-))
Procedure Division.
....
if flop is NUMERIC *> example of COBOL CLASS test
....
Pete.
| |
| Pete Dashwood 2006-05-12, 3:55 am |
|
"Karl Kiesel" <Karl.Kiesel@fujitsu-siemens.com> wrote in message
news:e41d9j$ovg$1@nntp.fujitsu-siemens.com...
>
> "Chuck Stevens" <charles.stevens@unisys.com> schrieb im Newsbeitrag
> news:e3vhio$1rg9$1@si05.rsvl.unisys.com...
> The 'COBOL-61 extended' report specifies as one of various clauses within
> a record description in the data division a CLASS clause with 'FUNCTION:
> To indicate the type of data being described' and with a syntax
> CLASS IS {ALPHABETIC / NUMERIC / APHANUMERIC /AN} (only keywords within
> the brackets are underlined)
> and several notes, of which the last says: '6. If a PICTURE is given, the
> CLASS clause is unnecessary. If both are used, however, the class of
> characters shown in the PICTURE must not contradict the CLASS clause of an
> elementary item, or of a group to which the item belongs'
>
> K. Kiesel
>
Thank you for posting that Karl.
Given that your document and Chuck's both indicate PICTURE was available,
I'm at a loss to account for why we didn't use it. It may have been lack of
understanding on my part at the time or perhaps it was an installlation
standard, I honestly can't remember.
I DO remember learning about PICTURE on an ICL COBOL course in Auckland in
1967.
Pete.
>
| |
| Chuck Stevens 2006-05-12, 6:55 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4ciugjF15psdsU1@individual.net...
>
> OK...
>
> 01 flip PICTURE 9 USAGE DISPLAY.
>
> 01 flip CLASS is NUMERIC, SIZE is 1, USAGE is DISPLAY.
>
[remainder snipped]
That's the part I couldn't find in any of the information I had available:
the use of CLASS *in a data-declaration entry* and the associated semantics
of the clause.
The only pre-'68-standard reference materials I have at hand show no sign of
the CLASS clause (though they do include SIZE).
-Chuck Stevens
| |
| Richard 2006-05-12, 6:55 pm |
| > That's the part I couldn't find in any of the information I had available:
> the use of CLASS *in a data-declaration entry* and the associated semantics
> of the clause.
> The only pre-'68-standard reference materials I have at hand show no sign of
> the CLASS clause (though they do include SIZE).
I recall early ICL compilers: XE11 Compact Cobol, XE13 Cobol '61 where
PICTURE was a new thing and not to be trusted. The 'CLASS' keyword was
optional, as was, and is, 'USAGE' and 'SIGN', so one could write:
77 WS-TOTAL SIZE 6 DISPLAY NUMERIC.
There were also EDITED and SIGNED but I can't remember if these were
hyphenated to NUMERIC. There were many things that could not be done
that could be with PICTURE such as insertion characters.
Actually that looks almost like SQL.
| |
|
| Pete Dashwood wrote:
>
> 01 prick SIZE is ENORMOUS, CLASS is OLYMPIC, USAGE is INTERNAL FLOATING
> POINT.
Glad to see your imagination is still there... ;)
(INTERNAL FLOATING POINT? That made me laugh....)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| HeyBub 2006-05-12, 9:55 pm |
| LX-i wrote:
> Pete Dashwood wrote:
>
VALUE "MITY69"
MOVE FUNCTION EXPAND (Prick) TO GOODNESS-ME.
DISPLAY GOODNESS-ME
Massachusetts Institute of Technology Year of 1969.
| |
| Pete Dashwood 2006-05-13, 6:55 pm |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:271ae$44654e67$45491dc8$3016@KNOLOG
Y.NET...
> Pete Dashwood wrote:
>
> Glad to see your imagination is still there... ;)
Hey, all I did was step out of the bath and glance in the mirror...
>
> (INTERNAL FLOATING POINT? That made me laugh....)
>
Good, that was the general idea. :-) Thanks for letting me know it was worth
the effort... :-)
Did you notice that in his response, Chuck cut it without referring to it at
all...? :-)
I expected a comment that the CLASS and SIZE violated COBOL standards.
('Internal floating point 'could be an IBM extension (pardon the pun...
:-)). If it isn't, then it bloody well ought to be... I'd use floating point
arithmetic just so I could code it...:-)
Pete.
| |
| Pete Dashwood 2006-05-13, 6:55 pm |
|
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:126akd8l1gshuff@news.supernews.com...
> LX-i wrote:
>
> VALUE "MITY69"
>
> MOVE FUNCTION EXPAND (Prick) TO GOODNESS-ME.
> DISPLAY GOODNESS-ME
> Massachusetts Institute of Technology Year of 1969.
My Alma Mater... :-)
If that's genuine, HeyBub, I am thrilled to be in such company :-) (MIT, not
the MITY prick...)
Pete.
| |
| HeyBub 2006-05-13, 6:55 pm |
| Pete Dashwood wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:126akd8l1gshuff@news.supernews.com...
[color=darkred]
> My Alma Mater... :-)
>
> If that's genuine, HeyBub, I am thrilled to be in such company :-)
> (MIT, not the MITY prick...)
>
> Pete.
Then you'll appreciate the following (posted on an anti-spam newsgroup to
those who complain that SPEWS (a blocklist of spamming ISPs) has blocked
their emails and could SPEWS please remove their IP addresses from the
list):
1. Your emails are like sperm: ready to leap out and do their thing.
2. Your ISP is a prick.
3. SPEWS is a condom.
4. We are innocent maidens who don't like surprises.
5. You are asking for one teeny hole in the rubber.
You'll have to get us drunk first.
| |
| Pete Dashwood 2006-05-13, 6:55 pm |
|
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:126btr8faudih6f@news.supernews.com...
> Pete Dashwood wrote:
>
>
> Then you'll appreciate the following (posted on an anti-spam newsgroup to
> those who complain that SPEWS (a blocklist of spamming ISPs) has blocked
> their emails and could SPEWS please remove their IP addresses from the
> list):
>
> 1. Your emails are like sperm: ready to leap out and do their thing.
> 2. Your ISP is a prick.
> 3. SPEWS is a condom.
> 4. We are innocent maidens who don't like surprises.
> 5. You are asking for one teeny hole in the rubber.
>
> You'll have to get us drunk first.
ROFL! And very apposite.
Pete.
| |
| Richard 2006-05-14, 6:55 pm |
| > That's the part I couldn't find in any of the information I had available:
> the use of CLASS *in a data-declaration entry* and the associated semantics
> of the clause.
http://www.icl1900.co.uk/techpub/c19ref.html
| |
| Chuck Stevens 2006-05-19, 6:55 pm |
| Thanks for the URL, Richard.
I do have to admit that neither the ICL 1900 COBOL compiler nor the summary
and comprehensive documentation for it are products to which I have been
exposed before! ICL systems haven't been all *that* common on this side of
the pond ...
-Chuck Stevens
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1147638066.184124.228270@v46g2000cwv.googlegroups.com...
>
> http://www.icl1900.co.uk/techpub/c19ref.html
>
| |
| Pete Dashwood 2006-05-20, 3:55 am |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e4kndv$2aek$1@si05.rsvl.unisys.com...
> Thanks for the URL, Richard.
>
> I do have to admit that neither the ICL 1900 COBOL compiler nor the
> summary and comprehensive documentation for it are products to which I
> have been exposed before! ICL systems haven't been all *that* common on
> this side of the pond ...
>
That's a pity...!
It was excellent hardware and software and a delight to program in COBOL or
PLAN (Program LAnguage Nineteen hundred) .
It was killed by losing the 6-bit vs 8-bit byte war (along with some other
very good systems), and the fact that the US market was never really
penetrated by it. A few systems were sold in the US, but I have no idea who
they were or where.
It used a single address hardware system (load and store) with everything
being done through registers and it was blazingly fast. IBM sold 360against
it on the basis that the system 360 had a more 'intelligent' instruction
set, but some benchmarks I did in the late sixties showed that the 1900
creamed it. So much for 'intelligent' (or what we would now call
'complex' )instruction sets... 1900 used RISC before the term was even
invented... :-).
It had a 24 bit word which was considered to be 4 6-bit characters. When it
looked like the world was going to standardize on an 8 bit byte, there was
talk of amending the internal 1900 architecture to consider the 24 bit word
as 3 8-bit bytes and I believe a prototype was actually built in the UK. By
the time it could've been brought to market, IBM had taken the market, and
the 1900 lapsed into obscurity. A new range was released by ICL which,
again, never really penetrated the US market. Eventually they were taken
over by Fujitsu.
I have nothing but happy memories of working on 1900s. Wish I could say the
same about some other household name hardware... :-)
Pete.
<snip>
| |
| Howard Brazee 2006-05-22, 7:55 am |
| On Sat, 20 May 2006 17:02:28 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
[color=darkred]
It seems odd to name a compiler 1900. Sounds as though it was
pre-WWI.
| |
| Ian Dalziel 2006-05-22, 6:55 pm |
| On Mon, 22 May 2006 07:31:13 -0600, Howard Brazee <howard@brazee.net>
wrote:
>On Sat, 20 May 2006 17:02:28 +1200, "Pete Dashwood"
><dashwood@enternet.co.nz> wrote:
>
>
>It seems odd to name a compiler 1900. Sounds as though it was
>pre-WWI.
Around the time of George III, you mean?
--
Ian
| |
| Richard 2006-05-22, 6:55 pm |
| > It seems odd to name a compiler 1900. Sounds as though it was
pre-WWI.
ICL had a history that went back to the UK agent for Hollerith
equipment which was pre-WWI.
The 1900 series had many items number as 19xx, and some did seem to be
pre-WWI. For example the 1911 High Speed Card Reader was almost
victorian in its engineering and styling. Granted it did originate in
the 1940s as tabulator equipment with electronic changes to give it a
1900 interface. It was a huge complicated piece of equipment with a two
stage input hopper that would gate 2000 cards down to about 100 in the
actual cyclic feed area. This then took two cards to the 'instant'
asynchronous read station. Throght the read cells and could divert
'bad' cards to a reject station while the rest were sent up a track to
the output stacks which were a moving belt of trays that would each
take a handfull of cards. You had to take the cards off before the
belt turned around the bottom wheels else they would be tipped on the
floor. Actually there were supposed to be light beams to detect
overflow but it wasn't reliable.
Inside was more wheels and levers than a knitting factory, all fed by a
centralised lubrication system with brass pipes to every moving part
(plus dozens of cards from past lives).
| |
| Pete Dashwood 2006-05-23, 3:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:r7f372hk3m7ot549o37f9tahaq10hqknmk@
4ax.com...
> On Sat, 20 May 2006 17:02:28 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> It seems odd to name a compiler 1900. Sounds as though it was
> pre-WWI.
>
The compiler wasn't named 1900. The system was. It used the first of
January, 1900 (which happened to be a Monday) as the base for all its date
arithmetic.
Pete.
| |
| James J. Gavan 2006-05-23, 6:55 pm |
| Ian Dalziel wrote:
> On Mon, 22 May 2006 07:31:13 -0600, Howard Brazee <howard@brazee.net>
> wrote:
>
>
>
>
> Around the time of George III, you mean?
Nicely put Ian. You could at least have given him a hint :-)
(Nostalgia for the ICT 1500 and ICL 1900 series).
Jimmy
|
|
|
|
|