Home > Archive > Cobol > May 2004 > GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed
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 |
GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed
|
|
| William M. Klein 2004-05-12, 6:47 pm |
| "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40a14cb9.58773361@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
<snip>
>
>
> GOBACK has been legitimized in the 2002 Standard. Acknowledged may be a better
> word; it has been available on most compilers for longer than 20 years.
>
When you say "most compilers" - on what basis do you claim this? I know that
most (all?) IBM compilers and those with "early" IBM-emulation mode provide it
(i.e. Micro Focus, Fujitsu, and CA-Realia). However, I don't know of ANY of the
non-IBM "emulation" compilers with it currently - much less for 20 years (e.g.
HP, DEC, Tandem, Unisys). It is certainly possible that some do (that I admit
to being unfamiliar with) - but I do question the "most compiler" statement
above.
It was (for those not familiar with the history) this type of generalization
based on limit data that caused previous problems with RW.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Robert Wagner 2004-05-12, 6:47 pm |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40a14cb9.58773361@news.optonline.net...
><snip>
better[color=darkred]
>
>When you say "most compilers" - on what basis do you claim this? I know that
>most (all?) IBM compilers and those with "early" IBM-emulation mode provide it
>(i.e. Micro Focus, Fujitsu, and CA-Realia). However, I don't know of ANY of
the
>non-IBM "emulation" compilers with it currently - much less for 20 years (e.g.
>HP, DEC, Tandem, Unisys). It is certainly possible that some do (that I admit
>to being unfamiliar with) - but I do question the "most compiler" statement
>above.
>
>It was (for those not familiar with the history) this type of generalization
>based on limit data that caused previous problems with RW.
It has been available on most compilers I've worked on, which have generally
been the 'IBM emulation' ones -- IBM, Micro Focus, Realia (a long-time love
affair) and Fujitsu. I would have said 'mainstream compilers' except Chuck
Stevens would have objected to the slight against Unisys. He's very sensitive on
the subject.
Last year *you* championed GOBACK as a universal return mechanism. I agreed,
without comment. Now that I speak on the subject, you have a tergiversation -- a
reversal of opinion.
This is pure politics. It's not about the merits of GOBACK, it's about
discrediting me (RW).
| |
| docdwarf@panix.com 2004-05-12, 6:47 pm |
| In article <40a16cfb.67032548@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>"William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
[snip]
[color=darkred]
>It has been available on most compilers I've worked on, which have generally
>been the 'IBM emulation' ones -- IBM, Micro Focus, Realia (a long-time love
>affair) and Fujitsu.
Mr Wagner, it might be fruitful to consider the difference between 'most
compilers' (your original assertion) and 'most compilers I have worked on'
(what you state when asked for the basis of your original assertion).
[snip]
>Last year *you* championed GOBACK as a universal return mechanism. I agreed,
>without comment. Now that I speak on the subject, you have a tergiversation -- a
>reversal of opinion.
Mr Wagner, to 'champion' something is not the same, I believe, as
asserting that it is implemented in 'most compilers'. You made an
assertion about 'most compilers' and when asked for the basis of this you
cited 'most compilers I have worked on'.
>
>This is pure politics. It's not about the merits of GOBACK, it's about
>discrediting me (RW).
Mr Wagner, anyone who, when asked to supply a basis for a 'most' they
employed respond with a 'most that I have worked on' does not frequently
need, in my opinion, anyone else's efforts to discredit them.
DD
| |
| Robert Wagner 2004-05-12, 10:30 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>
>On 12-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
>
>Sort of like saying "most operating systems have a start button that you press
>when you want to shut down the computer".
Haven't you seen the prompt "Press Enter to exit"?
>
>What relation does "Over 90% of production Cobol running today" have to do with
>"most compilers"?
Answered in my response to Chuck Stevens.
>How many compilers run on IBM mainframes, vs how many compilers run on PC's,
>mini computers, and other Mainframe computers?
If number of compilers available or installed was relevant, a free compiler
downloaded by 1,000,000 people (but used by few) would be 33 times more
significant than the estimated 30,000 IBM mainframe Cobol compilers worldwide.
| |
| Robert Wagner 2004-05-12, 10:30 pm |
| "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40a1f7c7.102569347@news.optonline.net...
>
>90%
>
>I would be surprised were that the case. What is the basis for this
>figure? Is that 90% of COBOL source lines worldwide, 90% of production
>COBOL programs in the United States, 90% of the COBOL shops in Armonk that
>have been using GOBACK since the days of DOS COBOL, 90% of the logic touched
>during transaction processing worldwide?
I meant source lines and logic touched in the US and Canada. Assuming equal
productivity and turnover (human nature being fairly constant), we can determine
relative usage from job ads. I just went to DICE and entered search keys all
beginning with "cobol and (programmer or developer) and ..". To find IBM
mainframe, I used "(mainframe or cics) and not unisys and not unix". To find
Unisys, I used "unisys and not unix and not cics". The results were:
IBM mainframe 217
AS/400 35 67% IBM
Unix 46
PC (xp or nt) 36
client-server 19 27% MF & a little IBM
Tandem 12
Unisys 9
Accu Cobol 2
Fujitsu 0
Realia 0
Siemens 0
Total 376
This shows 94% of professional programmers are using IBM or MF.
Under-represented are programmers working solo, for very small companies and in
academic settings.
| |
| Robert Wagner 2004-05-13, 12:30 am |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40a1f7c7.102569347@news.optonline.net...
><snip>
90%[color=darkred]
>
>Yes, I dispute that.
>
>I think that RM, AcuCOBOL, HP (Including former DEC and TANDEM), and Unisys
(not
>to mention OpenCOBOL, KOBOL, etc) constitute a FAR greater per centage than 10
>per cent.
I tried to provide evidence in reply to Chuck Stevens. A search for "cobol and
(rm or liant)" found zero. Accu Cobol and Unisys were previously reported.
"cobol and (dec or vax)" found three, one of which was a 'migration' away from
former DEC. "cobol and hitachi" (said to be a mainframe power outside the US)
returned one hit .. for a PC programmer.
HP does have their own compiler. The two HP (3000) shops I worked at recently
both used Micro Focus in preference to HP's.
OpenCOBOL, KOBOL and the like are toy compilers for hobbiests.
It is possible that job boards -- DICE and similar net-temps, monster, jobs,
etc. -- may be biased in that they look primarily for contractors as opposed to
employees. That means employers tend to be large (F-100) companies and
government agencies powered by politics and little concern for efficiency.
Can you make a case for 'right thinking' companies using other Cobol compilers?
> In fact, I think that Fujitsu and Micro Focus combined probably
>constitute less than 20 per cent of all production code today.
That's in the ballpark. I've heard, from several sources, that Fujitsu is 'very
popular' outside the US. I can't think of a way to quantify that.
> (As far as IBM
>COBOL goes, I think that a medium-larger part is on OS/400 - which has VERY
>different syntax support than what RW tends to assume that "all" IBM COBOL
>supports)
How odd it doesn't use the same 'front end' as other IBM compilers. On second
thought not so odd because AS/400 people like to think they have 'better ideas'
than everyone else. Kinda like Apple people, who don't have any Cobol and less
than 5% of market share.
I'm now on a project 'migrating' a major system from AS/400 to Unix. My
incidental exposure to AS/400 technology shows the debugger to be Grade C. Same
for the touted Integrated Database, which allows VSAM-oriented programmers to
conduct business-as-usual under the guise of being 'modern'. Database concepts
are out the window; it requires a program change every time a column is changed.
AS/400 had its genesis in a 1970 revamp of S/360 to something called NS (New
System). IBM management scrapped that plan and replaced it with S/370, a bigger
faster 360. NS resurfaced ca. 1980 as the AS/400. It has stagnated since then,
trying to use '80s technology to compete with Microsoft and Unix innovations.
>HOWEVER, I also admit that all that I state above is "only a feeling" and that
I
>don't have hard evidence to back this up. On the other hand, the problem with
>your (RW's) contention is that I don't think YOU have any evidence (other than
>your own experience) to back up your statement either.
>
>This is the problem I have always had with your "generalizations" - that you
>make them based on your experience - but "phrase them" as if they were fact.
It's not about experience, it's about reality. Reality is what keeps us honest.
It's the common ground we can't dispute, despite our emotional feelings favoring
other explanations.
Robert
| |
| Richard 2004-05-13, 5:30 am |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> I meant source lines and logic touched in the US and Canada.
Yet another different 'I meant'.
> Assuming equal
> productivity and turnover (human nature being fairly constant),
Human nature is far from constant. Productivity and turnover may be
vastly different between sites.
> we can determine relative usage from job ads.
What complete nonsense. Job ads are for desks that are empty. Empty
desks do not use compilers.
> IBM mainframe 217
> AS/400 35 67% IBM
AS/400 is a quite different beast. Your assertion was '90%' had the
same syntax. What have you done to establish that AS/400 has the same
syntax as the big iron ?
> Unix 46
> PC (xp or nt) 36
> client-server 19 27% MF & a little IBM
You seem to assume that _all_ Unix and PC is MF just because it is not
given. This is certainly not true.
> This shows 94% of professional programmers are using IBM or MF.
No. It shows that there are empty desks.
> Under-represented are programmers working solo, for very small companies and in
> academic settings.
Over represented are positions for which there are multiple ads.
| |
| Richard 2004-05-13, 5:30 am |
| robert.deletethis@wagner.net (Robert Wagner) wrote
[color=darkred]
> If number of compilers available or installed was relevant, ...
Which is exactly why you have had to back pedal from your original two
claims from their complete irrelevancy.
| |
| Howard Brazee 2004-05-13, 11:30 am |
|
On 12-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
> Haven't you seen the prompt "Press Enter to exit"?
Not that I recall. If I did recall it I probably would understand your point
though.
>
> If number of compilers available or installed was relevant, a free compiler
> downloaded by 1,000,000 people (but used by few) would be 33 times more
> significant than the estimated 30,000 IBM mainframe Cobol compilers worldwide.
I see three ways to evaluate the statement "most compilers".
1. Most instances of a compiler (the 1,000,000 mentioned above).
2. The majority of platforms that run on various platforms - Univac 1100, vs
Sun, vs IBM mini, vs IBM mainframe, vs PC
3. Subsets of the above, including all of the various versions of the CoBOL
compiler that runs on system 390.
What I don't see is that we should evaluate "significant" before we decide what
"most compilers" means.
| |
| Howard Brazee 2004-05-13, 11:30 am |
|
On 12-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
> I meant source lines and logic touched in the US and Canada.
What is the relationship between "most compilers" and "most source lines and
logic touched in the US and Canada"?
I bet there are a lot of those Mainframe CoBOL source programs using
alternatives to GOBACK, such as CALL EXIT. Plus lots have one exit for very
long programs.
| |
| Chuck Stevens 2004-05-13, 2:30 pm |
| "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40a2ccd1.157115733@news.optonline.net...
> I meant source lines and logic touched in the US and Canada. Assuming
equal
> productivity and turnover (human nature being fairly constant), we can
determine
> relative usage from job ads. I just went to DICE and entered search keys
all
> beginning with "cobol and (programmer or developer) and ..". To find IBM
> mainframe, I used "(mainframe or cics) and not unisys and not unix". To
find
> Unisys, I used "unisys and not unix and not cics".
I don't think that's a valid metric. I remember some years ago there were
two large banks in the same medium-sized city that were about the same size.
One shop used an IBM system, the other Unisys (Burroughs at the time). Both
performed fundamentally identical service bureau work for about the same
number of smaller banks, running the same number of checks every day, doing
the same number of ATM transactions from the same number of ATM machines,
etc., etc. They were fierce competitors for the bank service-bureau
business in this particular town.
It took the IBM shop a staff of about 75 people to keep their systems and
their applications going. The Burroughs shop got the same banking workload
done with fewer than ten.
One of the "selling points" of ex-Burroughs Unisys equipment has
historically been programmer productivity and ease of use.
-Chuck Stevens
| |
| Richard 2004-05-13, 5:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> OpenCOBOL, KOBOL and the like are toy compilers for hobbiests.
So was the first MicroFocus CIS Cobol, so was Fujitsu version 3. Some
stayed at that level, such as Nevada/Utah.
> Can you make a case for 'right thinking' companies using other Cobol compilers?
Presumably it is sufficient to show that they use another compiler for
you to brand them as 'wrong thinking'.
> How odd it doesn't use the same 'front end' as other IBM compilers.
It is not odd at all. It is a completely different system.
> On second
> thought not so odd because AS/400 people like to think they have 'better
> ideas' than everyone else.
Well you would fit right in there then. ;-)
> AS/400 had its genesis in a 1970 revamp of S/360 to something called NS (New
> System).
No. AS/400 has nothing to do with 360. It comes from the S36, S38
line.
> trying to use '80s technology to compete with Microsoft and Unix innovations.
No. IBM use RS6000 Power Systems to 'compete with Unix'. Oh, no it
_is_ Unix.
Actually AS/400s are Power machines too now aren't they ?
> It's not about experience, it's about reality. Reality is what keeps us honest.
> It's the common ground we can't dispute, despite our emotional feelings favoring
> other explanations.
One of the problems, Robert, is that you treat your 'emotional
feelings' as if they _were_ reality. You are adament that everything
you 'know' is universally true. You then arrange your 'I meants' and
filter your evidence to fit what you 'know'.
Others accept that there are limits to how far they can generalise and
assert, they see your claims as not fitting their experience and
knowledge. When faced with challenges you twist away with 'I meants'
and 'right thinking' leading to these conflicts.
I am quite sure that you will come to some sort of silent stand-off
with the AS/400 people after you try to impart your 'better ideas' on
them.
| |
| William M. Klein 2004-05-13, 5:30 pm |
| Just to give "positive" (even if qualified) feedback. I *DO* appreciate you
providing specific data to explain how you determine "most popular compilers".
I suppose that if I were to do a "market" research on this question, I would
look to see which compiler(s) are being used today to produce AND maintain COBOL
"production code" - both for "sale" and for in-house use. When I received this
information, I would check to see how many programmers "used" each copy of the
compiler.
This would certainly lead to different (how much I don't know) answers than you
received - especially if I was looking for what "syntax" is supported.
For example (just to talk about IBM COBOL compilers)
- how many/which support PIC 1 (all S/36 - S/38 - COBOL/400 compilers do - I
think)
- which support USAGE POINTER (OS/VS COBOL does NOT - and still is used in
DEPRESSINGLY many places)
- what about intrinsic functions (not supported by VS COBOL II)
Then there is the question of what is ACTUALLY in use. IBM MVS - OS/390 - z/OS
compiler have supported OO since IBM COBOL for MVS & VM - which was introduced
in the mid-90's. However, to find any customers using this feature for
PRODUCTION code would be a "long and pretty fruitless" search.
***
So it is clear, if I were FORCED to make a guess, I would not be surprised if
50-75 percent of all "production" COBOL code today is running on SOME IBM
platform (MVS-ish, VSE-ish, or OS/400). But I am also willing to say that this
is based on my LIMITED exposure to a variety of input sources. It would also
surprise me if there is as much as 20 percent of all production COBOL code that
is running on any "workstation" (Unix, Windows, Linux) platform. However, even
these GUESSES don't (adequately) distinguish between
- number of lines of code
- numbers of users of each program
- numbers of copies of each program on different machines
***
All of this comes back to my assertion that it is BEST (in my opinion) when
anyone posting to this forum EXPLICITLY qualify their "generalizations" to
indicate whether they are talking about their experience, what they have heard,
what they ASSUME is true - or some other "condition".
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40a2ccd1.157115733@news.optonline.net...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>
> I meant source lines and logic touched in the US and Canada. Assuming equal
> productivity and turnover (human nature being fairly constant), we can
determine
> relative usage from job ads. I just went to DICE and entered search keys all
> beginning with "cobol and (programmer or developer) and ..". To find IBM
> mainframe, I used "(mainframe or cics) and not unisys and not unix". To find
> Unisys, I used "unisys and not unix and not cics". The results were:
>
> IBM mainframe 217
> AS/400 35 67% IBM
> Unix 46
> PC (xp or nt) 36
> client-server 19 27% MF & a little IBM
> Tandem 12
> Unisys 9
> Accu Cobol 2
> Fujitsu 0
> Realia 0
> Siemens 0
> Total 376
>
> This shows 94% of professional programmers are using IBM or MF.
> Under-represented are programmers working solo, for very small companies and
in
> academic settings.
>
>
>
| |
| Howard Brazee 2004-05-13, 5:30 pm |
|
On 13-May-2004, riplin@Azonic.co.nz (Richard) wrote:
> One of the problems, Robert, is that you treat your 'emotional
> feelings' as if they _were_ reality. You are adament that everything
> you 'know' is universally true. You then arrange your 'I meants' and
> filter your evidence to fit what you 'know'.
>
> Others accept that there are limits to how far they can generalise and
> assert, they see your claims as not fitting their experience and
> knowledge. When faced with challenges you twist away with 'I meants'
> and 'right thinking' leading to these conflicts.
Quite a few people pass laws and go to war this way.
| |
| Robert Wagner 2004-05-13, 9:30 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>Human nature is far from constant. Productivity and turnover may be
>vastly different between sites.
We're not comparing two sites; we're comparing collections having dozens to
hundreds of members. The larger the sample, the more anomalies are discounted.
Mathematically, my assumption is called a 'negative finding'. We compared A to B
and found no difference. Think regression testing. The larger the number of
samples, the lower the probability of a false negative (beta).
>
>What complete nonsense. Job ads are for desks that are empty. Empty
>desks do not use compilers.
Most of these job ads are for future projects now being staffed or 'ramped up'.
Demand for Cobol programmers presages supply of Cobol programs.Estimating future
production by measuring present demand for raw materials is a common analytical
technique.
>
>AS/400 is a quite different beast. Your assertion was '90%' had the
>same syntax. What have you done to establish that AS/400 has the same
>syntax as the big iron ?
Good point. I've avoided AS/400 and intend to continue that policy.
>
>You seem to assume that _all_ Unix and PC is MF just because it is not
>given. This is certainly not true.
I searched within those for Fujitsu (0), Accu (2), RM/Liant (0) and Realia (0).
If you have better ideas, post the search keys and results.
in[color=darkred]
>
>Over represented are positions for which there are multiple ads.
Duplicates are created by recruiters and contracting companies, who do not bias
one compiler over another.
| |
| Robert Wagner 2004-05-13, 10:30 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>On 12-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
worldwide.[color=darkred]
>
>I see three ways to evaluate the statement "most compilers".
>1. Most instances of a compiler (the 1,000,000 mentioned above).
>2. The majority of platforms that run on various platforms - Univac 1100, vs
>Sun, vs IBM mini, vs IBM mainframe, vs PC
>3. Subsets of the above, including all of the various versions of the CoBOL
>compiler that runs on system 390.
>
>What I don't see is that we should evaluate "significant" before we decide what
>"most compilers" means.
It means executed code. When code generated by compiler X for a line of Cobol is
executed, that's one vote for compiler X.
Executions on single-user and 'sandbox' machines don't count.
| |
| Robert Wagner 2004-05-14, 6:30 am |
| "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>I don't think that's a valid metric. I remember some years ago there were
>two large banks in the same medium-sized city that were about the same size.
>One shop used an IBM system, the other Unisys (Burroughs at the time). Both
>performed fundamentally identical service bureau work for about the same
>number of smaller banks, running the same number of checks every day, doing
>the same number of ATM transactions from the same number of ATM machines,
>etc., etc. They were fierce competitors for the bank service-bureau
>business in this particular town.
>
>It took the IBM shop a staff of about 75 people to keep their systems and
>their applications going. The Burroughs shop got the same banking workload
>done with fewer than ten.
In the '80s I worked at a supermarket company that had 6 programmers and a total
IT budget of $1M/yr. Industry norms said IT should be half a percent of sales,
which would have ranged between $5M and $10M depending on our ups and downs.
Similar sized supermarket companies (e.g. HEB) did indeed spend that much and
had 50 programmers.
I worked there 6 years. After I left, they brought in a guy with IBM embroidered
in his underwear who deemed everything I'd done "unprofessional". The IT budget
quickly went from $1M to $7M, the body count from 6 to 25+, and response time
went down the drain. He ripped out my CICS accelerators and installed ERP.
We and competitors were all IBM shops. The difference wasn't the flag flying
over the machine, it was talent.
>One of the "selling points" of ex-Burroughs Unisys equipment has
>historically been programmer productivity and ease of use.
During the '70s I managed two Burroughs (medium systems) shops. One of them was
a large wholesale food distributor and supermarket operator comparable to
today's Fleming. I concur .. Burroughs were Dream Machines for running Cobol.
Lesson Learned: technical superiority wins battles but it doesn't win wars.
In the long run, companies that once had technical superiority lose it because
they're starved of money.
| |
| Howard Brazee 2004-05-14, 11:30 am |
|
On 13-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
> It means executed code. When code generated by compiler X for a line of Cobol
> is executed, that's one vote for compiler X.
I never would have guessed that. So if you were discussing grammar and said
"most languages" don't have a word for "no", the fact that there are a lot of
people speaking Chinese would support for your argument?
Or "Most programming languages have a procedure division", and point to how many
programs are written in CoBOL?
I think I'm starting to understand you.
| |
| Richard 2004-05-14, 4:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
>
> We're not comparing two sites;
Where did you get the 'two' from ? 'sites' is plural and may refer to
all.
> we're comparing collections having dozens to
> hundreds of members. The larger the sample, the more anomalies are discounted.
Are you ? How many of the ads were for sites that had more than 10
programmers ? and how did you determine the numbers of programmers at
each site ?
>
> Most of these job ads are for future projects now being staffed or 'ramped up'.
So now you say that 'most of those' don't even have source code yet ?
So what exactly do 'statistics' about empty desks with no source code
tell us about 'most compilers', or was that 'most source code' ?
>
> I searched within those for Fujitsu (0), Accu (2), RM/Liant (0) and Realia (0).
And then assumed that if it didn't mention the vendor then it _must_
be MF.
> If you have better ideas, post the search keys and results.
Yes, I do have a better idea: don't make huge meaningless
generalisations in support of something that is quite irrelevant and
is only an _opinion_.
> Duplicates are created by recruiters and contracting companies, who do not
> bias one compiler over another.
And yet another opinion stated as if it were fact.
It is only necessary to find one duplicate that is not by a recruiter
or agency, or one that does bias, to show your assertion is wrong.
| |
| Richard 2004-05-14, 4:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
[color=darkred]
> I searched within those for Fujitsu (0), Accu (2), RM/Liant (0) and Realia (0).
It may just be those compilers are used in sites where productivity is
high, morale is good and turnover is very low.
Or it may be that those compilers are mainly used in the large number
of smaller shops and independant developers who don't advertise for
jobs globally. They won't pay shifting expense or accommodation and
so only advertise locally, where you wouldn't find them.
| |
| Richard 2004-05-14, 4:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> It means executed code. When code generated by compiler X for a line of Cobol is
> executed, that's one vote for compiler X.
So, a simple 100 line program running on a mega-mainframe, with no IO
to slow it down, will generate billions of votes per second. A huge
once a month application consisting of hundreds of programs with
lots of IO (and thus idle wait) maintained by dozens of programmers
may generate only a few million votes.
Now, what was the significance to this of the number of empty desks
with no source code yet ?
| |
| Robert Wagner 2004-05-14, 10:30 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>So was the first MicroFocus CIS Cobol, so was Fujitsu version 3. Some
>stayed at that level, such as Nevada/Utah.
Yes, Micro Focus came from CIS, which in turn came from Dataskill 1500.
It is written in Cobol.
>
>Well you would fit right in there then. ;-)
My ideas work on all platforms. They are oriented to technology rather than
politics or culture.
>
>No. AS/400 has nothing to do with 360. It comes from the S36, S38
>line.
You're wrong. It came from a failed Big Iron concept that found a home in
S/36-38 land.
>Actually AS/400s are Power machines too now aren't they ?
Probably. Under the covers, nearly all modern machines are RISC emulating CISC.
Natively RISC machines are VERY fast, especially Sun. Both Sun and HP have
announced they're abandoning their successful platforms in favor of Intel
lookalikes. Visionaries know something we don't.
>One of the problems, Robert, is that you treat your 'emotional
>feelings' as if they _were_ reality. You are adament that everything
>you 'know' is universally true. You then arrange your 'I meants' and
>filter your evidence to fit what you 'know'.
It's the human condition. Let's deal with evidence in reality and ignore
feelings.
>Others accept that there are limits to how far they can generalise and
>assert, they see your claims as not fitting their experience and
>knowledge. When faced with challenges you twist away with 'I meants'
>and 'right thinking' leading to these conflicts.
>
>I am quite sure that you will come to some sort of silent stand-off
>with the AS/400 people after you try to impart your 'better ideas' on
>them.
It's not silent. The AS/400 mediocrities are constantly on the attack, as you
are. I've tried responding and I've tried ignoring. Neither silences them. They
have no shame.
I've also been attacked by hardware dweebs and Unix system administrators. Both
are failed programmers, as are testers.
People with mediocre intellect hate Real Programmers because it's an arena where
they tried and failed.
You're not so limited. Why do you side with them and attack us?
| |
| Robert Wagner 2004-05-15, 6:30 am |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
discounted.[color=darkred]
>
>Are you ? How many of the ads were for sites that had more than 10
>programmers ? and how did you determine the numbers of programmers at
>each site ?
For the last six years, I've been finding jobs through these ads. I'm now on the
sixth contracting project. Dozens and hundreds referred to number of sites, not
number of programmers at each, but in fact all six places where I worked were
big shops.
up'.[color=darkred]
>
>So now you say that 'most of those' don't even have source code yet ?
Typically, they're porting code from platform A to B, or doing an upgrade. They
have a large body of existing code and a spec for the port or upgrade.
The people who planned the project typically have rusty technical skills which
were mediocre when they last touched code, 5-20 years ago. They budgeted for
every program to be modified manually. Usually it can be done faster than that,
with a scripting or automated solution. Managers don't think in terms of tool
building because they never personally built a tool.
My current project is conversion from AS/400 to Unix. The AS/400 had 15 CL
'programs' to offload database tables to tab-delimited flat files. Management
budgeted and hired programmers to write 15 Cobol programs to replace those CL
scripts. All they needed was one Cobol program that built Dynamic SQL to offload
any table. I wrote it, gave it 15 program names, copied it 15 times, and
hardcoded the table name into each rather than passing it as a parameter.
Everyone's happy with a 'development' project completed on-time and on-budget.
After it goes into production and management's gaze is averted, someone will
grok they have 15 copies of the same program. Then some eager beaver will
propose 'simplification' by passing the table name as a parameter on the command
line. Committees will study it and issue copious reports, meetings, etc. In the
end, it'll get done.
In the Corporate world you plant a seed and wait months to years before it
germinates. If I'd proposed one program up-front, the idea would have been
rejected.
>So what exactly do 'statistics' about empty desks with no source code
>tell us about 'most compilers', or was that 'most source code' ?
They speak to demand for programmers who will produce real code within the next
year.
>Yes, I do have a better idea: don't make huge meaningless
>generalisations in support of something that is quite irrelevant and
>is only an _opinion_.
That's what you've just done.
>
>And yet another opinion stated as if it were fact.
>
>It is only necessary to find one duplicate that is not by a recruiter
>or agency, or one that does bias, to show your assertion is wrong.
In the real world, me must make decisions based on incomplete and conflicting
information. Trying to impose order by insisting on syllogistic logic is not a
practical solution. 'Judgment' and 'wisdom' refer to our skills in coping with
disorder.
| |
| Robert Wagner 2004-05-15, 7:30 am |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>
(0).[color=darkred]
>
>It may just be those compilers are used in sites where productivity is
>high, morale is good and turnover is very low.
We wish that were so, The more likely explanation is those compilers failed.
>Or it may be that those compilers are mainly used in the large number
>of smaller shops and independant developers who don't advertise for
>jobs globally. They won't pay shifting expense or accommodation and
>so only advertise locally, where you wouldn't find them.
US contractors are expected to pay their own moving (shifting) expense. When
they say 'local applicants only', it means they want an in-person interview but
are not authorized to pay travel expenses. I make it easy by offering to pay the
expenses myself. After I'm hired, they always reimburse me.
| |
| Richard 2004-05-15, 5:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> My ideas work on all platforms.
No. Many of the 'ideas' that I have seen from you do not work on 'all
platforms', but only on certain compilers that have used.
> They are oriented to technology rather than
> politics or culture.
The real question is: is it _appropriate_ technology. You came out
with your ENTRY/CALL idea as being _better_ than what was currently be
used, but it was quite inappropriate and was _not_ usable on any
platform.
In any case your assertions about it not being about 'politics or
culture' is disingenuous, you attack the 'cobol culture', explicitly
in some cases. In fact it seems that some of your ideas are
specifically designed to attack culture.
> You're wrong. It came from a failed Big Iron concept that found a home in
> S/36-38 land.
The System 3, 32, 34, 36, 38 line was from a completely different
division of IBM that had little contact with the big iron division.
> Both Sun and HP have
> announced they're abandoning their successful platforms in favor of Intel
> lookalikes. Visionaries know something we don't.
That is not quite true. While Sun has stopped development on one line
of CPUs it is not Intel that it will be using but the quite different
AMD technology for 64 bit machines. It will also be using AMD
tecnology for future Sun processors.
> It's not silent. The AS/400 mediocrities are constantly on the attack, as you
> are. I've tried responding and I've tried ignoring. Neither silences them. They
> have no shame.
Perhaps it is because they know that your ideas won't work, did you
try to convince them to use ENTRY/CALL instead of paragraphs ?
> I've also been attacked by hardware dweebs and Unix system administrators. Both
> are failed programmers, as are testers.
Insults, insults.
> People with mediocre intellect hate Real Programmers because it's an arena where
> they tried and failed.
Insults, insults.
Perhaps they attack you you because you insult them, explicitly or
implicitly calling them 'failed', 'mediocre intellect', and 'dweebs'.
Running around claiming that you are 'better' and have 'better ideas',
as you do here, does not win you any friends.
Especially when your ideas are not actually better at all. They are
just ego-centric self-promotion.
> You're not so limited. Why do you side with them and attack us?
'Us' ? Who are the 'us' ? Another ego-trip for you is this ? You
and the other 'super-programmers of the universe' ?
| |
| Richard 2004-05-15, 7:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> You're not so limited. Why do you side with them and attack us?
But I don't attack _you_, I 'attack' your _ideas_ where I see them as
being contradictory, unworkable, or simply sef-promoting ego trips.
As I had previously observed, you don't distinguish between 'who you
are' and 'what you say'. This is actually common amongst teenagers
with low self esteem.
| |
| Robert Wagner 2004-05-16, 12:30 am |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>
>No. Many of the 'ideas' that I have seen from you do not work on 'all
>platforms', but only on certain compilers that have used.
Name a platform that won't compile and run the sorts demo, nor show similar
timing results.
>
>The real question is: is it _appropriate_ technology. You came out
>with your ENTRY/CALL idea as being _better_ than what was currently be
>used, but it was quite inappropriate and was _not_ usable on any
>platform.
I spent years looking for an alternative to the troublesome (IMO) PERFORM.
Nested Programs seemed ok in principle, but bulky in practice. I discovered
ENTRY by accident when I wrote a recursion demo using Nested Programs, then
learned Micro Focus doesn't support recursion in that context. Why not? I
rewrite it with ENTRY and realized that's the PERFORM replacement I'd been
s ing.
Why do you call it "quite imappropriate?" Sure, it's not in the Standard, but
it's supported by IBM, Micro Focus and Fujitsu, which makes it a de-facto
standard in my mind.
>In any case your assertions about it not being about 'politics or
>culture' is disingenuous, you attack the 'cobol culture', explicitly
>in some cases. In fact it seems that some of your ideas are
>specifically designed to attack culture.
I've never used the phrase 'cobol culture' because I don't believe there is
single one. There is an IBM Mainframe Cobol culture, a Unisys Cobol culture, an
OO Cobol culture, a Unix Cobol culture, a Windows Cobol culture, and a Real
Programming In Cobol culture, which I advocate.
>
>The System 3, 32, 34, 36, 38 line was from a completely different
>division of IBM that had little contact with the big iron division.
"single-level store idea, planned to succeed IBM S/370 architecture, product
development effort started in 1971, reputed to have cost more than $1B,
cancelled in 1975, but the ideas developed into System/38, AS/400, and iSeries"
http://www.cs.clemson.edu/~mark/fs.html
From a current IBM iseries site:
" No other computing platform has such a powerful architecture as SLS. It's
patented. As simple as it sounds, it's also an immense effort to effectively
implement. SLS is a result of some of the most forward-thinking ideas. In fact,
the design, in development, was named "FS" for Future System."
http://www-1.ibm.com/servers/enable...w/overview.html
From the fascinating newsgroup archives of Lynn Wheeler, really worth a read:
"FS was never promised. It was a code name for a new system that started
sometime in the late '60s and was shelved in the early '70s. The big
innovations were to be object orientation and a one-level store. That
is, the "file system" was an extension of memory addressing."
and
"2,500 people were
mobilised for the FS project. Those in charge had the right to choose
people from any IBM units. I was working in Paris when I was picked
out of the blue to be sent to New York. Proof of the faith people had
in IBM is that I never heard of anyone refusing to move, nor
regretting it. However, other quiet warnings were taken less
seriously."
http://www.garlic.com/~lynn/2000f.html#16
FWIW: my failed New Dawn operating system, written 1990-92, also used SLS and
OO. I was unaware SLS had been patented.
>
>Perhaps it is because they know that your ideas won't work, did you
>try to convince them to use ENTRY/CALL instead of paragraphs ?
I now work with two AS/400 programmers who are very good .. Real Programmers.
I'm not in contact with the mediocrities I knew in the past.
>Perhaps they attack you you because you insult them, explicitly or
>implicitly calling them 'failed', 'mediocre intellect', and 'dweebs'.
>Running around claiming that you are 'better' and have 'better ideas',
>as you do here, does not win you any friends.
In person, I'm congenial and low-key. I casually show them some code and see
them get that deer-in-the-headlights look of fear. Next thing I know, they're on
the attack.
>
>'Us' ? Who are the 'us' ? Another ego-trip for you is this ? You
>and the other 'super-programmers of the universe' ?
I prefer the phrase Real Programmers. A good friend and Real Programmer who was
Chief Technology Officer at a well-known Silicon Valley Search Engine company
advised me that, if I wanted to get ahead in the software industry, I must
remove the word Cobol from my resume, as he had done. He said Cobol is the kiss
of death, an automatic rejection.
Think about that, hard.
| |
| Richard 2004-05-16, 5:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
>
> Name a platform that won't compile and run the sorts demo, nor show similar
> timing results.
You are making a logic error. 'Many of your ideas won't work on all
platforms' is not negated by one that does, or may do.
The way that you had used pointers and the CALL/ENTRY are ones that
won't.
> Why do you call it "quite imappropriate?" Sure, it's not in the Standard, but
> it's supported by IBM, Micro Focus and Fujitsu, which makes it a de-facto
> standard in my mind.
Yes, I do understand that while you claimed that you followed the ANSI
standard 'where possible', you actually just ignore it when you think
of something you claim to be 'better'.
If you don't know why CALL/ENTRY is 'quite inappropriate' then you
haven't understood what I have been saying about it. While it may work
in tiny demo programs, this cannot be applied to actual systems due to
name space polution.
In any case while the syntax is 'supported' in some compilers this is
not a guarantee that they work identically. The ENTRY syntax is also
in Level II and this cannot be used the way you think is 'better'.
I also doubt that you have even tried it with Fujitsu, let alone IBM.
I did a simple program with a Fujitsu compiler that I have here
(abbreviated source code):
CALL "one"
STOP RUN.
ENTRY "one".
DISPLAY "in one"
EXIT PROGRAM.
And while it compiled it failed to run, complaining about recursion.
I don't argue about these ideas to 'attack' you, I do it so that
others can not bother to waste their time on things that don't work or
are bug traps.
If you have such a dislike of PERFORM and a wish to pass parameters
then I would suggest that you change to using a language that better
suits your preferences. Over the years I have learnt and used
several, and tried several others. While I have applied much of what
I learnt back into my style of Cobol, I _also_ learnt those languages
limitations and what to avoid.
You walked into the CALL/ENTRY mechanism _without_ the benefit of
learning the lessons of name space polution that come from knowing and
using C, for example.
>
> I've never used the phrase 'cobol culture' because I don't believe there is
> single one. There is an IBM Mainframe Cobol culture, a Unisys Cobol culture, an
> OO Cobol culture, a Unix Cobol culture, a Windows Cobol culture,
Let me change that to "you attack the 'Cobol culture_s_'" then.
> and a Real
> Programming In Cobol culture, which I advocate.
Yes, I do notice how you claim to be 'better' than all others.
> In person, I'm congenial and low-key. I casually show them some code and see
> them get that deer-in-the-headlights look of fear. Next thing I know, they're on
> the attack.
You interpret it as 'fear' and 'attack', you don't ever seem to
consider that it is because it is unworkable and they see you as being
completely obstaninate in accepting that your ideas are flawed and
failing to account for other wider issues.
For example with the CALL/ENTRY, I must have said 'name space
polution' 3 or 4 times but it just doesn't sink in because you are so
attached to this idea of 'getting rid of PERFORM'.
I recall that with another idea I had to explain the problems several
times before you accept it couldn't work, you just claimed I was
attacking you until the penny dropped eventually.
>
> I prefer the phrase Real Programmers.
And who else in the 'us' am I attacking ? It is some of your ideas
that I am arguing against as being unusable, not you or your anonymous
'us'.
> A good friend and Real Programmer who was
> Chief Technology Officer at a well-known Silicon Valley Search Engine company
> advised me that, if I wanted to get ahead in the software industry,
Name dropping self promotion cuts no ice here.
> I must
> remove the word Cobol from my resume, as he had done. He said Cobol is the
> kiss of death, an automatic rejection.
Then why are you here trying to change Cobol into some parody of 35
year old C ?
> Think about that, hard.
Well obviously you haven't, you still work in Cobol shops.
| |
| Robert Wagner 2004-05-16, 9:30 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>If you don't know why CALL/ENTRY is 'quite inappropriate' then you
>haven't understood what I have been saying about it. While it may work
>in tiny demo programs, this cannot be applied to actual systems due to
>name space polution.
If pollution becomes a problem, one can use the program name as a 'slot' or
namespace partition. The principle is the same as OO languages using the class
as a qualifier. I do NOT recommend mangling.
>In any case while the syntax is 'supported' in some compilers this is
>not a guarantee that they work identically. The ENTRY syntax is also
>in Level II and this cannot be used the way you think is 'better'.
>
>I also doubt that you have even tried it with Fujitsu, let alone IBM.
>I did a simple program with a Fujitsu compiler that I have here
>(abbreviated source code):
>
> CALL "one"
> STOP RUN.
> ENTRY "one".
> DISPLAY "in one"
> EXIT PROGRAM.
>
>And while it compiled it failed to run, complaining about recursion.
Thanks for that information. My Fujitsu compiler stopped working. A search for
"recursive" or "recursion" in the manual found nothing.
>If you have such a dislike of PERFORM and a wish to pass parameters
>then I would suggest that you change to using a language that better
>suits your preferences. Over the years I have learnt and used
>several, and tried several others. While I have applied much of what
>I learnt back into my style of Cobol, I _also_ learnt those languages
>limitations and what to avoid.
I like Cobol better than the other languages I've used and attempted to use.
Anything I can do in C, I can do in Cobol .. just as quickly and with code
that's easier to read and maintain.
>
>Name dropping self promotion cuts no ice here.
If I had been name dropping, I would have mentioned a _name_. It was an appeal
to authority.
>
>Then why are you here trying to change Cobol into some parody of 35
>year old C ?
Did you ask that when the Standards Committee introduced Nested Programs in '85?
I want Cobol to be regarded by people in other cultures as a serious
general-purpose programming language, not a language good only for "accounting
and stuff like that". To gain that respect, we must use Cobol for more than
accounting. I'm not saying what we should be working on, only that what most of
us did in the past wasn't enough. And debating issues like paragraph numbering
while the ship slowly sinks is futile.
| |
| Richard 2004-05-17, 4:31 am |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> If pollution becomes a problem, one can use the program name as a 'slot' or
> namespace partition.
You appear to be claiming that the ENTRY names should be created in
form "program-labelname" to avoid pollution. This is another of your
off the cuff arbitrary fixits that may, or may not, actually fix the
very real problem, and certainly shows that you haven't thought this
through.
It may be that on some platforms there are limits to the length of
external names. This would result in truncation of the names and thus
still result in duplication.
There may be limits on the number of external names that may exist in
the run-unit. While this may be perfectly adequate for handling
program-ids, you are suggesting an increase of a couple of orders of
magnitude.
Paragraph names may be duplicated in one program and only need to be
unique within a section (not that I reccommend this), and only needs
qualification when a reference is ambiguous. Converting to ENTRY will
give errors or unexpected behaviour.
> The principle is the same as OO languages using the class
> as a qualifier. I do NOT recommend mangling.
C++ name mangling is a completely different thing. A Class can have
overloaded methods with different parameter types. The parameter types
are mangled to the end of the method name to give a unique call name.
> Thanks for that information. My Fujitsu compiler stopped working. A search for
> "recursive" or "recursion" in the manual found nothing.
Fujitsu does not support the use of ENTRY in you way you suggested at
all.
> I like Cobol better than the other languages I've used and attempted to use.
Then stop trying to change it into something else.
> Anything I can do in C, I can do in Cobol .. just as quickly and with code
> that's easier to read and maintain.
'Read and Maintain' is entirely what one is used to. I can 'read and
maintain' C code or Python or even Perl, just as easily as Cobol. I
choose the one to use by its suitability to the problem. There are
things that I do that I can write and get working much more quickly in
other languages.
>
> Did you ask that when the Standards Committee introduced Nested Programs in '85?
Nested programs are _not_ a parody of 35 year old C as your use of
ENTRY is. The refernce was because very early C compilers exported
all their routine and function names to the run-unit. Later (ie not
as long ago as 35 years), they introduced a mechanism to make routines
'file local', ie as if the were 'nested' inside the file. Perhaps you
can state this feature which ENTRY does not have ?
Nested programs do not fall into the name space trap. They are
carefully designed and implemented to be usable and scalable into
large applications.
But, as you say, Nested Programs are very '80s, they are 'What Pascal
Did', but at least they are a decade on from 'What C Did' in the 70s.
Your 'better' has failed miserably because it was based on your
emotional need to be seen as a 'Real Programmer' and a complete lack
of technical insight.
If you want to move on rather than back then learn and start using and
advocating OO Cobol.
> I want Cobol to be regarded by people in other cultures as a serious
> general-purpose programming language, not a language good only for "accounting
> and stuff like that".
Then you are probably wasting your time, people in 'other cultures'
have their own boat to paddle, and will ignore your attempts at this.
> To gain that respect, we must use Cobol for more than accounting.
Cobol is very good at certain things. Most of this is not because it
is good at 'accounting and stuff' it is because it is good at
'surviving change'.
In the time scale of Cobol use the technical 'culture' has moved from
Algol through Pascal, Ada, C, C++, Java and C#, with many side
branches. Those will never take to Cobol, never have, never will
regardless of how much you try to make it a poor imitation of what
they did years ago, they will move to the next language.
Cobol will continue to be used _because_ it doesn't require rewriting
every few years, or just because the site gets a new machine. The
systems outlive the fashion changes.
What you keep recommending is to break this. If your CALL/ENTRY was
used then it gets broken by another platform or another compiler.
> I'm not saying what we should be working on, only that what most of
> us did in the past wasn't enough. And debating issues like paragraph numbering
> while the ship slowly sinks is futile.
And you trying to make Cobol do everything is also futile. You should
be advocating that Cobol be used where its strengths are, not where
some other language is stronger, mixing the languages using OO where
the combination is better than both separately.
The next program that I need to write is a POP3/IMAP email collection
program that will extract attachments, unzip them, and process the
attachments. This is doddle to do in Python (for me), but I will use
an existing Cobol program to process the attachment data.
| |
| Howard Brazee 2004-05-17, 1:30 pm |
|
On 15-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
> I spent years looking for an alternative to the troublesome (IMO) PERFORM.
Why? What is it about PERFORM that troubles you?
> Nested Programs seemed ok in principle, but bulky in practice.
I have never figured out what improvement they have in principle over performs
and external calls. And haven't seen them actually be used beyond playing with
the language.
| |
| Howard Brazee 2004-05-17, 1:30 pm |
|
On 16-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
> I want Cobol to be regarded by people in other cultures as a serious
> general-purpose programming language, not a language good only for "accounting
> and stuff like that". To gain that respect, we must use Cobol for more than
> accounting. I'm not saying what we should be working on, only that what most
> of
> us did in the past wasn't enough. And debating issues like paragraph numbering
> while the ship slowly sinks is futile.
I've seen CoBOL used for mainframe applications of all kinds, but when shops add
web pages, they usually get Suns and use other languages. It doesn't seem to
be a function of "accounting" vs "database" vs "reporting".
Specifically, what applications do you notice that are not now using CoBOL, but
should be?
| |
| Robert Wagner 2004-05-17, 4:30 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>
>It may be that on some platforms there are limits to the length of
>external names. This would result in truncation of the names and thus
>still result in duplication.
>
>There may be limits on the number of external names that may exist in
>the run-unit. While this may be perfectly adequate for handling
>program-ids, you are suggesting an increase of a couple of orders of
>magnitude.
Unix and Microsoft have no such limitation. I doubt mainframes do. We had limits
like that in the early days, when memory was limited and we let the machine's
inadequacies affect programming style. Machines now have Gigabytes of memory.
>
>Then stop trying to change it into something else.
I'm just using the features provided. My one attempt to change the language was
not well received. :(
>
>'Read and Maintain' is entirely what one is used to. I can 'read and
>maintain' C code or Python or even Perl, just as easily as Cobol. I
>choose the one to use by its suitability to the problem. There are
>things that I do that I can write and get working much more quickly in
>other languages.
Python and Perl (now) are OO. Assuming I can call C libraries from Cobol, I
can't think of any problem where C is more suitable.
>Nested programs are _not_ a parody of 35 year old C as your use of
>ENTRY is. The refernce was because very early C compilers exported
>all their routine and function names to the run-unit. Later (ie not
>as long ago as 35 years), they introduced a mechanism to make routines
>'file local', ie as if the were 'nested' inside the file. Perhaps you
>can state this feature which ENTRY does not have ?
You're correct -- ENTRY does make all names public A compiler option to stop
that would be easy. Under Unix, one can solve the problem by linking each
program to a shared object and specifying -zdefs and -zmuldefs.
>If you want to move on rather than back then learn and start using and
>advocating OO Cobol.
Non-OO Cobol is unfairly (IMO) accused of being too verbose. Every time I tried
OO Cobol, even I found it too verbose. A sample program that isn't would be most
welcome.
"accounting[color=darkred]
>
>Then you are probably wasting your time, people in 'other cultures'
>have their own boat to paddle, and will ignore your attempts at this.
Suppose two or three hot programs were written 100% in Cobol. Don't you think
they'd be curious to find out more about the language?
>Cobol is very good at certain things. Most of this is not because it
>is good at 'accounting and stuff' it is because it is good at
>'surviving change'.
Some say it survives due to the inertia of (adopting Carl Sagan voice) billions
of lines of code.
>In the time scale of Cobol use the technical 'culture' has moved from
>Algol through Pascal, Ada, C, C++, Java and C#, with many side
>branches. Those will never take to Cobol, never have, never will
>regardless of how much you try to make it a poor imitation of what
>they did years ago, they will move to the next language.
Those people are dilettantes. In the unlikely event they did rediscover Cobol,
they'd drop it for something flashier upon receiving a package from the
Language-of-the-Month Club.
>Cobol will continue to be used _because_ it doesn't require rewriting
>every few years, or just because the site gets a new machine. The
>systems outlive the fashion changes.
Exactly. For the same reason, Cobol would be good for databases, ERP systems and
compilers. All have long life expectancy.
>And you trying to make Cobol do everything is also futile. You should
>be advocating that Cobol be used where its strengths are, not where
>some other language is stronger, mixing the languages using OO where
>the combination is better than both separately.
I can't disagree. Too bad 'they' ignore Cobol when providing examples and class
templates. We have to read them in VB or C#, translating to Cobol. It's also
unfortunate that good OO Cobol compilers cost thousands.
| |
| Robert Wagner 2004-05-17, 4:30 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>On 16-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
"accounting[color=darkred]
numbering[color=darkred]
>
>I've seen CoBOL used for mainframe applications of all kinds, but when shops
add
>web pages, they usually get Suns and use other languages. It doesn't seem to
>be a function of "accounting" vs "database" vs "reporting".
>
>Specifically, what applications do you notice that are not now using CoBOL, but
>should be?
In the applications arena, I'd like to work on:
...PC applications with a GUI. They're often written in VB.
...Applications that are Web enabled, now written in Cognos, Java, and others.
I've seen many shops that, upon switching from mainframe to client-server,
thought it necessary to rewrite everything in a more 'modern' language. They
don't believe me when I tell them it's unnecessary, they can use what they have
with the addition of a GUI easily written in Cobol. They think it's technically
impossible for Cobol to do a GUI or Web-style interface.
In the systems arena:
...Databases. I doubt even one is written in Cobol.
...Business Intelligence/Data Warehousing.
...Middleware. Even something as simple as an XML parser.
| |
| Robert Wagner 2004-05-17, 4:30 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>
>On 15-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
>
>Why? What is it about PERFORM that troubles you?
...Cannot pass parameters.
...THRU becomes a Shop Standard.
...Cannot do recursion.
Actually, you can pass parameters, but I don't advocate it.
set address of input-data to xxx
set address of output-data to yyy
perform convert-x-to-y
>
>I have never figured out what improvement they have in principle over performs
>and external calls. And haven't seen them actually be used beyond playing
with
>the language.
I use them. Richard says the advantage is reduced namespace pollution. I see the
advantage as reduced administrative overhead. They need not be listed on program
inventories, do not require their own documentation, need not be promoted
through the CM system, etc. Locality is an advantage if you're forced to use a
lame text editor which can edit only one file at a time.
| |
| Howard Brazee 2004-05-17, 6:30 pm |
|
On 17-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
> In the applications arena, I'd like to work on:
>
> ..PC applications with a GUI. They're often written in VB.
Any PC applications with a GUI? Why is CoBOL a good fit?
> ..Applications that are Web enabled, now written in Cognos, Java, and others.
Why is CoBOL a good fit?
> I've seen many shops that, upon switching from mainframe to client-server,
> thought it necessary to rewrite everything in a more 'modern' language. They
> don't believe me when I tell them it's unnecessary, they can use what they
> have
> with the addition of a GUI easily written in Cobol. They think it's
> technically
> impossible for Cobol to do a GUI or Web-style interface.
There are lots of silly people out there.
> In the systems arena:
>
> ..Databases. I doubt even one is written in Cobol.
Why is CoBOL a good fit?
> ..Business Intelligence/Data Warehousing.
> ..Middleware. Even something as simple as an XML parser.
| |
| Howard Brazee 2004-05-17, 6:30 pm |
|
On 17-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
> ..Cannot pass parameters.
> ..THRU becomes a Shop Standard.
> ..Cannot do recursion.
Stupid shop standards can happen just as easily without PERFORM.
When I want to do recursion, I use a tool set up for that. When I don't I don't
see any need for carrying the baggage around to require it.
When I want to protect data (using parameters), I use a tool set up for that.
When I don't, I don't see any need for carrying the baggage around to require
it.
> with
>
> I use them. Richard says the advantage is reduced namespace pollution. I see
> the
> advantage as reduced administrative overhead. They need not be listed on
> program
> inventories, do not require their own documentation, need not be promoted
> through the CM system, etc. Locality is an advantage if you're forced to use a
> lame text editor which can edit only one file at a time.
If you don't want them available to other programs, then they are just another
way of doing PERFORMs. A more complicated way.
| |
| Robert Wagner 2004-05-17, 9:30 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>
>On 17-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
>
>Any PC applications with a GUI? Why is CoBOL a good fit?
Because Cobol is better for writing validation logic, in a client app, and
vastly better for writing whole systems, in a standalone PC app. VB is used
because anyone, even a non-programmer, can paint screens rapidly. It's not
really programming, it's drag-and-drop. But VB is weak at writing procedural
code. As a result, VB programs sometimes have poor validation.
With appropriate tools, for instance Flexus SP2, a Cobol programmer can create
GUI screens just as rapidly. They are indistinguishable from VB and C++ screens
because they use the same OLE and Active X controls.
>
>Why is CoBOL a good fit?
Similar reasons. Cognos is a large BI tool, but many shops use it only as a 'Web
Report Generator' with Cobol server-style code and/or a database behind it.
Since most Cobol programmers do not know Cognos Reporting, they hire Cognos
specialists. Cobol can produce XML just as easily as Cognos can.
Management doesn't think so because it wasn't done when they were Cobol
programmers, 5-20 years ago.
>
>There are lots of silly people out there.
They're not silly, they're using old paradigms to manage modern technology.
Of the stuff invented since they stopped coding, their knowledge comes from
airline magazines.
| |
| Robert Wagner 2004-05-17, 9:30 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>
>On 17-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
>
>If you don't want them available to other programs, then they are just another
>way of doing PERFORMs. A more complicated way.
They combine the convenience of PERFORM (locality) with the data-hiding
isolation of external calls.
| |
| Richard 2004-05-17, 10:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> In the applications arena, I'd like to work on:
>
> ..PC applications with a GUI. They're often written in VB.
> ..Applications that are Web enabled, now written in Cognos, Java, and others.
I do both of those, and have done for several years.
> ..Databases. I doubt even one is written in Cobol.
Why would anyone write a database server in Cobol ? You wouldn't use
VB either, or Java.
> ..Business Intelligence/Data Warehousing.
> ..Middleware. Even something as simple as an XML parser.
I have a simple XML parser in Cobol, but why is it important to be
done in Cobol ?
| |
| Richard 2004-05-17, 11:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
>
> Unix and Microsoft have no such limitation. I doubt mainframes do. We had limits
> like that in the early days, when memory was limited and we let the machine's
> inadequacies affect programming style. Machines now have Gigabytes of memory.
Well that passed over your head, too.
The number of external names in a run-unit has _nothing_ to do with
the amount of memory or which OS is used.
If a run-unit is created statically then the issue is with the linker
that is used, if the run-unit is dynamic then it is an issue with the
run-time mechanism that keeps track of these names as programs are
loaded and cancelled.
> I'm just using the features provided. My one attempt to change the language was
> not well received. :(
No. You were _abusing_ a vendor extension and using it for something
it was never intended for, and in many cases did not work.
> You're correct -- ENTRY does make all names public A compiler option to stop
> that would be easy.
So, you _do_ want to change Cobol.
>
> Non-OO Cobol is unfairly (IMO) accused of being too verbose. Every time I tried
> OO Cobol, even I found it too verbose. A sample program that isn't would be most
> welcome.
You even complained that nested programs were too many extra lines and
seemed to want to use ENTRY just because it was one line.
Cobol isn't about cramming everything into minimum byte count, OO is
about making stuff that you reuse. Once a Class is written one only
has to use it and not type it all in again.
If you want to avoid verbosity use Perl.
> Suppose two or three hot programs were written 100% in Cobol. Don't you think
> they'd be curious to find out more about the language?
No. They'd just redo it in whatever language do jour was to show
theirs was 'hotter'.
> Exactly. For the same reason, Cobol would be good for databases, ERP systems and
> compilers. All have long life expectancy.
No.
| |
| Robert Wagner 2004-05-17, 11:30 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
limits[color=darkred]
>
>Well that passed over your head, too.
>
>The number of external names in a run-unit has _nothing_ to do with
>the amount of memory or which OS is used.
>
>If a run-unit is created statically then the issue is with the linker
>that is used, if the run-unit is dynamic then it is an issue with the
>run-time mechanism that keeps track of these names as programs are
>loaded and cancelled.
It didn't pass over my head. I looked it up in the Unix man page for ld -- the
'linker' used for both static and dynamic loading. It has no limits except
available memory. Why should it?
>You even complained that nested programs were too many extra lines and
>seemed to want to use ENTRY just because it was one line.
Nested programs didn't bother me, but I thought a one-line replacement of
paragram name would be easier to sell.
| |
| Richard 2004-05-17, 11:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
>
> ..Cannot pass parameters.
In most cases parameters are not an issue, they are only of real
significance if the code is to be reused with different data items,
your very real case of reformatting different dates, for example.
However, in general, if it is to be something that is done for several
different data items in one program then it is likely to be useful for
other programs too. This then leads to it being an external program,
or a class method.
> ..THRU becomes a Shop Standard.
So argue against THRU.
> ..Cannot do recursion.
There are very few real cases for using recursion. What recursive
ENTRY was designed to support is re-entrancy. For example Windows
callbacks.
In most cases an iteritive solution is just as good as a recursive
one.
> Richard says the advantage is reduced namespace pollution.
Did I actually say that ? No. I don't mind being criticised for what
I do say, but I deny you the right to make up things that I didn't
say. In any case it tends to show that you just didn't understand the
issue.
_Excessive_misuse_ of ENTRY causes namespace polution.
One major advantage of nested programs over internal use of ENTRYs is
_they_work_.
| |
| Robert Wagner 2004-05-18, 2:30 am |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>
>In most cases parameters are not an issue, they are only of real
>significance if the code is to be reused with different data items,
>your very real case of reformatting different dates, for example.
>However, in general, if it is to be something that is done for several
>different data items in one program then it is likely to be useful for
>other programs too. This then leads to it being an external program,
>or a class method.
>
>
>There are very few real cases for using recursion. What recursive
>ENTRY was designed to support is re-entrancy. For example Windows
>callbacks.
You argue for one call mechanism for zero parameters, another for a call with
parameters, and a third for recursion. What other language is designed that way?
The only one I can think of is Basic. Even there, GOSUB, which is analogous to
PERFORM, has been abandoned.
When a maintenance programmer sees the need for a parameter when calling a
paragraph that formerly had none, you would have him restructure the program to
make the paragraph an external program. Not gonna happen. He or she will take
the easy way out by moving it to a temp field in working-storage.
Re-entrancy is for multi-threading. Windows callbacks are not an example of
multi-threading.
To make a program thread-safe, multiple call mechanisms would require
restructuring EVERY paragraph into something else.
I agree there are few cases for recursion, but when you need it, it's nice to
have. Tree processing is one such.
>
>Did I actually say that ? No. I don't mind being criticised for what
>I do say, but I deny you the right to make up things that I didn't
>say. In any case it tends to show that you just didn't understand the
>issue.
>_Excessive_misuse_ of ENTRY causes namespace polution.
You beat me over the head with namespace pollution in re ENTRY, and said Nested
Programs were "carefully designed" to avoid the problem.
| |
| Richard 2004-05-18, 4:30 am |
| "Howard Brazee" <howard@brazee.net> wrote
> Any PC applications with a GUI? Why is CoBOL a good fit?
The first GUI Cobol program I did started when MF first released 16bit
version 2.1 with early release that included support for Windows
programs. This was when Win 3.0 was just out. It was no worse
writing it in Cobol than in any other language, but there was great
deal of existing Cobol code that could be reused, plus the data files
in the existing system. This was fully graphical, not just dialog
boxes, though there were a number of those. It was a container ship
loading system that drew the bays, the tanks, bonjean curves,
stability, torsion and bend and shear curves. Drag and drop
containers from terminal to bays.
These days most stuff of my Cobol is done with SP/2. It gives an
excellent UI, is easy to design screens with and isolates the UI from
the processing code.
>
> Why is CoBOL a good fit?
CGI web server programs are easy to do, though you need to deal with
the modeless connections. Its just as easy as other languages once
you have written some utility routines to parse the input and to
output using templates, or use propritry routines, but they don't do
anything that can't be done reasonably portably in Cobol.
The advantage of using Cobol (to me) is that it can reuse existing
application code (for example to pricing and discount module) and can
directly access existing data files for order systems and others.
>
> Why is CoBOL a good fit?
I doubt that it is.
| |
| Howard Brazee 2004-05-18, 11:30 am |
|
On 17-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
> You argue for one call mechanism for zero parameters, another for a call with
> parameters, and a third for recursion. What other language is designed that
> way?
> The only one I can think of is Basic. Even there, GOSUB, which is analogous to
> PERFORM, has been abandoned.
I haven't done Basic in a long time. Why was GOSUB abandoned? Does it now
emulate C and OO languages more?
| |
| Robert Wagner 2004-05-18, 1:30 pm |
| "Howard Brazee" <howard@brazee.net> wrote:
>On 17-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
>
to[color=darkred]
>
>I haven't done Basic in a long time. Why was GOSUB abandoned? Does it now
>emulate C and OO languages more?
Yes. VB is an OO language.
| |
| Howard Brazee 2004-05-18, 2:30 pm |
|
On 18-May-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:
> to
>
> Yes. VB is an OO language.
I don't generally call VB and Basic the same language. Much of the syntax is
the same, but Basic means one thing to me Visual Basic means a different thing.
| |
| Richard 2004-05-18, 5:30 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
> You argue for one call mechanism for zero parameters, another for a call with
> parameters, and a third for recursion.
No I don't. For a start I never argued for recursion. I have no
interest in recursion, iterative solutions are no more arduous, and
recursion, where it is supported, can be used with the Program-Id,
just as every other call is.
The PERFORM is not a 'call without parameters', it is a block
structuring mechanism and an iteration mechanism. It happens that it
allows (or required in older versions) the block to be separated and
made out-of-line.
> What other language is designed that way?
All of them actually, except they mostly require the blocks to be
in-line.
> The only one I can think of is Basic.
That may not represent a limitation of 'other languages'.
> Even there, GOSUB, which is analogous to PERFORM, has been abandoned.
BASIC is not _a_ language, it is a collection of dozens of languages
which may, or may not, be similar. In some BASIC languages the line
numbering is not used and GOSUB syntax requires a line number.
But then Cobol avoids such issues where 'the next release' requires
all the programs to be rewritten.
> When a maintenance programmer sees the need for a parameter when calling a
> paragraph that formerly had none,
Since when did a 'maintenance programmer' ever see the need for a
parameter ?
> you would have him restructure the program to
> make the paragraph an external program.
I never made that requirement, you are making it up. You seem to be
inventing things for me to say just to argue against them.
What I did say is that if some code is so useful that it should be
reused with a parameter, _and_ you would change it to make that
happen, then it may be useful to other programs and an external
program would allow that.
This is not the job of a 'maintenance programmer' but is a design
decision.
OTOH hand you were recommending that for the sake of one routine to
take a parameter the _whole_program_ should be changed to using ENTRY
and have no section or paragraph labels at all.
> Not gonna happen. He or she will take
> the easy way out by moving it to a temp field in working-storage.
Yes, probably. But then using ENTRY isn't going to ever happen
either, except where it is used for its intended purpore of external
re-entrancy.
> Re-entrancy is for multi-threading. Windows callbacks are not an example of
> multi-threading.
I don't know where you get your ideas from. MF introduced the systems
programming extensions, with LOCAL-STORAGE and recursion, around 1990.
This was used for Windows programs as callbacks require the run-unit
to be re-entrant.
Multi-threading came much later in the mid-90s. Though it builds on
the same system programming features, it would be wrong, as you have
done, to reverse the timeline.
With the large graphics Windows programs that I wrote a 'yield' would
potentially result in the program being re-entered (depending on what
was in the message queue) and changing the working-storage and file
areas (but not the local-storage). I used this regularly to keep the
screen updated, it didn't require me to abandon PERFORM of paragraphs
or any other mechanism. It did require me to carefully check shared
data.
> To make a program thread-safe,
I doubt there is much call to make existing programs thread-safe.
> multiple call mechanisms would require
> restructuring EVERY paragraph into something else.
No. You are wrong. A multi-threaded program may need to be carefully
designed to cater for this, but PERFORM of paragraphs is not on the
'don't do' list.
> I agree there are few cases for recursion, but when you need it, it's nice to
> have. Tree processing is one such.
You never need recursion, iteration can do exactly the same job.
Recursion does store away your local data in the stack for you, with
iteration an array (or list if you wish) can do exactly the same, with
just a few lines of code.
> You beat me over the head with namespace pollution in re ENTRY,
> and said Nested
> Programs were "carefully designed" to avoid the problem.
Yes. Using ENTRY for its intended task, an alternate external call
point is _not_ polution, it is an item _required_ to be added to the
run-unit namespace, just as program-ids are added to the namespace
because they need to be there so they can be called.
Nested programs are only locally visible and so do not add to the
run-unit namespace.
Polution is unrequired items in the namespace. It is only your misuse
of ENTRY that does this. Nested programs do not polute, by design.
It was your claim that I said 'nested programs _reduce_ polution'.
They do nothing to polution at all, they don't add or reduce it.
It is only your misuse of ENTRY that adds polution and eliminating
your misuse that reduces it.
But that was not the main objection to your 'better' use of ENTRY, the
main reason is that it just doesn't work in 'most compilers', even
where ENTRY exists. Even where it may be made to work in a demo toy
program, it does not scale to applications and would cause huge name
management problems.
You claimed it was 'better' and I would regard everything that you put
in this category with deep suspicion. Your ideas show a complete lack
of development, and have no understanding of what has been learnt from
other languages.
When you see 'fear' in your co-workers eyes, it isn't from your 'deep
intellectual insights'.
I think that you may be happier working in a different language, why
not try again to learn C.
| |
| Michael Wojcik 2004-05-18, 6:30 pm |
|
In article <40a55e57.325467891@news.optonline.net>, robert.deletethis@wagner.net (Robert Wagner) writes:
> riplin@Azonic.co.nz (Richard) wrote:
>
It was called FS, for Future Systems. FS was cancelled circa 1976.
Legendary IBMer Lynn Wheeler was partially responsible; his research
into the (abysmal) performance of FS was ammunition for those arguing
against it. His archives (at http://www.garlic.com/) have various
details.
FS was intended as the OS for either the 370 or a successor
tentatively named the S/380. It was partially intended as a clone-
killer, and partially a grandiose attempt to incorporate every
advanced OS feature anyone at IBM could dream up in the hope of
creating an OS so "advanced" it would drown all of its competitors.
[color=darkred]
>
> You're wrong. It came from a failed Big Iron concept that found a home in
> S/36-38 land.
You're both right (and wrong). The AS/400 ("Silverlake") project was
the migration strategy for S/36 and S/38, and OS/400 included an
S/38-compatibility mode for many years (it may still, for all I
know). OS/400 incorporated many ideas from FS, for a variety of
reasons; one is that some of the (many) people who worked on FS went
on to work on the S/36 and S/38 (which were successors to the S/3;
the S/34 was a stripped-down S/38). Another was that hardware had
improved to the point where some of the FS concepts, such as very
rigorous supervision of application behavior, were more feasible
(though the original AS/400s were still painfully slow, particularly
the little development boxes).
So the AS/400 belongs to the S/38 family, but OS/400 is most closely
related to FS, which was intended as an OS for the S/370 family
(though never completed, much less released).
Yes, for several years now.
[color=darkred]
> Probably. Under the covers, nearly all modern machines are RISC emulating
> CISC.
While this is arguable in a certain limited sense (most contemporary
CPUs are 8-bit microcontrollers, after all, and it's debatable
whether "emulating" is the proper term for a RISC core processing a
microdecoded CISC instruction stream), this has little to do with
what kind of processor AS/400s use. The 400s are built on POWER
CPUs now because 1) IBM owns POWER, and 2) POWER has better
performance characteristics (particularly in terms of things like
power consumption, which are more important in data centers than
they are with home users) than the only other currently-available,
viable, comparable architecture, IA64. (The 400 uses the 64-bit
POWER designs.)
> Natively RISC machines are VERY fast, especially Sun.
RISC architectures aren't inherently fast. The best SPEC numbers
right now belong to x86-family CPUs, because Intel and AMD have
cranked their clocks up to ridiculous speeds. Those are hugely
inefficient chips, but economies of scale have made them more
affordable than any other architecture for most purposes.
There are applications where a super-hot, power-devouring CPU is not
the best choice, and that's where something like POWER finds its
niche. (Or where people want a decent 64-bit implementation. Or
where they want binary compatibility with another architecture
because they've invested in it.)
It's true that the modern RISC designs, from POWER on, are much
better (in terms of instructions per cycle and so forth) than the old
CISC designs. But since the high-performance CISC CPUs are now RISC
cores with a layer of CISC-instruction decoding around them, it's a
moot point.
What it really comes down to is that there are a number of good ideas
for creating very fast CPUs; everyone is using the ones they can
afford; and Intel (and AMD) is throwing a clunky compatibility
wrapper around theirs, because they have to in order to keep their
customer base, but the core is so fast that they still get the
performance they need.
And "especially Sun"? Sun's best SPARC performance numbers aren't
close to IBM's best POWER ones. They're not close to Sun's best x86
numbers, in fact. Take a look at http://www.spec.org/. SPARC was a
nice design in its day, but Sun doesn't have the resources to keep up
with chip design and fabrication innovation. They gave it a good try
and kept SPARC viable for an impressively long time, but they're not
Intel or IBM. Inventing a usable silicon-on-insulator process and
retooling your fab to use it, for example, is a huge investment. Sun
never had that kind of money.
> Both Sun and HP have
> announced they're abandoning their successful platforms in favor of Intel
> lookalikes. Visionaries know something we don't.
They know that it's cheaper for them to use Intel chips (and clones)
because of the aforementioned economies of scale. Sun does, anyway.
What HP is doing is anyone's guess, particularly since the Compaq
merger. And long before its decline HP got in bed with Intel for
IA64 - they decided VLIW was the way to go, and by partnering with
Intel they could keep the best of PA-RISC in a processor family that
would enjoy much larger volumes. As it turned out, of course, IA64
is a dog and almost no one wants it (though probably Intel will
eventually throw enough resources at it for it to succeed).
ObCOBOL: GOBACK.
--
Michael Wojcik michael.wojcik@microfocus.com
This record comes with a coupon that wins you a trip around the world.
-- Pizzicato Five
| |
| Richard 2004-05-18, 11:30 pm |
| mwojcik@newsguy.com (Michael Wojcik) wrote
> It was partially intended as a clone-
> killer, and partially a grandiose attempt to incorporate every
> advanced OS feature anyone at IBM could dream up in the hope of
> creating an OS so "advanced" it would drown all of its competitors.
Now why does that sound like 'Longhorn' ?
| |
| Robert Wagner 2004-05-18, 11:30 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>BASIC is not _a_ language, it is a collection of dozens of languages
>which may, or may not, be similar. In some BASIC languages the line
>numbering is not used and GOSUB syntax requires a line number.
VB6 supports line numbers, GoTo, On number GoTo n,n,n .. and GOSUB.
VB.NET dropped them as obsolete language elements.
Basic never had GOSUB n THRU n
>
>Since when did a 'maintenance programmer' ever see the need for a
>parameter ?
A paragraph processes foo. They 're-engineer' the database by adding new-foo.
Now the old part of the program wants to call the paragraph with foo and some
new code added by the maintenance programmer wants to call it with new-foo.
Solution:
move foo to temp-foo
perform (paragraph)
--later--
move new-foo to temp-foo
perform (paragraph)
>What I did say is that if some code is so useful that it should be
>reused with a parameter, _and_ you would change it to make that
>happen, then it may be useful to other programs and an external
>program would allow that.
The paragraph is of no use to another program AND refers to 17 fields in this
program's working-storage. Would you have the maintenance programmer pass 17
parameters?
>This is not the job of a 'maintenance programmer' but is a design
>decision.
It happens all the time.
>OTOH hand you were recommending that for the sake of one routine to
>take a parameter the _whole_program_ should be changed to using ENTRY
>and have no section or paragraph labels at all.
Yes.
>
>I don't know where you get your ideas from. MF introduced the systems
>programming extensions, with LOCAL-STORAGE and recursion, around 1990.
>This was used for Windows programs as callbacks require the run-unit
>to be re-entrant.
>
>Multi-threading came much later in the mid-90s. Though it builds on
>the same system programming features, it would be wrong, as you have
>done, to reverse the timeline.
I gave no timeline. I said reentrant and multithreaded are not the same thing.
A reentrant program is a single process, a single entry in the operating
system's task table. It executes serially. A multithreaded program is multiple
processes running in parallel and having multiple entries in the task table
(called in Unix LightWeight Process (LWP)).
A multithreaded program must use synchronization to prevent two threads from
simultaneously accessing shared memory. That's not an issue in reentrant
programs.
A multithreaded program might have to wait for several parallel threads to
finish before it can continue. A reentrant program has only one thread.
>With the large graphics Windows programs that I wrote a 'yield' would
>potentially result in the program being re-entered (depending on what
>was in the message queue) and changing the working-storage and file
>areas (but not the local-storage). I used this regularly to keep the
>screen updated, it didn't require me to abandon PERFORM of paragraphs
>or any other mechanism. It did require me to carefully check shared
>data.
Ok, that's multithreading, which was first supported by Microsoft in NT (and
OS/2). It was not supported by Win9x and certainly not by Win3. MF support for
reentrancy alone was not adequate. You needed a dispatcher and a way to lock
shared data.
I'm guessing Microsoft forked a 'child process' for each message, and s | | |