| IBM Midrange today? [message #384228] |
Wed, 29 May 2019 15:32  |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Once upon a time IBM had the popular AS/400 line of computers.
I think they evolved into the "i series", but I'm not sure
what became of that. The IBM webpage focuses on "solutions".
I did find this:
https://en.wikipedia.org/wiki/IBM_i
Anyway, is anyone familiar with what became of the AS/400
and what its customers use today?
|
|
|
|
| Re: IBM Midrange today? [message #384231 is a reply to message #384228] |
Wed, 29 May 2019 18:36  |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> Once upon a time IBM had the popular AS/400 line of computers.
> I think they evolved into the "i series", but I'm not sure
> what became of that. The IBM webpage focuses on "solutions".
>
> I did find this:
> https://en.wikipedia.org/wiki/IBM_i
>
> Anyway, is anyone familiar with what became of the AS/400
> and what its customers use today?
One and the same.
Existing I series customers still call their computer AS/400.
Very impressive systems with software done right.
A pleasure to work with, even the RPG on these systems is done right.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #384232 is a reply to message #384228] |
Wed, 29 May 2019 18:42 |
|
|
Originally posted by: J. Clarke
On Wed, 29 May 2019 12:32:27 -0700 (PDT), hancock4@bbs.cpcn.com wrote:
> Once upon a time IBM had the popular AS/400 line of computers.
> I think they evolved into the "i series", but I'm not sure
> what became of that. The IBM webpage focuses on "solutions".
>
> I did find this:
> https://en.wikipedia.org/wiki/IBM_i
>
>
> Anyway, is anyone familiar with what became of the AS/400
> and what its customers use today?
If it's carrying AS/400 workloads it would I believe be the "i"
operating system, which if I understand correctly can run on Power
architecture or on some x86 systems.
|
|
|
|
| Re: IBM Midrange today? [message #384866 is a reply to message #384231] |
Thu, 11 July 2019 10:14 |
|
|
Originally posted by: Pamela
On 23:36 29 May 2019, Dan Espen <dan1espen@gmail.com> wrote:
> hancock4@bbs.cpcn.com writes:
>
>> Once upon a time IBM had the popular AS/400 line of computers.
>> I think they evolved into the "i series", but I'm not sure
>> what became of that. The IBM webpage focuses on "solutions".
>>
>> I did find this:
>> https://en.wikipedia.org/wiki/IBM_i
>>
>> Anyway, is anyone familiar with what became of the AS/400
>> and what its customers use today?
>
> One and the same.
>
> Existing I series customers still call their computer AS/400.
True oldies might even refer to the System/38. :)
> Very impressive systems with software done right.
> A pleasure to work with, even the RPG on these systems is done right.
Wasn't RPG easily outclassed by other languages?
|
|
|
|
| Re: IBM Midrange today? [message #384873 is a reply to message #384866] |
Thu, 11 July 2019 14:12 |
Charlie Gibbs
Messages: 5354
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-07-11, Pamela <pamela.poster@gmail.com> wrote:
> On 23:36 29 May 2019, Dan Espen <dan1espen@gmail.com> wrote:
>
>> hancock4@bbs.cpcn.com writes:
>>
>>> Once upon a time IBM had the popular AS/400 line of computers.
>>> I think they evolved into the "i series", but I'm not sure
>>> what became of that. The IBM webpage focuses on "solutions".
>>>
>>> I did find this:
>>> https://en.wikipedia.org/wiki/IBM_i
>>>
>>> Anyway, is anyone familiar with what became of the AS/400
>>> and what its customers use today?
>>
>> One and the same.
>>
>> Existing I series customers still call their computer AS/400.
>
> True oldies might even refer to the System/38. :)
>
>> Very impressive systems with software done right.
>> A pleasure to work with, even the RPG on these systems is done right.
>
> Wasn't RPG easily outclassed by other languages?
Depends. When used for the purpose for which it was intended
(generating report programs, for you anagram freaks), it did a
good job. The trouble began when IBM forgot what RPG stood for,
and started promoting its use in places where it didn't belong.
"When all you have is a hammer..."
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ Fight low-contrast text in web pages! http://contrastrebellion.com
|
|
|
|
| Re: IBM Midrange today? [message #384888 is a reply to message #384866] |
Thu, 11 July 2019 20:55 |
Peter Flass
Messages: 8402
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Pamela <pamela.poster@gmail.com> wrote:
> On 23:36 29 May 2019, Dan Espen <dan1espen@gmail.com> wrote:
>
>> hancock4@bbs.cpcn.com writes:
>>
>>> Once upon a time IBM had the popular AS/400 line of computers.
>>> I think they evolved into the "i series", but I'm not sure
>>> what became of that. The IBM webpage focuses on "solutions".
>>>
>>> I did find this:
>>> https://en.wikipedia.org/wiki/IBM_i
>>>
>>> Anyway, is anyone familiar with what became of the AS/400
>>> and what its customers use today?
>>
>> One and the same.
>>
>> Existing I series customers still call their computer AS/400.
>
> True oldies might even refer to the System/38. :)
>
>> Very impressive systems with software done right.
>> A pleasure to work with, even the RPG on these systems is done right.
>
> Wasn't RPG easily outclassed by other languages?
>
AFAIK it is the language of choice on those systems. I don’t think anyone
who programmed RPG back in the 60s would recognize the language.
--
Pete
|
|
|
|
| Re: IBM Midrange today? [message #384921 is a reply to message #384873] |
Fri, 12 July 2019 15:41 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Thursday, July 11, 2019 at 2:13:34 PM UTC-4, Charlie Gibbs wrote:
>> Wasn't RPG easily outclassed by other languages?
>
> Depends. When used for the purpose for which it was intended
> (generating report programs, for you anagram freaks), it did a
> good job. The trouble began when IBM forgot what RPG stood for,
> and started promoting its use in places where it didn't belong.
>
> "When all you have is a hammer..."
RPG was an excellent language for its day. Remember, that
was nearly 60 years ago and computers were much smaller
and less powerful. Before the advent of 4GL's like
Easytrieve or DYL, RPG fit a need for "quick and dirty"
reports.
According to the IBM history, RPG was intended to make
it easier to transition from tabulator plugboards to
programming. Supposedly, the RPG coding was similar to
wiring plugboards. I don't know how true that was
in practice.
I should note that personally I didn't care for RPG.
But I knew many who liked it.
|
|
|
|
| Re: IBM Midrange today? [message #384923 is a reply to message #384888] |
Fri, 12 July 2019 15:44 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Thursday, July 11, 2019 at 8:55:05 PM UTC-4, Peter Flass wrote:
>> Wasn't RPG easily outclassed by other languages?
>>
>
> AFAIK it is the language of choice on those systems. I don’t think anyone
> who programmed RPG back in the 60s would recognize the language.
Yes, modern RPG is very different than the original. The original
RPG had an automatic 'cycle'. This was discarded in later versions.
There is even a Visual RPG.
https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do? &solution=52949
I would venture that the evolution in RPG is analogous to
that of Dartmouth BASIC to Visual Basic. Visual Basic
is very different than the original.
|
|
|
|
| Re: IBM Midrange today? [message #384926 is a reply to message #384921] |
Fri, 12 July 2019 16:21 |
Anne & Lynn Wheel
Messages: 3161
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> RPG was an excellent language for its day. Remember, that
> was nearly 60 years ago and computers were much smaller
> and less powerful. Before the advent of 4GL's like
> Easytrieve or DYL, RPG fit a need for "quick and dirty"
> reports.
several spin-offs from science center ... offering virtual machine based
commercial services (first cp/67 and later vm/370). Some also quickly
moved up value stream to specializing in services for financial industry
and offerring 4GL languages (one of people a decade at one such company
involved in "first financial language", then left to co-found software
arts and do visicalc)
NCSS
https://en.wikipedia.org/wiki/National_CSS
had RAMIS from mathematica
https://en.wikipedia.org/wiki/Ramis_software
then NOMAD (NCSS Owned, Maintained, and Developed)
https://en.wikipedia.org/wiki/Nomad_software
more
https://www.computerhistory.org/collections/catalog/10265818 2
some mathematica people than doing RAMIS followon as FOCUS to be used by
TYMSHARE (on their virtual machine VM370/CMS offering, NCSS competitor),
prompting NCSS to do NOMAD
http://corphist.computerhistory.org/corphist/view.php?s=stor ies&id=139&PHPSESSID=ccd241...
more
http://www.decosta.com/Nomad/tales/history.html
tymshare
https://en.wikipedia.org/wiki/Tymshare
4th generation programming language
https://en.wikipedia.org/wiki/Fourth-generation_programming_ language
Also in the 70s, IBM San Jose Research did the original sql/relational
system/r on vm370 ... but had lots of fights with the rest of
corporation. While the corporation was preoccuped with EAGLE (next new
DBMS), managed to do tech transfer to Endicott and get it out as
SQL/DS. Later when EAGLE imploded, request was how fast could it be
ported to MVS ... and was eventually released as DB2, originally for
decision support *ONLY*.
science center posts
http://www.garlic.com/~lynn/subtopic.html#545tech
virtual machine commerecial online service posts
http://www.garlic.com/~lynn/submain.html#online
system/r posts
http://www.garlic.com/~lynn/submain.html#systemr
mentions science center spinoffs, as well as "First Financial Language"
done in 60s
https://archive.computerhistory.org/resources/access/text/20 15/09/102702884-05-01-acc.pdf
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: IBM Midrange today? [message #384930 is a reply to message #384228] |
Fri, 12 July 2019 17:24 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, May 29, 2019 at 1:32:29 PM UTC-6, hanc...@bbs.cpcn.com wrote:
> Once upon a time IBM had the popular AS/400 line of computers.
> I think they evolved into the "i series", but I'm not sure
> what became of that.
The iSeries still exists, but it uses a software layer over PowerPC hardware now.
John Savard
|
|
|
|
| Re: IBM Midrange today? [message #384977 is a reply to message #384930] |
Sat, 13 July 2019 15:33 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, July 12, 2019 at 5:25:00 PM UTC-4, Quadibloc wrote:
> The iSeries still exists, but it uses a software layer over PowerPC hardware now.
When I used an AS/400, I wondered about its assembler language
and instruction set. On a S/360, one could order an assembly
listing out of COBOL compile to see the generated instructions
or of course write in assembler. I don't believe that was
possible on the AS/400; one had to use a higher level language.
I read a book on the AS/400 and there was an awful lot going
on 'under the hood'.
Personally, I didn't see the advantage of all that layering.
The AS/400 took a lot from the failed Future System. To me,
they should've kept it simple, and followed the S/360
tradition, though maintaining compatibility with the S/3x series.
Actually, Z series is quite layered too these days.
I kind of miss the concept of the 1401 which had no 'software
layer' nor operating system (for the most part). You put in
your object deck, hit the load button, and your instructions
were directly executed by the hardware. But according to
Campbell-Kelly, the real genius of the 1401 was its high
speed card-reader and printer, faster than most to that
point.
|
|
|
|
| Re: IBM Midrange today? [message #384983 is a reply to message #384977] |
Sat, 13 July 2019 20:41 |
|
|
Originally posted by: Mike Albanese
On Saturday, July 13, 2019 at 3:33:11 PM UTC-4, hanc...@bbs.cpcn.com wrote:
> Personally, I didn't see the advantage of all that layering.
It's been a long time and perhaps I don't recall well, but didn't the layering come about in part because IBM had one group coming from the S/3, S/32, S/34, S/36 machines, and another group coming from the S/38 (seemingly a beast of a different nature), and they wanted to consolidate everyone onto one midrange platform?
|
|
|
|
| Re: IBM Midrange today? [message #384984 is a reply to message #384977] |
Sat, 13 July 2019 21:19 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> On Friday, July 12, 2019 at 5:25:00 PM UTC-4, Quadibloc wrote:
>
>> The iSeries still exists, but it uses a software layer over PowerPC
>> hardware now.
>
> When I used an AS/400, I wondered about its assembler language and
> instruction set. On a S/360, one could order an assembly listing out
> of COBOL compile to see the generated instructions or of course write
> in assembler. I don't believe that was possible on the AS/400; one
> had to use a higher level language. I read a book on the AS/400 and
> there was an awful lot going on 'under the hood'.
I put in a few years on the earlier version SYS/34. Wrote lots of COBOL
and kept some of the RPG from the first attempt. Unlike COBOL on S/360,
there was no need to look at any Assembler level code. I don't remember
any storage dumps, just messages that told you what went wrong and gave
you source code line number.
You just never needed to look under the hood.
> Personally, I didn't see the advantage of all that layering. The
> AS/400 took a lot from the failed Future System. To me, they
> should've kept it simple, and followed the S/360 tradition, though
> maintaining compatibility with the S/3x series.
Agree. The S/34 was really easy to use. It didn't need the stuff that
came with S/38 and AS/400. That's vendor lock in, plain and simple.
> Actually, Z series is quite layered too these days.
>
> I kind of miss the concept of the 1401 which had no 'software layer'
> nor operating system (for the most part). You put in your object
> deck, hit the load button, and your instructions were directly
> executed by the hardware.
When S/360 was announced, I knew IBM would FU the OS so I was reading
Principles of Operation to figure out how to use the bare metal.
As Lynn is about to tell us, it's not easy to write code using S/360
bare metal.
> But according to Campbell-Kelly, the real genius of the 1401 was its
> high speed card-reader and printer, faster than most to that point.
They sure worked well. They got a bit faster when revamped for S/360.
The OP code to read a card was "1".
The OP code to print a line was "2".
I read in the manual that OP code "3" would read a card and print a
line. I never did work out a mainline design that could use that OP
code.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #384985 is a reply to message #384983] |
Sat, 13 July 2019 21:23 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Mike Albanese <allegrippus@gmail.com> writes:
> On Saturday, July 13, 2019 at 3:33:11 PM UTC-4, hanc...@bbs.cpcn.com wrote:
>
>> Personally, I didn't see the advantage of all that layering.
>
> It's been a long time and perhaps I don't recall well, but didn't the
> layering come about in part because IBM had one group coming from the
> S/3, S/32, S/34, S/36 machines, and another group coming from the S/38
> (seemingly a beast of a different nature), and they wanted to
> consolidate everyone onto one midrange platform?
I always thought of S/38 as derived from the rest of the S/3 line.
The database/memory object stuff is added on to what was there before.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #384996 is a reply to message #384984] |
Sun, 14 July 2019 04:59 |
|
|
Originally posted by: Bob Eager
On Sat, 13 Jul 2019 21:19:34 -0400, Dan Espen wrote:
> When S/360 was announced, I knew IBM would FU the OS so I was reading
> Principles of Operation to figure out how to use the bare metal.
I used it to port an earlier operating system (home grown) to the XA
architecture. Of course, a major part was the channel code.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: IBM Midrange today? [message #384998 is a reply to message #384985] |
Sun, 14 July 2019 13:27 |
|
|
Originally posted by: Pamela
On 02:23 14 Jul 2019, Dan Espen <dan1espen@gmail.com> wrote:
> Mike Albanese <allegrippus@gmail.com> writes:
>
>> On Saturday, July 13, 2019 at 3:33:11 PM UTC-4, hanc...@bbs.cpcn.com
>> wrote:
>>
>>> Personally, I didn't see the advantage of all that layering.
>>
>> It's been a long time and perhaps I don't recall well, but didn't the
>> layering come about in part because IBM had one group coming from the
>> S/3, S/32, S/34, S/36 machines, and another group coming from the S/38
>> (seemingly a beast of a different nature), and they wanted to
>> consolidate everyone onto one midrange platform?
>
> I always thought of S/38 as derived from the rest of the S/3 line. The
> database/memory object stuff is added on to what was there before.
>
The S/38 was quite different to S34 etc but it came from the same group.
The S/38 had a deep layer of microcode which provided an object-oriented
machine -- although the official documentation never referred to it as
such.
This also accounted for performance difficulties because there were many
connections between objects which needed resolving when changes were made.
|
|
|
|
| Re: IBM Midrange today? [message #384999 is a reply to message #384984] |
Sun, 14 July 2019 15:00 |
Peter Flass
Messages: 8402
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> hancock4@bbs.cpcn.com writes:
>
>> On Friday, July 12, 2019 at 5:25:00 PM UTC-4, Quadibloc wrote:
>>
>>> The iSeries still exists, but it uses a software layer over PowerPC
>>> hardware now.
>>
>> When I used an AS/400, I wondered about its assembler language and
>> instruction set. On a S/360, one could order an assembly listing out
>> of COBOL compile to see the generated instructions or of course write
>> in assembler. I don't believe that was possible on the AS/400; one
>> had to use a higher level language. I read a book on the AS/400 and
>> there was an awful lot going on 'under the hood'.
>
> I put in a few years on the earlier version SYS/34. Wrote lots of COBOL
> and kept some of the RPG from the first attempt. Unlike COBOL on S/360,
> there was no need to look at any Assembler level code. I don't remember
> any storage dumps, just messages that told you what went wrong and gave
> you source code line number.
>
> You just never needed to look under the hood.
>
>> Personally, I didn't see the advantage of all that layering. The
>> AS/400 took a lot from the failed Future System. To me, they
>> should've kept it simple, and followed the S/360 tradition, though
>> maintaining compatibility with the S/3x series.
>
> Agree. The S/34 was really easy to use. It didn't need the stuff that
> came with S/38 and AS/400. That's vendor lock in, plain and simple.
>
>> Actually, Z series is quite layered too these days.
>>
>> I kind of miss the concept of the 1401 which had no 'software layer'
>> nor operating system (for the most part). You put in your object
>> deck, hit the load button, and your instructions were directly
>> executed by the hardware.
>
> When S/360 was announced, I knew IBM would FU the OS so I was reading
> Principles of Operation to figure out how to use the bare metal.
>
> As Lynn is about to tell us, it's not easy to write code using S/360
> bare metal.
Certainly a lot easier than modern systems.
>
>> But according to Campbell-Kelly, the real genius of the 1401 was its
>> high speed card-reader and printer, faster than most to that point.
>
> They sure worked well. They got a bit faster when revamped for S/360.
>
> The OP code to read a card was "1".
> The OP code to print a line was "2".
>
> I read in the manual that OP code "3" would read a card and print a
> line. I never did work out a mainline design that could use that OP
> code.
>
Card to print?
--
Pete
|
|
|
|
| Re: IBM Midrange today? [message #385010 is a reply to message #384999] |
Sun, 14 July 2019 17:41 |
|
|
Originally posted by: Terry Kennedy
On Sunday, July 14, 2019 at 3:00:38 PM UTC-4, Peter Flass wrote:
> Card to print?
Yes. AKA "interpreting punch".
We kept our 1442 (punch only) up through a 4331. Likewise for the 2501 reader. We flirted with the 2560 MFCM (Mother you-know-what Card Mangler) on a 370/125, but went back to the 2501/1442 on the follow-on /138.
|
|
|
|
| Re: IBM Midrange today? [message #385011 is a reply to message #384977] |
Sun, 14 July 2019 18:05 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, July 13, 2019 at 1:33:11 PM UTC-6, hanc...@bbs.cpcn.com wrote:
> Personally, I didn't see the advantage of all that layering.
It doesn't provide more performance per dollar to the customer, no.
But it does help to promote vendor lock-in.
John Savard
|
|
|
|
| Re: IBM Midrange today? [message #385014 is a reply to message #385010] |
Sun, 14 July 2019 18:31 |
Peter Flass
Messages: 8402
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Terry Kennedy <terry-groups@glaver.org> wrote:
> On Sunday, July 14, 2019 at 3:00:38 PM UTC-4, Peter Flass wrote:
>> Card to print?
>
> Yes. AKA "interpreting punch".
>
> We kept our 1442 (punch only) up through a 4331. Likewise for the 2501
> reader. We flirted with the 2560 MFCM (Mother you-know-what Card Mangler)
> on a 370/125, but went back to the 2501/1442 on the follow-on /138.
>
The MFCM could also interpret.
--
Pete
|
|
|
|
| Re: IBM Midrange today? [message #385015 is a reply to message #385011] |
Sun, 14 July 2019 18:31 |
Peter Flass
Messages: 8402
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Saturday, July 13, 2019 at 1:33:11 PM UTC-6, hanc...@bbs.cpcn.com wrote:
>
>> Personally, I didn't see the advantage of all that layering.
>
> It doesn't provide more performance per dollar to the customer, no.
>
> But it does help to promote vendor lock-in.
I’ve never worked on one. If it improves programmer performance that’s
probably a bigger money saver than faster hardware. People who have worked
on them have said they make it easy to get things done.
--
Pete
|
|
|
|
| Re: IBM Midrange today? [message #385016 is a reply to message #384998] |
Sun, 14 July 2019 18:35 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Pamela <pamela.poster@gmail.com> writes:
> On 02:23 14 Jul 2019, Dan Espen <dan1espen@gmail.com> wrote:
>
>> Mike Albanese <allegrippus@gmail.com> writes:
>>
>>> On Saturday, July 13, 2019 at 3:33:11 PM UTC-4, hanc...@bbs.cpcn.com
>>> wrote:
>>>
>>>> Personally, I didn't see the advantage of all that layering.
>>>
>>> It's been a long time and perhaps I don't recall well, but didn't the
>>> layering come about in part because IBM had one group coming from the
>>> S/3, S/32, S/34, S/36 machines, and another group coming from the S/38
>>> (seemingly a beast of a different nature), and they wanted to
>>> consolidate everyone onto one midrange platform?
>>
>> I always thought of S/38 as derived from the rest of the S/3 line. The
>> database/memory object stuff is added on to what was there before.
>>
>
> The S/38 was quite different to S34 etc but it came from the same group.
>
> The S/38 had a deep layer of microcode which provided an object-oriented
> machine -- although the official documentation never referred to it as
> such.
>
> This also accounted for performance difficulties because there were many
> connections between objects which needed resolving when changes were made.
Yes, it had the object orientied stuff, but all the software from S/3x
came over. OCL, SDA, RPG, can't remember all the TLAs.
There was a really nice software stack on the S/3 line.
I think that was part of why IBM was able to get the object stuff
to work.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385017 is a reply to message #384999] |
Sun, 14 July 2019 18:39 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> hancock4@bbs.cpcn.com writes:
>>
>>> On Friday, July 12, 2019 at 5:25:00 PM UTC-4, Quadibloc wrote:
>>>
>>>> The iSeries still exists, but it uses a software layer over PowerPC
>>>> hardware now.
>>>
>>> When I used an AS/400, I wondered about its assembler language and
>>> instruction set. On a S/360, one could order an assembly listing out
>>> of COBOL compile to see the generated instructions or of course write
>>> in assembler. I don't believe that was possible on the AS/400; one
>>> had to use a higher level language. I read a book on the AS/400 and
>>> there was an awful lot going on 'under the hood'.
>>
>> I put in a few years on the earlier version SYS/34. Wrote lots of COBOL
>> and kept some of the RPG from the first attempt. Unlike COBOL on S/360,
>> there was no need to look at any Assembler level code. I don't remember
>> any storage dumps, just messages that told you what went wrong and gave
>> you source code line number.
>>
>> You just never needed to look under the hood.
>>
>>> Personally, I didn't see the advantage of all that layering. The
>>> AS/400 took a lot from the failed Future System. To me, they
>>> should've kept it simple, and followed the S/360 tradition, though
>>> maintaining compatibility with the S/3x series.
>>
>> Agree. The S/34 was really easy to use. It didn't need the stuff that
>> came with S/38 and AS/400. That's vendor lock in, plain and simple.
>>
>>> Actually, Z series is quite layered too these days.
>>>
>>> I kind of miss the concept of the 1401 which had no 'software layer'
>>> nor operating system (for the most part). You put in your object
>>> deck, hit the load button, and your instructions were directly
>>> executed by the hardware.
>>
>> When S/360 was announced, I knew IBM would FU the OS so I was reading
>> Principles of Operation to figure out how to use the bare metal.
>>
>> As Lynn is about to tell us, it's not easy to write code using S/360
>> bare metal.
>
> Certainly a lot easier than modern systems.
>
>>
>>> But according to Campbell-Kelly, the real genius of the 1401 was its
>>> high speed card-reader and printer, faster than most to that point.
>>
>> They sure worked well. They got a bit faster when revamped for S/360.
>>
>> The OP code to read a card was "1".
>> The OP code to print a line was "2".
>>
>> I read in the manual that OP code "3" would read a card and print a
>> line. I never did work out a mainline design that could use that OP
>> code.
>
> Card to print?
Theoretically, but that was already written.
Like I said, I never did work out a good technique for
an application. Logically it would be an application that read cards
and printed, but working in the page skips, totals, headers just
never worked out for me.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385018 is a reply to message #385010] |
Sun, 14 July 2019 18:44 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Terry Kennedy <terry-groups@glaver.org> writes:
> On Sunday, July 14, 2019 at 3:00:38 PM UTC-4, Peter Flass wrote:
>> Card to print?
>
> Yes. AKA "interpreting punch".
>
> We kept our 1442 (punch only) up through a 4331. Likewise for the 2501
> reader. We flirted with the 2560 MFCM (Mother you-know-what Card
> Mangler) on a 370/125, but went back to the 2501/1442 on the follow-on
> /138.
1442 was usually found on a 1440.
One of the differences with the 1440 is that the card read command was
no longer "1".
One of the interesting things about the 1442 is that the cards made a
left hand turn in the internal feed path. Worked surprisingly well for us.
I worked with an MFCM on the model 20.
Never mangled anything.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385019 is a reply to message #385014] |
Sun, 14 July 2019 18:50 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Terry Kennedy <terry-groups@glaver.org> wrote:
>> On Sunday, July 14, 2019 at 3:00:38 PM UTC-4, Peter Flass wrote:
>>> Card to print?
>>
>> Yes. AKA "interpreting punch".
>>
>> We kept our 1442 (punch only) up through a 4331. Likewise for the 2501
>> reader. We flirted with the 2560 MFCM (Mother you-know-what Card Mangler)
>> on a 370/125, but went back to the 2501/1442 on the follow-on /138.
>
> The MFCM could also interpret.
Which I remember well from a program where I decided to spit out the
control totals for the job on a printed card. You didn't need to
punch any holes, just print.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385023 is a reply to message #385018] |
Sun, 14 July 2019 20:09 |
|
|
Originally posted by: Terry Kennedy
On Sunday, July 14, 2019 at 6:45:01 PM UTC-4, Dan Espen wrote:
> I worked with an MFCM on the model 20.
> Never mangled anything.
We described it as "2 input hoppers, 5 output bins, and a non-deterministic path between them". The flip-overs / shuffles / 90-degree turns didn't help, either. By the time the 370/125 came along, at least the specific unit our el-cheapo leasing company* foisted off on us was in pretty poor shape. The Power/VS environment we had to use (we were the "teaching people programming" group and got the machine after 3 PM from the "printing people's paychecks" group) selected different hoppers for read / punch and different output bins depending on what partition your job ran in. This caused student programming exercises like "read a bunch of data cards, sum them and punch some results on other cards" to punch onto other people's job decks. And of course, with students we'd get the occasional joker who tried to either punch or read a "lace card" (the 1442 had no problem punching those) which would gum up the works.
* Another example was that this leasing company delivered the CPU with half of the memory specified and a MAI add-on memory cabinet. The people who came to install it used a Sawzall to cut a 6" x 6" hole in the CPU cabinet to snake all of the memory wiring into the CPU. And the add-on memory had to be kept offline until a specific stage of IMPL and then put online, or the /125 would throw both "CPU early" and "CPU late" errors and halt until power-cycled.
|
|
|
|
| Re: IBM Midrange today? [message #385024 is a reply to message #385016] |
Sun, 14 July 2019 20:20 |
|
|
Originally posted by: Pamela
On 23:35 14 Jul 2019, Dan Espen <dan1espen@gmail.com> wrote:
> Pamela <pamela.poster@gmail.com> writes:
>
>> On 02:23 14 Jul 2019, Dan Espen <dan1espen@gmail.com> wrote:
>>
>>> Mike Albanese <allegrippus@gmail.com> writes:
>>>
>>>> On Saturday, July 13, 2019 at 3:33:11 PM UTC-4, hanc...@bbs.cpcn.com
>>>> wrote:
>>>>
>>>> > Personally, I didn't see the advantage of all that layering.
>>>>
>>>> It's been a long time and perhaps I don't recall well, but didn't the
>>>> layering come about in part because IBM had one group coming from the
>>>> S/3, S/32, S/34, S/36 machines, and another group coming from the
>>>> S/38 (seemingly a beast of a different nature), and they wanted to
>>>> consolidate everyone onto one midrange platform?
>>>
>>> I always thought of S/38 as derived from the rest of the S/3 line. The
>>> database/memory object stuff is added on to what was there before.
>>>
>>
>> The S/38 was quite different to S34 etc but it came from the same
>> group.
>>
>> The S/38 had a deep layer of microcode which provided an
>> object-oriented machine -- although the official documentation never
>> referred to it as such.
>>
>> This also accounted for performance difficulties because there were
>> many connections between objects which needed resolving when changes
>> were made.
>
> Yes, it had the object orientied stuff, but all the software from S/3x
> came over. OCL, SDA, RPG, can't remember all the TLAs. There was a
> really nice software stack on the S/3 line.
>
> I think that was part of why IBM was able to get the object stuff to
> work.
I think it may be the other way around.
The S/38 provided a platform for those utilities and HLL to sit on. The
object oriention of the S/38 lay below the "machine abstraction layer" and
was never really visible from the higher layers where those utilities were
being used.
The S/38 and AS/400 both suffered from a clunky screen interface at a time
when PC terminals and their graphics were becoming available. IBM
investment in new development always seemed too restricted.
|
|
|
|
| Re: IBM Midrange today? [message #385025 is a reply to message #384983] |
Sun, 14 July 2019 20:22 |
|
|
Originally posted by: Pamela
On 01:41 14 Jul 2019, Mike Albanese <allegrippus@gmail.com> wrote:
> On Saturday, July 13, 2019 at 3:33:11 PM UTC-4, hanc...@bbs.cpcn.com
> wrote:
>
>> Personally, I didn't see the advantage of all that layering.
>
> It's been a long time and perhaps I don't recall well, but didn't the
> layering come about in part because IBM had one group coming from the
> S/3, S/32, S/34, S/36 machines, and another group coming from the S/38
> (seemingly a beast of a different nature), and they wanted to
> consolidate everyone onto one midrange platform?
The consolidation never really happened. I don't think it had much to do
with software layering inside the big daddy of the range, S/38.
|
|
|
|
| Re: IBM Midrange today? [message #385027 is a reply to message #384977] |
Sun, 14 July 2019 20:29 |
|
|
Originally posted by: Pamela
On 20:33 13 Jul 2019, hancock4@bbs.cpcn.com wrote:
> On Friday, July 12, 2019 at 5:25:00 PM UTC-4, Quadibloc wrote:
>
>> The iSeries still exists, but it uses a software layer over PowerPC
>> hardware now.
>
> When I used an AS/400, I wondered about its assembler language and
> instruction set. On a S/360, one could order an assembly listing out of
> COBOL compile to see the generated instructions or of course write in
> assembler. I don't believe that was possible on the AS/400; one had to
> use a higher level language. I read a book on the AS/400 and there was
> an awful lot going on 'under the hood'.
>
> Personally, I didn't see the advantage of all that layering. The AS/400
> took a lot from the failed Future System. To me, they should've kept it
> simple, and followed the S/360 tradition, though maintaining
> compatibility with the S/3x series.
>
> Actually, Z series is quite layered too these days.
>
> I kind of miss the concept of the 1401 which had no 'software layer' nor
> operating system (for the most part). You put in your object deck, hit
> the load button, and your instructions were directly executed by the
> hardware. But according to Campbell-Kelly, the real genius of the 1401
> was its high speed card-reader and printer, faster than most to that
> point.
The design philosophy of Future Systems or S/38 was to not permit access
to the lower levels and certainly not to assembler level instructions, as
might be found on S/360. This seemed very restrictive but the machines
were designed as a no-tinkering box to sit in an office somewhere and need
little "deep" technical support.
In practise the competition were the smaller IBM 4300 machines which seemed
ridiculously over complicated (and overpriced) to someone from a S/3X shop.
|
|
|
|
| Re: IBM Midrange today? [message #385029 is a reply to message #385027] |
Sun, 14 July 2019 22:22 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Pamela <pamela.poster@gmail.com> writes:
> On 20:33 13 Jul 2019, hancock4@bbs.cpcn.com wrote:
>
>> On Friday, July 12, 2019 at 5:25:00 PM UTC-4, Quadibloc wrote:
>>
>>> The iSeries still exists, but it uses a software layer over PowerPC
>>> hardware now.
>>
>> When I used an AS/400, I wondered about its assembler language and
>> instruction set. On a S/360, one could order an assembly listing out of
>> COBOL compile to see the generated instructions or of course write in
>> assembler. I don't believe that was possible on the AS/400; one had to
>> use a higher level language. I read a book on the AS/400 and there was
>> an awful lot going on 'under the hood'.
>>
>> Personally, I didn't see the advantage of all that layering. The AS/400
>> took a lot from the failed Future System. To me, they should've kept it
>> simple, and followed the S/360 tradition, though maintaining
>> compatibility with the S/3x series.
>>
>> Actually, Z series is quite layered too these days.
>>
>> I kind of miss the concept of the 1401 which had no 'software layer' nor
>> operating system (for the most part). You put in your object deck, hit
>> the load button, and your instructions were directly executed by the
>> hardware. But according to Campbell-Kelly, the real genius of the 1401
>> was its high speed card-reader and printer, faster than most to that
>> point.
>
> The design philosophy of Future Systems or S/38 was to not permit access
> to the lower levels and certainly not to assembler level instructions, as
> might be found on S/360. This seemed very restrictive but the machines
> were designed as a no-tinkering box to sit in an office somewhere and need
> little "deep" technical support.
>
> In practise the competition were the smaller IBM 4300 machines which seemed
> ridiculously over complicated (and overpriced) to someone from a S/3X shop.
One of my projects was Inventory and Costing in a division of a large
manufacturer. We did I&C on S/34 at the same time the main office was
trying to do the same thing on an MVS/CMS mainframe using IMS DB/DC.
One of the differences between the projects is that the S/34 project
actually finished. We did that with a staff that maxed out at 4.
The main office stuff never finished, but they had about 50 consultants
on site.
Before we get the traditional consultant bad-mouthing, I was a
consultant too.
I offered to pull the mainframe effort out of it's hole, but
Arthur Anderson refused to turn over project control to me.
Anyway, the software on the S/34 was a big help getting the job done.
The S/34 application would have run rings around the mainframe stuff (if
it ever got done).
I used to get some satisfaction at month end, corporate would start
costing in the evening and invariably, next morning we'd hear they were
doing a re-run. This could go on for a few days. The S/34 would
do the same thing (for just our division) in 20 minutes, always with
perfect results.
I like those 5250s.
All input fields should have column separators.
The field exit key (like a tab key) should always right justify and zero
fill numeric fields.
I wonder how far those block oriented, fixed width character terminals could go.
I've long been in favor of 3270 protocol being extended to larger and
smaller characters. I don't think most businesses really need a full on graphics
terminal to get the job done.
Back to the 5250, some genius at IBM figured out that it would be a good
idea to design a terminal with a flat top:
http://www.corestore.org/5251-1.jpg
You could actually store things on top of that thing, like perhaps
operator instructions (and a nice plant). Put the plant on the desk to
water it.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385031 is a reply to message #385029] |
Mon, 15 July 2019 00:34 |
Charlie Gibbs
Messages: 5354
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-07-15, Dan Espen <dan1espen@gmail.com> wrote:
> Back to the 5250, some genius at IBM figured out that it would be a good
> idea to design a terminal with a flat top:
>
> http://www.corestore.org/5251-1.jpg
>
> You could actually store things on top of that thing, like perhaps
> operator instructions (and a nice plant). Put the plant on the desk to
> water it.
The tops of Univac printers were flat, and just close enough to level
to tempt you to put listings on them - and just far enough from level
that said listings would slide off and splatter all over the floor as
soon as your back was turned.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
|
|
| Re: IBM Midrange today? [message #385036 is a reply to message #384977] |
Mon, 15 July 2019 03:29 |
Anne & Lynn Wheel
Messages: 3161
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> Personally, I didn't see the advantage of all that layering.
> The AS/400 took a lot from the failed Future System. To me,
> they should've kept it simple, and followed the S/360
> tradition, though maintaining compatibility with the S/3x series.
original AS/400 was "Fort Knox" ... next generation Rochester merging
variety of S/3* products and use a risc/801 processor (part of the
effort at the time to move all internal microprocessors to common
801/risc base, low&mid-range 370, AS/400, controllers, etc ... for
various reasons all the efforts floundered and returned to traditional
custom CISC microprocessors). The floundering Fort Knox was way behind
schedule and never came out ... "Silverlake" was merged followon for
both s/36 and s/38.
https://wiki.midrange.com/index.php/Silverlake
The Project Silverlake started as a sequel to a predecessor project
code-named Fort Knox. The Fort Knox project had a lofty goal of
creating the ultimate minicomputer in response to the successes of
Digital Equipment Corporation(DEC) in the early 1980s. It was given
the code name Fort Knox after the location of the U.S. government's
gold depository.
The goal of Fort Knox was to unify several smaller IBM computers then
on the market and put DEC and other competitors on the run. Due to a
rigid development process, the specifications for creating this
computer grew more complex as each day passed. By 1985, it became
obvious that the development team was years away from a workable
product for the market, and the project was canceled.
....
The Silverlake project was highly ambitious, but strict controls were
put in place to keep its scope under the reins. Instead of everything
being invested from the ground up, key building blocks were taken from
the completed parts of the Fort Knox project as well as from two of
the products being replaced--the System 36 and the System 38
minicomputers.
.... snip ...
http://ibmsystemsmag.com/ibmi/trends/italk-with-tuohy/soltis -part2/
http://gallery.lib.umn.edu/exhibits/show/digital-state/ibm-r ochester
https://en.wikipedia.org/wiki/IBM_System_i#History
(Silverlake) AS/400 did eventually move to 801/risc ... in this case
power/pc ... but a decade later.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: IBM Midrange today? [message #385063 is a reply to message #384984] |
Mon, 15 July 2019 16:55 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, July 13, 2019 at 9:19:37 PM UTC-4, Dan Espen wrote:
>> But according to Campbell-Kelly, the real genius of the 1401 was its
>> high speed card-reader and printer, faster than most to that point.
>
> They sure worked well. They got a bit faster when revamped for S/360.
>
> The OP code to read a card was "1".
> The OP code to print a line was "2".
>
> I read in the manual that OP code "3" would read a card and print a
> line. I never did work out a mainline design that could use that OP
> code.
The Reference Manual for the 1401 includes the following blurb
about delays in the I/O process:
Card Read Instructions
The card reader operates at a rated speed of 800 cycles
per minute (one cycle every 75 milliseconds). The card
reading speed depends on the timing of the READ A CARD
instructions in the program. To effect continuous cardreading
at the rate of 800 cards per minute, a READ A
CARD instruction must be given within 10 milliseconds
after the preceding card has been actually read into
the IBM 1401 Processing Unit. If more than 10 milliseconds
are required for processing, the card read
speed drops to 400 cards per. minute. This happens
because of the mechanical structure of the card feed.
There is only one point in the cycle during which a card
can feed, and if no read impulse signals the feed at
that time, the reader will be delayed for 75 milliseconds
(or until the same point in the following cycle).
The read release special feature permits job time
improvements by allowing more actual processing time
during the read cycle.
http://www.bitsavers.org/pdf/ibm/1401/A24-1403-5_1401_Refere nce_Apr62.pdf
I recommend the above manual as it gives a lot of interesting details
about the base model 1401 and optional features that could improve
performance, such as overlap and more storage instructions.
The manual also includes timing for each instruction. Theorectically,
someone could calculate in advance how long it would take a program
to run. However, it would seem that doing such calculations would
be rather tedious (they're not simple and they didn't have convenient
electronic calculators back then).
In typical practice, I don't know if programmers took the above
into consideration while programming. I heard of some who did,
such as doing a READ, then doing a few more instructions before
the data became available. I know a lot of effort was made to
improve hardware performance in 1401 days, and even in assembler
coding in S/360 days.
As to all the optional features for a 1401, I don't know how that
worked under S/360 emulation. I'm _guessing_ that emulation
included them, but maybe not.
I also have no idea how much the optional features cost, and whether
they were worth the extra cost in terms of added performance. I know
some sites were on a tight budget and could only afford the bare bones
equipment. For instance, some shops used the 024 keypunch, which unlike
the 026, did not have a print and was a little cheaper. The 1401 came
with as little as 1,400 characters of memory, and I knew of sites that
had only that. I have no idea what the various levels of memory
on a 1401 would cost--how much more did a 16k 1401 cost vs. a 1.4k?
As mentioned, in the later 1960s, IBM continued to offer the 1401
to new customers at a discounted price even though S/360 was
available. This only lasted for a few years as the 1401s
began to age in the 1970s and not be reliable for business service.
Of course, then IBM could sell the 1401 users a model 30 or 40.
|
|
|
|
| Re: IBM Midrange today? [message #385064 is a reply to message #385029] |
Mon, 15 July 2019 16:58 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Sunday, July 14, 2019 at 10:22:22 PM UTC-4, Dan Espen wrote:
> One of my projects was Inventory and Costing in a division of a large
> manufacturer. We did I&C on S/34 at the same time the main office was
> trying to do the same thing on an MVS/CMS mainframe using IMS DB/DC.
>
> One of the differences between the projects is that the S/34 project
> actually finished. We did that with a staff that maxed out at 4.
> The main office stuff never finished, but they had about 50 consultants
> on site.
>
> Before we get the traditional consultant bad-mouthing, I was a
> consultant too.
>
> I offered to pull the mainframe effort out of it's hole, but
> Arthur Anderson refused to turn over project control to me.
>
> Anyway, the software on the S/34 was a big help getting the job done.
> The S/34 application would have run rings around the mainframe stuff (if
> it ever got done).
Could you elaborate n what aspects of the S/34 that
made the development work go so much faster?
I know IMS was kind of cumbersome.
|
|
|
|
| Re: IBM Midrange today? [message #385069 is a reply to message #384930] |
Mon, 15 July 2019 19:07 |
Rich Alderson
Messages: 494
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> writes:
> On Wednesday, May 29, 2019 at 1:32:29 PM UTC-6, hanc...@bbs.cpcn.com wrote:
>> Once upon a time IBM had the popular AS/400 line of computers.
>> I think they evolved into the "i series", but I'm not sure
>> what became of that.
> The iSeries still exists, but it uses a software layer over PowerPC hardware now.
ITYM "Power", not "PowerPC".
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: IBM Midrange today? [message #385071 is a reply to message #385063] |
Mon, 15 July 2019 19:29 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> On Saturday, July 13, 2019 at 9:19:37 PM UTC-4, Dan Espen wrote:
>
>>> But according to Campbell-Kelly, the real genius of the 1401 was its
>>> high speed card-reader and printer, faster than most to that point.
>>
>> They sure worked well. They got a bit faster when revamped for S/360.
>>
>> The OP code to read a card was "1".
>> The OP code to print a line was "2".
>>
>> I read in the manual that OP code "3" would read a card and print a
>> line. I never did work out a mainline design that could use that OP
>> code.
>
>
> The Reference Manual for the 1401 includes the following blurb
> about delays in the I/O process:
>
> Card Read Instructions
>
> The card reader operates at a rated speed of 800 cycles
> per minute (one cycle every 75 milliseconds). The card
> reading speed depends on the timing of the READ A CARD
> instructions in the program. To effect continuous cardreading
> at the rate of 800 cards per minute, a READ A
> CARD instruction must be given within 10 milliseconds
> after the preceding card has been actually read into
> the IBM 1401 Processing Unit. If more than 10 milliseconds
> are required for processing, the card read
> speed drops to 400 cards per. minute. This happens
> because of the mechanical structure of the card feed.
> There is only one point in the cycle during which a card
> can feed, and if no read impulse signals the feed at
> that time, the reader will be delayed for 75 milliseconds
> (or until the same point in the following cycle).
> The read release special feature permits job time
> improvements by allowing more actual processing time
> during the read cycle.
>
> http://www.bitsavers.org/pdf/ibm/1401/A24-1403-5_1401_Refere nce_Apr62.pdf
>
> I recommend the above manual as it gives a lot of interesting details
> about the base model 1401 and optional features that could improve
> performance, such as overlap and more storage instructions.
>
> The manual also includes timing for each instruction. Theorectically,
> someone could calculate in advance how long it would take a program
> to run. However, it would seem that doing such calculations would
> be rather tedious (they're not simple and they didn't have convenient
> electronic calculators back then).
Some of us studied the timing values, but you first have to make a working
program. The instructions you use are mostly determined by the requirements.
> In typical practice, I don't know if programmers took the above
> into consideration while programming. I heard of some who did,
> such as doing a READ, then doing a few more instructions before
> the data became available. I know a lot of effort was made to
> improve hardware performance in 1401 days, and even in assembler
> coding in S/360 days.
Like today, the best way to get performance was to not do any
extra steps.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385072 is a reply to message #385064] |
Mon, 15 July 2019 20:45 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com writes:
> On Sunday, July 14, 2019 at 10:22:22 PM UTC-4, Dan Espen wrote:
>
>> One of my projects was Inventory and Costing in a division of a large
>> manufacturer. We did I&C on S/34 at the same time the main office was
>> trying to do the same thing on an MVS/CMS mainframe using IMS DB/DC.
>>
>> One of the differences between the projects is that the S/34 project
>> actually finished. We did that with a staff that maxed out at 4.
>> The main office stuff never finished, but they had about 50 consultants
>> on site.
>>
>> Before we get the traditional consultant bad-mouthing, I was a
>> consultant too.
>>
>> I offered to pull the mainframe effort out of it's hole, but
>> Arthur Anderson refused to turn over project control to me.
>>
>> Anyway, the software on the S/34 was a big help getting the job done.
>> The S/34 application would have run rings around the mainframe stuff (if
>> it ever got done).
>
> Could you elaborate n what aspects of the S/34 that
> made the development work go so much faster?
>
> I know IMS was kind of cumbersome.
IMS has MFS. Cumbersome is one way to describe it.
It's clearly something designed in meetings.
I never saw an IMS screen painter.
MFS screen definitions are written by a coder in Assembler.
The output is at least 4 load modules that take extra
work to start using for a test. I could go on...
On S/34 you lay out or change a screen using he Screen Design Aid SDA.
This lets you create input and output fields and attributes by
typing in the layout. You can move stuff around, everything you need.
The best part is that the screen layout is saved as plain text
which is not compiled, it's used at run time.
You can edit it yourself, that causes no problems for the screen design aid.
When I had to port a S/34 application to Wang/VS it was pretty simple
to use the same screen definitions.
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385078 is a reply to message #385063] |
Tue, 16 July 2019 04:07 |
Charlie Gibbs
Messages: 5354
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> I also have no idea how much the optional features cost, and whether
> they were worth the extra cost in terms of added performance. I know
> some sites were on a tight budget and could only afford the bare bones
> equipment. For instance, some shops used the 024 keypunch, which unlike
> the 026, did not have a print and was a little cheaper.
Even then, there was an intermediate option. One of the 026s at one
place I worked had a cheaper code plate; it would print alphanumerics
and a handful of special characters properly, but the rest of the
special characters came out as little square blocks. Not much fun
when you're trying to read program source code.
> The 1401 came with as little as 1,400 characters of memory, and I knew
> of sites that had only that. I have no idea what the various levels of
> memory on a 1401 would cost--how much more did a 16k 1401 cost vs. a 1.4k?
Probably a lot. The Univac 9300s I worked on could be had with memory in 8K
increments up to 32K. I worked on an 8K machine once. Again, not much fun.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: IBM Midrange today? [message #385081 is a reply to message #385078] |
Tue, 16 July 2019 07:37 |
|
|
Originally posted by: J. Clarke
On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:
> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
>> I also have no idea how much the optional features cost, and whether
>> they were worth the extra cost in terms of added performance. I know
>> some sites were on a tight budget and could only afford the bare bones
>> equipment. For instance, some shops used the 024 keypunch, which unlike
>> the 026, did not have a print and was a little cheaper.
>
> Even then, there was an intermediate option. One of the 026s at one
> place I worked had a cheaper code plate; it would print alphanumerics
> and a handful of special characters properly, but the rest of the
> special characters came out as little square blocks. Not much fun
> when you're trying to read program source code.
Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
standard character for the square bracket--at work we use those
godawful trigraphs because if we don't the 3270 uses one code for the
square bracket and Eclipse/Compuware uses a different one--at least
the trigraphs are equally unreadable on all devices.
>> The 1401 came with as little as 1,400 characters of memory, and I knew
>> of sites that had only that. I have no idea what the various levels of
>> memory on a 1401 would cost--how much more did a 16k 1401 cost vs. a 1.4k?
>
> Probably a lot. The Univac 9300s I worked on could be had with memory in 8K
> increments up to 32K. I worked on an 8K machine once. Again, not much fun.
|
|
|
|
Members
Search
Help
Register
Login
Home
