Discussion:
Never say a kind word
(too old to reply)
J. Clarke
2020-02-13 23:58:59 UTC
Permalink
Said something nice about COBOL a couple of days ago.

Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.

Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.

But I am once again reminded of just how primitive that system is.
Peter Flass
2020-02-14 01:13:00 UTC
Permalink
Post by J. Clarke
Said something nice about COBOL a couple of days ago.
Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.
Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.
But I am once again reminded of just how primitive that system is.
?
--
Pete
Charlie Gibbs
2020-02-14 16:49:36 UTC
Permalink
Post by J. Clarke
Said something nice about COBOL a couple of days ago.
Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.
Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.
But I am once again reminded of just how primitive that system is.
Ah, the good old days, when "give a cryptic message and die" was
standard behaviour. In this modern age, programs put up a pretty
box that says "Something went wrong" and then die.

How far we've come.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
d***@gmail.com
2020-02-14 19:13:26 UTC
Permalink
Post by Charlie Gibbs
Ah, the good old days, when "give a cryptic message and die" was
standard behaviour. In this modern age, programs put up a pretty
box that says "Something went wrong" and then die.
...followed by several more pretty boxes saying "are you sure you want to die? (Y/N)"...
d***@gmail.com
2020-02-14 19:15:56 UTC
Permalink
At least in the old days you got back a mangled stack of cards and a hunk of 14x11 green-bar paper... something you could set fire to...
J. Clarke
2020-02-15 00:00:58 UTC
Permalink
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.

On the following program there were "unresolved externals":

PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END

No idea what line was generating the calls or where the library was
that would satisfy them.
Dan Espen
2020-02-15 03:36:04 UTC
Permalink
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?

Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
--
Dan Espen
J. Clarke
2020-02-15 13:42:10 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
John Levine
2020-02-15 15:56:07 UTC
Permalink
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
--
Regards,
John Levine, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
J. Clarke
2020-02-15 16:38:27 UTC
Permalink
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
Dan Espen
2020-02-15 19:30:09 UTC
Permalink
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
--
Dan Espen
J. Clarke
2020-02-15 22:12:49 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
Dan Espen
2020-02-16 00:05:10 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
With the C LE compiler you can ask the compiler to do it's externs
mixed case, full name (more than 8 characters), or you can force all
externs to 8 chars upper case. The linker has to be informed.

Of course passwords should never be in JCL, but I've seen people do it.

JCL can directly access Unix files. Look at DD PATH=.
So, there are valid reasons to have lower case in JCL.

On another project our JCL was parsed to create runbooks.
Comments in the JCL generated things like run name, purpose,
run frequency. End user documentation just works better mixed case.

But I strongly advise against using JCL. I had CLISTS and EXECS to do
all our compiles. Of course you need JCL to start a CLIST, but the
CLIST/EXEC can do things JCL never even dreamed of.
--
Dan Espen
J. Clarke
2020-02-16 02:01:23 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
With the C LE compiler you can ask the compiler to do it's externs
mixed case, full name (more than 8 characters), or you can force all
externs to 8 chars upper case. The linker has to be informed.
There was no C code.
Post by Dan Espen
Of course passwords should never be in JCL, but I've seen people do it.
JCL can directly access Unix files. Look at DD PATH=.
So, there are valid reasons to have lower case in JCL.
There are no Unix files in use by any system with which I am
associated. Perhaps someone in the company uses them, if so I have
been unable to idendify them.
Post by Dan Espen
On another project our JCL was parsed to create runbooks.
Comments in the JCL generated things like run name, purpose,
run frequency. End user documentation just works better mixed case.
But I strongly advise against using JCL. I had CLISTS and EXECS to do
all our compiles. Of course you need JCL to start a CLIST, but the
CLIST/EXEC can do things JCL never even dreamed of.
OK, you get yourself hired as the IT honcho at my employer and then
you can do it that way.
Peter Flass
2020-02-17 15:11:03 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
With the C LE compiler you can ask the compiler to do it's externs
mixed case, full name (more than 8 characters), or you can force all
externs to 8 chars upper case. The linker has to be informed.
Of course passwords should never be in JCL, but I've seen people do it.
JCL can directly access Unix files. Look at DD PATH=.
So, there are valid reasons to have lower case in JCL.
On another project our JCL was parsed to create runbooks.
Comments in the JCL generated things like run name, purpose,
run frequency. End user documentation just works better mixed case.
But I strongly advise against using JCL. I had CLISTS and EXECS to do
all our compiles. Of course you need JCL to start a CLIST, but the
CLIST/EXEC can do things JCL never even dreamed of.
I must be the only person in the world who likes JCL.
--
Pete
J. Clarke
2020-02-17 15:32:14 UTC
Permalink
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
Post by Peter Flass
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
With the C LE compiler you can ask the compiler to do it's externs
mixed case, full name (more than 8 characters), or you can force all
externs to 8 chars upper case. The linker has to be informed.
Of course passwords should never be in JCL, but I've seen people do it.
JCL can directly access Unix files. Look at DD PATH=.
So, there are valid reasons to have lower case in JCL.
On another project our JCL was parsed to create runbooks.
Comments in the JCL generated things like run name, purpose,
run frequency. End user documentation just works better mixed case.
But I strongly advise against using JCL. I had CLISTS and EXECS to do
all our compiles. Of course you need JCL to start a CLIST, but the
CLIST/EXEC can do things JCL never even dreamed of.
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Charlie Gibbs
2020-02-18 01:14:59 UTC
Permalink
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
Post by Peter Flass
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
"The purpose of JCL is to give you something to debug
once you've gotten your program working." -- me
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
h***@bbs.cpcn.com
2020-02-18 18:57:52 UTC
Permalink
Post by J. Clarke
Post by Peter Flass
I must be the only person in the world who likes JCL.
I found it a very powerful too to control program
execution and I/O devices. MVS (OS) JCL was largely
device independent. This made it easy to convert
say a hard copy printer to a disk file without
touching the program. Or, to upgrade hardware
devices without touching the program. For instance,
programs I wrote 35 years ago are untouched because
hardware changes (e.g. new disk drives) were handled
via JCL.

Modern technology has streamlined a lot of tasks
once required in JCL in earlier days. For instance,
I think everything is done on disk nowadays, no more
mag tape.

In the old days we had to be very careful about block sizing
and space allocation--not too small but not too much either.
Not as critical today and also more automated. Also, in
the old days we had to know what specific model of disk
or tape drive we were using, not so today.
Post by J. Clarke
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Yes, Fred Books gave a talk and said he didn't like it.

IBM grossly underestimated the requirements for operating
systems for its S/360 and ended up rushing like crazy to
get something available so the computer could be shipped.
This is documented in the S/360 history.
Peter Flass
2020-02-18 22:19:09 UTC
Permalink
Post by h***@bbs.cpcn.com
Post by J. Clarke
Post by Peter Flass
I must be the only person in the world who likes JCL.
I found it a very powerful too to control program
execution and I/O devices. MVS (OS) JCL was largely
device independent.
Usually. A lot of the complexity of the DD statement is that it allows the
user to specify a lot of device-dependent options if wanted (usually not
wanted). For example, you can have the program skip bad blocks on tape
instead giving an error, specify the transmission code for a terminal
(IIRC), the density of a tape, etc.
Post by h***@bbs.cpcn.com
of ddThis made it easy to convert
say a hard copy printer to a disk file without
touching the program. Or, to upgrade hardware
devices without touching the program. For instance,
programs I wrote 35 years ago are untouched because
hardware changes (e.g. new disk drives) were handled
via JCL.
Modern technology has streamlined a lot of tasks
once required in JCL in earlier days. For instance,
I think everything is done on disk nowadays, no more
mag tape.
In the old days we had to be very careful about block sizing
and space allocation--not too small but not too much either.
Not as critical today and also more automated. Also, in
the old days we had to know what specific model of disk
or tape drive we were using, not so today.
Post by J. Clarke
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Yes, Fred Books gave a talk and said he didn't like it.
IBM grossly underestimated the requirements for operating
systems for its S/360 and ended up rushing like crazy to
get something available so the computer could be shipped.
This is documented in the S/360 history.
--
Pete
J. Clarke
2020-02-19 00:35:57 UTC
Permalink
Post by h***@bbs.cpcn.com
Post by J. Clarke
Post by Peter Flass
I must be the only person in the world who likes JCL.
I found it a very powerful too to control program
execution and I/O devices. MVS (OS) JCL was largely
device independent. This made it easy to convert
say a hard copy printer to a disk file without
touching the program. Or, to upgrade hardware
devices without touching the program. For instance,
programs I wrote 35 years ago are untouched because
hardware changes (e.g. new disk drives) were handled
via JCL.
Unless you're writing device drivers your program shouldn't have to
know anything about disk drives except some kind of identifier.
Post by h***@bbs.cpcn.com
Modern technology has streamlined a lot of tasks
once required in JCL in earlier days. For instance,
I think everything is done on disk nowadays, no more
mag tape.
However tape is emulated and in some shops the Powers That Be want you
to use it.
Post by h***@bbs.cpcn.com
In the old days we had to be very careful about block sizing
and space allocation--not too small but not too much either.
Not as critical today and also more automated. Also, in
the old days we had to know what specific model of disk
or tape drive we were using, not so today.
Today block sizing and space allocation aren't something that
application software worries about, it never should have had to. But
on Z/OS you still have to tell it a lot of details that aren't needed
on Windows or Unix or just about any other operating system.
Post by h***@bbs.cpcn.com
Post by J. Clarke
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Yes, Fred Books gave a talk and said he didn't like it.
IBM grossly underestimated the requirements for operating
systems for its S/360 and ended up rushing like crazy to
get something available so the computer could be shipped.
This is documented in the S/360 history.
Dan Espen
2020-02-19 00:38:17 UTC
Permalink
Post by h***@bbs.cpcn.com
Post by Peter Flass
I must be the only person in the world who likes JCL.
I found it a very powerful too to control program
execution and I/O devices. MVS (OS) JCL was largely
device independent. This made it easy to convert
say a hard copy printer to a disk file without
touching the program. Or, to upgrade hardware
devices without touching the program. For instance,
programs I wrote 35 years ago are untouched because
hardware changes (e.g. new disk drives) were handled
via JCL.
Modern technology has streamlined a lot of tasks
once required in JCL in earlier days. For instance,
I think everything is done on disk nowadays, no more
mag tape.
In the old days we had to be very careful about block sizing
and space allocation--not too small but not too much either.
Not as critical today and also more automated. Also, in
the old days we had to know what specific model of disk
or tape drive we were using, not so today.
Nowadays, the correct value is BLKSIZE=0.
The system determines the blocksize (SDB).
--
Dan Espen
Peter Flass
2020-02-18 22:19:04 UTC
Permalink
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
Post by Peter Flass
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
With the C LE compiler you can ask the compiler to do it's externs
mixed case, full name (more than 8 characters), or you can force all
externs to 8 chars upper case. The linker has to be informed.
Of course passwords should never be in JCL, but I've seen people do it.
JCL can directly access Unix files. Look at DD PATH=.
So, there are valid reasons to have lower case in JCL.
On another project our JCL was parsed to create runbooks.
Comments in the JCL generated things like run name, purpose,
run frequency. End user documentation just works better mixed case.
But I strongly advise against using JCL. I had CLISTS and EXECS to do
all our compiles. Of course you need JCL to start a CLIST, but the
CLIST/EXEC can do things JCL never even dreamed of.
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Has everything but loops.
--
Pete
Dan Espen
2020-02-19 00:46:26 UTC
Permalink
Post by Peter Flass
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
Post by Peter Flass
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
With the C LE compiler you can ask the compiler to do it's externs
mixed case, full name (more than 8 characters), or you can force all
externs to 8 chars upper case. The linker has to be informed.
Of course passwords should never be in JCL, but I've seen people do it.
JCL can directly access Unix files. Look at DD PATH=.
So, there are valid reasons to have lower case in JCL.
On another project our JCL was parsed to create runbooks.
Comments in the JCL generated things like run name, purpose,
run frequency. End user documentation just works better mixed case.
But I strongly advise against using JCL. I had CLISTS and EXECS to do
all our compiles. Of course you need JCL to start a CLIST, but the
CLIST/EXEC can do things JCL never even dreamed of.
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Has everything but loops.
Missing simple assignment. (SET is not simple).
Doesn't communicate well with the launched program.
Doesn't run in the foreground.
Still can't simply create or replace a dataset.
--
Dan Espen
Kerr-Mudd,John
2020-02-19 11:18:32 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
[]
Post by Dan Espen
Post by Peter Flass
Post by J. Clarke
Post by Peter Flass
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Has everything but loops.
Missing simple assignment. (SET is not simple).
Doesn't communicate well with the launched program.
Doesn't run in the foreground.
Still can't simply create or replace a dataset.
That last was IEBGENER's job.
IEFBR14 - what a program!
--
Bah, and indeed, Humbug.
Dan Espen
2020-02-19 14:17:14 UTC
Permalink
Post by Peter Flass
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
[]
Post by Peter Flass
Post by J. Clarke
Post by Peter Flass
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming
language.
Has everything but loops.
Missing simple assignment. (SET is not simple). Doesn't communicate
well with the launched program. Doesn't run in the foreground.
Still can't simply create or replace a dataset.
That last was IEBGENER's job. IEFBR14 - what a program!
Actually, IEBGENER does a really poor job of copying, you probably meant
IEFBR14 but that only works when you know the dataset you want to
create/replace already exists.

I've most often seen a step that runs IDCAMS. The IDCAMS control cards
do a delete then set the return code to zero. Really ugly.

So, want to hide this mess? Just create a PROC called DELETE, pass it a
parm for the dataset to delete. Now you only have the problem that
you can only delete one dataset at a time this way so you have to invoke
IDCAMS over and over for multiple datasets. You also have to figure out
how to get the passed in parm into the control cards. (Fortunately,
that has become possible, if not simple.)
--
Dan Espen
Kerr-Mudd,John
2020-02-19 18:04:04 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
[]
Post by Peter Flass
Post by J. Clarke
Post by Peter Flass
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming
language.
Has everything but loops.
Missing simple assignment. (SET is not simple). Doesn't
communicate
Post by Dan Espen
well with the launched program. Doesn't run in the foreground.
Still can't simply create or replace a dataset.
That last was IEBGENER's job. IEFBR14 - what a program!
Actually, IEBGENER does a really poor job of copying, you probably meant
IEFBR14 but that only works when you know the dataset you want to
create/replace already exists.
I don't recall properly; it was nearly 40 years ago I last used this
stuff and barely got to grips with JCL; enough to compile and run COBOL
programs; Though I do recall doing something fiendishly cunningly with
conditionally executing programs with return codes. It seemed awfully
complicated for what I wanted.
Post by Dan Espen
I've most often seen a step that runs IDCAMS. The IDCAMS control cards
do a delete then set the return code to zero. Really ugly.
[]

indeed.
--
Bah, and indeed, Humbug.
Peter Flass
2020-02-19 23:29:40 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:03 -0700, Peter Flass
Post by Peter Flass
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
With LE you can also go wrong by giving bad CASE parms to the compiler
or linker.
All JCL used is upper case, always. No userid or password in the
code.
With the C LE compiler you can ask the compiler to do it's externs
mixed case, full name (more than 8 characters), or you can force all
externs to 8 chars upper case. The linker has to be informed.
Of course passwords should never be in JCL, but I've seen people do it.
JCL can directly access Unix files. Look at DD PATH=.
So, there are valid reasons to have lower case in JCL.
On another project our JCL was parsed to create runbooks.
Comments in the JCL generated things like run name, purpose,
run frequency. End user documentation just works better mixed case.
But I strongly advise against using JCL. I had CLISTS and EXECS to do
all our compiles. Of course you need JCL to start a CLIST, but the
CLIST/EXEC can do things JCL never even dreamed of.
I must be the only person in the world who likes JCL.
I don't think the people who _created_ JCL like JCL. I've heard it
admitted that they should have treated it as a programming language.
Has everything but loops.
Missing simple assignment. (SET is not simple).
Doesn't communicate well with the launched program.
PARM=
Post by Dan Espen
Doesn't run in the foreground.
Still can't simply create or replace a dataset.
IEFBR14
--
Pete
Dan Espen
2020-02-17 18:25:13 UTC
Permalink
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.

Nasty stuff.

IBM did a much better stab at it, when they created OCL for the S/3
line.

A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.

I still haven't figured out IBM's approach on z/OS.
Their current JCL command language insists that all commands begin
with '//' and they do support Unix shell on the same box.
But '#!" must be surrounded by JCL.

So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds
"#!" instead of "//X JOB", they should just start the script.

They have all the code that would allow the internal reader to read UNIX
type scripts, they just haven't pasted it together correctly.
--
Dan Espen
J. Clarke
2020-02-17 19:00:42 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I still haven't figured out IBM's approach on z/OS.
Their current JCL command language insists that all commands begin
with '//' and they do support Unix shell on the same box.
But '#!" must be surrounded by JCL.
So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds
"#!" instead of "//X JOB", they should just start the script.
They have all the code that would allow the internal reader to read UNIX
type scripts, they just haven't pasted it together correctly.
What's it using for input? What's it using for output? What datasets
is it accessing?
Dan Espen
2020-02-17 22:41:55 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I still haven't figured out IBM's approach on z/OS.
Their current JCL command language insists that all commands begin
with '//' and they do support Unix shell on the same box.
But '#!" must be surrounded by JCL.
So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds
"#!" instead of "//X JOB", they should just start the script.
They have all the code that would allow the internal reader to read UNIX
type scripts, they just haven't pasted it together correctly.
What's it using for input? What's it using for output? What datasets
is it accessing?
I think you are trying to make a case for DD cards.

Most UNIX scripts don't need DD cards, files are accessed using the file
names. If you start a UNIX program (or just a C program) when it
attempts to read STDIN or write STDOUT and there is no allocation,
the system does dynamic allocation.
--
Dan Espen
J. Clarke
2020-02-17 23:55:51 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I still haven't figured out IBM's approach on z/OS.
Their current JCL command language insists that all commands begin
with '//' and they do support Unix shell on the same box.
But '#!" must be surrounded by JCL.
So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds
"#!" instead of "//X JOB", they should just start the script.
They have all the code that would allow the internal reader to read UNIX
type scripts, they just haven't pasted it together correctly.
What's it using for input? What's it using for output? What datasets
is it accessing?
I think you are trying to make a case for DD cards.
Most UNIX scripts don't need DD cards, files are accessed using the file
names.
What's the file name? Hint--while the Unix subsystem recognizes
tree-structured directories and the like, that is not the only method
Z/OS uses to recognize files. And what's a "file" anyway? Z/OS
doesn't borrow Unix's conceit that "everything is a file". The
documentation uses the word "dataset", not the word "file". Unix
people think that they're the same. They aren't.
Post by Dan Espen
If you start a UNIX program (or just a C program) when it
attempts to read STDIN or write STDOUT and there is no allocation,
the system does dynamic allocation.
Which system? The JCL processor? To what does it dynamically
allocate? JCL is not designed to be run from a terminal.
Dan Espen
2020-02-18 03:32:46 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your
ways, there are a plethora of command languages, none of them as
primitive as JCL.
I still haven't figured out IBM's approach on z/OS. Their current
JCL command language insists that all commands begin with '//' and
they do support Unix shell on the same box. But '#!" must be
surrounded by JCL.
So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds "#!"
instead of "//X JOB", they should just start the script.
They have all the code that would allow the internal reader to read
UNIX type scripts, they just haven't pasted it together correctly.
What's it using for input? What's it using for output? What
datasets is it accessing?
I think you are trying to make a case for DD cards.
Most UNIX scripts don't need DD cards, files are accessed using the
file names.
What's the file name? Hint--while the Unix subsystem recognizes
tree-structured directories and the like, that is not the only method
Z/OS uses to recognize files. And what's a "file" anyway? Z/OS
doesn't borrow Unix's conceit that "everything is a file". The
documentation uses the word "dataset", not the word "file". Unix
people think that they're the same. They aren't.
I guess I'm one Unix person pretty familiar with IBM's terminology.

I'm having difficulty trying to see conceit in the "everything is a
file" concept. Linux especially puts lots of virtual things into files.
It's pretty cool. Of course sometimes you have to abandon the stream of
bytes concept. There are all kinds of databases for unix systems.
Post by J. Clarke
Post by Dan Espen
If you start a UNIX program (or just a C program) when it attempts to
read STDIN or write STDOUT and there is no allocation, the system does
dynamic allocation.
Which system? The JCL processor? To what does it dynamically
allocate? JCL is not designed to be run from a terminal.
STDOUT will go to SYSOUT='*' if you don't tell it otherwise. STDIN of
course starts out being the command stream.

JCL dpesn't run from a terminal but IBM took another stab when they
designed OCL and it runs fine in the foreground.
--
Dan Espen
Scott Lurndal
2020-02-18 15:17:44 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I still haven't figured out IBM's approach on z/OS.
Their current JCL command language insists that all commands begin
with '//' and they do support Unix shell on the same box.
But '#!" must be surrounded by JCL.
So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds
"#!" instead of "//X JOB", they should just start the script.
They have all the code that would allow the internal reader to read UNIX
type scripts, they just haven't pasted it together correctly.
What's it using for input? What's it using for output? What datasets
is it accessing?
I think you are trying to make a case for DD cards.
Most UNIX scripts don't need DD cards, files are accessed using the file
names.
What's the file name? Hint--while the Unix subsystem recognizes
tree-structured directories and the like, that is not the only method
Z/OS uses to recognize files. And what's a "file" anyway? Z/OS
doesn't borrow Unix's conceit that "everything is a file". The
documentation uses the word "dataset", not the word "file". Unix
people think that they're the same. They aren't.
Oh nonsense. A collection of bytes on disk. That's what both
systems are accessing. The nomenclature matters not. The ease
of access does. Unix, as a stream of bytes, allows the application
to impose any structure on the stream of bytes it likes. Given the existence
of symbolic (and hard) links in the filesystem, there is no possible
use for a DD card in unix.

There is _nothing_ better about the MVS/zOS way.
Post by J. Clarke
Post by Dan Espen
If you start a UNIX program (or just a C program) when it
attempts to read STDIN or write STDOUT and there is no allocation,
the system does dynamic allocation.
Which system? The JCL processor? To what does it dynamically
allocate? JCL is not designed to be run from a terminal.
Which again, was a failing on IBMs part. The Burroughs MCP commands
were designed to be run from a card reader, command file (WFL),
operator console or CANDE (timesharing) session or from a programmatic
call to the MCP (SPO message).

?EXECUTE APP; FILE INPUT=FRED CRD; FILE PRINTER=SHORT/OUTPUT PRN FORM

Executes the named application and assigns the internal filename
INPUT to the card reader (waiting for a deck named FRED) and the
internal filename PRINTER is assigned to the printer named SHORT
with special forms loaded.

If you don't want to go to the printer, but rather a printer backup file on
disk and read the cards from a 80 char record disk file named DECK1:

?EXECUTE APP; FILE INPUT=DECK1 DSK; FILE PRINTER=OUTPUT PBK

There is never a need to manually allocate disk space (which consists
of a sequence of fixed-sized sectors; none of the CKD nonsense).
Quadibloc
2020-02-18 20:24:05 UTC
Permalink
Post by Scott Lurndal
Oh nonsense. A collection of bytes on disk. That's what both
systems are accessing. The nomenclature matters not. The ease
of access does. Unix, as a stream of bytes, allows the application
to impose any structure on the stream of bytes it likes. Given the existence
of symbolic (and hard) links in the filesystem, there is no possible
use for a DD card in unix.
There is _nothing_ better about the MVS/zOS way.
I certainly don't recommend OS/360 JCL, as it is extremely complicated and hard
to learn.

But it isn't the only alternative to UNIX.

For example, look at the Michigan Terminal System. There was an operating system
for the System/360 with easy to understand commands. It wasn't as flexible as
UNIX, but it was no more cryptic than DOS.

To compile a FORTRAN program one would issue a command like

$RUN *FORTG INPUT=PROG OUTPUT=PROG.O

for example.

John Savard
J. Clarke
2020-02-19 00:40:46 UTC
Permalink
On Tue, 18 Feb 2020 12:24:05 -0800 (PST), Quadibloc
Post by Quadibloc
Post by Scott Lurndal
Oh nonsense. A collection of bytes on disk. That's what both
systems are accessing. The nomenclature matters not. The ease
of access does. Unix, as a stream of bytes, allows the application
to impose any structure on the stream of bytes it likes. Given the existence
of symbolic (and hard) links in the filesystem, there is no possible
use for a DD card in unix.
There is _nothing_ better about the MVS/zOS way.
I certainly don't recommend OS/360 JCL, as it is extremely complicated and hard
to learn.
But it isn't the only alternative to UNIX.
For example, look at the Michigan Terminal System. There was an operating system
for the System/360 with easy to understand commands. It wasn't as flexible as
UNIX, but it was no more cryptic than DOS.
To compile a FORTRAN program one would issue a command like
$RUN *FORTG INPUT=PROG OUTPUT=PROG.O
for example.
But does it support CICS?

Understand--a mainframe running something that is not Z/OS is an
expensive PC. Z/OS is part of the package. Some of the workloads it
handles were developed on a machine that wasn't much more capable than
an 8086 and now they are running unchanged at many gigahertz with an
operating system that fitted into that tiny machine and was performant
on it.
Peter Flass
2020-02-18 22:19:07 UTC
Permalink
Post by Scott Lurndal
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I still haven't figured out IBM's approach on z/OS.
Their current JCL command language insists that all commands begin
with '//' and they do support Unix shell on the same box.
But '#!" must be surrounded by JCL.
So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds
"#!" instead of "//X JOB", they should just start the script.
They have all the code that would allow the internal reader to read UNIX
type scripts, they just haven't pasted it together correctly.
What's it using for input? What's it using for output? What datasets
is it accessing?
I think you are trying to make a case for DD cards.
Most UNIX scripts don't need DD cards, files are accessed using the file
names.
What's the file name? Hint--while the Unix subsystem recognizes
tree-structured directories and the like, that is not the only method
Z/OS uses to recognize files. And what's a "file" anyway? Z/OS
doesn't borrow Unix's conceit that "everything is a file". The
documentation uses the word "dataset", not the word "file". Unix
people think that they're the same. They aren't.
Oh nonsense. A collection of bytes on disk. That's what both
systems are accessing. The nomenclature matters not. The ease
of access does. Unix, as a stream of bytes, allows the application
to impose any structure on the stream of bytes it likes. Given the existence
of symbolic (and hard) links in the filesystem, there is no possible
use for a DD card in unix.
There is _nothing_ better about the MVS/zOS way.
Here we disagree. I wrote the IO subsystem for Iron Spring PL/I to handle
record-formatted data and buffering doesn’t play well with length-prefixed
records (RECFM=V). Something very simple in zOS becomes complicated. Of
course CKD disk I/O is all emulated in zOS these days, somit’s the OS
that’s doing the work.
Post by Scott Lurndal
Post by J. Clarke
Post by Dan Espen
If you start a UNIX program (or just a C program) when it
attempts to read STDIN or write STDOUT and there is no allocation,
the system does dynamic allocation.
Which system? The JCL processor? To what does it dynamically
allocate? JCL is not designed to be run from a terminal.
Which again, was a failing on IBMs part. The Burroughs MCP commands
were designed to be run from a card reader, command file (WFL),
operator console or CANDE (timesharing) session or from a programmatic
call to the MCP (SPO message).
?EXECUTE APP; FILE INPUT=FRED CRD; FILE PRINTER=SHORT/OUTPUT PRN FORM
Executes the named application and assigns the internal filename
INPUT to the card reader (waiting for a deck named FRED) and the
internal filename PRINTER is assigned to the printer named SHORT
with special forms loaded.
If you don't want to go to the printer, but rather a printer backup file on
?EXECUTE APP; FILE INPUT=DECK1 DSK; FILE PRINTER=OUTPUT PBK
There is never a need to manually allocate disk space (which consists
of a sequence of fixed-sized sectors; none of the CKD nonsense).
Sequence or checkerboarded? Pre-allocating disk space is an attempt to keep
files contiguous.
--
Pete
Scott Lurndal
2020-02-19 16:46:22 UTC
Permalink
Post by Peter Flass
Post by Scott Lurndal
Post by J. Clarke
What's the file name? Hint--while the Unix subsystem recognizes
tree-structured directories and the like, that is not the only method
Z/OS uses to recognize files. And what's a "file" anyway? Z/OS
doesn't borrow Unix's conceit that "everything is a file". The
documentation uses the word "dataset", not the word "file". Unix
people think that they're the same. They aren't.
Oh nonsense. A collection of bytes on disk. That's what both
systems are accessing. The nomenclature matters not. The ease
of access does. Unix, as a stream of bytes, allows the application
to impose any structure on the stream of bytes it likes. Given the existence
of symbolic (and hard) links in the filesystem, there is no possible
use for a DD card in unix.
There is _nothing_ better about the MVS/zOS way.
Here we disagree. I wrote the IO subsystem for Iron Spring PL/I to handle
record-formatted data and buffering doesn’t play well with length-prefixed
records (RECFM=V). Something very simple in zOS becomes complicated. Of
course CKD disk I/O is all emulated in zOS these days, somit’s the OS
that’s doing the work.
Unix doesn't have (and never has had) "length-prefixed records".

There is _no_ structure, simply a stream of bytes to which random
access is provided.
Post by Peter Flass
Post by Scott Lurndal
Post by J. Clarke
Post by Dan Espen
If you start a UNIX program (or just a C program) when it
attempts to read STDIN or write STDOUT and there is no allocation,
the system does dynamic allocation.
Which system? The JCL processor? To what does it dynamically
allocate? JCL is not designed to be run from a terminal.
Which again, was a failing on IBMs part. The Burroughs MCP commands
were designed to be run from a card reader, command file (WFL),
operator console or CANDE (timesharing) session or from a programmatic
call to the MCP (SPO message).
?EXECUTE APP; FILE INPUT=FRED CRD; FILE PRINTER=SHORT/OUTPUT PRN FORM
Executes the named application and assigns the internal filename
INPUT to the card reader (waiting for a deck named FRED) and the
internal filename PRINTER is assigned to the printer named SHORT
with special forms loaded.
If you don't want to go to the printer, but rather a printer backup file on
?EXECUTE APP; FILE INPUT=DECK1 DSK; FILE PRINTER=OUTPUT PBK
There is never a need to manually allocate disk space (which consists
of a sequence of fixed-sized sectors; none of the CKD nonsense).
Sequence or checkerboarded? Pre-allocating disk space is an attempt to keep
files contiguous.
Burroughs files had one or more areas (up to 100). An area was some multiple
of the files record size multiplied by the blocking factor. Each area
was mapped to a contiguous set of sectors on a device (areas could easily be
allocated across multiple devices within a single file).

As the basic allocation size was a sector (100 bytes each on legacy DISK
media, 180 bytes each on PACK media (Large systems, e.g. B6500 et al, also
used 180 byte sectors), extent-based allocation did lead to fragmentation;
the operator could use the SQ (Squash) and SQP (Squash Pack) command to
initiate a defragmentation operation. I don't recall ever needing to
squash any of our packs during 8 years of MCP development, so it was
pretty rare.

If there was need to ensure that the entire file was contiguously allocated
on disk, it was certainly possible, but was very rarely used.

All 100-byte (DISK) media on a system was considered a single filesystem (DISK),
which could be divided into 8 allocation groups at system initailization;
the application could specify which of the allocation groups to use (one
was reserved for the MCP, for log files etc).

180-byte (PACK) media were grouped into one or more pack Families. The family
name was used when creating and accessing the files (much like a directory
name). A given family could consist of one or more packs; in the MCP
department, we had a family for the MCP source, one for the intermediate
object files, and several for other development activities. Additional
space could be added to a family at any time with a simple operator
command (assuming handy spare disk drive hardware and/or removable media).

Copying files was a simple as

?MOVE AND SET (SUMMARY, COMPARE) === FROM OLDFRED(PACK) TO FRED(PACK)

would move every file from the pack OLDFRED to the pack FRED.

or

?COPY AND SET (COMPARE) === from FRED(PACK) TO FREDBK(TAPE)


or

?PFM CRDDPK INDECK FRED/DECK12 80 9

would copy the card deck identified by the name INDECK to the file DECK12
on family FRED (with 80 byte records, 9 records per block; 720 bytes or
four 180-byte sectors).

THe card deck would have been introduced with a control card:

?DATA INDECK
<cards in deck>
?END
Bob Eager
2020-02-17 21:03:13 UTC
Permalink
Post by Dan Espen
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
Strangely, most of my bigger scripts on UNIX are written in REXX.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Dan Espen
2020-02-17 22:54:19 UTC
Permalink
Post by Bob Eager
Post by Dan Espen
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
Strangely, most of my bigger scripts on UNIX are written in REXX.
Yep, that's strange, but I know REXX pretty well, and I think that's
fine.

I did a quick search and found REXX/Tk and REXX DW (lightweight GUI).
I found Tk creates some really ugly GUIs. DW is Windows/Gtk+.
I did not find REXX/Qt. I prefer Qt to Gtk.

I'm really not a fan of bash,sh,etc. I think they are traps.
The shell languages can do a simple job well enough but as the shell
script grows all kinds of problems can show up.

I used to prefer Perl, but Python has more libraries so Python has
become my default language.
--
Dan Espen
Bob Eager
2020-02-17 23:50:35 UTC
Permalink
Post by Dan Espen
Post by Bob Eager
Post by Dan Espen
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive
as JCL.
Strangely, most of my bigger scripts on UNIX are written in REXX.
Yep, that's strange, but I know REXX pretty well, and I think that's
fine.
I did a quick search and found REXX/Tk and REXX DW (lightweight GUI).
I found Tk creates some really ugly GUIs. DW is Windows/Gtk+.
I did not find REXX/Qt. I prefer Qt to Gtk.
I use it for non GUI stuff. I have Regina as the interpreter, plus the
usual system utility library. Also REXX/Curl and REXX/Math. I haven't
needed anything else.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Ahem A Rivet's Shot
2020-02-18 12:33:30 UTC
Permalink
On Mon, 17 Feb 2020 17:54:19 -0500
Post by Dan Espen
I'm really not a fan of bash,sh,etc. I think they are traps.
They're great for one-off tasks like "run this test repeatedly until
it fails" or "dig out this set of files and ..." and I like that they are
more than powerful enough to do the jobs they're good for rather than being
under-powered and awkward even though that leads to temptation.
Post by Dan Espen
The shell languages can do a simple job well enough but as the shell
script grows all kinds of problems can show up.
Yep then a real programming language is usually in order.
Post by Dan Espen
I used to prefer Perl, but Python has more libraries so Python has
become my default language.
Those two spring to mind, I too have come to prefer Python although
from time to time I do miss the upside down data processing pipelines made
out of map and grep that are so convenient in Perl.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Scott Lurndal
2020-02-18 15:05:22 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
Or any of the Burroughs MCP's which were far friendlier and easier
to use than JCL.
Peter Flass
2020-02-18 22:19:05 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I do a lot with Linux. BASH is OK for simple stuff, but I find the plethora
of special characters confusing. Builtin functions for e.g. parsing a
filename would have been much clearer. For anything complicated I use Rexx.
Post by Dan Espen
I still haven't figured out IBM's approach on z/OS.
Their current JCL command language insists that all commands begin
with '//' and they do support Unix shell on the same box.
But '#!" must be surrounded by JCL.
So, why haven't they supported "#!filepath" as a valid
extension/replacement for JCL? If the internal reader finds
"#!" instead of "//X JOB", they should just start the script.
They have all the code that would allow the internal reader to read UNIX
type scripts, they just haven't pasted it together correctly.
--
Pete
Scott Lurndal
2020-02-19 16:22:31 UTC
Permalink
Post by Peter Flass
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I do a lot with Linux. BASH is OK for simple stuff, but I find the plethora
of special characters confusing. Builtin functions for e.g. parsing a
filename would have been much clearer. For anything complicated I use Rexx.
pathname='/path1/path2/path3/path4/file1.cob'

directory=$(dirname $pathname)
filename=$(basename $pathname)
file_sans_type=$(basename ${pathame} .cob}

How much easier can it get?
Ahem A Rivet's Shot
2020-02-19 16:53:09 UTC
Permalink
On Wed, 19 Feb 2020 16:22:31 GMT
Post by Scott Lurndal
pathname='/path1/path2/path3/path4/file1.cob'
directory=$(dirname $pathname)
filename=$(basename $pathname)
file_sans_type=$(basename ${pathame} .cob}
How much easier can it get?
There's one missing (as in not implemented) that would be handy.

file_type = `extname "$filename"`

So that the last can be

file_sans_type=`basename "$pathname" "$file_tyue"`
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Scott Lurndal
2020-02-19 17:31:05 UTC
Permalink
Post by Ahem A Rivet's Shot
On Wed, 19 Feb 2020 16:22:31 GMT
Post by Scott Lurndal
pathname='/path1/path2/path3/path4/file1.cob'
directory=$(dirname $pathname)
filename=$(basename $pathname)
file_sans_type=$(basename ${pathame} .cob}
How much easier can it get?
There's one missing (as in not implemented) that would be handy.
file_type = `extname "$filename"`
So that the last can be
file_sans_type=`basename "$pathname" "$file_tyue"`
One can do it the other way around:

$ echo ${filename##${file_sans_type}}
.cob

or

$ echo $filename | sed -e 's/.*\.\(.*\)/\1/'
cob
Dan Espen
2020-02-19 18:20:56 UTC
Permalink
Post by Scott Lurndal
Post by Peter Flass
Post by Dan Espen
Post by Peter Flass
I must be the only person in the world who likes JCL.
I'd guess that is pretty close to accurate.
Nasty stuff.
IBM did a much better stab at it, when they created OCL for the S/3
line.
A few minutes on a UNIX system should show you the error of your ways,
there are a plethora of command languages, none of them as primitive as
JCL.
I do a lot with Linux. BASH is OK for simple stuff, but I find the plethora
of special characters confusing. Builtin functions for e.g. parsing a
filename would have been much clearer. For anything complicated I use Rexx.
pathname='/path1/path2/path3/path4/file1.cob'
directory=$(dirname $pathname)
filename=$(basename $pathname)
file_sans_type=$(basename ${pathame} .cob}
How much easier can it get?
Try that with a COBOL filename "file$1.cob".
--
Dan Espen
Peter Flass
2020-02-15 23:46:47 UTC
Permalink
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
Check the JCL used to compile the production code for the libraries you
need. Are you using the same compiler? Version?
--
Pete
J. Clarke
2020-02-16 02:02:00 UTC
Permalink
On Sat, 15 Feb 2020 16:46:47 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
On Sat, 15 Feb 2020 15:56:07 -0000 (UTC), John Levine
Post by John Levine
Post by J. Clarke
Post by J. Clarke
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
PRINT and STOP call library routines in SYS1.FORTLIB (assuming this is
OS, dunno what it's called on DOS.) You might check that it exists
and isn't smashed.
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
Check the JCL used to compile the production code for the libraries you
need. Are you using the same compiler? Version?
There's only one Fortran compiler on this system of which i am aware.
Quadibloc
2020-02-16 20:33:19 UTC
Permalink
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.

It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.

On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.) But that
doesn't mean that everything gets linked just before run time.

Instead, you can compile a program, have some linking done on it, with only the
minimum necessary linking happening when you run the program. So maybe your
production code has FORTRAN library routines for printing that call OS routines
for printing baked in that you are missing. This is just one possibility.

John Savard
Dan Espen
2020-02-16 21:03:36 UTC
Permalink
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.) But that
doesn't mean that everything gets linked just before run time.
Hmm, I think you are conflating the linker vs. the loader.

z/OS has had DLLs (AKA shared libraries) for a long time now.

The loader needs to adjust ADCONs based on the load address.
I'm not sure what goes on with Windows (or UNIX) but I'm guessing
they need some analogous process after loading.

LE has made all of this even worse, not only does the loader need to
adjust all the address constants, but then the runtime logic needs to
copy the writable static to some GETMAINed storage and do another round
of adjustments.
Post by Quadibloc
Instead, you can compile a program, have some linking done on it, with only the
minimum necessary linking happening when you run the program. So maybe your
production code has FORTRAN library routines for printing that call OS routines
for printing baked in that you are missing. This is just one possibility.
John Savard
Not clear on how that can be. This is a link time problem.
--
Dan Espen
Bob Martin
2020-02-17 06:47:08 UTC
Permalink
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Not true. Program preparation on 360 was compile + linkedit to produce a module.
Post by Quadibloc
Windows. (Which then later added a kludge to allow the use of DLLs.) But that
doesn't mean that everything gets linked just before run time.
Instead, you can compile a program, have some linking done on it, with only the
minimum necessary linking happening when you run the program. So maybe your
production code has FORTRAN library routines for printing that call OS routines
for printing baked in that you are missing. This is just one possibility.
John Savard
J. Clarke
2020-02-17 12:46:11 UTC
Permalink
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Post by Quadibloc
But that
doesn't mean that everything gets linked just before run time.
Instead, you can compile a program, have some linking done on it, with only the
minimum necessary linking happening when you run the program. So maybe your
production code has FORTRAN library routines for printing that call OS routines
for printing baked in that you are missing. This is just one possibility.
John Savard
Peter Flass
2020-02-17 15:11:09 UTC
Permalink
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
--
Pete
J. Clarke
2020-02-17 15:37:43 UTC
Permalink
On Mon, 17 Feb 2020 08:11:09 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
How does that make it a "kludge"? By that logic most of OS/2 is a
"kludge" because the idea was used in earlier systems. "Kludge"
implies poor implementation, not prior art.
Peter Flass
2020-02-18 22:19:04 UTC
Permalink
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:09 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
How does that make it a "kludge"? By that logic most of OS/2 is a
"kludge" because the idea was used in earlier systems. "Kludge"
implies poor implementation, not prior art.
No, that’s not the reason it’s a kludge, just sayin’ it’s also not
original. Given the limitations of x86 architecture it’s about the best
that could be done. PIC on x86 has too much overhead for machines with 64K
memories.
--
Pete
J. Clarke
2020-02-19 00:50:48 UTC
Permalink
On Tue, 18 Feb 2020 15:19:04 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:09 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
How does that make it a "kludge"? By that logic most of OS/2 is a
"kludge" because the idea was used in earlier systems. "Kludge"
implies poor implementation, not prior art.
No, that’s not the reason it’s a kludge, just sayin’ it’s also not
original. Given the limitations of x86 architecture it’s about the best
that could be done. PIC on x86 has too much overhead for machines with 64K
memories.
The stated hardware requirement for Windows 1.01 was 256k of RAM, and
what does a programmable interrupt controller have to do with DLLs? Or
do you mean something else by "PIC"?

However, as has been pointed out, Windows shipped with DLLs two years
before OS/2 so if anything's "not original" it's OS/2.
Ahem A Rivet's Shot
2020-02-19 07:03:52 UTC
Permalink
On Tue, 18 Feb 2020 19:50:48 -0500
Post by J. Clarke
On Tue, 18 Feb 2020 15:19:04 -0700, Peter Flass
Post by Peter Flass
No, that’s not the reason it’s a kludge, just sayin’ it’s also not
original. Given the limitations of x86 architecture it’s about the best
that could be done. PIC on x86 has too much overhead for machines with
64K memories.
The stated hardware requirement for Windows 1.01 was 256k of RAM, and
what does a programmable interrupt controller have to do with DLLs? Or
do you mean something else by "PIC"?
Position Independent Code - from context.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Bob Eager
2020-02-19 09:00:37 UTC
Permalink
Post by J. Clarke
Post by Peter Flass
No, that’s not the reason it’s a kludge, just sayin’ it’s also not
original. Given the limitations of x86 architecture it’s about the best
that could be done. PIC on x86 has too much overhead for machines with
64K memories.
The stated hardware requirement for Windows 1.01 was 256k of RAM, and
what does a programmable interrupt controller have to do with DLLs? Or
do you mean something else by "PIC"?
Position Independent Code.

I don't know why he's wittering about 64k memories, though. That went out
with the 386 in 1987.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
J. Clarke
2020-02-19 12:24:47 UTC
Permalink
Post by Bob Eager
Post by J. Clarke
Post by Peter Flass
No, that’s not the reason it’s a kludge, just sayin’ it’s also not
original. Given the limitations of x86 architecture it’s about the best
that could be done. PIC on x86 has too much overhead for machines with
64K memories.
The stated hardware requirement for Windows 1.01 was 256k of RAM, and
what does a programmable interrupt controller have to do with DLLs? Or
do you mean something else by "PIC"?
Position Independent Code.
I don't know why he's wittering about 64k memories, though. That went out
with the 386 in 1987.
No, 640K memories went out with the 386.

The 8088 and later Intel processors could address 1 meg. The original
PC was socketed for (IIRC) up to 384K, the XT could IIRC hold a full
640K (the remainder of the address space being ROMS, video memory,
reserved areas for accessories some of which didn't happen, etc), and
socketed for 640K became the standard for "clones". The AT usually
maxed out at the same 640K but the CPU could address 16 meg--the
feature wasn't used very much due to various bugs and lack of support
from IBM and Microsoft, but non-DOS operating systems including Unix
(not Linux, real Unix from AT&T), Novell, and OS/2 could all use it.

The 386 and later added virtualization and a 32-bit address space.

Further, the segmentation system on the x86 made "position independent
code" rather easy to implement.
Scott Lurndal
2020-02-19 16:15:13 UTC
Permalink
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:09 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
How does that make it a "kludge"? By that logic most of OS/2 is a
"kludge" because the idea was used in earlier systems. "Kludge"
implies poor implementation, not prior art.
No, that’s not the reason it’s a kludge, just sayin’ it’s also not
original. Given the limitations of x86 architecture it’s about the best
that could be done. PIC on x86 has too much overhead for machines with 64K
memories.
What limitations? x86 has never been limited to 64k memory. 640k, perhaps, but that
was almost half a century ago, and long before shared libraries were part of
any x86 based operating system.

And once the 386 was out, segmentation was relegated to the garbage heap of history.
Bob Eager
2020-02-17 21:02:25 UTC
Permalink
Post by Peter Flass
Post by J. Clarke
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure
that any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN
code, and compiled it, it wouldn't run. Perhaps while the libraries
are there, in the form that the code from long ago needs them,
something needed at an earlier step in the compile - link - execute
chain has gone missing.
On a 360 type mainframe, executables are still stored as object code
that gets linked before execution, as opposed to being basically
binary blobs like under Windows. (Which then later added a kludge to
allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
That may or may not be the case. But I believe Windows 1.0 pre-dates OS/2
by at least a couple of years.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
J. Clarke
2020-02-17 21:26:56 UTC
Permalink
Post by Bob Eager
Post by Peter Flass
Post by J. Clarke
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure
that any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN
code, and compiled it, it wouldn't run. Perhaps while the libraries
are there, in the form that the code from long ago needs them,
something needed at an earlier step in the compile - link - execute
chain has gone missing.
On a 360 type mainframe, executables are still stored as object code
that gets linked before execution, as opposed to being basically
binary blobs like under Windows. (Which then later added a kludge to
allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
That may or may not be the case. But I believe Windows 1.0 pre-dates OS/2
by at least a couple of years.
The first commercial release of Windows was in November, 1985. The
first commercial release of OS/2 was in December, 1987, so 2 years is
about right.
Scott Lurndal
2020-02-18 15:03:53 UTC
Permalink
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
Who copied it from unix.
Peter Flass
2020-02-18 22:19:06 UTC
Permalink
Post by Scott Lurndal
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
Who copied it from unix.
Did unix have shared libraries back then? This was back in the a.out era.
--
Pete
Dan Espen
2020-02-19 00:52:21 UTC
Permalink
Post by Peter Flass
Post by Scott Lurndal
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
Who copied it from unix.
Did unix have shared libraries back then? This was back in the a.out era.
This page:

https://www.quora.com/Unix-When-and-how-was-the-concept-of-a-shared-library-developed

mentions:

Author: James Q. Arnold
Title: Shared Libraries on UNIX System V
Pages: 395-404
Publisher: USENIX
Proceedings: USENIX Conference
Proceedings Date: Summer 1986
Location: Atlanta, GA
--
Dan Espen
J. Clarke
2020-02-19 02:03:29 UTC
Permalink
Post by Dan Espen
Post by Peter Flass
Post by Scott Lurndal
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
Who copied it from unix.
Did unix have shared libraries back then? This was back in the a.out era.
https://www.quora.com/Unix-When-and-how-was-the-concept-of-a-shared-library-developed
Author: James Q. Arnold
Title: Shared Libraries on UNIX System V
Pages: 395-404
Publisher: USENIX
Proceedings: USENIX Conference
Proceedings Date: Summer 1986
Location: Atlanta, GA
6-8 months after Windows was released.
Scott Lurndal
2020-02-19 16:26:36 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by Peter Flass
Post by Scott Lurndal
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
Who copied it from unix.
Did unix have shared libraries back then? This was back in the a.out era.
https://www.quora.com/Unix-When-and-how-was-the-concept-of-a-shared-library-developed
Author: James Q. Arnold
Title: Shared Libraries on UNIX System V
Pages: 395-404
Publisher: USENIX
Proceedings: USENIX Conference
Proceedings Date: Summer 1986
Location: Atlanta, GA
6-8 months after Windows was released.
Windows 3.1 was released in 1992. And it didn't have shared libraries,
just a bunch of DOS drivers.
Scott Lurndal
2020-02-19 16:25:14 UTC
Permalink
Post by Peter Flass
Post by Scott Lurndal
Post by Peter Flass
Post by J. Clarke
On Sun, 16 Feb 2020 12:33:19 -0800 (PST), Quadibloc
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.)
What is the nature of this alleged "kludge"? Windows had DLLs from
version 1.0 on. They didn't call them that at that point, but the
support was there and parts of Windows were implemented using them.
Copied the idea from OS/2.
Who copied it from unix.
Did unix have shared libraries back then? This was back in the a.out era.
Unix had shared libraries in SVR3 in 1987. They weren't quite as flexible
as the shared objects that we know and love which were introduced in SVR4 a year later.
Peter Flass
2020-02-17 15:11:07 UTC
Permalink
Post by Quadibloc
Post by J. Clarke
Given that production Fortran code links and runs I'm pretty sure that
any libraries that are supposed to be there are there.
And you're using the same compiler. That is a tough one.
It's possible that if you took the source for that production FORTRAN code, and
compiled it, it wouldn't run. Perhaps while the libraries are there, in the form
that the code from long ago needs them, something needed at an earlier step in
the compile - link - execute chain has gone missing.
On a 360 type mainframe, executables are still stored as object code that gets
linked before execution, as opposed to being basically binary blobs like under
Windows. (Which then later added a kludge to allow the use of DLLs.) But that
doesn't mean that everything gets linked just before run time.
Not usually.
Post by Quadibloc
Instead, you can compile a program, have some linking done on it, with only the
minimum necessary linking happening when you run the program. So maybe your
production code has FORTRAN library routines for printing that call OS routines
for printing baked in that you are missing. This is just one possibility.
It’s hard to say without seeing the whole picture. Maybe the old code
statically links FORTRAN library routines that have since been replaced by
LE on the current system.
--
Pete
Dan Espen
2020-02-15 16:19:27 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?

Pretty sure if you posted the externs here I'd at least make a good guess.

I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
--
Dan Espen
J. Clarke
2020-02-15 16:37:41 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
Peter Flass
2020-02-15 23:46:46 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
--
Pete
J. Clarke
2020-02-16 02:03:12 UTC
Permalink
On Sat, 15 Feb 2020 16:46:46 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
Must not have worked in aerospace or finance then.
Dan Espen
2020-02-16 04:20:10 UTC
Permalink
Post by J. Clarke
On Sat, 15 Feb 2020 16:46:46 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
Must not have worked in aerospace or finance then.
I've done finance, loans, insurance, never a bank.

I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.

Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.

So everything was packed decimal S9(7)V9(5).
When they wanted to get a reciprocal it was:

77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).


COMPUTE ANS = ONE / AMT.

I looked at the generated assembler and every calculation in the program
was:

convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.

The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
--
Dan Espen
J. Clarke
2020-02-16 04:34:42 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 16:46:46 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
Must not have worked in aerospace or finance then.
I've done finance, loans, insurance, never a bank.
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
That must have been a long time ago. IBM mainframes have had hardware
floating point practically forever. And I don't know how old our
Fortran code is--the companion APL code has sections that detect
whether it's running on a mainframe--there hasn't been a mainframe
version of that APL for at least 20 years.
Peter Flass
2020-02-17 15:11:06 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 16:46:46 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
Must not have worked in aerospace or finance then.
I've done finance, loans, insurance, never a bank.
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
That must have been a long time ago. IBM mainframes have had hardware
floating point practically forever. And I don't know how old our
Fortran code is--the companion APL code has sections that detect
whether it's running on a mainframe--there hasn't been a mainframe
version of that APL for at least 20 years.
That’s surprising. We had VSAPL on zOS and zVM, but of course that was ...
mumble... ten years ago now.
--
Pete
J. Clarke
2020-02-17 15:38:32 UTC
Permalink
On Mon, 17 Feb 2020 08:11:06 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 16:46:46 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
Must not have worked in aerospace or finance then.
I've done finance, loans, insurance, never a bank.
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
That must have been a long time ago. IBM mainframes have had hardware
floating point practically forever. And I don't know how old our
Fortran code is--the companion APL code has sections that detect
whether it's running on a mainframe--there hasn't been a mainframe
version of that APL for at least 20 years.
That’s surprising. We had VSAPL on zOS and zVM, but of course that was ...
mumble... ten years ago now.
It's not VSAPL.
Charlie Gibbs
2020-02-16 17:24:39 UTC
Permalink
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>

Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.

I wish I had been given more time to give it a proper overhaul...
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Dan Espen
2020-02-16 20:50:40 UTC
Permalink
Post by Charlie Gibbs
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I wish I had been given more time to give it a proper overhaul...
Yep, USAGE INDEX is even better than COMP.

While I was working the above COBOL program, I noticed that the compiler
default had been set to TRUNC. This makes every operation on binary
check for overflow based on the picture.

So, if you had a counter:

77 COUNT COMP S99.

With the TRUNC option the COBOL compiler checked after every add that
the value in COUNT was not greater than decimal 99. Even though the
counter could go all the way to 32K.

So, not only was I able to crank up the speed on this one program, but
I was able to crank up the speed on EVERY COBOL program they had.
--
Dan Espen
J. Clarke
2020-02-16 21:06:55 UTC
Permalink
Post by Dan Espen
Post by Charlie Gibbs
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I wish I had been given more time to give it a proper overhaul...
Yep, USAGE INDEX is even better than COMP.
While I was working the above COBOL program, I noticed that the compiler
default had been set to TRUNC. This makes every operation on binary
check for overflow based on the picture.
77 COUNT COMP S99.
With the TRUNC option the COBOL compiler checked after every add that
the value in COUNT was not greater than decimal 99. Even though the
counter could go all the way to 32K.
So, not only was I able to crank up the speed on this one program, but
I was able to crank up the speed on EVERY COBOL program they had.
Finally found the problem. I went through every step of compiling the
production code and found that I had tried to use the same name for
two object modules. Fortran was compiling Hello to a module named
"hello" in the loadlib then I was trying to link that one to create a
module "hello".

Still not sure where it found the missing links.

And it would have been nice if it had just said "hey bonehead" like
any reasonable system would instead of going ahead and linking the
thing and then crashing.
Peter Flass
2020-02-17 15:11:08 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by Charlie Gibbs
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I wish I had been given more time to give it a proper overhaul...
Yep, USAGE INDEX is even better than COMP.
While I was working the above COBOL program, I noticed that the compiler
default had been set to TRUNC. This makes every operation on binary
check for overflow based on the picture.
77 COUNT COMP S99.
With the TRUNC option the COBOL compiler checked after every add that
the value in COUNT was not greater than decimal 99. Even though the
counter could go all the way to 32K.
So, not only was I able to crank up the speed on this one program, but
I was able to crank up the speed on EVERY COBOL program they had.
Finally found the problem. I went through every step of compiling the
production code and found that I had tried to use the same name for
two object modules. Fortran was compiling Hello to a module named
"hello" in the loadlib then I was trying to link that one to create a
module "hello".
Still not sure where it found the missing links.
And it would have been nice if it had just said "hey bonehead" like
any reasonable system would instead of going ahead and linking the
thing and then crashing.
That’s the unix philosophy - just stop with no code or message.
--
Pete
J. Clarke
2020-02-17 15:40:22 UTC
Permalink
On Mon, 17 Feb 2020 08:11:08 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by Charlie Gibbs
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I wish I had been given more time to give it a proper overhaul...
Yep, USAGE INDEX is even better than COMP.
While I was working the above COBOL program, I noticed that the compiler
default had been set to TRUNC. This makes every operation on binary
check for overflow based on the picture.
77 COUNT COMP S99.
With the TRUNC option the COBOL compiler checked after every add that
the value in COUNT was not greater than decimal 99. Even though the
counter could go all the way to 32K.
So, not only was I able to crank up the speed on this one program, but
I was able to crank up the speed on EVERY COBOL program they had.
Finally found the problem. I went through every step of compiling the
production code and found that I had tried to use the same name for
two object modules. Fortran was compiling Hello to a module named
"hello" in the loadlib then I was trying to link that one to create a
module "hello".
Still not sure where it found the missing links.
And it would have been nice if it had just said "hey bonehead" like
any reasonable system would instead of going ahead and linking the
thing and then crashing.
That’s the unix philosophy - just stop with no code or message.
_Someone_ has clearly never compiled or linked anything under UNIX. If
you think that UNIX systems give no messages in the case of a
compilation or linking error and just "stop" you really need to live
with UNIX for a while.
Dan Espen
2020-02-17 18:31:29 UTC
Permalink
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:08 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by Charlie Gibbs
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I wish I had been given more time to give it a proper overhaul...
Yep, USAGE INDEX is even better than COMP.
While I was working the above COBOL program, I noticed that the compiler
default had been set to TRUNC. This makes every operation on binary
check for overflow based on the picture.
77 COUNT COMP S99.
With the TRUNC option the COBOL compiler checked after every add that
the value in COUNT was not greater than decimal 99. Even though the
counter could go all the way to 32K.
So, not only was I able to crank up the speed on this one program, but
I was able to crank up the speed on EVERY COBOL program they had.
Finally found the problem. I went through every step of compiling the
production code and found that I had tried to use the same name for
two object modules. Fortran was compiling Hello to a module named
"hello" in the loadlib then I was trying to link that one to create a
module "hello".
Still not sure where it found the missing links.
And it would have been nice if it had just said "hey bonehead" like
any reasonable system would instead of going ahead and linking the
thing and then crashing.
That’s the unix philosophy - just stop with no code or message.
_Someone_ has clearly never compiled or linked anything under UNIX. If
you think that UNIX systems give no messages in the case of a
compilation or linking error and just "stop" you really need to live
with UNIX for a while.
gcc has a few messages where they report the problem, then they take a
guess at what you did wrong. Outstanding.
--
Dan Espen
Jorgen Grahn
2020-02-18 00:44:41 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
On Mon, 17 Feb 2020 08:11:08 -0700, Peter Flass
...
Post by Dan Espen
Post by J. Clarke
Post by Peter Flass
Post by J. Clarke
And it would have been nice if it had just said "hey bonehead" like
any reasonable system would instead of going ahead and linking the
thing and then crashing.
That’s the unix philosophy - just stop with no code or message.
_Someone_ has clearly never compiled or linked anything under UNIX. If
you think that UNIX systems give no messages in the case of a
compilation or linking error and just "stop" you really need to live
with UNIX for a while.
gcc has a few messages where they report the problem, then they take a
guess at what you did wrong. Outstanding.
There's the recently added "did you mean to write <foo>?" messages.
If you mean those: yes they are annoying, but they don't replace the
normal, useful messages.

And I think they were added because clang (the more trendy, Apple-
backed compiler the last few years) has them.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Scott Lurndal
2020-02-18 15:23:46 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
_Someone_ has clearly never compiled or linked anything under UNIX. If
you think that UNIX systems give no messages in the case of a
compilation or linking error and just "stop" you really need to live
with UNIX for a while.
Indeed.
Post by Dan Espen
gcc has a few messages where they report the problem, then they take a
guess at what you did wrong. Outstanding.
I recall a pascal compiler we ran under MVS; don't remember whose, but
when the student programmers left off the semi-colon that typically
terminates a statement, the compiler would print a syntax error, followed
by "Possibly missing a semi-colon in the prior line". It continually
amazed me at how may freshmen would ask what the syntax error means while
ignoring the reason printed by the compiler :-(.
Dan Espen
2020-02-17 18:30:00 UTC
Permalink
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by Charlie Gibbs
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I wish I had been given more time to give it a proper overhaul...
Yep, USAGE INDEX is even better than COMP.
While I was working the above COBOL program, I noticed that the compiler
default had been set to TRUNC. This makes every operation on binary
check for overflow based on the picture.
77 COUNT COMP S99.
With the TRUNC option the COBOL compiler checked after every add that
the value in COUNT was not greater than decimal 99. Even though the
counter could go all the way to 32K.
So, not only was I able to crank up the speed on this one program, but
I was able to crank up the speed on EVERY COBOL program they had.
Finally found the problem. I went through every step of compiling the
production code and found that I had tried to use the same name for
two object modules. Fortran was compiling Hello to a module named
"hello" in the loadlib then I was trying to link that one to create a
module "hello".
Still not sure where it found the missing links.
And it would have been nice if it had just said "hey bonehead" like
any reasonable system would instead of going ahead and linking the
thing and then crashing.
That’s the unix philosophy - just stop with no code or message.
Nope. Look in STDERR or maybe SYSLOG.

I really like the UNIX based "strace/truss" stuff.
Really makes mainframe stuff look like junk.
--
Dan Espen
Scott Lurndal
2020-02-18 15:26:55 UTC
Permalink
Post by Dan Espen
That’s the unix philosophy - just stop with no code or message.
Nope. Look in STDERR or maybe SYSLOG.
I really like the UNIX based "strace/truss" stuff.
Really makes mainframe stuff look like junk.
We had an equivalent on the Burroughs MCP;

?EX APP; TRACE

would direct an instruction trace to the printer (or printer
backup file on disk). Very useful. The app itself
(or the operator) could use the 'GT' command to start tracing
at an arbitrary point. There was also a system call (Branch
Communicate to the MCP) that would start tracing or dump a
core file (which could be analyzed with the PM - print memory
dump command).

By the mid-80s we had also implemented an interactive debugger
that ran on the block-mode screens.
Scott Lurndal
2020-02-18 15:21:22 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by Charlie Gibbs
Post by Dan Espen
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
<shudder>
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts
as COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I wish I had been given more time to give it a proper overhaul...
Yep, USAGE INDEX is even better than COMP.
While I was working the above COBOL program, I noticed that the compiler
default had been set to TRUNC. This makes every operation on binary
check for overflow based on the picture.
77 COUNT COMP S99.
With the TRUNC option the COBOL compiler checked after every add that
the value in COUNT was not greater than decimal 99. Even though the
counter could go all the way to 32K.
So, not only was I able to crank up the speed on this one program, but
I was able to crank up the speed on EVERY COBOL program they had.
Finally found the problem. I went through every step of compiling the
production code and found that I had tried to use the same name for
two object modules. Fortran was compiling Hello to a module named
"hello" in the loadlib then I was trying to link that one to create a
module "hello".
Still not sure where it found the missing links.
And it would have been nice if it had just said "hey bonehead" like
any reasonable system would instead of going ahead and linking the
thing and then crashing.
That’s the unix philosophy - just stop with no code or message.
Now that's completely wrong. In every possible way.

Have you ever, you know, actually _used_ unix? Or Linux? Or anything
other than MVS and Windows?
Bob Eager
2020-02-16 21:41:02 UTC
Permalink
Post by Charlie Gibbs
Reminds me of the time I was sent to a shop to diagnose a COBOL program.
It was hammering the CPU so hard that the customer estimated that it
would take 50 hours to run to completion. The program did a lot of
array processing, and the genius who wrote it declared all subscripts as
COMP-3 (packed decimal). The simple act of changing them to COMP-4
(binary) knocked 30% off the execution time.
I was hired to improve the performance of a large software package
written in COBOL.

The report writing language had a compiler *written* in COBOL. It
compiled to an interpretive code. The interpreter was written in COBOL,
as was the run time system.

I wrote a compatible compiler to native code, and a run-time system
written in native code.

The performance increase was 40%, and that was a change only to the
report writer.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Peter Flass
2020-02-17 15:11:05 UTC
Permalink
Post by Dan Espen
Post by J. Clarke
On Sat, 15 Feb 2020 16:46:46 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
Must not have worked in aerospace or finance then.
I've done finance, loans, insurance, never a bank.
I remember one pretty extreme amount of calculations at an insurance
company. They wrote it in COBOL blindly following a list of
optimizations and coding rules they got from IBM.
Some fool recommended they make all their variables the same size and
they name their constants instead of using literals.
So everything was packed decimal S9(7)V9(5).
77 ONE PIC S9(7)V(5) VALUE 1.
77 AMT PIC S9(7)V(5).
77 ANS PIC S9(7)V(5).
COMPUTE ANS = ONE / AMT.
I looked at the generated assembler and every calculation in the program
convert packed amounts to floats.
Call library routine to do the float computation (they had no floating
point feature).
Convert answer back to packed.
The thing was taking days to run a single test.
Eventually it ran at printer speed.
At no time did I think Fortran was the right answer.
Not in a COBOL/ASM shop.
Right. If you’re going to introduce a “new” language you need to have
commitment to it. Of course this is said as someone who used PL/I when
everyone else used COBOL.
--
Pete
Peter Flass
2020-02-17 15:11:04 UTC
Permalink
Post by J. Clarke
On Sat, 15 Feb 2020 16:46:46 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Just checked, your post mentions COBOL and Fortran, but not mainframe.
So, COBOL gave me a hint, but I've actually never run into any company
running Fortran on a mainframe.
I've never run into any company with a mainframe that does NOT run
Fortran on it.
Post by Dan Espen
Post by J. Clarke
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
Not even a Google search?
Not even a Google search.
Post by Dan Espen
Pretty sure if you posted the externs here I'd at least make a good guess.
I'm suspecting LE subroutines since they are sometimes difficult to
link to, but I think you mentioned the same problem with Fortran and I
didn't think Fortran was LE.
In the modern mainframe, everything is LE.
My experience tallies more closely with Dan’s than yours.
Must not have worked in aerospace or finance then.
Never. One shop had exactly one FORTRAN program to do some statistical
analysis.
--
Pete
Peter Flass
2020-02-15 23:46:44 UTC
Permalink
Post by J. Clarke
Post by Dan Espen
Post by J. Clarke
Post by d***@gmail.com
At least in the old days you got back a mangled stack of cards and a
hunk of 14x11 green-bar paper... something you could set fire to...
The damned thing refuses to punch an object deck--some configuration
option is set to override the PARM line. Turns out that there were
unresolved externals.
PROGRAM HELLO
PRINT *, "HELLO WORLD"
STOP
END
No idea what line was generating the calls or where the library was
that would satisfy them.
Punch an object deck?
Yes, Dan. It is a mainframe. I stated that clearly in my original
post.
Post by Dan Espen
Sounds like some kind of S/360 derived OS.
The linkage map shows you the unresolved extern and which module
made the reference to the extern.
There is one module, "HELLO", which generated 5 references to EXTERNS
none of which I could find documented anywhere.
“PRINT” would be an obvious one. there is probably an initialization
routine, maybe a termination routine, and “STOP” might generate a call.
That’s four.
--
Pete
J. Clarke
2020-02-14 23:58:20 UTC
Permalink
Post by Charlie Gibbs
Post by J. Clarke
Said something nice about COBOL a couple of days ago.
Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.
Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.
But I am once again reminded of just how primitive that system is.
Ah, the good old days, when "give a cryptic message and die" was
standard behaviour. In this modern age, programs put up a pretty
box that says "Something went wrong" and then die.
In the modern world you set breakpoints and when the program dies you
have a clue where it died and what it was doing when it did it.
Ahem A Rivet's Shot
2020-02-15 09:18:32 UTC
Permalink
On Fri, 14 Feb 2020 18:58:20 -0500
Post by J. Clarke
In the modern world you set breakpoints and when the program dies you
have a clue where it died and what it was doing when it did it.
Or you get a backtrace in the logs and work from that.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Peter Flass
2020-02-15 23:46:43 UTC
Permalink
Post by J. Clarke
Post by Charlie Gibbs
Post by J. Clarke
Said something nice about COBOL a couple of days ago.
Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.
Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.
But I am once again reminded of just how primitive that system is.
Ah, the good old days, when "give a cryptic message and die" was
standard behaviour. In this modern age, programs put up a pretty
box that says "Something went wrong" and then die.
In the modern world you set breakpoints and when the program dies you
have a clue where it died and what it was doing when it did it.
For developers. In some cases there are things users can do to fix problems
if only they had any information indicating what they might have done
wrong.
--
Pete
J. Clarke
2020-02-16 02:04:26 UTC
Permalink
On Sat, 15 Feb 2020 16:46:43 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
Post by Charlie Gibbs
Post by J. Clarke
Said something nice about COBOL a couple of days ago.
Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.
Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.
But I am once again reminded of just how primitive that system is.
Ah, the good old days, when "give a cryptic message and die" was
standard behaviour. In this modern age, programs put up a pretty
box that says "Something went wrong" and then die.
In the modern world you set breakpoints and when the program dies you
have a clue where it died and what it was doing when it did it.
For developers. In some cases there are things users can do to fix problems
if only they had any information indicating what they might have done
wrong.
While this is true, we aren't talking about users here.
Ahem A Rivet's Shot
2020-02-16 09:17:26 UTC
Permalink
On Sat, 15 Feb 2020 21:04:26 -0500
Post by J. Clarke
On Sat, 15 Feb 2020 16:46:43 -0700, Peter Flass
Post by Peter Flass
Post by J. Clarke
In the modern world you set breakpoints and when the program dies you
have a clue where it died and what it was doing when it did it.
For developers. In some cases there are things users can do to fix
problems if only they had any information indicating what they might
have done wrong.
While this is true, we aren't talking about users here.
Sysadmins can also make use of good fault reporting.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
h***@bbs.cpcn.com
2020-02-18 18:50:10 UTC
Permalink
Post by J. Clarke
Said something nice about COBOL a couple of days ago.
Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.
Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.
But I am once again reminded of just how primitive that system is.
Perhaps I am misunderstanding something--please correct me if
I'm wrong--but m perception of a mainframe compilation is different.
(Z series, previously S/360-370-390).

1) Compilations have multiple steps. First, optionally, is
a pre-processor if CICS or database is used. Not used for
plain batch programs.

2) The compile itself, e.g. Fortran or COBOL. At the end,
a condition code is set which is given in the control
(HASP/JES) listing. It is typically 00 or 04. Anything
higher means a syntax error that needs to be fixed.

3) The next step, typically transparent, is the linkage
editor. This should always result in a 00 return code,
anything else needs to be investigated.

If either of the above ends abnormally, there would be
a special return code as well as error messages. Today,
these messages can be checked on the internet. It is
rare for these to abend. If so, there may be a problem
in the libraries or JCL which is typically handled by
the systems programmers. Sometimes those libraries get
accidently deleted or are not up to date.

4) Once the LNKED is done the program may be executed.
Sometimes programs have their own error detection and may
set a return code and generate an error message. But
if the program has a failed condition, known as an exception,
it will abend with a message. The most common error is
a SOC7, data exception, such as using a letter in a numeric
field. But other errors may include a missing file.

Again, there is a lot of detail in the JES/HASP listing, such as
the error and if something needed is not found.



Again, if I am misunderstanding anything please correct me.
J. Clarke
2020-02-19 00:53:42 UTC
Permalink
Post by h***@bbs.cpcn.com
Post by J. Clarke
Said something nice about COBOL a couple of days ago.
Spend the day trying to figure out why my effing program won't run. It
compiles but from there is just gives me a cryptic message and dies.
Finally tried a Hello World in Fortran--minimal program, four lines of
code. It also gives a cryptic message and dies. Wasted a day.
Tomorrow I need to dig up the systems people and find out what's
wrong.
But I am once again reminded of just how primitive that system is.
Perhaps I am misunderstanding something--please correct me if
I'm wrong--but m perception of a mainframe compilation is different.
(Z series, previously S/360-370-390).
1) Compilations have multiple steps. First, optionally, is
a pre-processor if CICS or database is used. Not used for
plain batch programs.
2) The compile itself, e.g. Fortran or COBOL. At the end,
a condition code is set which is given in the control
(HASP/JES) listing. It is typically 00 or 04. Anything
higher means a syntax error that needs to be fixed.
3) The next step, typically transparent, is the linkage
editor. This should always result in a 00 return code,
anything else needs to be investigated.
If either of the above ends abnormally, there would be
a special return code as well as error messages. Today,
these messages can be checked on the internet. It is
rare for these to abend. If so, there may be a problem
in the libraries or JCL which is typically handled by
the systems programmers. Sometimes those libraries get
accidently deleted or are not up to date.
4) Once the LNKED is done the program may be executed.
Sometimes programs have their own error detection and may
set a return code and generate an error message. But
if the program has a failed condition, known as an exception,
it will abend with a message. The most common error is
a SOC7, data exception, such as using a letter in a numeric
field. But other errors may include a missing file.
Again, there is a lot of detail in the JES/HASP listing, such as
the error and if something needed is not found.
You understand how it is supposed to work. But it doesn't always work
that way. And you may have 10,000 lines of output to dig through to
find the actual error message, which doesn't have any standard tag
that you can search for.
Post by h***@bbs.cpcn.com
Again, if I am misunderstanding anything please correct me.
Loading...