Happy 30th Birthday!
Mike Ross
codenamed 'Pacific'), the direct ancestor of the AS/400, and the only part of
the Future System project to make it into production, takes place in Rochester.
Price of standard system: $91,780.
"To the approximately 1,500 Rochester IBMers in the cafeteria, auditorium,
and room 1100, the unveiling of the IBM System/38 on October 24 marked
the end of almost eight years of effort. Described as GSD's flagship for the
80s, the "System/38 is the largest program we've ever introduced in GSD,"
said C. B. Rogers, Jr., IBM vice president and president, GSD, ''and it is one
of the top three or four largest programs ever introduced in IBM."
Today....
http://www.corestore.org/38.htm
http://www.youtube.com/watch?v=2cAWArBXRhE
Cheers!
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Tony Toews [MVP]
>October 24th 1978: the official announcement of the IBM System/38 (previously
>codenamed 'Pacific'), the direct ancestor of the AS/400, and the only part of
>the Future System project to make it into production, takes place in Rochester.
>Price of standard system: $91,780.
Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in the very late 70s
and throughout the '80s I was always curious about the history of the FS project. We
heard that code word but that was bout it.
>http://www.corestore.org/38.htm
>
>http://www.youtube.com/watch?v=2cAWArBXRhE
Thanks for the memories.
BTW anyone looking for a IBM 729 Mark 5 tape drive? See
http://msmvps.com/blogs/access/archive/2008/11/10/looking-for-a-ibm-729-mark-5-tape-drive.aspx
for details.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Tony Toews [MVP]
>Haven't done a lot of work
Arrgghhh. Having done a lot of work ....
Anne & Lynn Wheeler
"Tony Toews [MVP]" <tto...@telusplanet.net> writes:
> Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in the very late 70s
> and throughout the '80s I was always curious about the history of the FS project. We
> heard that code word but that was bout it.
recent post in "Greater IBM" blog in thread about as/400 20th b'day
http://www.garlic.com/2008k.html#59 Happy 20th Birthday, AS/400
recent post in "Greater IBM" blog mentioning Future System
http://www.garlic.com/~lynn/2008o.html#66 Open Source, Unbundling, and Future System
slightly tangential post on subject of security for FS documents
(in a linkedin blog):
http://www.garlic.com/~lynn/2008o.html#67 Invitation to Join Mainframe Security Guru Group
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Del Cecchi
"Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
news:m31vxif...@garlic.com...
>
> "Tony Toews [MVP]" <tto...@telusplanet.net> writes:
>> Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in
>> the very late 70s
>> and throughout the '80s I was always curious about the history of
>> the FS project. We
>> heard that code word but that was bout it.
>
> recent post in "Greater IBM" blog in thread about as/400 20th b'day
> http://www.garlic.com/2008k.html#59 Happy 20th Birthday, AS/400
dood, bad link.
Anne & Lynn Wheeler
>http://www.garlic.com/2008k.html#59 Happy 20th Birthday, AS/400
oops, finger slip
should have had "~lynn" like the rest:
http://www.garlic.com/~lynn/2008k.html#59 Happy 20th Birthday, AS/400
Jeff Jonas
> (previously codenamed 'Pacific'), the direct ancestor of the AS/400
Wasn't the System 38 a cover story to IEEE Spectrum
or Communications of the ACM
for the 2-way microcoded instruction set?
(the opcode and the operands' data type selected the microcode).
That sounded really neat.
And was that the system where the address space was so large
that all the disks were mapped the same as RAM?
I tried to get a copy of "Principles of Operation"
from the NY IBM office but they blew me off despite being a consultant
trying to justify a system 38 or 36 instead of the 34 being recommended.
Charles Richmond
> Mike Ross <mi...@corestore.org> wrote:
>
>> October 24th 1978: the official announcement of the IBM System/38 (previously
>> codenamed 'Pacific'), the direct ancestor of the AS/400, and the only part of
>> the Future System project to make it into production, takes place in Rochester.
>> Price of standard system: $91,780.
>
> Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in the very late 70s
> and throughout the '80s I was always curious about the history of the FS project. We
> heard that code word but that was bout it.
>
So does that mean that the RPG language dates from 1978 also???
Believe it or *not*, some folks actually used RPG for *payroll*
applications and such. Shocking!!!
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Karl Hanson
> Tony Toews [MVP] wrote:
>> Mike Ross <mi...@corestore.org> wrote:
>>
>>> October 24th 1978: the official announcement of the IBM System/38
>>> (previously
>>> codenamed 'Pacific'), the direct ancestor of the AS/400, and the only
>>> part of
>>> the Future System project to make it into production, takes place in
>>> Rochester.
>>> Price of standard system: $91,780.
>>
>> Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in the
>> very late 70s
>> and throughout the '80s I was always curious about the history of the
>> FS project. We
>> heard that code word but that was bout it.
>>
>
> So does that mean that the RPG language dates from 1978 also???
> Believe it or *not*, some folks actually used RPG for *payroll*
> applications and such. Shocking!!!
>
>
RPG dates back at least to the 1401:
http://en.wikipedia.org/wiki/IBM_1401
And there are places describing it on the 1620, such as:
http://www.rwc.uc.edu/koehler/cshist.html
--
Karl Hanson
Tony Toews [MVP]
>> Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in the very late 70s
>> and throughout the '80s I was always curious about the history of the FS project. We
>> heard that code word but that was bout it.
>>
Note that the above should be "Having done a lot of work..."
>So does that mean that the RPG language dates from 1978 also???
Previous. I recall seeing it at about 1974 somewhere. According to Wiki 1959 and
that wouldn't surprise me.
>Believe it or *not*, some folks actually used RPG for *payroll*
>applications and such. Shocking!!!
The below systems were all on IBM S/34s later migrated to S/36s.
?!?!?!? We wrote complex interactive applications in it. One was the ticket back
office system for what was Canada's third largest airline for a while. 3,000 lines
of code in the main data entry program. CP Air would routinely phone the client for
information on CP Air tickets that also travelled on my clients tickets as CP Air was
months slow in entering the ticket data. My client was up to date.
One client had six thousand employees on our payroll system. And they laid off their
school bus driver employees three times a year at Christmas, Easter break and summer
break. So our system printed 6,000 UI separation forms three times a year as well as
T4s at the end of the year.
In fact IBM Toronto was visiting the client looking at the paper and mail handling
systems the client was using. I think Pitney Bowes supplied the gear. This
included the chief payroll clerk and a VP of IBM Canada. As they were being shown
around the payroll clerk form IBM remarked in astonishment. "You folks do the UI
separation slips on the computer? We have to do them by hand."
Another client was one of Alberta's largest trucking firms with 400 or 500 employees.
Etc, etc.
Tony Toews [MVP]
>> October 24th 1978: the official announcement of the IBM System/38
>> (previously codenamed 'Pacific'), the direct ancestor of the AS/400
>
>Wasn't the System 38 a cover story to IEEE Spectrum
>or Communications of the ACM
>for the 2-way microcoded instruction set?
>(the opcode and the operands' data type selected the microcode).
>That sounded really neat.
I don't recall that.
>And was that the system where the address space was so large
>that all the disks were mapped the same as RAM?
Yes, the address was a huge number like 4 billion or some such. Impressive for 1978.
>I tried to get a copy of "Principles of Operation"
>from the NY IBM office but they blew me off despite being a consultant
>trying to justify a system 38 or 36 instead of the 34 being recommended.
Well, I dunno who would recommend a S/34 if the S/36 was available as it was smaller,
faster and more capicity.
To me the decision back then would've been what software is available that most
closely suits my business operation. Then purchase the hardware to suit.
Tony Toews [MVP]
>RPG dates back at least to the 1401:
>http://en.wikipedia.org/wiki/IBM_1401
My former boss worked on the 1401 as he was an IBM CE. I can ask him. I should get
back in touch with him anyhow. I haven't contacted him for about five or six years
no.
Charlie Gibbs
(Charles Richmond) writes:
> So does that mean that the RPG language dates from 1978 also???
Nope - I was writing RPG in 1970.
> Believe it or *not*, some folks actually used RPG for *payroll*
> applications and such. Shocking!!!
Been there, done that. Actually, RPG was pretty decent if you were
using it for the purpose for which it was intended: generating report
programs. We did have one program which my boss and I studied for
several days before finally giving up and rewriting the code from
scratch. If there had been an Obfuscated RPG Code Contest, this thing
would have won. (And yes, it was a payroll program - so perhaps part
of the blame should go there instead. To paraphrase the old quote,
it's possible to write unreadable payroll programs in any language -
thanks to the fact that the specs themselves are often unreadable.)
The real trouble began when IBM forgot what RPG stood for, and started
hacking up the language to make it do things that it was never intended
to do. Converting 3000-line RPG programs that handle terminals was one
of the less fun periods of my career.
--
/~\ cgi...@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.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
jmfbahciv
> Tony Toews [MVP] wrote:
>> Mike Ross <mi...@corestore.org> wrote:
>>
>>> October 24th 1978: the official announcement of the IBM System/38
>>> (previously
>>> codenamed 'Pacific'), the direct ancestor of the AS/400, and the only
>>> part of
>>> the Future System project to make it into production, takes place in
>>> Rochester.
>>> Price of standard system: $91,780.
>>
>> Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in the
>> very late 70s
>> and throughout the '80s I was always curious about the history of the
>> FS project. We
>> heard that code word but that was bout it.
>>
>
> So does that mean that the RPG language dates from 1978 also???
> Believe it or *not*, some folks actually used RPG for *payroll*
> applications and such. Shocking!!!
Those institute techie schools were teaching RPG as early as 1971
or 1972. those poor souls thought they were coding experts because
the "ITTs" told them so. Tape Prep hired one of these people.
That woman couldn't even manage to layout a document using RUNOFF
and turned her nose up stating that it wasn't programming. RPG
was a similar approach only it would display its counts.
/BAH
Del Cecchi
> je...@panix.com (Jeff Jonas) wrote:
>
>>> October 24th 1978: the official announcement of the IBM System/38
>>> (previously codenamed 'Pacific'), the direct ancestor of the AS/400
>> Wasn't the System 38 a cover story to IEEE Spectrum
>> or Communications of the ACM
>> for the 2-way microcoded instruction set?
>> (the opcode and the operands' data type selected the microcode).
>> That sounded really neat.
>
> I don't recall that.
>
>> And was that the system where the address space was so large
>> that all the disks were mapped the same as RAM?
>
> Yes, the address was a huge number like 4 billion or some such. Impressive for 1978.
way bigger than that. 48 bits of virtual address. Addresses weren't
reused until after IPL as I recall.
>
>> I tried to get a copy of "Principles of Operation"
>>from the NY IBM office but they blew me off despite being a consultant
>> trying to justify a system 38 or 36 instead of the 34 being recommended.
>
> Well, I dunno who would recommend a S/34 if the S/36 was available as it was smaller,
> faster and more capicity.
A 36 was an updateed /34 in which the execution of the user programs was
carried out by an actual processor (The MSP or Main Storage Processor)
instead of being emulated by the CSP--Control Storage Processor).
Michael Kennedy
> So does that mean that the RPG language dates from 1978 also???
> Believe it or *not*, some folks actually used RPG for *payroll*
> applications and such. Shocking!!!
As others have already said, all programming languages can be deemed
"good" or not, suitable or not, easy or not, etc, etc.
For "commercial" apps, RPG was generally VERY suitable. Eg, for a
multi-file "merge" batch process, it's usually trivial in RPG, but could
be quite complex in most other languages. Even more interestingly, most
"current" programmers would not even understand the issues involved!!
And, in my experience, RPG was totally "Rock Solid". Never, ever, a
"glitch", crash, mysterious event, etc....
Personally, I wrote hundreds of RPG programs - including some huge
"animals" - from the early '70s onwards, and still support RPG apps with
various clients, and still need to regularly write/modify/review RPG
apps... including code that was written in the '70s!
- Mike
Tony Toews [MVP]
>Those institute techie schools were teaching RPG as early as 1971
>or 1972. those poor souls thought they were coding experts because
>the "ITTs" told them so. Tape Prep hired one of these people.
>That woman couldn't even manage to layout a document using RUNOFF
>and turned her nose up stating that it wasn't programming. RPG
>was a similar approach only it would display its counts.
Those places still exist. <sigh>
Tony Toews [MVP]
>>> And was that the system where the address space was so large
>>> that all the disks were mapped the same as RAM?
>>
>> Yes, the address was a huge number like 4 billion or some such. Impressive for 1978.
>
>way bigger than that. 48 bits of virtual address.
Ok, at least I got the 4 right.
>Addresses weren't reused until after IPL as I recall.
I vaguelly recall an IBM person telling us that we could move the dials to some
particular settings and do an IPL. However that we would almost certainly never need
to do it in the lifetime of the machine.
Karl Hanson
> Del Cecchi <delcecchinos...@gmail.com> wrote:
>
>>>> And was that the system where the address space was so large
>>>> that all the disks were mapped the same as RAM?
>>> Yes, the address was a huge number like 4 billion or some such. Impressive for 1978.
>> way bigger than that. 48 bits of virtual address.
>
> Ok, at least I got the 4 right.
>
>> Addresses weren't reused until after IPL as I recall.
>
> I vaguelly recall an IBM person telling us that we could move the dials to some
> particular settings and do an IPL. However that we would almost certainly never need
> to do it in the lifetime of the machine.
>
This sounds like address regeneration. As explained in the reference
below, it depends on temp vs permanent address type. The PWRDWNSYS
(power down system) CL command had an ADRRGN (address regeneration)
option for permanent addresses.
Excerpt from:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc413735.pdf
Address Regeneration: On System/38, the
system assigns internal addresses and has a fixed
limit to the number that can be assigned. Two
address types, Permanent and Temporary, are
used and both percentages of the addresses used
are shown using DSPSYSSTS. On System/38,
the temporary addresses are generated again at
each initial program load (IPL), and you must periodically
generate the permanent addresses again.
--
Karl Hanson
Del Cecchi
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:n35lh4dl8jutc7tsv...@4ax.com...
RPG goes back to S/3 and perhaps to 1401 (1401 before my time)
del
Joe Morris
> "Tony Toews [MVP]" <tto...@telusplanet.net> wrote:
>> Charles Richmond <fri...@tx.rr.com> wrote:
>>>So does that mean that the RPG language dates from 1978 also???
>> Previous. I recall seeing it at about 1974 somewhere. According to Wiki
>> 1959 and that wouldn't surprise me.
>>>Believe it or *not*, some folks actually used RPG for *payroll*
>>>applications and such. Shocking!!!
>>
>> The below systems were all on IBM S/34s later migrated to S/36s.
>>
[snip]
>
> RPG goes back to S/3 and perhaps to 1401 (1401 before my time)
I'm not sure when it appeared (or if it was part of the original V1.0
release) but when I started running OS/360 in 1967 it was part of the
system. (E-level memory requirement; IESRPG. I have no idea why I remember
the 3-letter module name prefix after all these years...) Note that the
prefix immediately preceeds that of the E-level assembler for OS/360
(IETASM) which puts its origin (if not necessarily its release) rather early
in the life of OS/360.
One way of looking at RPG is to see it as an emulation of an EAM shop, with
various unit record devices (readers, punches, sorters, and accounting
machines) and their plugboards being mapped to the RPG statements and
fields.
Joe Morris
ArarghMai...@not.at.arargh.com
<delcecchi...@gmail.com> wrote:
<snip>
>
>RPG goes back to S/3 and perhaps to 1401 (1401 before my time)
IIRC, there was a RPG for the 1401.
I think that one intended use was to convert 407 jobs.
See HISTORY section:
http://en.wikipedia.org/wiki/Report_Program_Generator
--
ArarghMail811 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Rostyslaw J. Lewyckyj
For example Google for 1401 + rpg retrieves about 188.000 hits, and
http://en.wikipedia.org/wiki/Report_Program_Generator
states that IBMs RPG first appeared in 1959.
--
Rostyk
jmfbahciv
> jmfbahciv <jmfbahciv@aol> wrote:
>
>> Those institute techie schools were teaching RPG as early as 1971
>> or 1972. those poor souls thought they were coding experts because
>> the "ITTs" told them so. Tape Prep hired one of these people.
>> That woman couldn't even manage to layout a document using RUNOFF
>> and turned her nose up stating that it wasn't programming. RPG
>> was a similar approach only it would display its counts.
>
> Those places still exist. <sigh>
Yea, I know. :-( At least the people who go there know how
to plug the computer into the wall.
/BAH
jmfbahciv
Kewl. I liked using the COBOL report writer. I'd been told that
RPG provided similar functionality. My comment was about the
failure of that woman to transfer her RPG skills to laying out
docs using RUNOFF. Being able to plan how the document will look
without actually seeing the final result is what is required
with typesetting. RUNOFF was a simple-minded formatting program
that would do the filling and justifying for you. She couldn't
do any layout. I don't see how she did any RPG coding without
being able to layout the formats of the pages that the reporter
writer output.
I wasn't dis'ing RPG. I was dis'ing those idiotic schools.
/BAH
Tony Toews [MVP]
>This sounds like address regeneration. As explained in the reference
>below, it depends on temp vs permanent address type.
Thanks for the clarification. I was in the right province but not even in the
ballpark. <smile>
Michael Kennedy
> RPG provided similar functionality.
Yes - similar to Cobol... The overall result/output was the same, obviously!
Main difference was the "Cycle" mechanism built into RPG - as others
have mentioned, and as is covered in the Wikipedia references, etc. That
facility included all the main logic related to opening all files,
reading/writing them, "matching" them, sub-totalling, control
breaks/control levels, closing them, etc. The programmer just "plugged
into" the standard cycles, and programmed what was required at each
point in the cycles.
With COBOL, the programmer had to manually handle all File-I/O, which
can be quite tricky with multiple input files and multiple outputs.
OTOH, COBOL was a bit more "readable" than, seemingly, "random" letters
and digits that made up an RPG program.
Overall, RPG = COBOL + Millions of cups of coffee.
> My comment was about the
> failure of that woman to transfer her RPG skills to laying out
> docs using RUNOFF. Being able to plan how the document will look
> without actually seeing the final result is what is required
> with typesetting. RUNOFF was a simple-minded formatting program
> that would do the filling and justifying for you. She couldn't
> do any layout. I don't see how she did any RPG coding without
> being able to layout the formats of the pages that the reporter
> writer output.
Yep - with RPG, one always had to do thorough layouts of all files
(including reports), prior to coding. And with Cobol, etc, also!
- Mike
jmfbahciv
When I wrote report writing code (DEC didn't have RPG but it was
implemented in COBOL), I always used the SORT...USING clauses.
That way the manipulative code (and there was always requirements
to futz with the input and output data) was always in the logical
place (input or output, but not both). It kept later coders
from making big messes.
The LCG COBOL report writer had a bug which didn't do
the totals correctly. So the work-around was to move
the data by hand into temporary fields and use those
temp fields as the source of the report writing summing
fields. I don't think that bug was ever fixed and I'm
almost sure it was a Day 1 bug.
/BAH
/BAH
Michael Kennedy
> When I wrote report writing code (DEC didn't have RPG but it was
> implemented in COBOL), I always used the SORT...USING clauses.
> That way the manipulative code (and there was always requirements
> to futz with the input and output data) was always in the logical
> place (input or output, but not both). It kept later coders
> from making big messes.
Good!
It's at least 25 years since I did any serious COBOL work, but I vaguely
recall the SORT...USING facility, and, I think, there were some other
"report writing" tools also - in my case, mostly IBM COBOL on the
mainframes, and Micro-Focus on the "micros".
> The LCG COBOL report writer had a bug which didn't do
> the totals correctly. So the work-around was to move
> the data by hand into temporary fields and use those
> temp fields as the source of the report writing summing
> fields. I don't think that bug was ever fixed and I'm
> almost sure it was a Day 1 bug.
Nasty!, and a nice solution! I've no recollection of any "LCG" product,
and I've also no recollection of any similar bugs in the IBM or
Micro-Focus versions. I do recall a dreadful problem in some mainframe
versions - if one accessed a file that had not been "opened", the whole
app fell over, with reams of memory-dumps, etc. ...instead of a "File
Not Open" message/error!
- Mike
jmfbahciv
> jmfbahciv wrote:
<snip>
>
>> The LCG COBOL report writer had a bug which didn't do
>> the totals correctly. So the work-around was to move
>> the data by hand into temporary fields and use those
>> temp fields as the source of the report writing summing
>> fields. I don't think that bug was ever fixed and I'm
>> almost sure it was a Day 1 bug.
>
> Nasty!, and a nice solution! I've no recollection of any "LCG" product,
> and I've also no recollection of any similar bugs in the IBM or
> Micro-Focus versions. I do recall a dreadful problem in some mainframe
> versions - if one accessed a file that had not been "opened", the whole
> app fell over, with reams of memory-dumps, etc. ...instead of a "File
> Not Open" message/error!
<grin> Ooops. Do you remember if the bug ever got fixed?
/BAH
Michael Kennedy
>> Nasty!, and a nice solution! I've no recollection of any "LCG"
>> product, and I've also no recollection of any similar bugs in the IBM
>> or Micro-Focus versions. I do recall a dreadful problem in some
>> mainframe versions - if one accessed a file that had not been
>> "opened", the whole app fell over, with reams of memory-dumps, etc.
>> ...instead of a "File Not Open" message/error!
>
> <grin> Ooops. Do you remember if the bug ever got fixed?
I've no idea. I certainly hope so!!
- Mike
Peter Flass
>
> Nasty!, and a nice solution! I've no recollection of any "LCG" product,
> and I've also no recollection of any similar bugs in the IBM or
> Micro-Focus versions. I do recall a dreadful problem in some mainframe
> versions - if one accessed a file that had not been "opened", the whole
> app fell over, with reams of memory-dumps, etc. ...instead of a "File
> Not Open" message/error!
>
Only if you included a //SYSUDUMP DD statement, otherwise not.
What's wrong with ABEND S0C1 to tell you your file isn't open? <g>
Michael Kennedy
> Only if you included a //SYSUDUMP DD statement, otherwise not.
>
> What's wrong with ABEND S0C1 to tell you your file isn't open? <g>
Peter,
These nightmares occurred about 35 years ago!!! I don't recall the JCL
we were using <GG>. But I do recall many of us spending a few days
peering over reams of memory dumps, and looking through lots of the
internal ASM code, etc, etc.
The big issue was that we did not realise (until the end of the
debugging period) that the chaos was caused by an I-O to an unopened
file. If we had known, we would have just opened the darned file <G>.
It's kinda funny now; then not!
- Mike
jmfbahciv
Of course; that's why we call them war stories.
/BAH
Tony Toews [MVP]
>Main difference was the "Cycle" mechanism built into RPG - as others
>have mentioned, and as is covered in the Wikipedia references, etc. That
>facility included all the main logic related to opening all files,
>reading/writing them, "matching" them, sub-totalling, control
>breaks/control levels, closing them, etc. The programmer just "plugged
>into" the standard cycles, and programmed what was required at each
>point in the cycles.
I've been tightly focusing on Microsoft Access and dabbling in VB6.0 and SQL Server
for more than a decade now so I'm not familiar with what is out there these days.
Nevertheless there's nothing that quite matches the sheer convenience of the level
breaks and such that were built into RPG for reporting. Close somewhat but not
quite.
>Overall, RPG = COBOL + Millions of cups of coffee.
Add several keyboards per year to the COBOL side. <smile>
Mike Hore
> Mike Ross <mi...@corestore.org> wrote:
>
>> October 24th 1978: the official announcement of the IBM System/38 (previously
>> the Future System project to make it into production, takes place in Rochester.
>> Price of standard system: $91,780.
>
> and throughout the '80s I was always curious about the history of the FS project. We
>
>> http://www.corestore.org/38.htm
>>
>> http://www.youtube.com/watch?v=2cAWArBXRhE
>
> Thanks for the memories.
Coming late to this thread (as usual)...
For anybody interested in the internals of the S/38 - AS/400, I
recommend "Inside the AS/400" by Frank Soltis of Rochester who was one
of the chief designers. I got my copy from Amazon.
Cheers, Mike.
---------------------------------------------------------------
Mike Hore mike_h...@OVE.invalid.aapt.net.au
---------------------------------------------------------------
Jonathan Ball
>> Kewl. I liked using the COBOL report writer. I'd been told that
>> RPG provided similar functionality.
>
> Yes - similar to Cobol... The overall result/output was the same,
> obviously!
>
> Main difference was the "Cycle" mechanism built into RPG - as others
> have mentioned, and as is covered in the Wikipedia references, etc. That
> facility included all the main logic related to opening all files,
> reading/writing them, "matching" them, sub-totalling, control
> breaks/control levels, closing them, etc. The programmer just "plugged
> into" the standard cycles, and programmed what was required at each
> point in the cycles.
Moving from a S/370 COBOL environment to the S/38 in 1982 (using COBOL),
and then picking up RPG II/III about seven or eight months later, I
always thought RPG and its cycle reminded me of DYL 260, right down to
the letter-coded specification types and a cycle.
> With COBOL, the programmer had to manually handle all File-I/O, which
> can be quite tricky with multiple input files and multiple outputs.
I wouldn't say that, and of course, increasingly through the life cycle
of RPG III, RPG/400 and RPG IV, developers abandoned the cycle and did
virtually all the file I/O using full procedural files, anyway.
> OTOH, COBOL was a bit more "readable" than, seemingly, "random" letters
> and digits that made up an RPG program.
Being bilingual on the S/38 and AS/400 (now "tri", if you count the SQL
procedural language), I always thought there were certain things COBOL
did far better than RPG all the way up to RPG IV and free-format RPG
came about:
* Boolean logic: IF A = B AND (C = D OR (E = F AND G > H))
* Complex arithmetic computation: COMPUTE A = (B + C) / D
* Complex character variable assignment: STRING A [DELIMITED BY '.'] etc.
* Multi-dimensional tables (OCCURS within OCCURS within OCCURS, etc.)
RPG still doesn't have this last one.
Free-format RPG, on top of the other improvements in RPG IV, finally
made the readability of RPG as good as that of COBOL.
Michael Roach
<jmfbahciv@aol> wrote:
>
>When I wrote report writing code (DEC didn't have RPG but it was
>implemented in COBOL), I always used the SORT...USING clauses.
>That way the manipulative code (and there was always requirements
>to futz with the input and output data) was always in the logical
>place (input or output, but not both). It kept later coders
>from making big messes.
DEC may not have had it but DECUS did by 1976:
http://pdp-10.trailing-edge.com/decuslib10-10/01/43,50517/releas.doc.html
http://tinyurl.com/5de3ss
In High School I was a TSS/8 system manager with the author (from a
different school in the district.) Later we worked together for Alpha
Microsystems. He wrote DECUS RPG II while still in High School at my
dad's shop.
--
Too much of everything is just enough.
-- Bob Wier
Michael Kennedy
...<snip>...
> Free-format RPG, on top of the other improvements in RPG IV, finally
> made the readability of RPG as good as that of COBOL.
...<snip>...
Jonathan,
You're right - I was thinking of the "Original" versions and specs of
the basic products. In hindsight, I should have mentioned the later
releases, and, perhaps, "add-ons", etc.
- Mike
hanc...@bbs.cpcn.com
> So does that mean that the RPG language dates from 1978 also???
> Believe it or *not*, some folks actually used RPG for *payroll*
> applications and such. Shocking!!!
RPG dates from 1959 and the introduction of the IBM 1401 computer.
It was developed to mimic the plugboard programming of the IBM 407
tabulating/accounting machine (which was surprisingly extremely
sophisticated). The idea was that people who knew how to wire such
plugboards would find it easy to learn RPG. It was also a low-
overhead language in that it could run on a machine with very little
memory on it.
RPG was offered on System/360 when it came out. It was used on the
mini-version of the System/360, the model 20 (although it seems the
model 20 was used for an RJE workstation terminal).
When IBM introduced the System/3 (circa 1970), a low cost machine for
users who couldn't justify the expense of a "mainframe" like the
System/360, even a low end model 20), they enhanced RPG to be RPG II.
It was the primary language used to program the System/3.
As an aside, when the S/3 came out, there were still many traditional
punched-card tab machine shops in opereation, since at that time for
small outfits it was still cheaper to use such machines rather than go
to an electronic computer like System/360. Indeed, in the early days
of System/360 many shops kept some tab machines handy for some pre-
processing (ie sorts) and post processing (more sorts, card
interpretation, special listings, etc.)
It took a long time, longer than most of us realize, for electronic
components to come down in price to be cheaper than electro-magnetic
relay logic. Thus the old tab machines soldiered on for many years,
well into the early 1980s!
When IBM introduced the new midrange line (S/34,36,38 though
apparently not in that order), RPG was enhanced again to handle on-
line work. Around that time the automatic 'cycle' of RPG was de-
emphasized in favor of other control logic.
RPG continued to be enhanced for the AS/400 and subsequent offerings,
including a Visual RPG.
hanc...@bbs.cpcn.com
> Haven't done a lot of work on the S/34, S/36, S/38 and AS/400 in the very late 70s
> and throughout the '80s I was always curious about the history of the FS project. We
> heard that code word but that was bout it.
The book "IBM System/360 and early S/370" by Pugh et al, goes into
detail on the history of the FS project. The S/38 used some of the
concepts developed for FS, but not all of it, and most of FS effort
was wasted. I strongly recommend the book, it is an excellent
technical and R&D history of the System/360 and IBM of 1960s and
1970s.
"FS" or future system, was IBM's plan to replace the System/360.
However, it turned out that it was awfully complex and very tough to
develop and implement. Further, so many customers had System/360s
they wouldn't want to change over (and still don't, 45 years after
System/360 was announced, which is pretty amazing in its own right.)
hanc...@bbs.cpcn.com
> Being bilingual on the S/38 and AS/400 (now "tri", if you count the SQL
> procedural language), I always thought there were certain things COBOL
> did far better than RPG all the way up to RPG IV and free-format RPG
> came about:
Every language has some advantages and disadvantages. DYL280 (or
Easytrive+) can do a lot of things, but some reports needed special
logic. For example, we had reports with not only the usual hiearchial
control breaks, but also some overlapped sub totals of offices grouped
together in different ways. Without the overlap Easytrieve would've
made it easy, but the overlap forced COBOL.
Sadly, IBM added some very desirable date and math functions to COBOL-
for-MVS very late in the game, it's a shame these weren't available
decades earlier. Most shops 'rolled their own' common routines to
such work.
In some cases Assembler was required to do a few things COBOL couldn't
do.
hanc...@bbs.cpcn.com
> The LCG COBOL report writer had a bug which didn't do
> the totals correctly.
I don't believe the COBOL "Report Writer" feature had wide
acceptance. I only knew of one person who used it (as an experiment),
and regretted using it. I believe it's not even available anymore.
Gene Wirchenko
It is part of the standard.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
jmfbahciv
of the job required the functionality. I knew of more jobs that
used the functionality.
/BAH
jmfbahciv
> hanc...@bbs.cpcn.com wrote:
>
>> On Nov 20, 7:46 am, jmfbahciv <jmfbahciv@aol> wrote:
>>> The LCG COBOL report writer had a bug which didn't do
>>> the totals correctly.
>> I don't believe the COBOL "Report Writer" feature had wide
>> acceptance. I only knew of one person who used it (as an experiment),
>> and regretted using it. I believe it's not even available anymore.
>
> It is part of the standard.
Hancock must not know many people who had to churn out accounting
reports based on raw computer data.
/BAH
hanc...@bbs.cpcn.com
> >I don't believe the COBOL "Report Writer" feature had wide
> >acceptance. I only knew of one person who used it (as an experiment),
> >and regretted using it. I believe it's not even available anymore.
>
> It is part of the standard.
This is NOT to say it wasn't used, but rather it's use from limited.
There were various elements of COBOL that did not have wide
acceptance. Some elements did not work out so well in practice.
According to the IBM website, REPORT WRITER was discontinued for COBOL-
for-MVS. If you had programs that used it, you had to get a pre-
compiler to process it. To me, that suggests the usage wasn't that
great.
hanc...@bbs.cpcn.com
> >> I don't believe the COBOL "Report Writer" feature had wide
> >> acceptance. I only knew of one person who used it (as an experiment),
> >> and regretted using it. I believe it's not even available anymore.
>
> > It is part of the standard.
>
> Hancock must not know many people who had to churn out accounting
> reports based on raw computer data.
Well, how often do you see Report Writer utilized in COBOL programs
today? In the past?
Gene Wirchenko
Irrelevant. That something is not used much does not make it
unavailable, and you have not even established that.
I have never used COBOL outside of school, so I have not read
many COBOL programs. I did use the Report Writer.
hanc...@bbs.cpcn.com
> Irrelevant. That something is not used much does not make it
> unavailable, and you have not even established that.
Please review what was posted before:
Peter Flass
Just as easy as using Report Writer was to have s skeleton deck for a
report program (or file update, merge, etc.) and just keypunch the
formats for the report and insert them. If you wanted to be "brave" you
could just have the field names be the same and do all the work with one
'MOVE CORRESPONDING' statement, use 'ADD CORRESPONDING' for totals, etc.
jmfbahciv
> jmfbahciv wrote:
>> Gene Wirchenko wrote:
>>> hanc...@bbs.cpcn.com wrote:
>>>
>>>> On Nov 20, 7:46 am, jmfbahciv <jmfbahciv@aol> wrote:
>>>>> The LCG COBOL report writer had a bug which didn't do
>>>>> the totals correctly.
>>>> I don't believe the COBOL "Report Writer" feature had wide
>>>> acceptance. I only knew of one person who used it (as an experiment),
>>>> and regretted using it. I believe it's not even available anymore.
>>>
>>> It is part of the standard.
>>
>> Hancock must not know many people who had to churn out accounting
>> reports based on raw computer data.
>>
>> /BAH
>
> Just as easy as using Report Writer was to have s skeleton deck for a
> report program (or file update, merge, etc.) and just keypunch the
> formats for the report and insert them.
Not everybody used cards. And cards only had a 72-wide field ( using
all 80 meant tradeoffs). A line printer listing was was 120? columns
wide that could be used for all the wordage required to make
cost accounting listings.
>If you wanted to be "brave" you
> could just have the field names be the same and do all the work with one
> 'MOVE CORRESPONDING' statement, use 'ADD CORRESPONDING' for totals, etc.
Just how much data handling did you do which went from raw bits
collected within the computer to a cost accounting listing that could
be read by people who were scared to death of all computers?
Sheesh!
/BAH
Michael Wojcik
> On Dec 11, 9:19 am, jmfbahciv <jmfbahciv@aol> wrote:
>>>> I don't believe the COBOL "Report Writer" feature had wide
>>>> acceptance. I only knew of one person who used it (as an experiment),
>>>> and regretted using it. I believe it's not even available anymore.
>>> It is part of the standard.
And still supported by MF COBOL, among other implementations.
>> Hancock must not know many people who had to churn out accounting
>> reports based on raw computer data.
>
> Well, how often do you see Report Writer utilized in COBOL programs
> today? In the past?
There are six articles about Report Writer in the MF Supportline KB. I
recently saw queries about the Acu Report Writer on our internal
newsgroups. There are thirteen messages about it in our user forums,
though the most recent is from 2006.
So *someone* is using it. I don't know how often the people who use it
run into problems, so I can't guess what those statistics might mean
in terms of overall use.
My impression is that new and recently-migrated applications are more
likely to use other reporting facilities, such as Crystal Reports. But
I don't have any real data on that subject.
I believe I used to hear about Report Writer significantly more often
in the 1990s.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Peter Flass
> Peter Flass wrote:
>> jmfbahciv wrote:
>>> Gene Wirchenko wrote:
>>>> hanc...@bbs.cpcn.com wrote:
>>>>
>>>>> On Nov 20, 7:46 am, jmfbahciv <jmfbahciv@aol> wrote:
>>>>>> The LCG COBOL report writer had a bug which didn't do
>>>>>> the totals correctly.
>>>>> I don't believe the COBOL "Report Writer" feature had wide
>>>>> acceptance. I only knew of one person who used it (as an experiment),
>>>>> and regretted using it. I believe it's not even available anymore.
>>>>
>>>> It is part of the standard.
>>>
>>> Hancock must not know many people who had to churn out accounting
>>> reports based on raw computer data.
>>>
>>> /BAH
>>
>> Just as easy as using Report Writer was to have s skeleton deck for a
>> report program (or file update, merge, etc.) and just keypunch the
>> formats for the report and insert them.
>
> Not everybody used cards. And cards only had a 72-wide field ( using
> all 80 meant tradeoffs). A line printer listing was was 120? columns
> wide that could be used for all the wordage required to make
> cost accounting listings.
>
You missed what I was saying. We didn't supply the report image, but
the COBOL definitions for the data. Most of the program could be
pre-written.
>
>> If you wanted to be "brave" you could just have the field names be the
>> same and do all the work with one 'MOVE CORRESPONDING' statement, use
>> 'ADD CORRESPONDING' for totals, etc.
>
> Just how much data handling did you do which went from raw bits
> collected within the computer to a cost accounting listing that could
> be read by people who were scared to death of all computers?
>
> Sheesh!
>
> /BAH
Collected within the computer? In those days it was all "data-entry",
which meant keypunching to IBM types. I did lots of this stuff, maybe
10 years or so. I worked for various consultants and did mostly new
development.
I don't think this business model exists any more. We became the
client's development staff, did the whole package from design to
installation. Unlike facilities-management outfits we turned the
finished systems over to the customer to run on his own hardware.
For a time it was a quick way for companies to migrate from 14xx to 360s
without trying to carry over a lot of obsolete systems written in
Autocoder with octal patches and no source. The customer would up with
a clean and well-documented system.
You learn a lot in a hurry about many different systems this way.
jmfbahciv
Yep. I did.
> We didn't supply the report image, but
> the COBOL definitions for the data. Most of the program could be
> pre-written.
How did your customers read in the "format" statement? Or was it
edited in or compiled with a FOO+[customer procedure section]?
>
>>
>>> If you wanted to be "brave" you could just have the field names be
>>> the same and do all the work with one 'MOVE CORRESPONDING' statement,
>>> use 'ADD CORRESPONDING' for totals, etc.
>>
>> Just how much data handling did you do which went from raw bits
>> collected within the computer to a cost accounting listing that could
>> be read by people who were scared to death of all computers?
>>
>> Sheesh!
>>
>> /BAH
>
> Collected within the computer?
Yes.
> In those days it was all "data-entry",
Not if the computer had the ability to write its data to a disk or
magtape or something.
> which meant keypunching to IBM types. I did lots of this stuff, maybe
> 10 years or so. I worked for various consultants and did mostly new
> development.
>
> I don't think this business model exists any more. We became the
> client's development staff, did the whole package from design to
> installation. Unlike facilities-management outfits we turned the
> finished systems over to the customer to run on his own hardware.
>
> For a time it was a quick way for companies to migrate from 14xx to 360s
> without trying to carry over a lot of obsolete systems written in
> Autocoder with octal patches and no source. The customer would up with
> a clean and well-documented system.
>
> You learn a lot in a hurry about many different systems this way.
Yea. That's fun.
I was talking about data collected by each computer so that the owner
of the gear could recover costs. In olden days, this was called
cross-charging and every computer-gear owner would cross-charge
the time (usually wall-clock time) used by its "customers".
Universities did this. All timeshare companies did this.
The only way to justify buying a new computer was to have detailed
records of the usage of the gear you do have so you could prove
you needed more capacity.
/BAH
Peter Flass
Compiled. The customers didn't write anything. These wern't report
generator programs like DYL/360, Mark IV, etc. They were standard
pre-written COBOL programs, just that parts of them were pre-prewritten.
>>
>>>
>>>> If you wanted to be "brave" you could just have the field names be
>>>> the same and do all the work with one 'MOVE CORRESPONDING'
>>>> statement, use 'ADD CORRESPONDING' for totals, etc.
>>>
>>> Just how much data handling did you do which went from raw bits
>>> collected within the computer to a cost accounting listing that could
>>> be read by people who were scared to death of all computers?
>>>
>>> Sheesh!
>>>
>>> /BAH
>>
>> Collected within the computer?
>
> Yes.
>
>> In those days it was all "data-entry",
>
> Not if the computer had the ability to write its data to a disk or
> magtape or something.
Still had to come from somewhere.
>
>> which meant keypunching to IBM types. I did lots of this stuff, maybe
>> 10 years or so. I worked for various consultants and did mostly new
>> development.
>>
>> I don't think this business model exists any more. We became the
>> client's development staff, did the whole package from design to
>> installation. Unlike facilities-management outfits we turned the
>> finished systems over to the customer to run on his own hardware.
>>
>> For a time it was a quick way for companies to migrate from 14xx to
>> 360s without trying to carry over a lot of obsolete systems written in
>> Autocoder with octal patches and no source. The customer would up
>> with a clean and well-documented system.
>>
>> You learn a lot in a hurry about many different systems this way.
>
> Yea. That's fun.
>
> I was talking about data collected by each computer so that the owner
> of the gear could recover costs. In olden days, this was called
> cross-charging and every computer-gear owner would cross-charge
> the time (usually wall-clock time) used by its "customers".
> Universities did this. All timeshare companies did this.
> The only way to justify buying a new computer was to have detailed
> records of the usage of the gear you do have so you could prove
> you needed more capacity.
"My" customers didn't run timesharing shops. These were smallish
mainframes (360/30 and /25 mostly) that ran applications for the owner only.
Rich Alderson
> For a time it was a quick way for companies to migrate from 14xx to 360s
> without trying to carry over a lot of obsolete systems written in
> Autocoder with octal patches and no source. The customer would up with
> a clean and well-documented system.
One quibble (my first computer was a 1401): Autocoder/1401 code was decimal,
not octal. Patches were generally BCD.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
Peter Flass
> Peter Flass <Peter...@Yahoo.com> writes:
>
>> For a time it was a quick way for companies to migrate from 14xx to 360s
>> without trying to carry over a lot of obsolete systems written in
>> Autocoder with octal patches and no source. The customer would up with
>> a clean and well-documented system.
>
> One quibble (my first computer was a 1401): Autocoder/1401 code was decimal,
> not octal. Patches were generally BCD.
>
That's a good quibble;-)
Jonathan Ball
I don't think it ever was available on the S/38-AS/400-iSeries-i5, was
it? I can't see any mention of it in the V5R3 COBOL reference. I used
to use it in the late 1970s in MVS shops, but never saw it again after I
moved to S/38 in 1982.
Peter Flass
<guess>Probably because it's basically RPG for COBOL programmers. S/38
programmers probably started with RPG and only went to COBOL for
programs that became too complex, and so would have no need for Report
Writer.</guess>
Jonathan Ball
I actually went the opposite direction: I came to S/38 as a COBOL
programmer from a 30xx MVS environment, then picked up RPG. In my
mainframe days, I never used report writer all that much - enough to
make it work, but not enough to become expert.