I don't think this is behind a paywall, but if it is I apologize.
It says:: "please enable JS and disable add-blocker"
ha
Mainframes are obsolete. The mindset of “the CPU is expensive, let’s surround it with complex channel controllers to handle batch I/O”
stopped being relevant sometime in the 1980s, if not before.
On Wed, 14 Aug 2024 20:14:57 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
It says:: "please enable JS and disable add-blocker"
ha
8-) I do allow JS, but I tightly control it with NoScript.
The article started ok, talking about how certain applications are
latency sensitive and how they could benefit from having an AI be
resident on the mainframe.
Actually a good portion of the article seemed rather positive on the
idea of implementing AI models on mainframes. Unfortunately it
devolves into implications that AI doesn't play nice with COBOL and
that mainframes can't be programmed in other languages.
Not knowing COBOL well, I can't speak to the former.
The latter,
however, is bullshit.
On Wed, 14 Aug 2024 20:14:57 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
It says:: "please enable JS and disable add-blocker"
ha
8-) I do allow JS, but I tightly control it with NoScript.
The article started ok, talking about how certain applications are
latency sensitive and how they could benefit from having an AI be
resident on the mainframe.
Actually a good portion of the article seemed rather positive on the
idea of implementing AI models on mainframes. Unfortunately it
devolves into implications that AI doesn't play nice with COBOL and
that mainframes can't be programmed in other languages.
Not knowing COBOL well, I can't speak to the former. The latter,
however, is bullshit.
from the article:
"
Mainframes do have limitations. They are constrained by the computing
power within their boxes, unlike the cloud, which can scale up by
drawing on computing power distributed across many locations and
servers. They are also unwieldy—with years of old code tacked on—and don’t integrate well with new applications. That makes them costly to manage and difficult to use as a platform for developing new
applications.
:
Still, efforts to do away with the mainframe have been going for
years, especially as the number of developers conversant in Cobol—one
of the primary programming languages used in mainframes—quickly
dwindles.
"
On Thu, 15 Aug 2024 16:04:13 +0000, George Neuner wrote:
On Wed, 14 Aug 2024 20:14:57 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
It says:: "please enable JS and disable add-blocker"
ha
8-) I do allow JS, but I tightly control it with NoScript.
The article started ok, talking about how certain applications are
latency sensitive and how they could benefit from having an AI be
resident on the mainframe.
There are only 3 kinds of applications::
a) those that are latency sensitive
b) those that are bandwidth sensitive
c) those that are balanced between latency and bandwidth.
Caches deal with (a)
On Thu, 15 Aug 2024 16:04:13 +0000, George Neuner wrote:
from the article:
"Still, efforts to do away with the mainframe have been going for
years, especially as the number of developers conversant in Cobol—one
of the primary programming languages used in mainframes—quickly
dwindles.
"
While dusty deck COBOL programs make assumptions about the environment
they compute within, there is nothing preventing computer makers from supporting those features that COBOL programs require and getting a
COBOL compiler for their ISA up and running. The problem is that as
long as there are mainframe makers, the other computer makers do not
see a big enough market to make the required investments.
On Thu, 15 Aug 2024 0:02:11 +0000, Lawrence D'Oliveiro wrote:
Mainframes are obsolete. The mindset of “the CPU is expensive, let’s
surround it with complex channel controllers to handle batch I/Oâ€
stopped being relevant sometime in the 1980s, if not before.
If one defines a mainframe computer as having the ability to remove and replace every component without taking the computer off line--then
mainframes are still relevant. Reliability, Availability,
Serviceability.
And when I say everything I mean everything:
power supplies, memories, disks, NICs, other devices, CPUs, cooling,
..
Reliability may trade speed for never failing as a good trade off Availability 100% up time 24/7/365 for a decade or longer without
outages
Serviceability replacement of any and all modules while keeping the
system "up"
Thus a mainframe is more about how it is constructed than what parts
are used to construct it.
While dusty deck COBOL programs make assumptions about the environment
they compute within, there is nothing preventing computer makers from supporting those features that COBOL programs require and getting a
COBOL compiler for their ISA up and running. The problem is that as
long as there are mainframe makers, the other computer makers do not
see a big enough market to make the required investments.
On Thu, 15 Aug 2024 0:02:11 +0000, Lawrence D'Oliveiro wrote:
Mainframes are obsolete. The mindset of “the CPU is expensive, let’s surround it with complex channel controllers to handle batch I/O”
stopped being relevant sometime in the 1980s, if not before.
If one defines a mainframe computer as having the ability to remove
and replace every component without taking the computer off line--then mainframes are still relevant. Reliability, Availability,
Serviceability.
And when I say everything I mean everything:
power supplies, memories, disks, NICs, other devices, CPUs, cooling,
..
Reliability may trade speed for never failing as a good trade off Availability 100% up time 24/7/365 for a decade or longer without
outages
Serviceability replacement of any and all modules while keeping the
system "up"
Thus a mainframe is more about how it is constructed than what parts
are used to construct it.
On Thu, 15 Aug 2024 17:44:42 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:
On Thu, 15 Aug 2024 0:02:11 +0000, Lawrence D'Oliveiro wrote:
=20
=20
Mainframes are obsolete. The mindset of =E2=80=9Cthe CPU is expensive, = >let=E2=80=99s
surround it with complex channel controllers to handle batch I/O=E2=80= >=9D
stopped being relevant sometime in the 1980s, if not before. =20
If one defines a mainframe computer as having the ability to remove
and replace every component without taking the computer off line--then
mainframes are still relevant. Reliability, Availability,
Serviceability.
=20
And when I say everything I mean everything:
power supplies, memories, disks, NICs, other devices, CPUs, cooling,
..
And then there comes an electrician and pulls big red switch. Twice.
And after that it turns out that live link to reserved computer 20 miles >apart and the whole restart procedure was never tested.
That's exactly what happened in Heathrow not so many (7) years ago.
It was never confirmed that computers in fault were IBM mainframes, but
what else it could have possibly been?
On Thu, 15 Aug 2024 0:02:11 +0000, Lawrence D'Oliveiro wrote:
Mainframes are obsolete. The mindset of “the CPU is expensive, let’s
surround it with complex channel controllers to handle batch I/O”
stopped being relevant sometime in the 1980s, if not before.
If one defines a mainframe computer as having the ability to remove and replace every component without taking the computer off line--then
mainframes are still relevant. Reliability, Availability,
Serviceability.
Google and the others assume everything can and will fail, but all
operations can fail over to some other unit, which might even be in a
totally different geographic region.
Dewar used to say that COBOL is the "Rodney Dangerfield of programming languages", which just "don't get no respect".
If one defines a mainframe computer as having the ability to remove and replace every component without taking the computer off line--then
mainframes are still relevant. Reliability, Availability,
Serviceability.
On Thu, 15 Aug 2024 22:06:16 +0300, Niklas Holsti wrote:
Dewar used to say that COBOL is the "Rodney Dangerfield of programming
languages", which just "don't get no respect".
Except people laughed *with* Rodney Dangerfield, whereas they laugh *at* >COBOL. For Dangerfield, it was just an act, after all: you don’t think his >real life was like that, do you?
COBOL was designed specifically for “business” computing, back when there >was a clearly demarcation of what this meant: no need for complex >mathematical formulae, no need for string/text manipulation, no need for >interactive terminals.
One major crack in this wall came with the introduction of relational
DBMSes, particularly ones using SQL as their interface language: suddenly, >the use of such databases became very much a core “business” need.
The best way to interface to such a DBMS was to be able to generate SQL >strings on the fly; but this required some facility with manipulation of >dynamic, variable-length strings, which COBOL completely lacked. And so >special extensions were tacked on, just to cope with the generation of SQL >queries and templates.
On Thu, 15 Aug 2024 22:06:16 +0300, Niklas Holsti wrote:
Dewar used to say that COBOL is the "Rodney Dangerfield of programming
languages", which just "don't get no respect".
Except people laughed *with* Rodney Dangerfield, whereas they laugh *at* >COBOL.
The best way to interface to [relational] DBMS was to be able to generate SQL >strings on the fly; but this required some facility with manipulation of >dynamic, variable-length strings, which COBOL completely lacked. And so >special extensions were tacked on, just to cope with the generation of SQL >queries and templates.
One major crack in this wall came with the introduction of relational
DBMSes, particularly ones using SQL as their interface language: suddenly, the use of such databases became very much a core “business” need.
The best way to interface to such a DBMS was to be able to generate SQL strings on the fly; but this required some facility with manipulation of dynamic, variable-length strings, which COBOL completely lacked. And so special extensions were tacked on, just to cope with the generation of SQL queries and templates.
trivia: I worked with Jim Gray and Vera Watson on the original
SQL/relational implementation, "System/R". Also we were able to do
technical transfer to Endicott (under the "radar" while corporation was preoccupied with "EAGLE", next great DBMS) for SQL/DS.
This is the first I have heard of "EAGLE". Can you talk about what it
was like? Was it an "enhanced IMS", or did it follow the CODASYL
model, or something completely different?
trivia: I worked with Jim Gray and Vera Watson on the original
SQL/relational implementation, "System/R". Also we were able to do
technical transfer to Endicott (under the "radar" while corporation was preoccupied with "EAGLE", next great DBMS) for SQL/DS. Then when "EAGLE" imploded, there was a request for how fast could "System/R" be ported to
MVS (eventually released as DB2).
Back when I was in school it was fashionable to sneer at COBOL, but I
don't think many of the people doing the sneering knew anything about
the language.
For example, it has coroutines implemented in a very
useful way. I doubt any of them knew that, and at the time, very few
other languages did.
The current version of COBOL has a lot of extensions over the 1960s
version which should be no surprise. The current versions of Fortran
and C are a lot bigger than the classic versions, too.
For example, it has coroutines implemented in a very
useful way. I doubt any of them knew that, and at the time, very few
other languages did.
Really?? You’re not talking about that “ALTER ... TO PROCEED TO ...” crap,
are you?
For some kinds of work, COBOL is still an entirely reasonable language, albeit
one where the learning curve can be pretty steep.
On 2024-08-16 10:14, John Levine wrote (in part):
For some kinds of work, COBOL is still an entirely reasonable language, albeit
one where the learning curve can be pretty steep.
An interesting comment on the learning curve (and I know nothing about
COBOL) given the story that the language was created to allow
non-programmers to programme.
An interesting comment on the learning curve (and I know nothing
about COBOL) given the story that the language was created to allow non-programmers to programme.
I had a basic COBOL course at college in 1980-81, and
became quite clear that this wasn't what I wanted to do.
John
In article <v9t3ih$2e8ee$1@dont-email.me>, OrangeFish@invalid.invalid (OrangeFish) wrote:
An interesting comment on the learning curve (and I know nothing about
COBOL) given the story that the language was created to allow
non-programmers to programme.
It doesn't require learning concepts that are strange to accountants or bookkeepers.
It doesn't require learning concepts that are strange to accountants or
bookkeepers.
Level numbers? “USAGE IS COMPUTATIONAL”? “RESERVE «n» ALTERNATE AREAS”,
“ALTER «target» TO PROCEED TO «dest»”? All the fun of the “MOVE” >statement?
Oh, and compound interest requires working with transcendental functions, >doesn’t it?
So, John is not a COBOholic !!
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Fri, 16 Aug 2024 14:14:51 -0000 (UTC), John Levine wrote:[...]
For example, it has coroutines implemented in a very
useful way. I doubt any of them knew that, and at the time, very few
other languages did.
Really?? You’re not talking about that “ALTER ... TO PROCEED TO ...” crap,
are you?
A Google search for "cobol coroutines" would have saved you some time
and embarrassment.
In article <v9t3ih$2e8ee$1@dont-email.me>, OrangeFish@invalid.invalid >(OrangeFish) wrote:
An interesting comment on the learning curve (and I know nothing
about COBOL) given the story that the language was created to allow
non-programmers to programme.
It doesn't require learning concepts that are strange to accountants or >bookkeepers. Just about all of its keywords are ordinary English words
being used in something like their normal sense. It's much easier for >business people to learn than assembler, which is what it was intended to >replace.
However, it has a /lot/ of keywords and is generally verbose, the rules
on combining keywords are a bit weird, and it lacks "expressive power" - >trying to get it to deal with data types that aren't built into it is
kind of hard. I had a basic COBOL course at college in 1980-81, and
became quite clear that this wasn't what I wanted to do.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
Oh, and compound interest requires working with transcendental functions,
doesn’t it?
Uh, no, it's just repeated multiplication. COBOL makes it easy to say what the precision
of each number is with the decimal point location to get the rounding right. I suppose if
you want to compute the APR for a daily compounded rate that's more complicated but not
something I'd expect in typical COBOL code, more likely to be an input that's changed when
they change the interest rate they charge.
If you want bond prices or internal rates of return, you need to compute the zero of a
long polynomial which is tedious (I did it for a financial package in the 1980s) but still
not transcendental, and in any event, I doubt either were common in the kind of
bookkeeping stuff COBOL was typically used for.
Burroughs Cobol 68 compiler was used to implement various
system utilities, including the disk/pack defragmenter. Granted,
it had an 'ENTER SYMBOLIC' verb which allowed embedded assembler
:-).
In article <9V1xO.583702$qO%5.449825@fx16.iad>, scott@slp53.sl.home
(Scott Lurndal) wrote:
Burroughs Cobol 68 compiler was used to implement various
system utilities, including the disk/pack defragmenter. Granted,
it had an 'ENTER SYMBOLIC' verb which allowed embedded assembler
:-).
Were Burroughs deliberately eccentric, or was that just an emergent
property of the company?
I am so glad I did not take up the idea of specialising in Burroughs
stuff after graduation. It was suggested because I was fond of Algol 68,
but it would have been very career-limiting.
In article <9V1xO.583702$qO%5.449825@fx16.iad>, scott@slp53.sl.home
(Scott Lurndal) wrote:
Burroughs Cobol 68 compiler was used to implement various
system utilities, including the disk/pack defragmenter. Granted,
it had an 'ENTER SYMBOLIC' verb which allowed embedded assembler
:-).
Were Burroughs deliberately eccentric, or was that just an emergent
property of the company?
I am so glad I did not take up the idea of specialising in Burroughs
stuff after graduation. It was suggested because I was fond of Algol 68,
but it would have been very career-limiting.
John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
Oh, and compound interest requires working with transcendental
functions, doesn’t it?
Uh, no, it's just repeated multiplication.
For some simple bonds, parts of the price or yield calculations are
integer power series so one could roll your own integer power function optimized to do the minimum number of multiplies.
x^17 = ((((x^2)^2)^2)^2)*x
The Burroughs MCP was always far more advanced
(and much easier to use) than any contemporaneous IBM operating
system ...
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 20 Aug 2024 11:51:14 -0400, EricP wrote:[...]
x^17 = ((((x^2)^2)^2)^2)*x
I’d really like to see how you’d write that in COBOL ...
COMPUTE X17 = ((((X**2)**2)**2)**2)*X
MitchAlsup1 wrote:
On Wed, 21 Aug 2024 0:52:58 +0000, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 20 Aug 2024 11:51:14 -0400, EricP wrote:[...]
x^17 = ((((x^2)^2)^2)^2)*x
I’d really like to see how you’d write that in COBOL ...
COMPUTE X17 = ((((X**2)**2)**2)**2)*X
Why not::
COMPUTE x17 = x**17
There are compilers these days that produce the above from
the simpler evaluation.
In Cobol does that ** operator raise an FP or decimal value to an
integer power by repeated multiplication, as John originally wanted,
or does it use a transcendental POW?
On Wed, 21 Aug 2024 0:52:58 +0000, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 20 Aug 2024 11:51:14 -0400, EricP wrote:[...]
x^17 = ((((x^2)^2)^2)^2)*x
I’d really like to see how you’d write that in COBOL ...
COMPUTE X17 = ((((X**2)**2)**2)**2)*X
Why not::
COMPUTE x17 = x**17
There are compilers these days that produce the above from
the simpler evaluation.
If I could find a spec for SQLlite's table format, might also be worth looking at, TBD...
Underused: It is a sensible way of structuring data, but needing to
interface with it though SQL strings is awkward and inefficient.
Or, do some weird OO thing where object methods exist for SQL keywords
and each method returns an object that can be used to glue on the next keyword:
res=db.select().from("FOOTAB").where().equals("NAME", "John").end();
On Sun, 18 Aug 2024 18:21:00 +0000, John Dallman wrote:
I had a basic COBOL course at college in 1980-81, and
became quite clear that this wasn't what I wanted to do.
John
So, John is not a COBOholic !!
On Fri, 23 Aug 2024 09:40:00 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
MitchAlsup1 wrote:
On Sun, 18 Aug 2024 18:21:00 +0000, John Dallman wrote:
I had a basic COBOL course at college in 1980-81, and
became quite clear that this wasn't what I wanted to do.
John
So, John is not a COBOholic !!
Also not a COBOL fan, mostly due to the verbosity.
I once ported a COBOL-specific algorithm to Pascal, which meant that
I had to reimplement code for all the 80-col punch card formatted IO
as well as sorting according to quite special rules.
The original was 25 pages, my replacement ~5, at least half of which
was the COBOL specific function replacements, so the mainline code
became an order of magnitude smaller.
Terje
What would be the size if you were porting it from COBOL to COBOL ?
Michael S wrote:
On Fri, 23 Aug 2024 09:40:00 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
MitchAlsup1 wrote:
On Sun, 18 Aug 2024 18:21:00 +0000, John Dallman wrote:
I had a basic COBOL course at college in 1980-81,
and became quite clear that this wasn't what I wanted to do.
John
So, John is not a COBOholic !!
Also not a COBOL fan, mostly due to the verbosity.
I once ported a COBOL-specific algorithm to Pascal, which meant
that I had to reimplement code for all the 80-col punch card
formatted IO as well as sorting according to quite special rules.
The original was 25 pages, my replacement ~5, at least half of
which was the COBOL specific function replacements, so the
mainline code became an order of magnitude smaller.
Terje
What would be the size if you were porting it from COBOL to COBOL ?Huh?
Are you asking about optimizing the COBOL to be much less verbose?
I have absolutely no idea where I would even have started such a
task, I just looked at the actual source code, while already knowing
_what_ it was doing, and then figured out how to reimplement it in a different language.
It is quite possible that the original COBOL was non-optimal, but I
still have no way to determine that.
Terje
MitchAlsup1 wrote:
On Sun, 18 Aug 2024 18:21:00 +0000, John Dallman wrote:
I had a basic COBOL course at college in 1980-81, and
became quite clear that this wasn't what I wanted to do.
John
So, John is not a COBOholic !!
Also not a COBOL fan, mostly due to the verbosity.
I once ported a COBOL-specific algorithm to Pascal, which meant that
I had to reimplement code for all the 80-col punch card formatted IO
as well as sorting according to quite special rules.
The original was 25 pages, my replacement ~5, at least half of which
was the COBOL specific function replacements, so the mainline code
became an order of magnitude smaller.
Terje
I once ported a COBOL-specific algorithm to Pascal, which meant
that I had to reimplement code for all the 80-col punch card
formatted IO as well as sorting according to quite special rules.
The original was 25 pages, my replacement ~5, at least half of
which was the COBOL specific function replacements, so the
mainline code became an order of magnitude smaller.
My assumption was that majority of size reduction happened due to
identifying repeated patterns and implementing them as subroutines.
Which could be done in any reasonable language. I know nothing about
COBOL, but hope that it supports subroutines.
I simply don't see how mere syntax difference between COBOL and Pascal,
On Thu, 22 Aug 2024 15:59:34 -0500, BGB wrote:
Underused: It is a sensible way of structuring data, but needing to
interface with it though SQL strings is awkward and inefficient.
Actually, that works fine in any language with decent string handling.
Or, do some weird OO thing where object methods exist for SQL keywords
and each method returns an object that can be used to glue on the next
keyword:
res=db.select().from("FOOTAB").where().equals("NAME", "John").end();
ORMs are a waste of time.
On 8/22/2024 9:36 PM, Lawrence D'Oliveiro wrote:
On Thu, 22 Aug 2024 15:59:34 -0500, BGB wrote:String processing adds bulk and inefficiency.
Underused: It is a sensible way of structuring data, but needing to
interface with it though SQL strings is awkward and inefficient.
Actually, that works fine in any language with decent string handling.
Granted, maybe not enough to matter in the face of a typical database
query.
But, I was left thinking, some programs use SQLite, which exists as a
single giant C file. I guess it technically works, but has the downside
of adding something like IIRC around 900K or so to the size of the
binaries' ".text" section.
05 COMMAND PIC X(3).
88 NAVIGATE VALUE "NAV".
88 PHASERS VALUE "PHA".
88 TORPEDO VALUE "TOR".
88 SHIELDS VALUE "DEF".
88 DOCK VALUE "DOC".
88 LIB-COM VALUE "COM".
88 NAV-C VALUE "NAV".
88 PHA-C VALUE "PHA".
88 TOR-C VALUE "TOR".
88 DEF-C VALUE "DEF".
88 DOC-C VALUE "DOC".
88 COM-C VALUE "COM".
I simply don't see how mere syntax difference between COBOL and
Pascal, which by itself is not particularly terse or particularly
expressive, could alone account for such massive reduction in the
size of the program text.
... you are confusing two different computer lines.
String processing adds bulk and inefficiency.
Granted, maybe not enough to matter in the face of a typical database
query.
Remember what Knuth (or maybe it was Hoare) said: “Premature optimization >is the root of all evil”. String processing has to be in the language for >other reasons (think: composing messages and processing input when >interacting with a human user), why not use it for this?
Also, it is quite common now to use text-based protocols for networks
(e.g. messages in JSON format). That may sound inefficient, but it eases >debugging so much, that has become a major consideration.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
String processing adds bulk and inefficiency.
Granted, maybe not enough to matter in the face of a typical database
query.
Remember what Knuth (or maybe it was Hoare) said: “Premature optimization >>is the root of all evil”. String processing has to be in the language for >>other reasons (think: composing messages and processing input when >>interacting with a human user), why not use it for this?
Interactimg? Human user? COBOL was designed for computers that took their >inputs from mag tapes or card readers and sent their output to printers or >other tapes. The human user had lights and switches. By the 1960s most >computers had a console terminal but even so the interaction tended to
be MOUNT CHECK FORM XYZ123 IN PRINTER, not anything complex.
I realize times have changed, viz, the Star Trek program, but in the era
when COBOL was designed the goal was to keep the expensive computer doing >work, not hanging around waiting for someone to type something.
John Levine <johnl@taugh.com> writes:
[...]
COBOL is by design, really really verbose, e.g. what we would write as[...]
tg = kb + ro
is
ADD KICK-BACK TO RAKE-OFF GIVING TOTAL-GRAFT.
Or:
COMPUTE TOTAL-GRAPH = KICK-BACK + RAKE-OFF
or even:
COMPUTE TG = KB + RO
The use of verbose names like KICK-BACK rather than overly abbreviated
names like kb is not a feature of the language, though it may be more idiomatic in Cobol than in most other languages. I wouldn't use "tg",
"kb", and "ro" in any language unless they were well known abbreviations
in the problem domain (or very localized).
COBOL was designed for computers that took
their inputs from mag tapes or card readers and sent their output to
printers or other tapes.
I see that IBM has JSON GENERATE and JSON PARSE for just this situation.
Even in the mid 60's, burroughs cobol supported 'ACCEPT' and 'DISPLAY'
verbs.
COBOL is exceptionally verbose and un-expressive. It makes elementary
logic very long-winded. I don't think it was specifically designed to
make simple programming tasks look like vast intellectual feats to
managers who don't understand what their staff are doing, but it does
that job quite well.
On Sat, 24 Aug 2024 17:33:29 -0000 (UTC), John Levine wrote:
COBOL was designed for computers that took
their inputs from mag tapes or card readers and sent their output to
printers or other tapes.
Precisely my point. That left it unprepared for the coming of relational >databases and SQL. And indeed interactive computing in business use.
I see that IBM has JSON GENERATE and JSON PARSE for just this situation.
Not standard COBOL though, is it?
But then, COBOL was never quite IBM’s thing ...
On Mon, 26 Aug 2024 14:54:52 GMT, Scott Lurndal wrote:
Even in the mid 60's, burroughs cobol supported 'ACCEPT' and 'DISPLAY'
verbs.
How exciting. That works fine for one terminal; what if you have to work
with several?
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
But then, COBOL was never quite IBM’s thing ...
Uh, on what planet? IBM has had COBOL on their mainframes since the
705 III.
On Thu, 29 Aug 2024 01:12:23 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
But then, COBOL was never quite IBM’s thing ...
Uh, on what planet? IBM has had COBOL on their mainframes since the
705 III.
Umm, three-digit IBM model numbers were vacuum-tube machines, not >transistorized. COBOL dates from the transistor era.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 29 Aug 2024 01:12:23 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
But then, COBOL was never quite IBM’s thing ...
Uh, on what planet? IBM has had COBOL on their mainframes since
the 705 III.
Umm, three-digit IBM model numbers were vacuum-tube machines, not >transistorized. COBOL dates from the transistor era.
As usual, you are incorrect. The Univac I was a vacuum tube
machine (valves for the right-ponders) and was used for COBOL
development (via FLOW-MATIC) by Admiral Hopper (whom I met
at ACM '80).
On Fri, 30 Aug 2024 14:28:17 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:=20
On Thu, 29 Aug 2024 01:12:23 -0000 (UTC), John Levine wrote:
=20
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
=20
But then, COBOL was never quite IBM=C3=A2=E2=82=AC=E2=84=A2s thing ...=
=20=20
Uh, on what planet? IBM has had COBOL on their mainframes since
the 705 III. =20
Umm, three-digit IBM model numbers were vacuum-tube machines, not=20
transistorized. COBOL dates from the transistor era. =20
As usual, you are incorrect. The Univac I was a vacuum tube
machine (valves for the right-ponders) and was used for COBOL
development (via FLOW-MATIC) by Admiral Hopper (whom I met
at ACM '80).
FLOW-MATIC influenced COBOL, but it's not the same language as COBOL.
Which does not mean that COBOL was not implemented on IBM 705 m3.=20
Unlike majority of posters in this group, John tends to be correct about >facts.
It would not surprise me if COBOL compiler was implemented and tested on
7080 then, while still on 7080, ported to emulated 705 and then sold to
users of real 705.
On Fri, 30 Aug 2024 14:28:17 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 29 Aug 2024 01:12:23 -0000 (UTC), John Levine wrote:As usual, you are incorrect. The Univac I was a vacuum tube
According to Lawrence D'Oliveiro <ldo@nz.invalid>:Umm, three-digit IBM model numbers were vacuum-tube machines, not
But then, COBOL was never quite IBM’s thing ...Uh, on what planet? IBM has had COBOL on their mainframes since
the 705 III.
transistorized. COBOL dates from the transistor era.
machine (valves for the right-ponders) and was used for COBOL
development (via FLOW-MATIC) by Admiral Hopper (whom I met
at ACM '80).
FLOW-MATIC influenced COBOL, but it's not the same language as COBOL.
Which does not mean that COBOL was not implemented on IBM 705 m3.
Unlike majority of posters in this group, John tends to be correct about facts.
It would not surprise me if COBOL compiler was implemented and tested on
7080 then, while still on 7080, ported to emulated 705 and then sold to
users of real 705.
On Fri, 30 Aug 2024 14:28:17 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 29 Aug 2024 01:12:23 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
But then, COBOL was never quite IBM’s thing ...
Uh, on what planet? IBM has had COBOL on their mainframes since
the 705 III.
Umm, three-digit IBM model numbers were vacuum-tube machines, not
transistorized. COBOL dates from the transistor era.
As usual, you are incorrect. The Univac I was a vacuum tube
machine (valves for the right-ponders) and was used for COBOL
development (via FLOW-MATIC) by Admiral Hopper (whom I met
at ACM '80).
FLOW-MATIC influenced COBOL, but it's not the same language as COBOL.
Which does not mean that COBOL was not implemented on IBM 705 m3.
According to Michael S <already5chosen@yahoo.com>:
On Fri, 30 Aug 2024 14:28:17 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 29 Aug 2024 01:12:23 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
But then, COBOL was never quite IBM’s thing ...
Uh, on what planet? IBM has had COBOL on their mainframes since
the 705 III.
Umm, three-digit IBM model numbers were vacuum-tube machines, not
transistorized. COBOL dates from the transistor era.
As usual, you are incorrect. The Univac I was a vacuum tube
machine (valves for the right-ponders) and was used for COBOL
development (via FLOW-MATIC) by Admiral Hopper (whom I met
at ACM '80).
FLOW-MATIC influenced COBOL, but it's not the same language as COBOL.
Which does not mean that COBOL was not implemented on IBM 705 m3.
In the unlikely event anyone cares, here's the manual:
https://bitsavers.org/pdf/ibm/7080/J28-6177-3_IBM_705_7080_Programming_Systems_COBOL_Additional_Specifications_Apr64.pdf
I can easily believe they wrote COBOL on the 7080 and then backported it to the 705, but so what?
The original question whether "COBOL was never quite IBM's thing" and it is obvious to
anyone who spends five minutes looking that they supported it up and down the product
lines. There was even COBOL for the 1401 which is pretty amazing considering how tiny
a 1401 was and it ran in 4000 characters of core. You needed tapes or a disk but even so.
VAX Fortran77 and other compilers and tools were developed concurrently
with VAX hardware on the PDP-11 but emitting VAX instructions.
It would not surprise me if COBOL compiler was implemented and tested on
7080 then, while still on 7080, ported to emulated 705 and then sold to
users of real 705.
On Fri, 30 Aug 2024 12:24:35 -0400, EricP wrote:
VAX Fortran77 and other compilers and tools were developed concurrently
with VAX hardware on the PDP-11 but emitting VAX instructions.
DEC was quite fond of BLISS at the time. Its high-performance “Fortran
IV Plus” compiler for the PDP-11 was written in BLISS.
Trouble is, they were not able to get a decent BLISS compiler to fit
within the limitations of the PDP-11. So the Fortran IV Plus compiler
had to be built on a PDP-10.
As I recall, IBM wasn't part of CODASYL, and had no part in COBOL development. So it had the usual _NIH_ attitude and was trying to
push PL/I as its all-singing, all-dancing language for both business
and scientific use, for some time.
Imagine trying to fit LLVM or GCC into a PDP/11 address space.
They did later try to promote PL/1 as "the language for everything,"
Every typo correction must include at least one additional typo.
IF one wanted to raise an FP or decimal value to an integer power
by repeated multiplies and had to roll your own routine, then what
is the optimal way to do so?
EricP <ThatWouldBeTelling@thevillage.com> writes:
IF one wanted to raise an FP or decimal value to an integer power
by repeated multiplies and had to roll your own routine, then what
is the optimal way to do so?
A harder problem than most people expect. Covered in The Art of
Computer Programming, vol 2, "The Evaluation of Powers".
In practical terms, repeated squaring and optionally multiplying
is just fine. But it isn't always optimal.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 54:57:56 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,420 |
| Posted today: | 1 |