Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » iBM System/3 FORTRAN for engineering/science work?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: iBM System/3 FORTRAN for engineering/science work? [message #409995 is a reply to message #409901] Fri, 16 July 2021 14:33 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Wednesday, July 14, 2021 at 12:50:21 AM UTC-4, ly...@garlic.com wrote:
> mid-70s, I also started to pontificate that while systems were getting
> faster ... disk performance wasn't increasing as fast ... as well as
> there being huge amount of bloat. In the early 80s, I was writing that
> relative system disk performance had declined by an order of magnitude
> from early 360 days to the early 80s (i.e. disks got 3-5 faster while
> rest of system got 40-50 times faster). Disk executives took exception
> and assigned the division performance group to refute my claims ... they
> came back after a few weeks and basically said I had slightly
> understated the problem. They then respun the analysis for a (IBM user
> group) SHARE presentation on how to configure disks to improve system
> throughput.... 16Aug1984, Share 63, B874. old posts with some
> intro/summarry

Not sure if this is comparable since it's the Univac 90/30 (sort of S/370 equivalent),
but I had the machine to myself on a weekend and ran some tests of multi-programming
performance. Our machine had the equivalent of 3330 drives. They were top loaders
and we could look down through the glass and watch the head action.

One thing was obvious--having multiple programs use the same drive was
a performance disaster. The disk drive ran like an overloaded washing machine,
shaking like crazy and the heads went in and out. Run time was bad.

But even running two programs simultaneously using two separate drives
was slow. Indeed, it'd be faster (wall clock) to run the two programs
sequentially rather than simultaneously. I'm not sure why that was, perhaps
the disk channel was shared among the drives, perhaps the CPU or
supervisor couldn't handle multi-programming very well (even though
supposedly the OS could handle up to five regions and we had plenty
of memory).

(We had tape drives that seemed pretty fast, but we did nothing on tape
except backups).

I know others here who used the Univac 90/30 were very positive on them,
and I knew of other sites that loved them. But my observation wasn't as
positive. As mentioned, I have no idea of the price/performance, other
than Univac was supposedly a lot cheaper than the equivalent powered
IBM mainframe, especially a new one. So, perhaps as a low end machine,
equivalent to a S/370-125 (not virtual) it could do the job economically.

We were speaking of optimization. The output of the 90/30's COBOL
compiler had the assembler and it was definitely not optimized, and I
don't believe the machine even offered that option. (I don't know about
other Univacs).

My impression was that because the 90/30 was a byte oriented machine,
like S/360, it didn't really fit in Univac's product line of word oriented machines.
For instance, a lot of Univac's programmers attempted to do stuff not allowed
on byte machines, like having spaces in a numeric field and attempting to load
an ISAM file by inserts, not a copy.

Here's the system brochure:
http://bitsavers.org/pdf/univac/series_90/Univac_90_30_Syste m_Brochure_Mar74.pdf

Bitsavers has a few manuals:
http://bitsavers.org/pdf/univac/series_90/
Re: iBM System/3 FORTRAN for engineering/science work? [message #410006 is a reply to message #409995] Fri, 16 July 2021 18:40 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2021-07-16, undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:

> On Wednesday, July 14, 2021 at 12:50:21 AM UTC-4, ly...@garlic.com wrote:
>
>> mid-70s, I also started to pontificate that while systems were getting
>> faster ... disk performance wasn't increasing as fast ... as well as
>> there being huge amount of bloat. In the early 80s, I was writing that
>> relative system disk performance had declined by an order of magnitude
>> from early 360 days to the early 80s (i.e. disks got 3-5 faster while
>> rest of system got 40-50 times faster). Disk executives took exception
>> and assigned the division performance group to refute my claims ... they
>> came back after a few weeks and basically said I had slightly
>> understated the problem. They then respun the analysis for a (IBM user
>> group) SHARE presentation on how to configure disks to improve system
>> throughput.... 16Aug1984, Share 63, B874. old posts with some
>> intro/summarry
>
> Not sure if this is comparable since it's the Univac 90/30 (sort of S/370
> equivalent),

IIRC the non-privileged instruction set was bit-for-bit identical with that
of the 360/50. The 370 instructions came later, with the System 80 line.

> but I had the machine to myself on a weekend and ran some tests of
> multi-programming performance. Our machine had the equivalent of
> 3330 drives. They were top loaders and we could look down through
> the glass and watch the head action.

Ah, you had the 8430s - lucky guy. Most sites I worked on originally
had 8416s (28MB/spindle), which looked much like the 8430, complete
with the glass top. These were later replaced by the 8418 - twice the
capacity, but an opaque lid meant you couldn't watch the heads thrash
anymore. (I did, however, find a display on the front panel which
showed the length of the current seek, and could identify problems
that way.)

> One thing was obvious--having multiple programs use the same drive was
> a performance disaster. The disk drive ran like an overloaded washing
> machine, shaking like crazy and the heads went in and out. Run time
> was bad.
>
> But even running two programs simultaneously using two separate drives
> was slow. Indeed, it'd be faster (wall clock) to run the two programs
> sequentially rather than simultaneously. I'm not sure why that was,
> perhaps the disk channel was shared among the drives, perhaps the CPU
> or supervisor couldn't handle multi-programming very well (even though
> supposedly the OS could handle up to five regions and we had plenty
> of memory).

The supervisor was pretty disk-bound. It spent a lot of time rolling
transient code into and out of memory, and many system utilities had
lots of overlays. This is no doubt a consequence of trying to squeeze
too much programming into too little memory. Salesmen were constantly
low-balling memory requirements, and customers who scrimped and got
128K of memory soon wound up shelling out the bucks to go to 192K.

I found that if the jobs weren't too disk-bound (a bit of clever design
helped here), three concurrent jobs was the point of diminishing returns.

You also had to watch out for CPU-bound jobs (e.g. sorts). OS/3 did not
time-slice jobs of equal priority, so if one of your jobs was CPU-bound
(or went into a loop), other running jobs of equal or lower priority
came to a screeching halt. A later release of OS/3 added a sysgen option
to change the default priority to something other than the lowest possible
value; that way you could run most jobs at default priority, while
specifying a lower priority for CPU-bound steps.

> (We had tape drives that seemed pretty fast, but we did nothing on tape
> except backups).
>
> I know others here who used the Univac 90/30 were very positive on them,
> and I knew of other sites that loved them. But my observation wasn't as
> positive. As mentioned, I have no idea of the price/performance, other
> than Univac was supposedly a lot cheaper than the equivalent powered
> IBM mainframe, especially a new one. So, perhaps as a low end machine,
> equivalent to a S/370-125 (not virtual) it could do the job economically.

They must have done something right - they sold a lot of them.

> We were speaking of optimization. The output of the 90/30's COBOL
> compiler had the assembler and it was definitely not optimized, and I
> don't believe the machine even offered that option. (I don't know about
> other Univacs).
>
> My impression was that because the 90/30 was a byte oriented machine,
> like S/360, it didn't really fit in Univac's product line of word oriented
> machines.

It didn't try; it was a totally different product line.

> For instance, a lot of Univac's programmers attempted to do stuff
> not allowed on byte machines, like having spaces in a numeric field
> and attempting to load an ISAM file by inserts, not a copy.

Ouch. I remember watching a machine doing that. It was running so
painfully slowly that I found it faster to cancel the job and re-write
the program.

> Here's the system brochure:
> http://bitsavers.org/pdf/univac/series_90/Univac_90_30_Syste m_Brochure_Mar74.pdf
>
> Bitsavers has a few manuals:
> http://bitsavers.org/pdf/univac/series_90/

I'm just finishing up scanning the wall of OS/3 (90/30 and System 80)
manuals that I was issued when I worked at Univac. I'll be uploading
over 300 documents (3.5GB) to Bitsavers Real Soon Now.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
Re: iBM System/3 FORTRAN for engineering/science work? [message #410016 is a reply to message #409995] Sat, 17 July 2021 02:13 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Saturday, July 17, 2021 at 4:33:27 AM UTC+10, undefined Hancock-4 wrote:
> On Wednesday, July 14, 2021 at 12:50:21 AM UTC-4, ly...@garlic.com wrote:
>> mid-70s, I also started to pontificate that while systems were getting
>> faster ... disk performance wasn't increasing as fast ... as well as
>> there being huge amount of bloat. In the early 80s, I was writing that
>> relative system disk performance had declined by an order of magnitude
>> from early 360 days to the early 80s (i.e. disks got 3-5 faster while
>> rest of system got 40-50 times faster). Disk executives took exception
>> and assigned the division performance group to refute my claims ... they
>> came back after a few weeks and basically said I had slightly
>> understated the problem. They then respun the analysis for a (IBM user
>> group) SHARE presentation on how to configure disks to improve system
>> throughput.... 16Aug1984, Share 63, B874. old posts with some
>> intro/summarry
> Not sure if this is comparable since it's the Univac 90/30 (sort of S/370 equivalent),
> but I had the machine to myself on a weekend and ran some tests of multi-programming
> performance. Our machine had the equivalent of 3330 drives. They were top loaders
> and we could look down through the glass and watch the head action.
>
> One thing was obvious--having multiple programs use the same drive was
> a performance disaster. The disk drive ran like an overloaded washing machine,
> shaking like crazy and the heads went in and out. Run time was bad.
>
> But even running two programs simultaneously using two separate drives
> was slow. Indeed, it'd be faster (wall clock) to run the two programs
> sequentially rather than simultaneously. I'm not sure why that was, perhaps
> the disk channel was shared among the drives, perhaps the CPU or
> supervisor couldn't handle multi-programming very well (even though
> supposedly the OS could handle up to five regions and we had plenty
> of memory).
..
A lot depended on the blocking factor.
The ICL System 4 thrashed the disc drives because there was no blocking
of 80-byte records.
The drives began failing after about 5 years of that punishment.
Records were subsequently de-blanked and blocked to 386(?) bytes
with considerable improvement in performance, but full-track
blocking would have been even better.
..
> (We had tape drives that seemed pretty fast, but we did nothing on tape
> except backups).
>
> I know others here who used the Univac 90/30 were very positive on them,
> and I knew of other sites that loved them. But my observation wasn't as
> positive. As mentioned, I have no idea of the price/performance, other
> than Univac was supposedly a lot cheaper than the equivalent powered
> IBM mainframe, especially a new one. So, perhaps as a low end machine,
> equivalent to a S/370-125 (not virtual) it could do the job economically.
>
> We were speaking of optimization. The output of the 90/30's COBOL
> compiler had the assembler and it was definitely not optimized, and I
> don't believe the machine even offered that option. (I don't know about
> other Univacs).
>
> My impression was that because the 90/30 was a byte oriented machine,
> like S/360, it didn't really fit in Univac's product line of word oriented machines.
> For instance, a lot of Univac's programmers attempted to do stuff not allowed
> on byte machines, like having spaces in a numeric field and attempting to load
> an ISAM file by inserts, not a copy.
>
> Here's the system brochure:
> http://bitsavers.org/pdf/univac/series_90/Univac_90_30_Syste m_Brochure_Mar74.pdf
>
> Bitsavers has a few manuals:
> http://bitsavers.org/pdf/univac/series_90/
Re: iBM System/3 FORTRAN for engineering/science work? [message #410036 is a reply to message #410016] Sat, 17 July 2021 15:12 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2021-07-17, Robin Vowels <robin.vowels@gmail.com> wrote:

> A lot depended on the blocking factor.
> The ICL System 4 thrashed the disc drives because there was no blocking
> of 80-byte records.
> The drives began failing after about 5 years of that punishment.
> Records were subsequently de-blanked and blocked to 386(?) bytes
> with considerable improvement in performance, but full-track
> blocking would have been even better.

Assuming you have enough memory for those big buffers...

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
Re: iBM System/3 FORTRAN for engineering/science work? [message #410044 is a reply to message #410036] Sun, 18 July 2021 00:33 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Sunday, July 18, 2021 at 5:13:28 AM UTC+10, Charlie Gibbs wrote:
> On 2021-07-17, Robin Vowels <robin....@gmail.com> wrote:
>
>> A lot depended on the blocking factor.
>> The ICL System 4 thrashed the disc drives because there was no blocking
>> of 80-byte records.
>> The drives began failing after about 5 years of that punishment.
>> Records were subsequently de-blanked and blocked to 386(?) bytes
>> with considerable improvement in performance, but full-track
>> blocking would have been even better.
..
> Assuming you have enough memory for those big buffers...
..
Plenty of memory fir that.
You can't get any work out of thrashing disc drives.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410063 is a reply to message #410044] Sun, 18 July 2021 11:20 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2021-07-18, Robin Vowels <robin.vowels@gmail.com> wrote:

> On Sunday, July 18, 2021 at 5:13:28 AM UTC+10, Charlie Gibbs wrote:
>
>> On 2021-07-17, Robin Vowels <robin....@gmail.com> wrote:
>>
>>> A lot depended on the blocking factor.
>>> The ICL System 4 thrashed the disc drives because there was no blocking
>>> of 80-byte records.
>>> The drives began failing after about 5 years of that punishment.
>>> Records were subsequently de-blanked and blocked to 386(?) bytes
>>> with considerable improvement in performance, but full-track
>>> blocking would have been even better.
>>
>> Assuming you have enough memory for those big buffers...
>
> Plenty of memory fir that.
> You can't get any work out of thrashing disc drives.

True, but one shop I worked in went to the other extreme:
full-track blocking for every file. One system consisted
of a program that created half a dozen work files (even
though some were redundant). Six output files - plus an
input file - with a track size of 10K meant that 70K of
the machine's 192K went to buffers alone. It certainly
didn't make anything else run faster since there was no
memory left to run more.

And rather than just sorting the work files and printing
reports as successive steps, another shop standard was to
kick off separate jobs to sort and print each one. Now
_there_ was thrashing for you - just moved to the job
scheduler. I wrote one such system for them, and found
that the entire job would take about 20 minutes just
to schedule, let alone run. I said to hell with their
standards, wrote it in a sane fashion, and got test runs
through in a minute or two. They were furious, of course,
but I pointed out that they were perfectly free to change it
back to their time-consuming way once I was finished testing.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
Re: iBM System/3 FORTRAN for engineering/science work? [message #410128 is a reply to message #410063] Tue, 20 July 2021 15:05 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Sunday, July 18, 2021 at 11:21:30 AM UTC-4, Charlie Gibbs wrote:
> True, but one shop I worked in went to the other extreme:
> full-track blocking for every file. One system consisted
> of a program that created half a dozen work files (even
> though some were redundant). Six output files - plus an
> input file - with a track size of 10K meant that 70K of
> the machine's 192K went to buffers alone. It certainly
> didn't make anything else run faster since there was no
> memory left to run more.

Yes, on older machines too high a blocking factor caused problems, too.
They used to warn us not max out on blocking factors. Memory was not
unlimited, as you say.

In the old days we calculated optimum blocksizes based on our logical
record length and the device we were writing to. Disk drives had different
lengths.

I once experimented with a S/360 tape drive. I found a block size of
about 5,000 characters was the max, anything beyond that would
generate I/O errors and waste time with retries.

Later machines could handle maximum blocks. Indeed, in later years
we coded BLKSIZE=0 in our JCL which would maximize blocksize
for whatever device we were creating a file on. As data centers got
bigger and had a mix of devices, the dynamic automatic blocking
made it easier for us, since we didn't have to worry about the device
type.

Amazing, in the early days we were intimately familiar with the
characteristics of say the 2311 vs. the 2314 or various tape drives.
Our coding depended on it to optimize performance and memory.
But now, devices evolve and we don't even know what we're writing to.
The system handles it all automatically, with automatic file allocation.

Sometimes we had older jobs with hardcoded low blocksizes. They
ran poorly. Upgrading it was an easy way to improve performance.

In a few cases, such as files being sent out or specialty devices,
blocksize and other issues still mattered. JCL still allows to set
specifics if desired.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410129 is a reply to message #409905] Tue, 20 July 2021 15:07 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Wednesday, July 14, 2021 at 3:39:57 AM UTC-4, Quadibloc wrote:
> On Tuesday, July 13, 2021 at 4:11:16 PM UTC-6, undefined Hancock-4 wrote:
>
>> But the Programmers Guide provided valuable tips for coding and setup
>> for performance, efficiency, and maintainability. Unlike the language
>> reference, it was written in a more casual understandable style.
> What I remembered of the FORTRAN Programmer's Guide is that it
> gave technical details of the use of the compiler - things like calling
> sequences - which were useful for certain advanced programming
> tasks.
>
> I had not noticed that it was an approachable guide to writing better
> programs, as you describe these books.

It had a lot of info on the compiling and programming environments,
but that was useful for all programmers, not just advanced ones.

The Guides on bitsavers certainly contain sections on writing better programs
as do the modern ones.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410147 is a reply to message #410128] Wed, 21 July 2021 01:29 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Koenig

undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb:

> In the old days we calculated optimum blocksizes based on our logical
> record length and the device we were writing to. Disk drives had different
> lengths.

I remember the recommendation for FB80 files switching from a
blocksize of 3200 bytes to a blocksize of 3120 bytes when the
computer center switched generations of mainframes and therefore
disk type, as well.

30 years ago I could probably have told you the disk drive
types this was optimum for. Not any more :-)
Re: iBM System/3 FORTRAN for engineering/science work? [message #410148 is a reply to message #410063] Wed, 21 July 2021 01:49 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Monday, July 19, 2021 at 1:21:30 AM UTC+10, Charlie Gibbs wrote:
> On 2021-07-18, Robin Vowels <robin....@gmail.com> wrote:
>
>> On Sunday, July 18, 2021 at 5:13:28 AM UTC+10, Charlie Gibbs wrote:
>>
>>> On 2021-07-17, Robin Vowels <robin....@gmail.com> wrote:
>>>
>>>> A lot depended on the blocking factor.
>>>> The ICL System 4 thrashed the disc drives because there was no blocking
>>>> of 80-byte records.
>>>> The drives began failing after about 5 years of that punishment.
>>>> Records were subsequently de-blanked and blocked to 386(?) bytes
>>>> with considerable improvement in performance, but full-track
>>>> blocking would have been even better.
>>>
>>> Assuming you have enough memory for those big buffers...
>>
>> Plenty of memory fir that.
>> You can't get any work out of thrashing disc drives.
..
> True, but one shop I worked in went to the other extreme:
> full-track blocking for every file. One system consisted
> of a program that created half a dozen work files (even
> though some were redundant). Six output files - plus an
> input file - with a track size of 10K meant that 70K of
> the machine's 192K went to buffers alone. It certainly
> didn't make anything else run faster since there was no
> memory left to run more.
..
Another useful improvement, in the days of PCP, was to specify
a number of buffers. I think that we used about 8 buffers, which
gave a useful improvement when reading cards and simultaneously
printing.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410156 is a reply to message #410147] Wed, 21 July 2021 13:14 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2021-07-21, Thomas Koenig <tkoenig@netcologne.de> wrote:

> undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb:
>
>> In the old days we calculated optimum blocksizes based on our logical
>> record length and the device we were writing to. Disk drives had different
>> lengths.
>
> I remember the recommendation for FB80 files switching from a
> blocksize of 3200 bytes to a blocksize of 3120 bytes when the
> computer center switched generations of mainframes and therefore
> disk type, as well.
>
> 30 years ago I could probably have told you the disk drive
> types this was optimum for. Not any more :-)

I wrote a utility that would take a record size and generate
a table of optimum blocking factors for a 2311 or 2314 drive.
My memory has faded somewhat too, but I suspect you were
working with neither of them. :-) I seem to recall that
1680 was a good block size for 80-byte records on the 2314.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
Re: iBM System/3 FORTRAN for engineering/science work? [message #410158 is a reply to message #410128] Wed, 21 July 2021 14:08 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:
> On Sunday, July 18, 2021 at 11:21:30 AM UTC-4, Charlie Gibbs wrote:
>> True, but one shop I worked in went to the other extreme:
>> full-track blocking for every file. One system consisted
>> of a program that created half a dozen work files (even
>> though some were redundant). Six output files - plus an
>> input file - with a track size of 10K meant that 70K of
>> the machine's 192K went to buffers alone. It certainly
>> didn't make anything else run faster since there was no
>> memory left to run more.
>
> Yes, on older machines too high a blocking factor caused problems, too.
> They used to warn us not max out on blocking factors. Memory was not
> unlimited, as you say.

When designing a system we considered the program with the most files and
figured how much memory would be required for double-buffering. We’d
usually start looking at half-track blocking, then look at single-buffering
on some datasets if we couldn’t do double. Systems design was fun in the
olden days.

>
> In the old days we calculated optimum blocksizes based on our logical
> record length and the device we were writing to. Disk drives had different
> lengths.

Switching from 2311 to 2314 meant recalculating everything. There were a
lot of programs to do this. I wrote one, and only this year found out I
could have gotten one from SHARE.

>
> I once experimented with a S/360 tape drive. I found a block size of
> about 5,000 characters was the max, anything beyond that would
> generate I/O errors and waste time with retries.

At first I misread this as disk. I don’t recall a lot of problems with
tape, but maybe we didn’t use huge blick sizes.

>
> Later machines could handle maximum blocks. Indeed, in later years
> we coded BLKSIZE=0 in our JCL which would maximize blocksize
> for whatever device we were creating a file on. As data centers got
> bigger and had a mix of devices, the dynamic automatic blocking
> made it easier for us, since we didn't have to worry about the device
> type.

Blksize=0 only came along much later, maybe as part of SMS on MVS/XA or
maybe /ESA. It was better than sliced bread, but wouldn’t have worked on
machines with limited storage where we counted every byte.

>
> Amazing, in the early days we were intimately familiar with the
> characteristics of say the 2311 vs. the 2314 or various tape drives.
> Our coding depended on it to optimize performance and memory.
> But now, devices evolve and we don't even know what we're writing to.
> The system handles it all automatically, with automatic file allocation.

All the fun is gone :-(

>
> Sometimes we had older jobs with hardcoded low blocksizes. They
> ran poorly. Upgrading it was an easy way to improve performance.
>
> In a few cases, such as files being sent out or specialty devices,
> blocksize and other issues still mattered. JCL still allows to set
> specifics if desired.
>
>
>
>



--
Pete
Re: iBM System/3 FORTRAN for engineering/science work? [message #410238 is a reply to message #410148] Fri, 23 July 2021 15:01 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Wednesday, July 21, 2021 at 1:49:05 AM UTC-4, Robin Vowels wrote:

> Another useful improvement, in the days of PCP, was to specify
> a number of buffers. I think that we used about 8 buffers, which
> gave a useful improvement when reading cards and simultaneously
> printing.

In the QuickBasic compiler there was a LEN option for file I/O.
Setting this high would greatly improve reading and writing speed,
especially with floppy drives since a bigger block would be written.
I don't think it saved any space (sector drives), but on floppies it
reduced the start/stop action, allowing more continuous writing.

(This was not available on the interpreted QBASIC version).
Re: iBM System/3 FORTRAN for engineering/science work? [message #410239 is a reply to message #410158] Fri, 23 July 2021 15:16 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Wednesday, July 21, 2021 at 2:08:33 PM UTC-4, Peter Flass wrote:


> When designing a system we considered the program with the most files and
> figured how much memory would be required for double-buffering. We’d
> usually start looking at half-track blocking, then look at single-buffering
> on some datasets if we couldn’t do double. Systems design was fun in the
> olden days.

On the smaller S/360 and equivalent competitors (e.g. RCA Spectra),
physical size was limited but files could be big. Careful design
was required, as you describe, to fit everything in without flogging
the machine.

In my opinion, sometimes data centers would attempt to do too much
on their machines of the time--loading too much data volume or program
complexity onto a machine that simply wasn't up to handling it. Programmers
would pull all sorts of tricks to squeeze it all in, and be on standby if something
blew up--which happened often.

And it seemed that no sooner that they got a bigger machine then they loaded
another new bulky application on it which continued the old problems.

Indeed, I think these problems continued until roughly 1990 (depending on a
site) when hardware finally got cheap enough that they could buy adequately
sized and powered machines (enough memory, I/O channels, disk and space,
and CPU speed).





>> In the old days we calculated optimum blocksizes based on our logical
>> record length and the device we were writing to. Disk drives had different
>> lengths.
> Switching from 2311 to 2314 meant recalculating everything. There were a
> lot of programs to do this. I wrote one, and only this year found out I
> could have gotten one from SHARE.

Yes, every time the data center upgraded conversions were necessary
to reflect the new hardware, even if it was the same brand of computer.


>> I once experimented with a S/360 tape drive. I found a block size of
>> about 5,000 characters was the max, anything beyond that would
>> generate I/O errors and waste time with retries.
> At first I misread this as disk. I don’t recall a lot of problems with
> tape, but maybe we didn’t use huge blick sizes.

We were using a cheapo S/360 tape drive. I think the later models
on S/370 with 6250 bpi worked better. And of course the later
cartridges were even better.



>> Later machines could handle maximum blocks. Indeed, in later years
>> we coded BLKSIZE=0 in our JCL which would maximize blocksize
>> for whatever device we were creating a file on. As data centers got
>> bigger and had a mix of devices, the dynamic automatic blocking
>> made it easier for us, since we didn't have to worry about the device
>> type.
> Blksize=0 only came along much later, maybe as part of SMS on MVS/XA or
> maybe /ESA. It was better than sliced bread, but wouldn’t have worked on
> machines with limited storage where we counted every byte.

SMS had a lot of advantages, especially for the system programmers, but
there were some growing pains. It took a lot of overhead and wouldn't
have been possible on older machines. But overall it worked out well,
including automated backups.

I think SMS introduced compression onto IBM mainframes which could
save a lot of space. PKZIP on steroids. Transparent to application people..

Indeed, I think one function of SMS was to automatically offload little
used files to slower medium freeing high speed stuff for more important
files. Again, transparent.




>> Amazing, in the early days we were intimately familiar with the
>> characteristics of say the 2311 vs. the 2314 or various tape drives.
>> Our coding depended on it to optimize performance and memory.
>> But now, devices evolve and we don't even know what we're writing to.
>> The system handles it all automatically, with automatic file allocation..

> All the fun is gone :-(

There was a sense of pride in knowing how to use the reference cards
and optimize settings to get improved performance and space usage.
Likewise in coding for efficiency.

Indeed, that was fun.

On the flip side, as mentioned above when systems were squeezed to
the hilt, failures were common and a nuisance to fix. Getting a phone
call at 3 a.m. to come in (no home terminals then) was not much fun
and happened too often.

I think at least one data center programmers got tired of the 3 a.m.
phone calls and pressured management to spend the money to
upgrade the machine to reduce troubles.

At least a few data centers suffered massive resignations when
staff just got tired of problems.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410240 is a reply to message #410156] Fri, 23 July 2021 15:19 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Wednesday, July 21, 2021 at 1:15:18 PM UTC-4, Charlie Gibbs wrote:

> I wrote a utility that would take a record size and generate
> a table of optimum blocking factors for a 2311 or 2314 drive.
> My memory has faded somewhat too, but I suspect you were
> working with neither of them. :-) I seem to recall that
> 1680 was a good block size for 80-byte records on the 2314.

Another challenge was allocating space for VSAM files, which could
be trickier than sequential or even older ISAM files. I don't think
the parameters of the IDCAMS programs, like control interval
sizes, were automated and more a guesswork.

Indeed, it seemed to me many programmers didn't care for
VSAM, preferring to use databases (i.e. DB2, IMS, etc).
But VSAM had a lot of advantages, including performance
since it had a lot less overhead than a formal database system.

Our 90/30 had ISAM.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410266 is a reply to message #410239] Sat, 24 July 2021 17:35 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2021-07-23, undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:

> On Wednesday, July 21, 2021 at 2:08:33 PM UTC-4, Peter Flass wrote:
>
>> When designing a system we considered the program with the most files
>> and figured how much memory would be required for double-buffering.
>> We’d usually start looking at half-track blocking, then look at
>> single-buffering on some datasets if we couldn’t do double. Systems
>> design was fun in the olden days.
>
> On the smaller S/360 and equivalent competitors (e.g. RCA Spectra),
> physical size was limited but files could be big. Careful design
> was required, as you describe, to fit everything in without flogging
> the machine.
>
> In my opinion, sometimes data centers would attempt to do too much
> on their machines of the time--loading too much data volume or program
> complexity onto a machine that simply wasn't up to handling it.
> Programmers would pull all sorts of tricks to squeeze it all in,
> and be on standby if something blew up--which happened often.

Part of this was due to computer salesmen lowballing hardware
requirements. Once the machine had been sold and installed,
it was usually too late to back out, so the customer sucked it
up and paid for the additional hardware that, had they known,
they would have needed all along.

> And it seemed that no sooner that they got a bigger machine then they
> loaded another new bulky application on it which continued the old
> problems.

Parkinson's Law states that work expands so as to fill the time
available for its completion. There are various corollaries,
such as programs expanding to fill available memory, data files
expanding to fill available drives, etc.

> Indeed, I think these problems continued until roughly 1990 (depending
> on a site) when hardware finally got cheap enough that they could buy
> adequately sized and powered machines (enough memory, I/O channels,
> disk and space, and CPU speed).

Alas, there is a difference between "could" and "did". Even in the
last few years we've run into problems when customers scrimped on
disk space: not just with inadequate drives but also with bad
partitioning schemes.
x
> There was a sense of pride in knowing how to use the reference cards
> and optimize settings to get improved performance and space usage.
> Likewise in coding for efficiency.
>
> Indeed, that was fun.
>
> On the flip side, as mentioned above when systems were squeezed to
> the hilt, failures were common and a nuisance to fix. Getting a phone
> call at 3 a.m. to come in (no home terminals then) was not much fun
> and happened too often.

BTDTGTS (been there, done that, got the scars)
That's why, for a long time, I didn't have a telephone at home.
It had to be a _real_ emergency before someone would drive over,
bang on the door, wake up the landlady, and have her get me.

> I think at least one data center programmers got tired of the 3 a.m.
> phone calls and pressured management to spend the money to
> upgrade the machine to reduce troubles.
>
> At least a few data centers suffered massive resignations when
> staff just got tired of problems.

You just had to pray that management was intelligent enough to
take the hint.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
Re: iBM System/3 FORTRAN for engineering/science work? [message #410267 is a reply to message #410240] Sat, 24 July 2021 17:35 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2021-07-23, undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote:

> On Wednesday, July 21, 2021 at 1:15:18 PM UTC-4, Charlie Gibbs wrote:
>
>> I wrote a utility that would take a record size and generate
>> a table of optimum blocking factors for a 2311 or 2314 drive.
>> My memory has faded somewhat too, but I suspect you were
>> working with neither of them. :-) I seem to recall that
>> 1680 was a good block size for 80-byte records on the 2314.
>
> Another challenge was allocating space for VSAM files, which could
> be trickier than sequential or even older ISAM files. I don't think
> the parameters of the IDCAMS programs, like control interval
> sizes, were automated and more a guesswork.
>
> Indeed, it seemed to me many programmers didn't care for
> VSAM, preferring to use databases (i.e. DB2, IMS, etc).
> But VSAM had a lot of advantages, including performance
> since it had a lot less overhead than a formal database system.
>
> Our 90/30 had ISAM.

Did you get to the point where MIRAM files were introduced?
They were much nicer, and allowed indexing on up to 5 keys.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
Re: iBM System/3 FORTRAN for engineering/science work? [message #410298 is a reply to message #410266] Mon, 26 July 2021 16:09 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Saturday, July 24, 2021 at 5:36:10 PM UTC-4, Charlie Gibbs wrote:

>> I think at least one data center programmers got tired of the 3 a.m.
>> phone calls and pressured management to spend the money to
>> upgrade the machine to reduce troubles.
>> At least a few data centers suffered massive resignations when
>> staff just got tired of problems.

> You just had to pray that management was intelligent enough to
> take the hint.

Unfortunately, a lot of data center managements were not intelligent
enough and allowed massive disruptions. For some reason, high
corporate management supported them until it was too late.
A fix usually required very expensive consultants to dig through
everything. At least one large bank was forced to sell out to another
since its customers got too pissed off from the mess, but this was
not unique. Sometimes the trainwreck made the newspaper with
resultant bad publicity.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410299 is a reply to message #410267] Mon, 26 July 2021 16:13 Go to previous messageGo to next message
hancock4 is currently offline  hancock4
Messages: 6746
Registered: December 2011
Karma: 0
Senior Member
On Saturday, July 24, 2021 at 5:36:10 PM UTC-4, Charlie Gibbs wrote:
>> Our 90/30 had ISAM.
> Did you get to the point where MIRAM files were introduced?
> They were much nicer, and allowed indexing on up to 5 keys.

No, that was after my time.

On our IBM mainframe, we made use of VSAM alternate indexes
to allow for multiple non-unique keys (e.g. searching by name, DOB, etc).
Very efficient and worked well.

As mentioned, VSAM was kind of disparaged, everyone pushed for
a modern system like SQL. But our systems programmers and database
administrators, who monitored performance, noted that our VSAM system was
very efficient while they had problems with some SQL systems. Even on
new powerful machines, a sloppy SQL query could flog the machine.

Geez, we have one VSAM system now 45 years old, and will probably reach 50.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410326 is a reply to message #409905] Wed, 28 July 2021 01:07 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: gah4

On Wednesday, July 14, 2021 at 12:39:57 AM UTC-7, Quadibloc wrote:
> On Tuesday, July 13, 2021 at 4:11:16 PM UTC-6, undefined Hancock-4 wrote:
>
>> But the Programmers Guide provided valuable tips for coding and setup
>> for performance, efficiency, and maintainability. Unlike the language
>> reference, it was written in a more casual understandable style.

> What I remembered of the FORTRAN Programmer's Guide is that it
> gave technical details of the use of the compiler - things like calling
> sequences - which were useful for certain advanced programming
> tasks.

> I had not noticed that it was an approachable guide to writing better
> programs, as you describe these books.

It seems that instead of (usual) a hash table, Fortran H uses six balanced
trees. One suggestion in the PG is to distribute variable names over
the 1 to 6 characters about equally, for faster compilation.

Writing better programs, but not necessarily more readable.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410327 is a reply to message #410147] Wed, 28 July 2021 01:13 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: gah4

On Tuesday, July 20, 2021 at 10:29:40 PM UTC-7, Thomas Koenig wrote:

(snip)

> I remember the recommendation for FB80 files switching from a
> blocksize of 3200 bytes to a blocksize of 3120 bytes when the
> computer center switched generations of mainframes and therefore
> disk type, as well.

> 30 years ago I could probably have told you the disk drive
> types this was optimum for. Not any more :-)

3120 is (rounded down from 3156) quarter track 3330. It is also not so far from
half track 2314, so if you don't know which one, it is a good choice.
Re: iBM System/3 FORTRAN for engineering/science work? [message #410362 is a reply to message #410326] Fri, 30 July 2021 00:19 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Tuesday, July 27, 2021 at 11:07:41 PM UTC-6, gah4 wrote:

> It seems that instead of (usual) a hash table, Fortran H uses six balanced
> trees. One suggestion in the PG is to distribute variable names over
> the 1 to 6 characters about equally, for faster compilation.

And here I thought that just meant it used six hash tables.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #410363 is a reply to message #410362] Fri, 30 July 2021 00:20 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Thursday, July 29, 2021 at 10:19:03 PM UTC-6, Quadibloc wrote:
> On Tuesday, July 27, 2021 at 11:07:41 PM UTC-6, gah4 wrote:

>> It seems that instead of (usual) a hash table, Fortran H uses six balanced
>> trees. One suggestion in the PG is to distribute variable names over
>> the 1 to 6 characters about equally, for faster compilation.

> And here I thought that just meant it used six hash tables.

Actually, no more than five hash tables. It would be silly to use a
_hash_ table for one-letter variable names.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #410370 is a reply to message #410363] Fri, 30 July 2021 10:57 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Thursday, July 29, 2021 at 10:19:03 PM UTC-6, Quadibloc wrote:
>> On Tuesday, July 27, 2021 at 11:07:41 PM UTC-6, gah4 wrote:
>
>>> It seems that instead of (usual) a hash table, Fortran H uses six balanced
>>> trees. One suggestion in the PG is to distribute variable names over
>>> the 1 to 6 characters about equally, for faster compilation.
>
>> And here I thought that just meant it used six hash tables.
>
> Actually, no more than five hash tables. It would be silly to use a
> _hash_ table for one-letter variable names.

:-)



--
Pete
Re: iBM System/3 FORTRAN for engineering/science work? [message #411680 is a reply to message #409493] Tue, 05 October 2021 18:56 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: antispam

Bob Eager <news0009@eager.cx> wrote:
> On Wed, 30 Jun 2021 15:56:40 -0400, Rich Alderson wrote:
>
>> (NB: When I first started programming, the language was called "PL/1"
>> in the
>> IBM manuals; by the time I started using it professionally, years
>> before the UChicago job, they had gone to the "PL/I" version of the
>> name.)
>
> One of my colleagues did his Ph.D. in the 1960s. He had also worked for
> IBM. Part of his research was the construction of a general purpose macro
> language and processor.
>
> As a piss take of IBM, he called it ML/I. (Macro Language 1)
>
> http://www.ml1.org.uk
>

The site says "sources" but I was not able to find neither LOWL sources
nor C sources. Is this intentional or are they somewhere?

--
Waldek Hebisch
Re: iBM System/3 FORTRAN for engineering/science work? [message #411685 is a reply to message #411680] Tue, 05 October 2021 19:13 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Branimir Maksimovic

On 2021-10-05, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:
> The site says "sources" but I was not able to find neither LOWL sources
> nor C sources. Is this intentional or are they somewhere?
>
Swift is what is most engineering language now,
you need IQ more then 150 to program in it :P

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp
Re: iBM System/3 FORTRAN for engineering/science work? [message #411700 is a reply to message #411685] Wed, 06 October 2021 06:55 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Tuesday, October 5, 2021 at 5:13:22 PM UTC-6, Branimir Maksimovic wrote:

> Swift is what is most engineering language now,
> you need IQ more then 150 to program in it

From what I have heard of Swift, it is a nice language.

But I thought it was only for writing applications for the
Macintosh computer and iOS devices.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #411701 is a reply to message #411680] Wed, 06 October 2021 07:00 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Tuesday, October 5, 2021 at 4:56:34 PM UTC-6, anti...@math.uni.wroc.pl wrote:

> The site says "sources" but I was not able to find neither LOWL sources
> nor C sources. Is this intentional or are they somewhere?

At first, I wasn't able to figure out where the sources were at all, but when
I followed the links to the details of implementations for various operating
systems, most didn't have sources, but the first source I did find...

was in PLAN, for the GEORGE 3 operating system on the ICL 1900.

So I suppose the site only has such sources as happen to be available,
and the source for Microsoft Windows, which would have the most interest,
is not among those.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #411702 is a reply to message #411701] Wed, 06 October 2021 07:07 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Wednesday, October 6, 2021 at 5:01:00 AM UTC-6, Quadibloc wrote:
> On Tuesday, October 5, 2021 at 4:56:34 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>
>> The site says "sources" but I was not able to find neither LOWL sources
>> nor C sources. Is this intentional or are they somewhere?

> At first, I wasn't able to figure out where the sources were at all, but when
> I followed the links to the details of implementations for various operating
> systems, most didn't have sources, but the first source I did find...
>
> was in PLAN, for the GEORGE 3 operating system on the ICL 1900.
>
> So I suppose the site only has such sources as happen to be available,
> and the source for Microsoft Windows, which would have the most interest,
> is not among those.

As for LOWL, which appears to have been a language similar to PL/360, what
I did find was that for the IBM 370 implementation for MVS, they had at least
the *assembler* sources, *plus* the macros used in converting from LOWL to
assembler. So you might be able to work backwards.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #411703 is a reply to message #411702] Wed, 06 October 2021 07:11 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Wednesday, October 6, 2021 at 5:07:24 AM UTC-6, Quadibloc wrote:

> As for LOWL, which appears to have been a language similar to PL/360, what
> I did find was that for the IBM 370 implementation for MVS, they had at least
> the *assembler* sources, *plus* the macros used in converting from LOWL to
> assembler. So you might be able to work backwards.

Ah. I now see that LOWL is not specific to System/370, but instead is specific
to ML/1. It was described in "Macro Languages and Portable Software" by
Peter C. Brown.

So the LOWL source would have been the basis for all the implementations,
not just for the IBM mainframe implementation.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #411704 is a reply to message #411680] Wed, 06 October 2021 07:18 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Tuesday, October 5, 2021 at 4:56:34 PM UTC-6, anti...@math.uni.wroc.pl wrote:

> The site says "sources" but I was not able to find neither LOWL sources
> nor C sources. Is this intentional or are they somewhere?

It turns out the LOWL source is linked to from *this* page:

http://www.ml1.org.uk/implementation.html

about "How ML/1 is implemented", since it is the root from which
many implementations on different platforms were developed.

From the discussion there, it appears that many implementors at
one time had access to the "C-Map", Bob Eager's conversion of
the source for ML/1 to C. Even though I didn't notice it on the site,
then, that implies there is a good chance of it floating around somewhere.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #411705 is a reply to message #411704] Wed, 06 October 2021 07:21 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Wednesday, October 6, 2021 at 5:18:21 AM UTC-6, Quadibloc wrote:
> On Tuesday, October 5, 2021 at 4:56:34 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>> The site says "sources" but I was not able to find neither LOWL sources
>> nor C sources. Is this intentional or are they somewhere?
> It turns out the LOWL source is linked to from *this* page:
>
> http://www.ml1.org.uk/implementation.html
>
> about "How ML/1 is implemented", since it is the root from which
> many implementations on different platforms were developed.

That page also states that the C source is available... *on request*,
so presumably one will have to agree to certain conditions to obtain
it from the web site operator.

John Savard
Re: iBM System/3 FORTRAN for engineering/science work? [message #411706 is a reply to message #411700] Wed, 06 October 2021 08:32 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Branimir Maksimovic

On 2021-10-06, Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Tuesday, October 5, 2021 at 5:13:22 PM UTC-6, Branimir Maksimovic wrote:
>
>> Swift is what is most engineering language now,
>> you need IQ more then 150 to program in it
>
> From what I have heard of Swift, it is a nice language.
>
> But I thought it was only for writing applications for the
> Macintosh computer and iOS devices.

You can write on Linux also, only Windows is not
supported, but on Linux you have to write
everything from scratch as Foundation libraries
are not available :P
Swift is really C++ done right...
>
> John Savard
Greets, Branimir.

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp
Re: iBM System/3 FORTRAN for engineering/science work? [message #411707 is a reply to message #411704] Wed, 06 October 2021 08:45 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Wed, 06 Oct 2021 04:18:20 -0700, Quadibloc wrote:

> On Tuesday, October 5, 2021 at 4:56:34 PM UTC-6,
> anti...@math.uni.wroc.pl wrote:
>
>> The site says "sources" but I was not able to find neither LOWL sources
>> nor C sources. Is this intentional or are they somewhere?
>
> It turns out the LOWL source is linked to from *this* page:
>
> http://www.ml1.org.uk/implementation.html
>
> about "How ML/1 is implemented", since it is the root from which many
> implementations on different platforms were developed.
>
> From the discussion there, it appears that many implementors at one time
> had access to the "C-Map", Bob Eager's conversion of the source for ML/1
> to C. Even though I didn't notice it on the site,
> then, that implies there is a good chance of it floating around
> somewhere.

I can supply it on demand. Email me.



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: iBM System/3 FORTRAN for engineering/science work? [message #411708 is a reply to message #411702] Wed, 06 October 2021 08:49 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Wed, 06 Oct 2021 04:07:23 -0700, Quadibloc wrote:

> As for LOWL, which appears to have been a language similar to PL/360,
> what I did find was that for the IBM 370 implementation for MVS, they
> had at least the *assembler* sources, *plus* the macros used in
> converting from LOWL to assembler. So you might be able to work
> backwards.

LOWL is an assembly language. PL/360 is a bit higher level than that. You
may be thinking of L, which was the original implementation language for
ML/I. Quite difficult to map, hence the low level version - LOWL.

And both L and LOWL versions are on the site.

http://www.ml1.org.uk/implementation.html



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: iBM System/3 FORTRAN for engineering/science work? [message #411709 is a reply to message #411703] Wed, 06 October 2021 08:50 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Wed, 06 Oct 2021 04:11:51 -0700, Quadibloc wrote:

> On Wednesday, October 6, 2021 at 5:07:24 AM UTC-6, Quadibloc wrote:
>
>> As for LOWL, which appears to have been a language similar to PL/360,
>> what I did find was that for the IBM 370 implementation for MVS, they
>> had at least the *assembler* sources, *plus* the macros used in
>> converting from LOWL to assembler. So you might be able to work
>> backwards.
>
> Ah. I now see that LOWL is not specific to System/370, but instead is
> specific to ML/1. It was described in "Macro Languages and Portable
> Software" by Peter C. Brown.
>
> So the LOWL source would have been the basis for all the
> implementations,
> not just for the IBM mainframe implementation.

Very early ones were done with L, but not many.

The 370 one was done with LOWL. I remember doing that one...

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: iBM System/3 FORTRAN for engineering/science work? [message #411711 is a reply to message #411702] Wed, 06 October 2021 09:22 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Wed, 06 Oct 2021 04:07:23 -0700, Quadibloc wrote:

> As for LOWL, which appears to have been a language similar to PL/360,
> what I did find was that for the IBM 370 implementation for MVS, they
> had at least the *assembler* sources, *plus* the macros used in
> converting from LOWL to assembler. So you might be able to work
> backwards.

Essentially, there are all the sources I have been able to find. I did
many of the implementations myself, so they are mostly there (I have lost
one or two). In particular, I don't have the PDP-10 version, but that
would be pretty easy (I may do it sometime). I did do it originally, in
competition with a guy implementing STAGE2!



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: iBM System/3 FORTRAN for engineering/science work? [message #411712 is a reply to message #411706] Wed, 06 October 2021 09:11 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Wed, 06 Oct 2021 12:32:35 GMT
Branimir Maksimovic <branimir.maksimovic@icloud.com> wrote:

> Swift is really C++ done right...

I thought that was D.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Re: iBM System/3 FORTRAN for engineering/science work? [message #411713 is a reply to message #411712] Wed, 06 October 2021 09:34 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Branimir Maksimovic

On 2021-10-06, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Wed, 06 Oct 2021 12:32:35 GMT
> Branimir Maksimovic <branimir.maksimovic@icloud.com> wrote:
>
>> Swift is really C++ done right...
>
> I thought that was D.
>
D has GC, and is old, too mutch like Java...

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp
Re: iBM System/3 FORTRAN for engineering/science work? [message #411723 is a reply to message #411708] Wed, 06 October 2021 20:40 Go to previous messageGo to previous message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Wednesday, October 6, 2021 at 6:49:03 AM UTC-6, Bob Eager wrote:

> And both L and LOWL versions are on the site.
>
> http://www.ml1.org.uk/implementation.html

As you may have seen from my later posts, I eventually did
find them myself; between my posts and yours, Waldek
Hebisch, who originally asked about C and LOWL sources,
should be able to find what he needs.

John Savard
Pages (4): [ «    1  2  3  4    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: Who Knew ?
Next Topic: Re: Telemedicine forecast by "The Jetsons" (1962)
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 14:04:56 EDT 2024

Total time taken to generate the page: 0.04596 seconds