IBM Midrange today?

[hanc...@bbs.cpcn.com]

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?

[Dan Espen]

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

[J. Clarke]

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.

[Charlie Gibbs]

On 2019-07-11, Pamela <pamela...@gmail.com> wrote:

> On 23:36 29 May 2019, Dan Espen <dan1...@gmail.com> wrote:
>
>> hanc...@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..."

--
/~\ 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.
/ \ Fight low-contrast text in web pages! http://contrastrebellion.com

[Peter Flass]

Pamela <pamela...@gmail.com> wrote:
> On 23:36 29 May 2019, Dan Espen <dan1...@gmail.com> wrote:
>

>> hanc...@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

[hanc...@bbs.cpcn.com]

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.

[hanc...@bbs.cpcn.com]

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.

[Anne & Lynn Wheeler]

hanc...@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/102658182

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=stories&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/2015/09/102702884-05-01-acc.pdf

--
virtualization experience starting Jan1968, online at home since Mar1970

[Quadibloc]

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

[hanc...@bbs.cpcn.com]

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.

[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?

[Dan Espen]

hanc...@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

[Dan Espen]

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

[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

[Peter Flass]

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

[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.

[Quadibloc]

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

[Peter Flass]

The MFCM could also interpret.

--
Pete

[Peter Flass]

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

[Dan Espen]

Pamela <pamela...@gmail.com> writes:

> 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

[Dan Espen]

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

[Dan Espen]

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

[Dan Espen]

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

[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.

[Dan Espen]

Pamela <pamela...@gmail.com> writes:

> 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

[Charlie Gibbs]

On 2019-07-15, Dan Espen <dan1...@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.

--
/~\ 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.

/ \ "Alexa, define 'bugging'."

[Ahem A Rivet's Shot]

On Sun, 14 Jul 2019 18:44:59 -0400
Dan Espen <dan1...@gmail.com> wrote:

> 1442 was usually found on a 1440.

It was also popular on 1130s.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Anne & Lynn Wheeler]

hanc...@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-rochester
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.

[hanc...@bbs.cpcn.com]

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_Reference_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.

[hanc...@bbs.cpcn.com]

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.

[Rich Alderson]

ITYM "Power", not "PowerPC".

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Dan Espen]

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

[Dan Espen]

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

[Charlie Gibbs]

On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.

[J. Clarke]

On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgi...@kltpzyxm.invalid>
wrote:

>On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.

[Dan Espen]

J. Clarke <jclarke...@gmail.com> writes:

> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgi...@kltpzyxm.invalid>
> wrote:
>
>>On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.

A simple matter of choosing the right code pages.

We went through this before. Your shop uses tri-graphs because it's
backward. As I remember, belligerently backward.

--
Dan Espen

[Charlie Gibbs]

On 2019-07-16, J Clarke <jclarke...@gmail.com> wrote:

> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgi...@kltpzyxm.invalid>
> wrote:
>
>> On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.

Oops. s/026/029/ My bad.

> 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.

No, this was long before I got into square brackets, or C for that matter.

Aha! DuckDuckGo to the rescue:

https://www.masswerk.at/misc/card-punch-typography/part2-ibm029-EA.html

Note that parentheses, the plus sign, and the apostrophe were among
the characters that got the treatment. Thus a statement like

MVC LINE+25(14),=CL14'THIS IS A TEST'

came out rather hard to read.

[Peter Flass]

Sounds like CICS’ BMS, except that only generated one load module and a
couple of DSECTS/copy books.

--
Pete

[Peter Flass]

Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.

After a while you could read the punches pretty easily.

>
>> 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.
>

Probably OK for simple RPG stuff, but I wouldn’t want to do much on it.

--
Pete

[Peter Flass]

Kids these days have no idea. A low-end Rasperry Pi comes with loads of
memory AND an OS!

--
Pete

[hanc...@bbs.cpcn.com]

IBM published a "programmers guide" along with the reference
manual for its computers. It contained a lot of suggestions
on how to improve performance.

http://bitsavers.org/pdf/ibm/360/dos/cobol/GC28-6398-1_DOS_American_National_Standard_COBOL_Programmers_Guide_Feb70.pdf

With S/360 assembler, there were various ways to accomplish
the same thing, but certain methods were more machine efficient
than others and used less memory. They're probably not as
relevant today, but a site with a model 30 with 32k of memory
and a lot of work to put through it would give them consideration.



there are a few tips in here (e.g. branch-on-count, branch-on-index)
http://bitsavers.trailing-edge.com/pdf/ibm/360/asm/SC20-1646-6_int360asm_Aug70.pdf

[hanc...@bbs.cpcn.com]

On Tuesday, July 16, 2019 at 4:08:03 AM UTC-4, Charlie Gibbs wrote:
> On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.

Our S/360-40 had a 48 character print chain, so special
characters didn't print. Not easy to read program listings.
The director refused to consider upgrading to the normal
64 character chain--he felt it would be (a) too expensive,
and (b) reduce print speed too much. But then one of
the clients wanted parenthesis to show negative fields
instead of a '-', so we got one. It turned out the upgrade
was provided free by IBM, and it didn't slow down printing
at all.

If it were up to that director, all the work would've
been done in Autocoder under emulation. No COBOL.

[hanc...@bbs.cpcn.com]

On Tuesday, July 16, 2019 at 2:57:48 PM UTC-4, Peter Flass wrote:
> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> > On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.
>
> After a while you could read the punches pretty easily.

Western Union liked using Baudot because its operators learned
how to read the punched tapes. That was a stated reason for
not going to ASCII.

A legacy of punched cards remains to this day: If in a
COBOL program you DISPLAY a signed field, the last character
will have the 'overpunch'. It won't be a digit, but a letter,
as it would be in a punched card.

[hanc...@bbs.cpcn.com]

On Tuesday, July 16, 2019 at 4:08:03 AM UTC-4, Charlie Gibbs wrote:

> > 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.

The lowest memory I ever heard of for a S/360 model 30 was 32k,
but I suspect there were some 16k machines out there. Depending
on what manual you read, the model 30 _may_ have been offered with
as little as 8k, but I think later on IBM upgraded that.


On our S/360 model 40, the supervisor/DOS took up 14 k, so
a 16k machine wouldn't have any room for the application
program. We had 128k, later upgraded to 192k. A 128k
was quite a bit--a 100k COBOL program was quite large
and complex. In my opinion, that should be the upper
limit of most COBOL programs to avoid too much
complexity and maintenance headaches.

[hanc...@bbs.cpcn.com]

On Tuesday, July 16, 2019 at 2:57:48 PM UTC-4, Peter Flass wrote:

> > 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.
>
> Probably OK for simple RPG stuff, but I wouldn’t want to do much on it.

I think a big advantage of early RPG was that it could run on
smaller machines. COBOL compilers took up more room.

[J. Clarke]

On Tue, 16 Jul 2019 09:17:27 -0400, Dan Espen <dan1...@gmail.com>
wrote:

OK, tell me how to set a code page in Eclipse that matches the one in
Rumba.

[Dan Espen]

Somehow, I was only lightly exposed to CICS.

I've never been a fan of "compiled" screen definitions.
On the S/34 the source was so simple to parse at run time
I'm sure it had no impact on response time.

When ISPF started optionally compiling it's screen definitions
I was not a fan. I saw no visible difference in performance
and maintained a large number of screens which were never compiled.

What I wanted is for ISPF screens to work under IMS.
I suppose CICS would be good to.


--
Dan Espen

[Dan Espen]

I worked for 2 years on an 8k 1440 with disk.
Sometimes I had to do a bit of thinking, but 8K was
plenty. I only remember one program that got near the limit.
Of course, no OS.

--
Dan Espen

[Peter Flass]

There’s a big difference between some programmers on ISPF and 100,000
transactions per second on CICS (or IMS). This is the same situation vs.
midrange systems where the transaction rates are much lower. CICS and IMS
(and more so TPF) are all aimed at achieving maximum performance, at the
expense of ease of use.

>
> What I wanted is for ISPF screens to work under IMS.
> I suppose CICS would be good to.
>

What would you do with ISPF that would be a good fit as a CICS transaction?


--
Pete

[Dan Espen]

Start here:

https://stackoverflow.com/questions/3751791/how-to-change-default-text-file-encoding-in-eclipse

Seems like you get Windows to set a file association to a code page.
Two different answers:

Window -> Preferences -> General -> Workspace : Text file encoding
Window > Preferences > General > Content Types

Not sure if you are moving the file to MVS or maybe you have it NFS
mounted?

ISPF won't display square brackets unless you set option 0 terminal type
to 3278a. Rumba should just work.

--
Dan Espen

[Dan Espen]

Make the wall between ISPF and IMS seamless.
Allow new code to get/put screen data through variables and ISPF panels
instead of MFS.

--
Dan Espen

[J. Clarke]

On Tue, 16 Jul 2019 23:09:02 -0400, Dan Espen <dan1...@gmail.com>

We are not moving the "file" and it is not "mounted". We use Eclipse
with the Compuware Topaz plugin that interacts directly with a
component on the mainframe. To edit a dataset I double-click on it
and it opens in an editor. To submit a job I right-click on it and
submit. Flasher output appears in another window--I can save that
directly to the PC if I want to.

The problem is that everything that we've tried ends up with the "["
and "]" keystrokes in the Eclipse editor (all of them, there are
several) putting a different EBCDIC value in the dataset from the one
that the same keystrokes on the 3270a screen put into the dataset. The
compiler seems happy with either encoding. If you know of a code page
for Eclipse that results in the same EBCDIC value appearing for those
characters as when they are entered from 3270a screen, please share.
We have been unable to find one.

[Charlie Gibbs]

On 2019-07-16, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:

> On Tuesday, July 16, 2019 at 2:57:48 PM UTC-4, Peter Flass wrote:
>
>>> 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.
>>
>> Probably OK for simple RPG stuff, but I wouldn’t want to do much on it.

Indeed. Even in assembly language, it was a tight squeeze. The
assembler didn't have room for a very big symbol table, so programs
were peppered with statements like

BC 8,*+26

(No extended mnemonics - there wasn't room for the assembler to
support them.)

> I think a big advantage of early RPG was that it could run on
> smaller machines. COBOL compilers took up more room.

Yup. Univac released a COBOL compiler for the 9300, but it existed
strictly to satisfy some government requirement; it was so limited
as to be totally impractical for actual use. I did try running
"The Common Business-Oriented Goldilocks" through it - it churned
away for a while, spitting out all sorts of error messages, and
eventually crashed.

[Charlie Gibbs]

On 2019-07-16, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:

> On Tuesday, July 16, 2019 at 4:08:03 AM UTC-4, Charlie Gibbs wrote:
>
>> On 2019-07-15, hanc...@bbs.cpcn.com <hanc...@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.
>
> Our S/360-40 had a 48 character print chain, so special
> characters didn't print. Not easy to read program listings.
> The director refused to consider upgrading to the normal
> 64 character chain--he felt it would be (a) too expensive,
> and (b) reduce print speed too much. But then one of
> the clients wanted parenthesis to show negative fields
> instead of a '-', so we got one. It turned out the upgrade
> was provided free by IBM, and it didn't slow down printing
> at all.

At one shop where I did some contract work, management felt
that changing between 48- and 63-character print bands would
save enough time to be worth it. They totally ignored the
time taken to change the bands - especially if the operator
was off for coffee when the band change request came up.
I think they eventually saw reason and left the 63-character
band on all the time.

> If it were up to that director, all the work would've
> been done in Autocoder under emulation. No COBOL.

At the same shop, where I was converting programs from their
old Univac 9400 to a new 90/30, I took advantage of the new
instructions. One day, while I was out, a bug came up.
When I got back, I found manuals and program listings open
all over the desk, with people trying to figure out what
that newfangled BXLE instruction did. Hell hath no fury
like an ex-programmer, now a manager, who sees what some
upstart has done to his precious spaghetti code.

[Dan Espen]

That sounds pretty nice. I got similar results by writing a series
of Perl scripts to copy files using FTP and launching compiles using
the FTP interface to JES.

> The problem is that everything that we've tried ends up with the "["
> and "]" keystrokes in the Eclipse editor (all of them, there are
> several) putting a different EBCDIC value in the dataset from the one
> that the same keystrokes on the 3270a screen put into the dataset. The
> compiler seems happy with either encoding. If you know of a code page
> for Eclipse that results in the same EBCDIC value appearing for those
> characters as when they are entered from 3270a screen, please share.
> We have been unable to find one.

Hmm, just read the Topaz User Guide and I still have no clue what
Topaz is using to get the mainframe data accessible to Windows.
I do see it's a licensed product so Compuware might offer a solution.

I think you're dealing with Windows understanding of the code page
the mainframe files are using. Sounds like you are accessing mainframe
PDS members, not mainframe HFS files.
The link above suggests that UTF-8 works.

--
Dan Espen

[hanc...@bbs.cpcn.com]

On Tuesday, July 16, 2019 at 9:30:22 PM UTC-4, Peter Flass wrote:


> There’s a big difference between some programmers on ISPF and 100,000
> transactions per second on CICS (or IMS). This is the same situation vs.
> midrange systems where the transaction rates are much lower. CICS and IMS
> (and more so TPF) are all aimed at achieving maximum performance, at the
> expense of ease of use.

I also suspect CICS and IMS were created a lot earlier and
despite upgrades over the years, still relate to their old
roots (like Basic Mapping Support).

[J. Clarke]

On Wed, 17 Jul 2019 08:31:06 -0400, Dan Espen <dan1...@gmail.com>

I can access PDS members, but also all manner of other datasets. The
other day I had occasion to dump part of a VSAM dataset to a CSV. The
only thing I've found that Topaz won't deal with is a tape--I have to
copy it to DASD before Topaz will try to do anything with it.

[Peter Flass]

There’s probably that, too. IBM wants pretty good justification or ROI for
adding new features, so adding a text-based mapping feature most likely
wouldn’t make the cut.

--
Pete

[Dan Espen]

Probably some z/OS system setting makes tapes not available.
Where I worked you couldn't use them from ISPF but I think I knew
someone with an override.

I guess as long as it looks like a text file the above:

Window -> Preferences -> General -> Workspace : Text file encoding

should get Topaz to insert the right square brackets.
I assume you want x'AD' x'BD'.

--
Dan Espen

[Dan Espen]

Our developers wrote a few MFS generators.
I think some of them were toying with MFS bypass.

As I've recounted before, I did my first online application on
IBM 2260s. When IBM announced the 3270 my boss asked me to
evaluate the 3270. I recommended against it. The required datastream
is crap. When I started using ASCII terminals I was impressed at
the simplicity of the design and high function.

--
Dan Espen

[Peter Flass]

My experience was just the opposite, but I guess neither is especially
pertinent today.

--
Pete

[Charlie Gibbs]

Yes, I was pretty jealous when I saw how simple things were on minis.
Mainframers insisted that async was only fit for low-speed communication -
the Univac 90/30's serial port could only do 2400 bps, as opposed to the
9600 bps you could get with synchronous. Mind you, with modem prices at
$1/bps in those days, not many people sprang for anything over 2400 bps
if you were going outside the building - two and a half grand for a Bell
201 was enough, especially when you added in the cost of the leased line
you needed for it.

BTW it wasn't ASCII vs. EBCDIC, but the synchronous block-mode protocols
that made things complicated. The Univac 90/30 used EBCDIC (its
non-privileged instructions were bit-for-bit identical to those of
the IBM 360/50), but the terminals were ASCII, with their own form
of multi-dropped bisync protocol. The programming interface was a
nightmare - their Integrated Communications Access Method (ICAM) must
have been at least as bad as IBM's TCAM, BTAM, or whatever alphabet
soup they had (I never got a close look at IBM's offerings). As far as
we (the official Vancouver experts) knew, there was only one person in
all of Canada who really understood ICAM, and a couple of times we flew
him out from Montreal to help us set up something out of the ordinary.
One such case was when we were doing a bisync interface to an IBM
System/38. We spent the entire day on the customer site, and by
the end of the day we finally got it working. Afterwards, we unwound
in an empty office, shooting the bull with our Montreal guru. He
carried on a conversation with us while simultaneously scrambling
and unscrambling a Rubik's Cube. That's the sort of mind it took
to understand this stuff.

I had too much experience with Univac's version of CICS, which they
confusingly called IMS. I wound up creating and interpreting the
datastreams myself - in COBOL, no less.

[Dan Espen]

Agree completely.

Actually there were 3270s that ran in ASCII mode.
They preseented special problems when trying to poll them.
I ended up resorting to channel programming to get them to work
as we wanted.

> The Univac 90/30 used EBCDIC (its
> non-privileged instructions were bit-for-bit identical to those of
> the IBM 360/50), but the terminals were ASCII, with their own form
> of multi-dropped bisync protocol. The programming interface was a
> nightmare - their Integrated Communications Access Method (ICAM) must
> have been at least as bad as IBM's TCAM, BTAM, or whatever alphabet
> soup they had (I never got a close look at IBM's offerings). As far as
> we (the official Vancouver experts) knew, there was only one person in
> all of Canada who really understood ICAM, and a couple of times we flew
> him out from Montreal to help us set up something out of the ordinary.
> One such case was when we were doing a bisync interface to an IBM
> System/38. We spent the entire day on the customer site, and by
> the end of the day we finally got it working. Afterwards, we unwound
> in an empty office, shooting the bull with our Montreal guru. He
> carried on a conversation with us while simultaneously scrambling
> and unscrambling a Rubik's Cube. That's the sort of mind it took
> to understand this stuff.

I'm not a Rubiks cube type but I did have a good grasp on BTAM and VTAM.
VTAM is the latest in IBM Communications. When IBM killed off
BTAM we got on a conference call and explained how our BTAM 3780
product could NOT be ported to VTAM. IBM didn't care. I guess their
BTAM guy was retiring.

Also did a number of VTAM interfaces to 3270s. Not pretty.

--
Dan Espen

[Scott Lurndal]

Dan Espen <dan1...@gmail.com> writes:
>Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
>
>> On 2019-07-17, Dan Espen <dan1...@gmail.com> wrote:
>>
>>> Peter Flass <peter...@yahoo.com> writes:
>>>

>>
>> BTW it wasn't ASCII vs. EBCDIC, but the synchronous block-mode protocols
>> that made things complicated.
>
>Agree completely.
>
>Actually there were 3270s that ran in ASCII mode.
>They preseented special problems when trying to poll them.
>I ended up resorting to channel programming to get them to work
>as we wanted.

It sounds like IBM datacomm really sucked.

While Burroughs also used EBCDIC, poll/select and block-mode terminals,
no application needed to care - the MCP and the DCP (Data
Comm Processor hardware box) did all the heavy lifting,
including all protocol handling (e.g. POLL/SELECT on
multidrop current-loop or RS232 lines).

All the application needed to care about was the terminal
type (screen vs. hardcopy). The screen control sequences
were the same for over five generations of terminals (TD7x0,
TD8x0, MT983, ET1100, T27) covering twenty five years through
1990.

Moreover, the terminals were common across all the mainframe
lines (small systems, e.g. B1900, medium systems, e.g. B4900,
and large systems, e.g. B6900).

Customers would configure their network using NDL (Network Definition
Language)which associated terminal line # and poll/select address
with the logical stations. NDL is compiled to 'firmware' which is downloaded
to the DCP[*] at boot or when reconfigured.

Then the customer would create an "MCS" using a special descriptive
language to describe the stations and applications; this descriptive
language is used to automatically generate the source code for a BPL program which
interfaces to between one and ten DCP's and routes packets between stations
and applications.

[*] B774 (70's), B874 (70's/80's), B974 (80's, 90's), CP3680 (originally
developed by customer - based on an HP2000 internally and connected to the
host using a mag tape channel controller).

[anti...@math.uni.wroc.pl]

Dan Espen <dan1...@gmail.com> wrote:
> As I've recounted before, I did my first online application on
> IBM 2260s. When IBM announced the 3270 my boss asked me to
> evaluate the 3270. I recommended against it. The required datastream
> is crap. When I started using ASCII terminals I was impressed at
> the simplicity of the design and high function.

I looked at descriptin of 3270 way after it became obsolete.
If purpose is to get maximal throughput from limited central
processor, than the concept of 3270 looks very good. Namely
IIUC with 3270 application is doing single block send to
transfer screen to 3270. After that user is interacting with
3270. When done user presses 'Send' button and application
receives input for the whole screen. So just to block
transfers and two interrupts to central processor. To
perfrom comparable functionality classical terminals
must exchange hundreds of characters with central processor,
which means hundreds of interrupts. So with classical
terminals central processor uses lot of cycles for
context switching. And for smooth operation one needs
response time below 100ms.

Of course, 3270 datastream is complicated. And somewhat
inflexible. For example when using 3270 I was annoyed that
it operated in overwrite mode with no visible way to get
insert mode. Later, after quick look at desription of
datastream my impression is that it did not support insert
mode at all...

--
Waldek Hebisch

[Peter Flass]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> Dan Espen <dan1...@gmail.com> writes:
>> Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
>>
>>> On 2019-07-17, Dan Espen <dan1...@gmail.com> wrote:
>>>
>>>> Peter Flass <peter...@yahoo.com> writes:
>>>>
>
>>>
>>> BTW it wasn't ASCII vs. EBCDIC, but the synchronous block-mode protocols
>>> that made things complicated.
>>
>> Agree completely.
>>
>> Actually there were 3270s that ran in ASCII mode.
>> They preseented special problems when trying to poll them.
>> I ended up resorting to channel programming to get them to work
>> as we wanted.
>
> It sounds like IBM datacomm really sucked.
>
> While Burroughs also used EBCDIC, poll/select and block-mode terminals,
> no application needed to care - the MCP and the DCP (Data
> Comm Processor hardware box) did all the heavy lifting,
> including all protocol handling (e.g. POLL/SELECT on
> multidrop current-loop or RS232 lines).

From what I read, Poll/Select was a lot like BISYNC.

>
> All the application needed to care about was the terminal
> type (screen vs. hardcopy). The screen control sequences
> were the same for over five generations of terminals (TD7x0,
> TD8x0, MT983, ET1100, T27) covering twenty five years through
> 1990.
>
> Moreover, the terminals were common across all the mainframe
> lines (small systems, e.g. B1900, medium systems, e.g. B4900,
> and large systems, e.g. B6900).
>
> Customers would configure their network using NDL (Network Definition
> Language)which associated terminal line # and poll/select address
> with the logical stations. NDL is compiled to 'firmware' which is downloaded
> to the DCP[*] at boot or when reconfigured.
>
> Then the customer would create an "MCS" using a special descriptive
> language to describe the stations and applications; this descriptive
> language is used to automatically generate the source code for a BPL program which
> interfaces to between one and ten DCP's and routes packets between stations
> and applications.

Sounds like TCAM.

>
> [*] B774 (70's), B874 (70's/80's), B974 (80's, 90's), CP3680 (originally
> developed by customer - based on an HP2000 internally and connected to the
> host using a mag tape channel controller).
>

--
Pete

[Peter Flass]

<anti...@math.uni.wroc.pl> wrote:
> Dan Espen <dan1...@gmail.com> wrote:
>> As I've recounted before, I did my first online application on
>> IBM 2260s. When IBM announced the 3270 my boss asked me to
>> evaluate the 3270. I recommended against it. The required datastream
>> is crap. When I started using ASCII terminals I was impressed at
>> the simplicity of the design and high function.
>
> I looked at descriptin of 3270 way after it became obsolete.
> If purpose is to get maximal throughput from limited central
> processor, than the concept of 3270 looks very good. Namely
> IIUC with 3270 application is doing single block send to
> transfer screen to 3270. After that user is interacting with
> 3270. When done user presses 'Send' button and application
> receives input for the whole screen.

Usually the 3270 only transmits the fields the user entered, so a lot less
data.

> So just to block
> transfers and two interrupts to central processor. To
> perfrom comparable functionality classical terminals
> must exchange hundreds of characters with central processor,
> which means hundreds of interrupts. So with classical
> terminals central processor uses lot of cycles for
> context switching. And for smooth operation one needs
> response time below 100ms.

That’s why I always thought start/stop terminals sucked. They’re okay if
you’re a minicomputer supporting one of them, otherwise not so much.

>
> Of course, 3270 datastream is complicated. And somewhat
> inflexible. For example when using 3270 I was annoyed that
> it operated in overwrite mode with no visible way to get
> insert mode. Later, after quick look at desription of
> datastream my impression is that it did not support insert
> mode at all...
>

It does, the field should be null-filled, not space-filled, otherwise use
the erase eof key.



--
Pete

[Scott Lurndal]

Peter Flass <peter...@yahoo.com> writes:
><anti...@math.uni.wroc.pl> wrote:
>> Dan Espen <dan1...@gmail.com> wrote:

>> So just to block
>> transfers and two interrupts to central processor. To
>> perfrom comparable functionality classical terminals
>> must exchange hundreds of characters with central processor,
>> which means hundreds of interrupts. So with classical
>> terminals central processor uses lot of cycles for
>> context switching. And for smooth operation one needs
>> response time below 100ms.
>
>That’s why I always thought start/stop terminals sucked. They’re okay if
>you’re a minicomputer supporting one of them, otherwise not so much.

The user experience with standard start/stop terminals is far superior to
the block-mode interface on the mainframe systems (IBM or BUNCH)
for interactive usage; where block-mode terminals are useless outside of
static forms-based applications.

We supported hundreds of start/stop terminals on our VAXen (with a PDP-11/44 front-end
terminal concentrator, which also fronted the ITEL AS/6 for Wylbur allowing
any ASCII terminal such as the ADM-3A's and VT-100's access to either the
VAX cluster or WYLBUR (via MILTEN) on the mainframe)

https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR

Like our homegrown PDP-11/44 front-end, Gandalf offered similar
capabilities.

https://en.wikipedia.org/wiki/Gandalf_Technologies

[hanc...@bbs.cpcn.com]

On Thursday, July 18, 2019 at 4:09:39 AM UTC-4, Charlie Gibbs wrote:

> Yes, I was pretty jealous when I saw how simple things were on minis.
> Mainframers insisted that async was only fit for low-speed communication -
> the Univac 90/30's serial port could only do 2400 bps, as opposed to the
> 9600 bps you could get with synchronous. Mind you, with modem prices at
> $1/bps in those days, not many people sprang for anything over 2400 bps
> if you were going outside the building - two and a half grand for a Bell
> 201 was enough, especially when you added in the cost of the leased line
> you needed for it.

I think 2400 wasn't bad for text only monochrome transmissions.

>
> BTW it wasn't ASCII vs. EBCDIC, but the synchronous block-mode protocols
> that made things complicated. The Univac 90/30 used EBCDIC (its
> non-privileged instructions were bit-for-bit identical to those of
> the IBM 360/50), but the terminals were ASCII, with their own form
> of multi-dropped bisync protocol. The programming interface was a
> nightmare - their Integrated Communications Access Method (ICAM) must
> have been at least as bad as IBM's TCAM, BTAM, or whatever alphabet
> soup they had (I never got a close look at IBM's offerings). As far as
> we (the official Vancouver experts) knew, there was only one person in
> all of Canada who really understood ICAM, and a couple of times we flew
> him out from Montreal to help us set up something out of the ordinary.
> One such case was when we were doing a bisync interface to an IBM
> System/38. We spent the entire day on the customer site, and by
> the end of the day we finally got it working. Afterwards, we unwound
> in an empty office, shooting the bull with our Montreal guru. He
> carried on a conversation with us while simultaneously scrambling
> and unscrambling a Rubik's Cube. That's the sort of mind it took
> to understand this stuff.

We attempted to use the Univac 90/30 software, but it was
horrible. We had classes at Blue Bell an the instructor
didn't even know how it worked.

The software Univac supplied for the 90/30 was definitely
weak as compared to equivalent software for S/360-370.

> I had too much experience with Univac's version of CICS, which they
> confusingly called IMS. I wound up creating and interpreting the
> datastreams myself - in COBOL, no less.

In the IBM world, mainframers typically used CICS. However,
I believe the early IBM database package, IMS, also offered
an online option.

I had an employer who used a "baby CICS", MTCS (?) that
was good for a low usage system.

CICS greatly improved over the last 40 years. It became much
easier to program and more reliable.

I think today IBM makes a lot of money on license fees from
CICS.

With the concentration of service onto single Z boxes,
the transaction load handled today is amazing.

[Dan Espen]

Buffer address encoding:

http://www.tommysprinkle.com/mvs/P3270/sbaxlate.htm

--
Dan Espen

[Questor]

On Thu, 18 Jul 2019 20:08:25 GMT, sc...@slp53.sl.home (Scott Lurndal) wrote:
>Peter Flass <peter...@yahoo.com> writes:

>>That's why I always thought start/stop terminals sucked. They're okay if
>>you're a minicomputer supporting one of them, otherwise not so much.
>
>The user experience with standard start/stop terminals is far superior to
>the block-mode interface on the mainframe systems (IBM or BUNCH)
>for interactive usage; where block-mode terminals are useless outside of
>static forms-based applications.
>
> We supported hundreds of start/stop terminals on our VAXen (with a PDP-11/44 front-end
>terminal concentrator, which also fronted the ITEL AS/6 for Wylbur allowing
>any ASCII terminal such as the ADM-3A's and VT-100's access to either the
>VAX cluster or WYLBUR (via MILTEN) on the mainframe)
>
>https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR
>
>Like our homegrown PDP-11/44 front-end, Gandalf offered similar
>capabilities.
>
>https://en.wikipedia.org/wiki/Gandalf_Technologies

Gandalf boxes were terminal switchers, not terminal concentrators. They did not
increase the number of terminals that could be connected to any one system,
rather they made it easy to connect a terminal to any of the computers served by
that Gandalf box. They could also be ganged together, increasing the number of
systems available. The ones used at many DEC facilities in the early 1980s were
based on the PDP-11/70, if memory serves. As Ethernet started to be deployed in
the mid-1980s, DEC came out with their LAT (Local Area Terminal) product, which
performed a similar function over the network.

[Scott Lurndal]

use...@only.tnx (Questor) writes:
>On Thu, 18 Jul 2019 20:08:25 GMT, sc...@slp53.sl.home (Scott Lurndal) wrote:
>>Peter Flass <peter...@yahoo.com> writes:
>>>That's why I always thought start/stop terminals sucked. They're okay if
>>>you're a minicomputer supporting one of them, otherwise not so much.
>>
>>The user experience with standard start/stop terminals is far superior to
>>the block-mode interface on the mainframe systems (IBM or BUNCH)
>>for interactive usage; where block-mode terminals are useless outside of
>>static forms-based applications.
>>
>> We supported hundreds of start/stop terminals on our VAXen (with a PDP-11/44 front-end
>>terminal concentrator, which also fronted the ITEL AS/6 for Wylbur allowing
>>any ASCII terminal such as the ADM-3A's and VT-100's access to either the
>>VAX cluster or WYLBUR (via MILTEN) on the mainframe)
>>
>>https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR
>>
>>Like our homegrown PDP-11/44 front-end, Gandalf offered similar
>>capabilities.
>>
>>https://en.wikipedia.org/wiki/Gandalf_Technologies
>
>Gandalf boxes were terminal switchers, not terminal concentrators. They did not
>increase the number of terminals that could be connected to any one system,
>rather they made it easy to connect a terminal to any of the computers served by
>that Gandalf box.

And that's exactly what our PDP-11/44 front end did. It allowed (via a
particular input sequence) selection of the host to which the terminal will
be connected. That's where the Gandalf comparison comes in.

[Bob Eager]

On Tue, 23 Jul 2019 16:20:34 +0000, Scott Lurndal wrote:

>>Gandalf boxes were terminal switchers, not terminal concentrators. They
>>did not increase the number of terminals that could be connected to any
>>one system, rather they made it easy to connect a terminal to any of the
>>computers served by that Gandalf box.
>
> And that's exactly what our PDP-11/44 front end did. It allowed (via a
> particular input sequence) selection of the host to which the terminal
> will be connected. That's where the Gandalf comparison comes in.

WE had teh same (but not for IBM, for various ICL machines). Ours ran on
11/03s, though, down line loaded from a host 11. I wrote a lot of the
code for that.




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

Use the BIG mirror service in the UK:
http://www.mirrorservice.org