| Re: IBM Midrange today? [message #385082 is a reply to message #385081] |
Tue, 16 July 2019 09:17   |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
> wrote:
>
>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>
>>> I also have no idea how much the optional features cost, and whether
>>> they were worth the extra cost in terms of added performance. I know
>>> some sites were on a tight budget and could only afford the bare bones
>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>> the 026, did not have a print and was a little cheaper.
>>
>> Even then, there was an intermediate option. One of the 026s at one
>> place I worked had a cheaper code plate; it would print alphanumerics
>> and a handful of special characters properly, but the rest of the
>> special characters came out as little square blocks. Not much fun
>> when you're trying to read program source code.
>
> Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
> standard character for the square bracket--at work we use those
> godawful trigraphs because if we don't the 3270 uses one code for the
> square bracket and Eclipse/Compuware uses a different one--at least
> the trigraphs are equally unreadable on all devices.
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
|
|
|
|
| Re: IBM Midrange today? [message #385085 is a reply to message #385081] |
Tue, 16 July 2019 13:47 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-07-16, J Clarke <jclarke.873638@gmail.com> wrote:
> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
> wrote:
>
>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>
>>> I also have no idea how much the optional features cost, and whether
>>> they were worth the extra cost in terms of added performance. I know
>>> some sites were on a tight budget and could only afford the bare bones
>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>> the 026, did not have a print and was a little cheaper.
>>
>> Even then, there was an intermediate option. One of the 026s at one
>> place I worked had a cheaper code plate; it would print alphanumerics
>> and a handful of special characters properly, but the rest of the
>> special characters came out as little square blocks. Not much fun
>> when you're trying to read program source code.
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-ibm 029-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.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: IBM Midrange today? [message #385089 is a reply to message #385072] |
Tue, 16 July 2019 14:57 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> hancock4@bbs.cpcn.com writes:
>
>> On Sunday, July 14, 2019 at 10:22:22 PM UTC-4, Dan Espen wrote:
>>
>>> One of my projects was Inventory and Costing in a division of a large
>>> manufacturer. We did I&C on S/34 at the same time the main office was
>>> trying to do the same thing on an MVS/CMS mainframe using IMS DB/DC.
>>>
>>> One of the differences between the projects is that the S/34 project
>>> actually finished. We did that with a staff that maxed out at 4.
>>> The main office stuff never finished, but they had about 50 consultants
>>> on site.
>>>
>>> Before we get the traditional consultant bad-mouthing, I was a
>>> consultant too.
>>>
>>> I offered to pull the mainframe effort out of it's hole, but
>>> Arthur Anderson refused to turn over project control to me.
>>>
>>> Anyway, the software on the S/34 was a big help getting the job done.
>>> The S/34 application would have run rings around the mainframe stuff (if
>>> it ever got done).
>>
>> Could you elaborate n what aspects of the S/34 that
>> made the development work go so much faster?
>>
>> I know IMS was kind of cumbersome.
>
> IMS has MFS. Cumbersome is one way to describe it.
> It's clearly something designed in meetings.
>
> I never saw an IMS screen painter.
> MFS screen definitions are written by a coder in Assembler.
> The output is at least 4 load modules that take extra
> work to start using for a test. I could go on...
Sounds like CICS’ BMS, except that only generated one load module and a
couple of DSECTS/copy books.
--
Pete
|
|
|
|
| Re: IBM Midrange today? [message #385090 is a reply to message #385078] |
Tue, 16 July 2019 14:57 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
>> I also have no idea how much the optional features cost, and whether
>> they were worth the extra cost in terms of added performance. I know
>> some sites were on a tight budget and could only afford the bare bones
>> equipment. For instance, some shops used the 024 keypunch, which unlike
>> the 026, did not have a print and was a little cheaper.
>
> Even then, there was an intermediate option. One of the 026s at one
> place I worked had a cheaper code plate; it would print alphanumerics
> and a handful of special characters properly, but the rest of the
> special characters came out as little square blocks. Not much fun
> when you're trying to read program source code.
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
|
|
|
|
| Re: IBM Midrange today? [message #385091 is a reply to message #385090] |
Tue, 16 July 2019 15:00 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>
>>> I also have no idea how much the optional features cost, and whether
>>> they were worth the extra cost in terms of added performance. I know
>>> some sites were on a tight budget and could only afford the bare bones
>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>> the 026, did not have a print and was a little cheaper.
>>
>> Even then, there was an intermediate option. One of the 026s at one
>> place I worked had a cheaper code plate; it would print alphanumerics
>> and a handful of special characters properly, but the rest of the
>> special characters came out as little square blocks. Not much fun
>> when you're trying to read program source code.
>
> 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.
>
Kids these days have no idea. A low-end Rasperry Pi comes with loads of
memory AND an OS!
--
Pete
|
|
|
|
| Re: IBM Midrange today? [message #385094 is a reply to message #385071] |
Tue, 16 July 2019 15:31 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Monday, July 15, 2019 at 7:29:52 PM UTC-4, Dan Espen wrote:
> hancock4@bbs.cpcn.com writes:
>
>> On Saturday, July 13, 2019 at 9:19:37 PM UTC-4, Dan Espen wrote:
>>
>>>> But according to Campbell-Kelly, the real genius of the 1401 was its
>>>> high speed card-reader and printer, faster than most to that point.
>>>
>>> They sure worked well. They got a bit faster when revamped for S/360.
>>>
>>> The OP code to read a card was "1".
>>> The OP code to print a line was "2".
>>>
>>> I read in the manual that OP code "3" would read a card and print a
>>> line. I never did work out a mainline design that could use that OP
>>> code.
>>
>>
>> The Reference Manual for the 1401 includes the following blurb
>> about delays in the I/O process:
>>
>> Card Read Instructions
>>
>> The card reader operates at a rated speed of 800 cycles
>> per minute (one cycle every 75 milliseconds). The card
>> reading speed depends on the timing of the READ A CARD
>> instructions in the program. To effect continuous cardreading
>> at the rate of 800 cards per minute, a READ A
>> CARD instruction must be given within 10 milliseconds
>> after the preceding card has been actually read into
>> the IBM 1401 Processing Unit. If more than 10 milliseconds
>> are required for processing, the card read
>> speed drops to 400 cards per. minute. This happens
>> because of the mechanical structure of the card feed.
>> There is only one point in the cycle during which a card
>> can feed, and if no read impulse signals the feed at
>> that time, the reader will be delayed for 75 milliseconds
>> (or until the same point in the following cycle).
>> The read release special feature permits job time
>> improvements by allowing more actual processing time
>> during the read cycle.
>>
>> http://www.bitsavers.org/pdf/ibm/1401/A24-1403-5_1401_Refere nce_Apr62.pdf
>>
>> I recommend the above manual as it gives a lot of interesting details
>> about the base model 1401 and optional features that could improve
>> performance, such as overlap and more storage instructions.
>>
>> The manual also includes timing for each instruction. Theorectically,
>> someone could calculate in advance how long it would take a program
>> to run. However, it would seem that doing such calculations would
>> be rather tedious (they're not simple and they didn't have convenient
>> electronic calculators back then).
>
> Some of us studied the timing values, but you first have to make a working
> program. The instructions you use are mostly determined by the requirements.
>
>> In typical practice, I don't know if programmers took the above
>> into consideration while programming. I heard of some who did,
>> such as doing a READ, then doing a few more instructions before
>> the data became available. I know a lot of effort was made to
>> improve hardware performance in 1401 days, and even in assembler
>> coding in S/360 days.
>
> Like today, the best way to get performance was to not do any
> extra steps.
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_A merican_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
|
|
|
|
| Re: IBM Midrange today? [message #385095 is a reply to message #385078] |
Tue, 16 July 2019 15:35 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Tuesday, July 16, 2019 at 4:08:03 AM UTC-4, Charlie Gibbs wrote:
> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
>> I also have no idea how much the optional features cost, and whether
>> they were worth the extra cost in terms of added performance. I know
>> some sites were on a tight budget and could only afford the bare bones
>> equipment. For instance, some shops used the 024 keypunch, which unlike
>> the 026, did not have a print and was a little cheaper.
>
> Even then, there was an intermediate option. One of the 026s at one
> place I worked had a cheaper code plate; it would print alphanumerics
> and a handful of special characters properly, but the rest of the
> special characters came out as little square blocks. Not much fun
> when you're trying to read program source code.
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.
>> The 1401 came with as little as 1,400 characters of memory, and I knew
>> of sites that had only that. I have no idea what the various levels of
>> memory on a 1401 would cost--how much more did a 16k 1401 cost vs. a 1.4k?
>
> Probably a lot. The Univac 9300s I worked on could be had with memory in 8K
> increments up to 32K. I worked on an 8K machine once. Again, not much fun.
>
> --
> /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
> \ / I'm really at ac.dekanfrus if you read it the right way.
> X Top-posted messages will probably be ignored. See RFC1855.
> / \ "Alexa, define 'bugging'."
|
|
|
|
| Re: IBM Midrange today? [message #385096 is a reply to message #385090] |
Tue, 16 July 2019 15:39 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Tuesday, July 16, 2019 at 2:57:48 PM UTC-4, Peter Flass wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>
>>> I also have no idea how much the optional features cost, and whether
>>> they were worth the extra cost in terms of added performance. I know
>>> some sites were on a tight budget and could only afford the bare bones
>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>> the 026, did not have a print and was a little cheaper.
>>
>> Even then, there was an intermediate option. One of the 026s at one
>> place I worked had a cheaper code plate; it would print alphanumerics
>> and a handful of special characters properly, but the rest of the
>> special characters came out as little square blocks. Not much fun
>> when you're trying to read program source code.
>
> 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.
|
|
|
|
| Re: IBM Midrange today? [message #385097 is a reply to message #385078] |
Tue, 16 July 2019 15:44 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: IBM Midrange today? [message #385098 is a reply to message #385090] |
Tue, 16 July 2019 15:45 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: IBM Midrange today? [message #385104 is a reply to message #385082] |
Tue, 16 July 2019 18:29 |
|
|
Originally posted by: J. Clarke
On Tue, 16 Jul 2019 09:17:27 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>> wrote:
>>
>>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>>
>>>> I also have no idea how much the optional features cost, and whether
>>>> they were worth the extra cost in terms of added performance. I know
>>>> some sites were on a tight budget and could only afford the bare bones
>>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>>> the 026, did not have a print and was a little cheaper.
>>>
>>> Even then, there was an intermediate option. One of the 026s at one
>>> place I worked had a cheaper code plate; it would print alphanumerics
>>> and a handful of special characters properly, but the rest of the
>>> special characters came out as little square blocks. Not much fun
>>> when you're trying to read program source code.
>>
>> Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
>> standard character for the square bracket--at work we use those
>> godawful trigraphs because if we don't the 3270 uses one code for the
>> square bracket and Eclipse/Compuware uses a different one--at least
>> the trigraphs are equally unreadable on all devices.
>
> 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.
OK, tell me how to set a code page in Eclipse that matches the one in
Rumba.
|
|
|
|
| Re: IBM Midrange today? [message #385105 is a reply to message #385089] |
Tue, 16 July 2019 19:16 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> hancock4@bbs.cpcn.com writes:
>>
>>> On Sunday, July 14, 2019 at 10:22:22 PM UTC-4, Dan Espen wrote:
>>>
>>>> One of my projects was Inventory and Costing in a division of a large
>>>> manufacturer. We did I&C on S/34 at the same time the main office was
>>>> trying to do the same thing on an MVS/CMS mainframe using IMS DB/DC.
>>>>
>>>> One of the differences between the projects is that the S/34 project
>>>> actually finished. We did that with a staff that maxed out at 4.
>>>> The main office stuff never finished, but they had about 50 consultants
>>>> on site.
>>>>
>>>> Before we get the traditional consultant bad-mouthing, I was a
>>>> consultant too.
>>>>
>>>> I offered to pull the mainframe effort out of it's hole, but
>>>> Arthur Anderson refused to turn over project control to me.
>>>>
>>>> Anyway, the software on the S/34 was a big help getting the job done.
>>>> The S/34 application would have run rings around the mainframe stuff (if
>>>> it ever got done).
>>>
>>> Could you elaborate n what aspects of the S/34 that
>>> made the development work go so much faster?
>>>
>>> I know IMS was kind of cumbersome.
>>
>> IMS has MFS. Cumbersome is one way to describe it.
>> It's clearly something designed in meetings.
>>
>> I never saw an IMS screen painter.
>> MFS screen definitions are written by a coder in Assembler.
>> The output is at least 4 load modules that take extra
>> work to start using for a test. I could go on...
>
> Sounds like CICS’ BMS, except that only generated one load module and a
> couple of DSECTS/copy books.
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
|
|
|
|
| Re: IBM Midrange today? [message #385106 is a reply to message #385090] |
Tue, 16 July 2019 19:19 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>
>>> I also have no idea how much the optional features cost, and whether
>>> they were worth the extra cost in terms of added performance. I know
>>> some sites were on a tight budget and could only afford the bare bones
>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>> the 026, did not have a print and was a little cheaper.
>>
>> Even then, there was an intermediate option. One of the 026s at one
>> place I worked had a cheaper code plate; it would print alphanumerics
>> and a handful of special characters properly, but the rest of the
>> special characters came out as little square blocks. Not much fun
>> when you're trying to read program source code.
>
> 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.
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
|
|
|
|
| Re: IBM Midrange today? [message #385107 is a reply to message #385036] |
Tue, 16 July 2019 19:40 |
|
|
Originally posted by: Pamela
On 08:29 15 Jul 2019, Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> hancock4@bbs.cpcn.com writes:
>>
>>
>> Personally, I didn't see the advantage of all that layering. The AS/400
>> took a lot from the failed Future System. To me, they should've kept
>> it simple, and followed the S/360 tradition, though maintaining
>> compatibility with the S/3x series.
>
> original AS/400 was "Fort Knox" ... next generation Rochester merging
> variety of S/3* products and use a risc/801 processor (part of the
> effort at the time to move all internal microprocessors to common
> 801/risc base, low&mid-range 370, AS/400, controllers, etc ... for
> various reasons all the efforts floundered and returned to traditional
> custom CISC microprocessors). The floundering Fort Knox was way behind
> schedule and never came out ... "Silverlake" was merged followon for
> both s/36 and s/38. https://wiki.midrange.com/index.php/Silverlake
>
> The Project Silverlake started as a sequel to a predecessor project
> code-named Fort Knox. The Fort Knox project had a lofty goal of creating
> the ultimate minicomputer in response to the successes of Digital
> Equipment Corporation(DEC) in the early 1980s. It was given the code
> name Fort Knox after the location of the U.S. government's gold
> depository.
>
> The goal of Fort Knox was to unify several smaller IBM computers then
> on the market and put DEC and other competitors on the run. Due to a
> rigid development process, the specifications for creating this computer
> grew more complex as each day passed. By 1985, it became obvious that
> the development team was years away from a workable product for the
> market, and the project was canceled.
Let's not forget that in the midrange, DEC was too well regarded by its
user base to lose many sites to IBM sales competition. However their user
base tenedd to be more scientific and technical rather than IBM's
commercial base.
> ...
>
> 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/
Thanks for posting that. It never struck me that AS/400 was such a great
big radical departure from the S/38 before it. The hardware had shrunk in
size but, and someone may correct me, the actual softare wasn't vastly
different to what went before it.
I believe Frank Soltis may have been the more senior but I also recall
Glenn Henry had a significant part to play in the design of the S/38.
"He was the instigator, lead architect and development manager
responsible for the IBM System/32, IBM System/38 "
http://www.ithistory.org/honor-roll/mr-gaylord-g-glenn-henry
> http://gallery.lib.umn.edu/exhibits/show/digital-state/ibm-r ochester
> https://en.wikipedia.org/wiki/IBM_System_i#History
>
> (Silverlake) AS/400 did eventually move to 801/risc ... in this case
> power/pc ... but a decade later.
It should not be forgotten there was more than a little rivarly inside IBM
between the S/360 architecture people and the S/3X people. Midrange was
sometimes seen as the "toy shop" and relatively poorly resourced perhaps
because the sales force didn't get as much bonus for them. A new S/38
installation might even be seen as a lost opportunity for a lovely
revenue-generating MVS licence plus its associated software!
|
|
|
|
| Re: IBM Midrange today? [message #385108 is a reply to message #385029] |
Tue, 16 July 2019 19:46 |
|
|
Originally posted by: Pamela
On 03:22 15 Jul 2019, Dan Espen <dan1espen@gmail.com> wrote:
> Pamela <pamela.poster@gmail.com> writes:
>
>> [...]
>
> 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 think S/34 used to just sit in the corner of an office and were run by a
regular member of staff.
> 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.
Very useful! :) Very clicky (almost clunking) keyboard, I believe.
|
|
|
|
| Re: IBM Midrange today? [message #385113 is a reply to message #385105] |
Tue, 16 July 2019 21:30 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> hancock4@bbs.cpcn.com writes:
>>>
>>>> On Sunday, July 14, 2019 at 10:22:22 PM UTC-4, Dan Espen wrote:
>>>>
>>>> > One of my projects was Inventory and Costing in a division of a large
>>>> > manufacturer. We did I&C on S/34 at the same time the main office was
>>>> > trying to do the same thing on an MVS/CMS mainframe using IMS DB/DC.
>>>> >
>>>> > One of the differences between the projects is that the S/34 project
>>>> > actually finished. We did that with a staff that maxed out at 4.
>>>> > The main office stuff never finished, but they had about 50 consultants
>>>> > on site.
>>>> >
>>>> > Before we get the traditional consultant bad-mouthing, I was a
>>>> > consultant too.
>>>> >
>>>> > I offered to pull the mainframe effort out of it's hole, but
>>>> > Arthur Anderson refused to turn over project control to me.
>>>> >
>>>> > Anyway, the software on the S/34 was a big help getting the job done.
>>>> > The S/34 application would have run rings around the mainframe stuff (if
>>>> > it ever got done).
>>>>
>>>> Could you elaborate n what aspects of the S/34 that
>>>> made the development work go so much faster?
>>>>
>>>> I know IMS was kind of cumbersome.
>>>
>>> IMS has MFS. Cumbersome is one way to describe it.
>>> It's clearly something designed in meetings.
>>>
>>> I never saw an IMS screen painter.
>>> MFS screen definitions are written by a coder in Assembler.
>>> The output is at least 4 load modules that take extra
>>> work to start using for a test. I could go on...
>>
>> Sounds like CICS’ BMS, except that only generated one load module and a
>> couple of DSECTS/copy books.
>
> 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.
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
|
|
|
|
| Re: IBM Midrange today? [message #385118 is a reply to message #385104] |
Tue, 16 July 2019 23:09 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Tue, 16 Jul 2019 09:17:27 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>>> wrote:
>>>
>>>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>>>
>>>> > I also have no idea how much the optional features cost, and whether
>>>> > they were worth the extra cost in terms of added performance. I know
>>>> > some sites were on a tight budget and could only afford the bare bones
>>>> > equipment. For instance, some shops used the 024 keypunch, which unlike
>>>> > the 026, did not have a print and was a little cheaper.
>>>>
>>>> Even then, there was an intermediate option. One of the 026s at one
>>>> place I worked had a cheaper code plate; it would print alphanumerics
>>>> and a handful of special characters properly, but the rest of the
>>>> special characters came out as little square blocks. Not much fun
>>>> when you're trying to read program source code.
>>>
>>> Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
>>> standard character for the square bracket--at work we use those
>>> godawful trigraphs because if we don't the 3270 uses one code for the
>>> square bracket and Eclipse/Compuware uses a different one--at least
>>> the trigraphs are equally unreadable on all devices.
>>
>> 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.
>
> OK, tell me how to set a code page in Eclipse that matches the one in
> Rumba.
Start here:
https://stackoverflow.com/questions/3751791/how-to-change-de fault-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
|
|
|
|
| Re: IBM Midrange today? [message #385119 is a reply to message #385113] |
Tue, 16 July 2019 23:31 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> hancock4@bbs.cpcn.com writes:
>>>>
>>>> > On Sunday, July 14, 2019 at 10:22:22 PM UTC-4, Dan Espen wrote:
>>>> >
>>>> >> One of my projects was Inventory and Costing in a division of a large
>>>> >> manufacturer. We did I&C on S/34 at the same time the main office was
>>>> >> trying to do the same thing on an MVS/CMS mainframe using IMS DB/DC.
>>>> >>
>>>> >> One of the differences between the projects is that the S/34 project
>>>> >> actually finished. We did that with a staff that maxed out at 4.
>>>> >> The main office stuff never finished, but they had about 50 consultants
>>>> >> on site.
>>>> >>
>>>> >> Before we get the traditional consultant bad-mouthing, I was a
>>>> >> consultant too.
>>>> >>
>>>> >> I offered to pull the mainframe effort out of it's hole, but
>>>> >> Arthur Anderson refused to turn over project control to me.
>>>> >>
>>>> >> Anyway, the software on the S/34 was a big help getting the job done.
>>>> >> The S/34 application would have run rings around the mainframe stuff (if
>>>> >> it ever got done).
>>>> >
>>>> > Could you elaborate n what aspects of the S/34 that
>>>> > made the development work go so much faster?
>>>> >
>>>> > I know IMS was kind of cumbersome.
>>>>
>>>> IMS has MFS. Cumbersome is one way to describe it.
>>>> It's clearly something designed in meetings.
>>>>
>>>> I never saw an IMS screen painter.
>>>> MFS screen definitions are written by a coder in Assembler.
>>>> The output is at least 4 load modules that take extra
>>>> work to start using for a test. I could go on...
>>>
>>> Sounds like CICS’ BMS, except that only generated one load module and a
>>> couple of DSECTS/copy books.
>>
>> 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.
>
> 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?
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
|
|
|
|
| Re: IBM Midrange today? [message #385120 is a reply to message #385118] |
Tue, 16 July 2019 23:52 |
|
|
Originally posted by: J. Clarke
On Tue, 16 Jul 2019 23:09:02 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Tue, 16 Jul 2019 09:17:27 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>
>>>> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>>>> wrote:
>>>>
>>>> >On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>>> >
>>>> >> I also have no idea how much the optional features cost, and whether
>>>> >> they were worth the extra cost in terms of added performance. I know
>>>> >> some sites were on a tight budget and could only afford the bare bones
>>>> >> equipment. For instance, some shops used the 024 keypunch, which unlike
>>>> >> the 026, did not have a print and was a little cheaper.
>>>> >
>>>> >Even then, there was an intermediate option. One of the 026s at one
>>>> >place I worked had a cheaper code plate; it would print alphanumerics
>>>> >and a handful of special characters properly, but the rest of the
>>>> >special characters came out as little square blocks. Not much fun
>>>> >when you're trying to read program source code.
>>>>
>>>> Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
>>>> standard character for the square bracket--at work we use those
>>>> godawful trigraphs because if we don't the 3270 uses one code for the
>>>> square bracket and Eclipse/Compuware uses a different one--at least
>>>> the trigraphs are equally unreadable on all devices.
>>>
>>> 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.
>>
>> OK, tell me how to set a code page in Eclipse that matches the one in
>> Rumba.
>
> Start here:
>
> https://stackoverflow.com/questions/3751791/how-to-change-de fault-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.
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.
|
|
|
|
| Re: IBM Midrange today? [message #385122 is a reply to message #385095] |
Wed, 17 July 2019 02:08 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-07-16, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> On Tuesday, July 16, 2019 at 4:08:03 AM UTC-4, Charlie Gibbs wrote:
>
>> On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>
>>> I also have no idea how much the optional features cost, and whether
>>> they were worth the extra cost in terms of added performance. I know
>>> some sites were on a tight budget and could only afford the bare bones
>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>> the 026, did not have a print and was a little cheaper.
>>
>> Even then, there was an intermediate option. One of the 026s at one
>> place I worked had a cheaper code plate; it would print alphanumerics
>> and a handful of special characters properly, but the rest of the
>> special characters came out as little square blocks. Not much fun
>> when you're trying to read program source code.
>
> 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.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: IBM Midrange today? [message #385123 is a reply to message #385098] |
Wed, 17 July 2019 02:08 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-07-16, hancock4@bbs.cpcn.com <hancock4@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.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: IBM Midrange today? [message #385129 is a reply to message #385120] |
Wed, 17 July 2019 08:31 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Tue, 16 Jul 2019 23:09:02 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Tue, 16 Jul 2019 09:17:27 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>>
>>>> > On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>>>> > wrote:
>>>> >
>>>> >>On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>>> >>
>>>> >>> I also have no idea how much the optional features cost, and whether
>>>> >>> they were worth the extra cost in terms of added performance. I know
>>>> >>> some sites were on a tight budget and could only afford the bare bones
>>>> >>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>>> >>> the 026, did not have a print and was a little cheaper.
>>>> >>
>>>> >>Even then, there was an intermediate option. One of the 026s at one
>>>> >>place I worked had a cheaper code plate; it would print alphanumerics
>>>> >>and a handful of special characters properly, but the rest of the
>>>> >>special characters came out as little square blocks. Not much fun
>>>> >>when you're trying to read program source code.
>>>> >
>>>> > Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
>>>> > standard character for the square bracket--at work we use those
>>>> > godawful trigraphs because if we don't the 3270 uses one code for the
>>>> > square bracket and Eclipse/Compuware uses a different one--at least
>>>> > the trigraphs are equally unreadable on all devices.
>>>>
>>>> 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.
>>>
>>> OK, tell me how to set a code page in Eclipse that matches the one in
>>> Rumba.
>>
>> Start here:
>>
>> https://stackoverflow.com/questions/3751791/how-to-change-de fault-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.
>
> 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.
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
|
|
|
|
| Re: IBM Midrange today? [message #385136 is a reply to message #385113] |
Wed, 17 July 2019 16:45 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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).
|
|
|
|
| Re: IBM Midrange today? [message #385137 is a reply to message #385129] |
Wed, 17 July 2019 18:36 |
|
|
Originally posted by: J. Clarke
On Wed, 17 Jul 2019 08:31:06 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Tue, 16 Jul 2019 23:09:02 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>
>>>> On Tue, 16 Jul 2019 09:17:27 -0400, Dan Espen <dan1espen@gmail.com>
>>>> wrote:
>>>>
>>>> >J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >
>>>> >> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>>>> >> wrote:
>>>> >>
>>>> >>>On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>>> >>>
>>>> >>>> I also have no idea how much the optional features cost, and whether
>>>> >>>> they were worth the extra cost in terms of added performance. I know
>>>> >>>> some sites were on a tight budget and could only afford the bare bones
>>>> >>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>>> >>>> the 026, did not have a print and was a little cheaper.
>>>> >>>
>>>> >>>Even then, there was an intermediate option. One of the 026s at one
>>>> >>>place I worked had a cheaper code plate; it would print alphanumerics
>>>> >>>and a handful of special characters properly, but the rest of the
>>>> >>>special characters came out as little square blocks. Not much fun
>>>> >>>when you're trying to read program source code.
>>>> >>
>>>> >> Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
>>>> >> standard character for the square bracket--at work we use those
>>>> >> godawful trigraphs because if we don't the 3270 uses one code for the
>>>> >> square bracket and Eclipse/Compuware uses a different one--at least
>>>> >> the trigraphs are equally unreadable on all devices.
>>>> >
>>>> >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.
>>>>
>>>> OK, tell me how to set a code page in Eclipse that matches the one in
>>>> Rumba.
>>>
>>> Start here:
>>>
>>> https://stackoverflow.com/questions/3751791/how-to-change-de fault-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.
>>
>> 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.
>
> 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.
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.
|
|
|
|
| Re: IBM Midrange today? [message #385140 is a reply to message #385136] |
Wed, 17 July 2019 18:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<hancock4@bbs.cpcn.com> wrote:
> 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).
>
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
|
|
|
|
| Re: IBM Midrange today? [message #385141 is a reply to message #385137] |
Wed, 17 July 2019 19:17 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Wed, 17 Jul 2019 08:31:06 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Tue, 16 Jul 2019 23:09:02 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>>
>>>> > On Tue, 16 Jul 2019 09:17:27 -0400, Dan Espen <dan1espen@gmail.com>
>>>> > wrote:
>>>> >
>>>> >>J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>
>>>> >>> On 16 Jul 2019 08:07:30 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>>>> >>> wrote:
>>>> >>>
>>>> >>>>On 2019-07-15, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>>>> >>>>
>>>> >>>>> I also have no idea how much the optional features cost, and whether
>>>> >>>>> they were worth the extra cost in terms of added performance. I know
>>>> >>>>> some sites were on a tight budget and could only afford the bare bones
>>>> >>>>> equipment. For instance, some shops used the 024 keypunch, which unlike
>>>> >>>>> the 026, did not have a print and was a little cheaper.
>>>> >>>>
>>>> >>>>Even then, there was an intermediate option. One of the 026s at one
>>>> >>>>place I worked had a cheaper code plate; it would print alphanumerics
>>>> >>>>and a handful of special characters properly, but the rest of the
>>>> >>>>special characters came out as little square blocks. Not much fun
>>>> >>>>when you're trying to read program source code.
>>>> >>>
>>>> >>> Are you sure that's not EBCDIC? EBCDIC today still doesn't have a
>>>> >>> standard character for the square bracket--at work we use those
>>>> >>> godawful trigraphs because if we don't the 3270 uses one code for the
>>>> >>> square bracket and Eclipse/Compuware uses a different one--at least
>>>> >>> the trigraphs are equally unreadable on all devices.
>>>> >>
>>>> >>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.
>>>> >
>>>> > OK, tell me how to set a code page in Eclipse that matches the one in
>>>> > Rumba.
>>>>
>>>> Start here:
>>>>
>>>> https://stackoverflow.com/questions/3751791/how-to-change-de fault-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.
>>>
>>> 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.
>>
>> 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.
>
> 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.
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
|
|
|
|
| Re: IBM Midrange today? [message #385142 is a reply to message #385140] |
Wed, 17 July 2019 19:26 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> <hancock4@bbs.cpcn.com> wrote:
>> 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).
>
> 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.
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
|
|
|
|
| Re: IBM Midrange today? [message #385144 is a reply to message #385142] |
Wed, 17 July 2019 21:19 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> <hancock4@bbs.cpcn.com> wrote:
>>> 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).
>>
>> 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.
>
> 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.
>
My experience was just the opposite, but I guess neither is especially
pertinent today.
--
Pete
|
|
|
|
| Re: IBM Midrange today? [message #385150 is a reply to message #385142] |
Thu, 18 July 2019 04:08 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-07-17, Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> <hancock4@bbs.cpcn.com> wrote:
>>
>>> 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).
>>
>> 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.
>
> 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.
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.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: IBM Midrange today? [message #385161 is a reply to message #385150] |
Thu, 18 July 2019 10:17 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2019-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> <hancock4@bbs.cpcn.com> wrote:
>>>
>>>> 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).
>>>
>>> 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.
>>
>> 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.
>
> 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.
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
|
|
|
|
| Re: IBM Midrange today? [message #385162 is a reply to message #385161] |
Thu, 18 July 2019 10:44 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>
>> On 2019-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>>
>>> Peter Flass <peter_flass@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).
|
|
|
|
| Re: IBM Midrange today? [message #385168 is a reply to message #385142] |
Thu, 18 July 2019 15:15 |
|
|
Originally posted by: antispam
Dan Espen <dan1espen@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
|
|
|
|
| Re: IBM Midrange today? [message #385169 is a reply to message #385162] |
Thu, 18 July 2019 15:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> Dan Espen <dan1espen@gmail.com> writes:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>
>>> On 2019-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>>>
>>>> Peter Flass <peter_flass@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
|
|
|
|
| Re: IBM Midrange today? [message #385170 is a reply to message #385168] |
Thu, 18 July 2019 15:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<antispam@math.uni.wroc.pl> wrote:
> Dan Espen <dan1espen@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
|
|
|
|
| Re: IBM Midrange today? [message #385171 is a reply to message #385170] |
Thu, 18 July 2019 16:08 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> <antispam@math.uni.wroc.pl> wrote:
>> Dan Espen <dan1espen@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
|
|
|
|
| Re: IBM Midrange today? [message #385172 is a reply to message #385150] |
Thu, 18 July 2019 17:34 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: IBM Midrange today? [message #385177 is a reply to message #385168] |
Thu, 18 July 2019 19:04 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
antispam@math.uni.wroc.pl writes:
> Dan Espen <dan1espen@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...
Buffer address encoding:
http://www.tommysprinkle.com/mvs/P3270/sbaxlate.htm
--
Dan Espen
|
|
|
|
| Re: IBM Midrange today? [message #385358 is a reply to message #385171] |
Tue, 23 July 2019 12:12 |
usenet
Messages: 556
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On Thu, 18 Jul 2019 20:08:25 GMT, scott@slp53.sl.home (Scott Lurndal) wrote:
> Peter Flass <peter_flass@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.
|
|
|
|
| Re: IBM Midrange today? [message #385359 is a reply to message #385358] |
Tue, 23 July 2019 12:20 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
usenet@only.tnx (Questor) writes:
> On Thu, 18 Jul 2019 20:08:25 GMT, scott@slp53.sl.home (Scott Lurndal) wrote:
>> Peter Flass <peter_flass@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.
|
|
|
|
| Re: IBM Midrange today? [message #385369 is a reply to message #385359] |
Tue, 23 July 2019 17:16 |
|
|
Originally posted by: 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
|
|
|
|
Members
Search
Help
Register
Login
Home
