2004 Newsgroup postings (02/28 - 03/20) Lynn Wheeler

2004 Newsgroup Postings (02/28 - 03/20)

A POX on you, Dennis Ritchie!!!
Oldest running code
Oldest running code
Oldest running code
OS Partitioning and security
PSW Sampling
If the x86 ISA could be redone
IBM operating systems
IBM operating systems and APL
TSS/370 binary distribution now available
XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
40yrs, science center, feb. 1964
The BASIC Variations
Yakaota
A POX on you, Dennis Ritchie!!!
If there had been no MS-DOS
Anyone Still Using Cards?
If there had been no MS-DOS
IT jobs move to India
IT jobs move to India
Parallel programming again (Re: Intel announces "CT" aka
PSW Sampling
More complex operations now a better choice?
Jargon Files Wanted
More complex operations now a better choice?
More complex operations now a better choice?
Moribund TSO/E
Moribund TSO/E
Moribund TSO/E
separate MMU chips
Moribund TSO/E
Moribund TSO/E
Moribund TSO/E
separate MMU chips
Playing games in mainframe
Computer-oriented license plates
If there had been no MS-DOS
Memory Affinity
ATA drives and vibration problems in multi-drive racks
Memory Affinity
Microprocessor History Site
If there had been no MS-DOS
Moribund TSO/E
why and how VeriSign, thawte became a trusted CA?
If there had been no MS-DOS
Detecting when FIN has arrived
IBM 360 memory
IBM 360 memory
IBM 360 Memory
[OT] Lockheed puts F-16 manuals online
[OT] Lockheed puts F-16 manuals online
[OT] Lockheed puts F-16 manuals online
Detecting when FIN has arrived
defination of terms: "Application Server" vs. "Transaction Server"
[OT] Lockheed puts F-16 manuals online
Idea for concurrent transactions
Bushwah and shrubbery
[OT] Lockheed puts F-16 manuals online
real multi-tasking, multi-programming
real multi-tasking, multi-programming
IBM 360 memory
IBM 360 memory

A POX on you, Dennis Ritchie!!!

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A POX on you, Dennis Ritchie!!!
Newsgroups: alt.folklore.computers
Date: Sat, 28 Feb 2004 16:31:18 GMT

Roland Hutchinson writes:
It is very easy to answer why.

The MLA handbook does not seek to provide guidance for formatting texts in a way that will help the reader to read efficiently.

It provides guidance for formating manuscripts in a way that will help the editor, the copyeditor, and the publisher do their jobs efficiently. The text that leaves the author's hands therefore, for a variety of reasons, is NOT formatted the way it will be when the reader ultimately sees it.

after we decided on doing the internal online telephone book as a killer app to get executives interested in using keyboards ... during deployment we got into big discussion about whether it should be name/number or number/name in the display.

the scenario was that if there was a single exact match .. then leading number would be the faster thing for the person to find .. however, if there wasn't a single exact match and there was a list of names, then it would be easier for the human to scan leading names (especially when there was some variability in number lengths).

couple minor previous posts:
https://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Oldest running code

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest running code
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 28 Feb 2004 16:52:43 GMT

Brian Inglis writes:
GML is a markup language, not a programming language. But the APFs (Application Processing Functions associated to GML tags) were written in SCRIPT (/DCF?) control language, which provides a macro programming language with conditionals and either jumps or loops, I can't remember, and can't find the ref card right now. Changed GML to handle IBM 6670 and various models of Xerox laser printers almost identically to IBM 3800 printers, and support every font provided (max 4 per page IIRC), once upon a time.

i knew some number of people who were considered GML programmers ... especially in various parts of the business that specialized in writing responses to RFPs and other stuff. script had macro, conditionals, testing, branching, logic, etc (aka programming)

the original application was SCRIPT ... from mid-60s on CMS .. done at the cambridge science center. it supported runoff like "dot" commands. Later (still at cambridge science center) "G", "M", and "L" invented gml and GML syntax support was also added to SCRIPT. the analogy might be the difference between a machine program and an assembler programmer where machine & assembler are sometimes used interchangeably.

an early, widely available publication that utilized the conditional support was the 360 (later 370) principles of operation and the architecture "red book". The architecture "red book" was an internal only document distributed in a ox-blood colored 3ring binder. It was a superset of the 360 principles of operation (describing the machine operation, instructions, etc) which included all the unannounced instructions, a lot of engineering/hardware consideration notes on instructions & machine features, and various justifications for incorporating/adding the instruction to the original architecture.

When the 360 principles of operation was printed ... it was done w/o all the architecture, engineering, and business notes.

misc. past science center posts
https://www.garlic.com/~lynn/subtopic.html#545tech

recent posting referencing redbook:
https://www.garlic.com/~lynn/2004b.html#57 PLO instruction

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Oldest running code

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest running code
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 28 Feb 2004 16:56:38 GMT

Brian Inglis writes:
Nice hack, wish it had been documented in the EXEC/EXEC2 manuals! Now if only the diagnose calls were as easy to substitute. Although life required a lot less assembler when REXX was released with the DIAG?NOSE?() function, ISTR REXX did not support all the possible VM DIAG instruction operands, and some assembly was still required.

yes, very early on, i decided to do a demo of the power of REX (before it changed it name to REXX) and that it wasn't just another pretty command batching language. I selected the CP/CMS dump processing facility ... which was a large assembler written application supported by a modest sized organization in endicott.

the objective was to spend 3 months half-time re-implementing the application in REX which would have ten times the function and ran ten times faster. I did have to do about 120 instructions of assembler to achieve the goal. misc. past refs to the effort:
https://www.garlic.com/~lynn/submain.html#dumprx

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Oldest running code

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest running code
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 28 Feb 2004 19:11:58 GMT

Brian Inglis writes:
WAIT RDR1RDR1 <8bytes hex zeros> ^^^^^^^^ fence word with x'FF' I presume?

nope ... standard fencing was eight bytes of x'00'

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

OS Partitioning and security

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS Partitioning and security
Newsgroups: comp.security.misc
Date: Sat, 28 Feb 2004 19:10:04 GMT

"Tsvi Gad" writes:
I am looking for information about the following issue: A client I work for is going to use a single hardware for the Development and Production servers by using the machine ability of OS Partitioning. It means that every OS has its own hardware exept the bus that is common. The problem is that for security reasons there is a need to separate the two servers and it also has different sets of data. I am sure every vendor will confirm that kind of architecture as safe but my guts says otherwise.

Does anyone have some article or expirience that will support my opinion?

note one of the original partitionings used extensively for various security operations was virtual machines .... dating back to cp/67
https://www.garlic.com/~lynn/2003d.html#72 CP/67 35th anniversary

which morphed into VM/370. various microcode performance assists for virtual machine support
https://www.garlic.com/~lynn/submain.html#mcode

became quite sophisticated ... leading to PR/SM and then to LPARS ... or logical partitions ... where a significant subset of the VM/370 support is implemented directly in the hardware of the machine ... and it is possible to partition the real hardware into multiple "logical partitions" each running their own operating system.

much more recently there have been the intel architecture virtual machine software implementations used for providing partitioning (as well as security) ... and a number of vendors are now talking about offering hardware-supported partitioning ... similar to the mainframe LPAR concept.

the other higher level concept for partitioning for security are the capability-based operating system implementations ... like gnosis, keykos, and eros (see refs following the pr/sm and lpar refs).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

PSW Sampling

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PSW Sampling
Newsgroups: bit.listserv.ibm-main
Date: Sat, 28 Feb 2004 23:45:13 GMT

jfregus@ibm-main.ix.netcom.com (John F. Regus) writes:
There is only one PSA per processor. You cannot look at the PSA for one machine while inside of another.

on 360/67 SMP ... each processor had a different PSA 4k that came out of real storage someplace; all 4k PSAs could be addressed by all processors by their "real" address (just a matter of knowing what 4k real address each processor had their PSA set to); however, real page zero was "lost".

for 370 SMP ... this was modified so that each processor could address real page zero ... by the real address of that processor's PSA ... aka each processor loaded a 4k real page address into their PSA register ... all references to page zero were converted to the page address in the PSA register and all addresses for the real page address in the PSA address was converted to real page zero. That way all processors could address the real page zero ... by using the value loaded into their PSA register. operating systems then could use their PSA for processor specific information ... and still be able to use real page zero for complex-wide information. discussion of z/390 prefixing (now 8k bytes):
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/3.7?SHELF=DZ9ZBK01&DT=20020416112421

long ago and far away ... boeing wichita used a video camera focused on the 370/168 display lights to do PSW sampling.

reference to 370/145 microcode change to do psw sampling:
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

sort of part of the evoluation in vm microcode assists that led up to PR/SM and eventually LPARs.

misc. other mcode refs:
https://www.garlic.com/~lynn/submain.html#mcode

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

If the x86 ISA could be redone

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If the x86 ISA could be redone...
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 29 Feb 2004 03:30:42 GMT

"Stephen Fuld" writes:
I can't comment more on the PDP 11 due to lack of knowledge, but you are conflating several things with regard to S370. First, the vitrual address stuff. The early S370s, specifically the 155 and 165 did not have virtual memory, as they were essentially just faster S360s. Even when the virtual address systems came out (the models ending in 8), they still didn't support any more than 16 MB of memory. The ability to use more than 24 bits for a memory address came only with Extended Addressing mode (called XA), which came later. I expect the Wheelers can provide specific dates for all of these.

360/67 was basically a 360/65 with DAT (dynamic address translation) box providing virtual memory. the 360/67 supported both 24bit and 32bit virtual addressing (circa late 1966). there was official product for the 360/67 called TSS/360 which never was very successful. however, a virtual machine operating system utilizing virtual memory was developed by the cambridge science center, initially on a custom modified 360/40 and later ported to standard 360/67. note on cp/67 35th anniv:
https://www.garlic.com/~lynn/2003d.html#72
which later morphed into vm/370 for 370. misc. other posts about cambridge science center:
https://www.garlic.com/~lynn/subtopic.html#545tech
which also was where GML (precursor to SGML, HTML, XML, etc) originated as well as the internal network
https://www.garlic.com/~lynn/internet.htm

the early 370s were shipped w/o dyanamic address translation enabled ... in the 155 and 165 case ... the hardware wasn't even there. however, there was something of strong speculation since the rollers on the front of the 370/145 had a lamp in the psw bit definitions with the designation "XLATE" ... that lots of customers speculated as meaning translation. later with the announcement of virtual memory, a new floppy disk was distributed which contained the microcode to enable virtual memory on the 145. the 155 & 165 required field upgrades. however there were issues with the 165 field upgrade. the original 370 virtual memory architecture ("redbook") included selective invaliation instructions (invalidate page table entry, invalidate segment table entry, invalidate address space) in addition to the purge lookaside buffer (PTLB). however, the 165 engineers claimed that implementing the selective invalidation instructions would delay the virtual memory hardware availability for the 165 by six months ... so the instructions were dropped from 370 virtual memory product (although selective invalidate page table entry was latter introduced with the 3033).

the 3033 also had a hack for addressing more than 16mbytes of real memory. The 370 16bit pagetable entry had two unused bits ... 12 bits for (4k byte) page number, page table invalid bit and page reference bit. The 3033 hack was to use the two unused bits and add them to the page number field ... extended the number of 4k pages that could be specified to 14bits or possibly up to 64mbytes of real storage. While instructions couldn't address more than 24bits, they could be translated to a real page address that could resolve to 26bit address. This, in part worked since 370 architecture had originally extended i/o addressing with IDAL (indirect data list) that allowed 31-bit address specification.

another issue was that the mainstream mainframe commercial batch system had the kernel and all services occupying the same address space as applications with API that evolved using pointer passing (which then was predicated on associated parameters in the same address space). The initial transition to 370 virtual memory for this batch system was single virtual (paged) 16mbyte address space as if it was running on 16mbyte real machine ... with 8mbytes reserved for kernel functions and 8mbytes for all applications. This then evolved into MVS with multiple virtual address spaces ... with each application having its own 16mbyte address space ... although with shared kernel occupying 8mbytes of each application address space. After the mid 70s, there got to be a problem with expanding system services taking more than 8mbytes (of the 16mbyte) virtual address apace ... in some cases leaving only 4mbytes in each address space for actual application use.

to address this issue a dual address space feature was introduced with the 3033 (in addition to greater than 16mbyte real addressing). this allowed semi-priviledged system service applications to reside in their own address space and be called by normal user applications using pointer-passing API paradigm ... where the sermi-priviledged system services had expanded instructions that could access alternative (typically user domain) virtual address spaces. This somewhat alleviated the problem of fitting all system services in the same 16mbyte virtual address space with a running application.

xa with 31bit addressing (not 32bit as in the earlier 360/67) was referred to originally as 811 (date of architecture specification, nov, 1978) ... and was introduced with 3081 processors.

xa introduced the concept of access registers that sort of expanded the concept of cross-memory services. in addition to the fact that there was a pointer passing paradigm ... some number of system services were packaged as system libraries and invoked by standard subroutine program call. For various integrity reasons there was a desire to move most of these library system functions into semi-priviledged and different address space from the running application ... but still be able to do subroutine linkages w/o the overhead of kernel calls, priviledge checking and address space changes. so there are now a number of access tables for services that are predefined ... some number of alternatively defined address spaces and a lightweight PC/program-call instruction that can call subroutines in alternative address spaces under controlled rules. These still use the pointer passing API paradigm ... and these subroutines use cross-memory instructions to access parameters and data in the application address space. while the original cross memory services were originally targeted at moderating some of the difficulty of all system services occupying the same 16mbyte address space as the application ... the access register architecture continues the cross memory paradigm into the 31-bit (and now 64bit) architecture ... more as an integrity feature ... rather than as memory size relief.

some past posts on access registers (in some cases include URL pointers to official architecture/hardware descriptions);
https://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
https://www.garlic.com/~lynn/2002n.html#74 Everything you wanted to know about z900 from IBM

totally random recent posting on paging (from mainframe n.g.)
https://www.garlic.com/~lynn/2004b.html#60 paging

more dates than you possibly ever wanted to know:


Product
or Event          Ann.  FCS            Description
CDC6600          63-08 64-09     LARGE SCIENTIFIC PROCESSOR
IBMS/360-67      65-08 66-06 10  MOD 65+DAT; 1ST IBM VIRTUAL MEMORY
IBMPL/I.LANG.    66-?? 6????     MAJOR NEW LANGUAGE (IBM)
IBMS/360-91      66-01 67-11 22  VERY LARGE CPU; PIPELINED
IBMPRICE         67-?? 67???     PRICE INCREASE???
IBMOS/360        67-?? 67-12     MVT - ADVANCED MULTIPROGRAMMED OS
IBMTSS           67??? ??-??     32-BIT VS SCP-MOD 67; COMMERCIAL FAILURE
1Kbit/chip.RAM   68              First commercial semicon memory chip
IBMCP/67         68+?? 68+??     MULTIPLE VIRTUAL MACHINES SCP-MOD 67
IBMSW.UNBUNDLE   69-06 70-01 07  IBM SOFTWARE, SE SERVICES SEP. PRICED
IBMS/360-195     69-08 71-03 20  VERY LARGE CPU; FEW SOLD; SCIENTIFIC
IBMS/370ARCH.    70-06 71-02 08  EXTENDED (REL. MINOR) VERSION OF S/360
IBM3330-1        70-06 71-08 14  DISK: 200MB/BOX, $392/MB
IBMS/370-155     70-06 71-01 08  LARGE S/370
IBMS/370-165     70-06 71-04 10  VERY LARGE S/370
IBMS/370-145     70-09 71-08 11  MEDIUM S/370 - BIPOLAR MEMORY - VS READY
AMHAMDAHL        70-10           AMDAHL CORP. STARTS BUSINESS
Intel,Hoff       71              Invention of microprocessor
IBMS/370-135     71-03 72-05 14  INTERMED. S/370 CPU
IBMS/360-22      71-04 71-07 03  SMALL S/360 CPU
IBMLEASE         71-05 71 06 01  FixTERM PLAN;AVE. -16% FOR 1,2 YR LEASE
IBMPRICE         71-07 71+?? +8% ON SOME CPUS;1.5% WTD AVE. ALL CPU
IBMS/370-195     71-07 73-05 22  V. LARGE S/370 VERS. OF 360-195, FEW SOLD
IBMVM.ASSIST     72+?? 7?-??     MICROCODE ASSIST FOR VM/370
IBMMVS-JES3      72+?? 75-10     LOOSE-COUPLED MP (ASP-LIKE)
IBMMVS-JES2      72-?? 72-08     JOB-ENTRY SUBSYSTEM 2 (HASP-LIKE)
IBMVSAM          72+?? 7?-??     NEW RANDOM ACCESS METHOD
IBM3705          72-03 72-06     COMMS CNTLR: 352 LINES; 56KB/SEC
IBMS/370.VS      72-08 73-08 12  VIRTUAL STORAGE ARCHITECTURE FOR S/370
IBM135-3         72-08 73-08 12  INTERMED. S/370 CPU
IBM145-3         72-08 73-08 12  INTERMED. S/370 CPU
IBM158           72-08 73-04 08  LARGE S/370, VIRTUAL MEMORY
IBM168           72-08 73-08 12  VERY LARGE S/370 CPU, VIRTUAL MEMORY
IBMOS/VS1        72-08 73-??     VIRTUAL STORAGE VERSION OF OS/MFT
IBMOS/VS2(SVS)   72-08 72+??     VIRTUAL STORAGE VERSION OF OS/MVT
IBMOS/VS2(MVS)   72-08 74-08     MULTIPLE VIRTUAL ADDRESS SPACES
IBMVM/370        72-08 72+??     MULTIPLE VIRTUAL MACHINES (LIKE CP/67)
IBM125           72-10 73-04 06  SMALL S/370 CPU
AMHV/6           75-04?75-06 02  FIRST AMDAHL MACHINE, FIRST  PCM CPU
AMHV6-2          76-10 77-09 11  (1.05-1.15)V6 WITH 32K BUFFER
AMHV7            77-03 78-09 18  AMDAHL RESP. TO 3033 (1.5-1.7) V6
IBM3033          77-03 78-03 12  VERY LARGE S/370+EF INSTRUCTIONS
IBM3031          77-10 78-03 05  LARGE S/370+EF INSTRUCTIONS
IBM3032          77-10 78-03 05  LARGE S/370+EF INSTRUCTIONS
IBM3033MP        78-03 79-09 18  MULTIPROCESSOR OF 3033
IBM3033MP        78-03 79-09 18  MULTIPROCESSOR OF 3033
AMHPLANT         78-05           AMDAHL OPENS DUBLIN, IRELAND PLANT
AMHV8            78-10 79-09 11  (1.80-2.00)V6, FLD UPGR. FROM V7
IBM3033AP        79-01 80-02 13  ATTACHED PROCESSOR OF 3033 (3042)
IBM3033          79-11 79-11 00  -15% PURCHASE PRICE CUT
IBM3033N         79-11 80-01 04  DEGRADED 3033, 3.9MIPS
IBM3033AP        80-06 80-08 02  3033 ATTACHED PROCESSOR
IBM3033          80-06 81-10 16  Ext. Addr.=32MB REAL ADDR.;MP ONLY
IBMD.Addr.Sp.    80-06 81-06 12  Dual Address Space for 3033
IBM3033XF        80-06 81-06 12  OPTIONAL HW/FW PERF. ENHANCE FOR MVS/SP
AMHUTS           80-09 81-05     UTS=Amdahl Unix Op. System (under VM)
IBM3033.24MB     80-11 81-11 12  24MB REAL MEM. FOR 3033UP, AP
IBM3081D         80-11 81-4Q 12  FIRST H MODEL, 10MIPS IN DP, WATER COOLED
AMH580/5860      80-11 82-09 22  (2V8, 12+ MIPS) UP, NEW,AIR COOLED TECH.
AMH580/5880      80-11 85-05 54  MP OF 5860 AT 21+ MIPS
IBM3033S         80-11 81-01 02  2.2MIPS, DEGRADED 3033 (ENTRY 3033 MODEL)
IBM3033N.UPGR.   80-11 80-11 00  9%-14% PERF. IMPROVE, NO CHARGE
IBM3081K         81-10 82-2Q 08  NEW DP FUM: 1.353081D, 64K BUFFER/OVLAP
IBM370-XA        81-10 83-03 17  NEW ARCH 3081: 31 BIT REAL/VIRT, NEW I/O
IBM3033.PRICE    81-10           10% IN US, 12-20% EUROPE PURCH. ONLY
IBM3033S.PERF.   81-10 82-06 08  NO-CHARGE PERF. BOOST BY 8%-10%
IBM3033          82-03           16% PUR.PRICE CUT, -14%Mem.Price($31K/MB)
IBM3033          82-03           3033 Placed on LIMITED-NEW PRODUCTION
IBM3084          82-09 83-4Q 15  1.93081K Perf., 4 way MP, 3081K upgrade

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

IBM operating systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM operating systems
Newsgroups: alt.folklore.computers
Date: Sun, 29 Feb 2004 16:56:49 GMT

cstacy@news.dtpq.com (Christopher C. Stacy) writes:
I used APL*PLUS in the 70s on the Amdahl/470. I believe that there was another layer of standard or hacked-up operating system underneath that. Does anyone know what that was? And what was the relationship of the IBM operating systems to the APL that IBM had (APL/360)?

many of the early Amdahls ran mts (michigan terminal system) and vm/370 at universities. the first business/commercial account to install Amdahl was aetna in hartford around mid 1976; from recent post
https://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone


AMHV/6           75-04?75-06 02  FIRST AMDAHL MACHINE, FIRST  PCM CPU
AMHV6-2          76-10 77-09 11  (1.05-1.15)V6 WITH 32K BUFFER
AMHV7            77-03 78-09 18  AMDAHL RESP. TO 3033 (1.5-1.7) V6

random unrelated ... activity I was involved in as undergraduate that we get blamed for producing the first PCM controller and spawning the PCM controller business:
https://www.garlic.com/~lynn/submain.html#360pcm

later in the 70s there were more Amdahl machines running mvs.

apl\360 was apl language and subtasking monitor/swapper that ran as subsystem under os/360. it typically managed two 16kbyte (or 32kbyte) swapping regions for apl workspaces and all the terminal interactions, besides also providing the apl interpreter.

cambridge science center circa 1970
https://www.garlic.com/~lynn/subtopic.html#545tech

took a copy of apl\360 and adopted just the interpreter to cms\apl ... and doing things like rewriting the garbage collecttion for virtual memory environment (and opening up apl so workspace could just about be full 16mbyte). it also "corrupted" the apl syntax by adding support for doing system calls ... so apl programs could do things like read/write files. this was used to provide services to corporate hdqtrs planning and business people for doing what-if things that are typically done with spreadsheets today ... using business models written in apl. this was something of security challenge since there were lots of MIT & BU students using cambridge system ... and corporate people were loading the most highly valued corporate data on the machine. some misc. comments about cp/67, vm/370 and security in time-sharing offerings:
https://www.garlic.com/~lynn/submain.html#timeshare

cms\apl also became the delivery vehicle for HONE supporting all the field, marketing, sales people world-wide (hone as well as lots of general APL comments):
https://www.garlic.com/~lynn/subtopic.html#hone
about 1977 all the US HONE datacenters were consolidated in California ... and possibly the largest (at the time) single system operations was created for supporting US marketing, sales and field forces. HONE clones were created at various places around the world ... for some number of clones I hand carried and personally did the install ... the original was when EMEA hdqtrs moved from NY to la defense (near paris) ... random recent ref:
https://www.garlic.com/~lynn/2004b.html#58 oldest running code

the palo alto science center later did apl\cms with a microcode accelerator for the 370/145 (apl programs on the 145 w/apl-mcode would run as fast as on 370/168). apl\cms was then transferred to santa teresa labs (STL) where support was added for running under MVS (somewhat back to the original apl\360) in addition to running on CMS ... and renamed apl\sv ... for apl shared variable. This was important to many people because it eliminated the system call API interface (corruption) introduced with cms\apl and replaced it with the shared-variable paradigm ... where things like system call APIs were abstracted behind the shared variable interface.

there was a special 2741 typeball and little stickers for the front face of 2741 keys ... that supported the APL character set (as well as cp/67 and vm/370 translate tables). later there was special 3277 display model that supported apl character set.

quicky use of search engine for a apl*plus (& stsc) history:
http://www.lescasse.com/APLHistory.asp
http://www.rexswain.com/aplinfo.html

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

IBM operating systems and APL

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM operating systems and APL
Newsgroups: alt.folklore.computers
Date: Sun, 29 Feb 2004 17:14:10 GMT

johnl@iecc.com (John R. Levine) writes:
The IBM 5100, an early single user portable computer, also ran APL\360. They wrote an emulator for as much of the 360 instruction set as APL needed, and replaced the OS interface with code to talk to the keyboard, screen, and cartridge tape that the 5100 had. It wasn't fast, but it was real APL and was quite usable.

random past 5100 & palm (Put All Logic in Microcode) refs:
https://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
https://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
https://www.garlic.com/~lynn/2000d.html#15 APL version in IBM 5100 (Was: Resurrecting the IBM 1130)
https://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
https://www.garlic.com/~lynn/2000g.html#46 A new "Remember when?" period happening right now
https://www.garlic.com/~lynn/2001b.html#45 First OS?
https://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
https://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2002b.html#39 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2002b.html#47 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2003i.html#79 IBM 5100
https://www.garlic.com/~lynn/2003i.html#82 IBM 5100
https://www.garlic.com/~lynn/2003i.html#84 IBM 5100
https://www.garlic.com/~lynn/2003j.html#0 IBM 5100
https://www.garlic.com/~lynn/2003n.html#6 The IBM 5100 and John Titor
https://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

TSS/370 binary distribution now available

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS/370 binary distribution now available
Newsgroups: bit.listserv.ibm-main
Date: Sun, 29 Feb 2004 19:17:15 GMT

edgould@ibm-main.ameritech.net (Edward A. Gould) writes:
Hmmm.. I was around 30 years ago and don't honestly remember too much about TSS. Is there an INTRO or some such doc that will at least give me a basic understanding of TSS?

there is some of the politics between the science center and mohansic over virtual memory operating system in melinda's refs:
http://www.leeandmelindavarian.com/Melinda#VMHist

tss/360 was time-sharing system that supported virtual memory and both 24-bit and 32-bit virtual address modes on 360/67 (i.e. 67 had 32-bit virtual address supported compared to the later 31-bit virtual address support introduced much later with 3081).

one big user of TSS/370 was at&t which had a special version of TSS kernel as the underpinnings of 370 unix-based internal offering.

use search engines on tss/360 & tss/370 for lot more references

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
Newsgroups: alt.folklore.computers
Date: Tue, 02 Mar 2004 04:48:04 GMT

Peter Flass writes:
On a software basis alone it would win hands-down. BPM/BTM were somewhat primitive, but still beat TSO. UTS (and presumably CP-V) were very capable systems, and the Fortran compiler would run rings around anything IBM had.

i wasn't doing TSO ... as undergraduate ... I had put terminal I/O support into HASP and support for the syntax from the CMS editor .. for early CRJE. put I was doing lots of cms stuff ... and by the time of 370/145 was VM/370 and cms. recent threads that touch on some of the issues:
https://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
https://www.garlic.com/~lynn/2004b.html#53 origin of UNIX dd command
https://www.garlic.com/~lynn/2004b.html#47 new to mainframe asm

This was about the time of the CERN TSO-CMS bake-off ... the report was made available at SHARE about the TSO-CMS comparison (benchmarks, features, useability, etc).

an interesting side point was that while the CERN report was general made available at SHARE ... the copies that were taken "in house" got stamped "confidential, restricted"; available on need to know basis only ... aka it wouldn't do to distribute thruout the corporation how TSO actually fared against CMS.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

40yrs, science center, feb. 1964

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 40yrs, science center, feb. 1964
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 02 Mar 2004 18:39:47 GMT

Feb. 1964, 40years, cambridge science center

other 545 tech sq references:
https://www.garlic.com/~lynn/subtopic.html#545tech

cp/67 was announced at spring '68 share in houston (cp/40 had been previously been done on modified 360/40 pending availability of 360/67):
https://www.garlic.com/~lynn/2003d.html#72

long post that includes several 360/370 announce/fcs dates:
https://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone

other timesharing refs:
https://www.garlic.com/~lynn/submain.html#timeshare

from Melinda's history paper
http://www.leeandmelindavarian.com/Melinda#VMHist

short extract from the history paper at above
... 360 announced 4/7/1964 ...

... Feb 64, IBM had sent Norm to establish the Science Center ...

... Also in 1969, the system that was to become UNIX would be begun at Bell Labs as an offshoot and elegant simplification of both CTSS and Multics ...

longer extract (see the original paper for much more) ...
However, inside IBM at that time there was a strong belief that time-sharing would never amount to anything and that what the world needed was faster batch processing. MIT and other leading-edge customers were dismayed, and even angered, on April 7, 1964, when IBM announced System/360 without address relocation capability. The previous Fall, MIT had founded Project MAC to design and build an even more useful time-sharing system based on the CTSS prototype. Within Project MAC, Corbato and others were to draw on the lessons they had learned from CTSS to build the Multics system. The basic goal of the Multics project "was to develop a working prototype for a computer utility embracing the whole complex of hardware, software, and users that would provide a desirable, as well as feasible, model for other system designers to study." At the outset, Project MAC purchased a second modified 7094 on which to run CTSS while developing Multics. It then requested bids for the processor on which Multics would run.

In February of 1964, IBM had sent Norm Rasmussen to Cambridge to establish what became the Cambridge Scientific Center (CSC). Cambridge in the 1960s was an exciting place, full of ferment. It was a congenial place for Rasmussen, who was very much a man of that era, and it was a congenial assignment, as well, because Rasmussen was eager to demonstrate that science has a role to play in the building of good software. Rasmussen arranged for space for the Scientific Center in the same building as Project MAC, 545 Technology Square. (For many years after that, the Scientific Center programmers and the Project MAC programmers would remain on friendly terms and would occasionally get together in the bar on the ground floor of that building after work.)

All of IBM's contractual relationships with MIT were turned over to the new Scientific Center to administer. The Scientific Center was also expected to take the lead in making IBM "respectable" to the academics. So, only weeks after his arrival in Cambridge, Rasmussen had to deal with MIT's very negative reaction to System/360. Within days of the System/360 announcement, the chief S/360 architect, Gene Amdahl, came to Cambridge to meet with Professor Corbato and his colleagues, but that meeting seems only to have made matters worse.

As a loyal IBMer, Rasmussen was deeply embarrassed by IBM's failure to heed the advice of such an important customer, and he became determined to make things right, to do whatever was necessary to make System/360 right for MIT and other customers. To do that, he knew that he would need very talented people, so he set about attracting the best people he could find. He was fortunate to be able to start by taking over the staff of IBM's MIT Liaison Office. From the Liaison Office came two very skilled Systems Engineers, Les Comeau and John Harmon, as well as a quiet, unassuming Customer Engineer named Fritz Giesin, who would come to be treasured by generations of programmers at the Center. Next came another excellent IBM programmer, Ron Brennan, from the Federal Systems Division. Shortly after that, one of the seven CTSS authors, Lyndalee Korn, left MIT to join the Center.

One of the first jobs for the staff of the new Center was to put together IBM's proposal to Project MAC. In the process, they brought in many of IBM's finest engineers to work with them to specify a machine that would meet Project MAC's requirements, including address translation. They were delighted to discover that one of the lead S/360 designers, Gerry Blaauw, had already done a preliminary design for address translation on System/360. Address translation had not been incorporated into the basic System/360 design, however, because it was considered to add too much risk to what was already a very risky undertaking. The machine that IBM proposed to Project MAC was a S/360 that had been modified to include the "Blaauw Box. This machine was also bid to Bell Labs at about the same time. It was never built, however, because both MIT and Bell Labs chose another vendor.

MIT's stated reason for rejecting IBM's bid was that it wanted a processor that was a main-line product, so that others could readily acquire a machine on which to run Multics. It was generally believed, however, that displeasure with IBM's attitude toward time-sharing was a factor in Project MAC's decision. Losing Project MAC and Bell Labs had important consequences for IBM. Seldom after that would IBM processors be the machines of choice for leading-edge academic computer science research. Project MAC would go on to implement Multics on a GE 645 and would have it in general use at MIT by October, 1969. Also in 1969, the system that was to become UNIX would be begun at Bell Labs as an offshoot and elegant simplification of both CTSS and Multics, and that project, too, would not make use of IBM processors.

But getting back to the summer of 1964: Norm Rasmussen had just begun his fight to make System/360 acceptable to the academics and was not having an easy time of it. During that summer, Professor Corbato (a man widely known for his gentlemanliness) published a Project MAC Report containing a devastating analysis of the weaknesses of the S/360 as a machine on which to implement a time-sharing system. Other customers were also expressing concern about the lack of time-sharing capability in System/360. In August, SHARE's Advanced Planning Division presented a survey of the currently operating on-line programming systems. One of the speakers was Fernando Corbato, who emphasized the potential for growth of the computing industry due to time-sharing.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

The BASIC Variations

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.lang.basic,alt.folklore.computers
Date: Tue, 02 Mar 2004 21:12:34 GMT

hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins) writes:
The oil companies don't seem to have anything to do with it--it sounds like garden variety tax-dodging.

I don't know about Wales, but in the U.S., fuel taxes pay for things such as roads . . . we sell dyed untaxed diesel for agricultural use.

slightly related thread on fuel taxes for roads
https://www.garlic.com/~lynn/2002j.html#41 Transportation
https://www.garlic.com/~lynn/2003i.html#21 Spam Bomb

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Yakaota

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Yakaota
Newsgroups: alt.folklore.computers
Date: Thu, 04 Mar 2004 22:50:36 GMT

Charles Richmond writes:
In the US in the 1970's, the common thing to say was "computer code" and *not* "codes". Instruction codes were refered to as operation codes or "op-codes".

the high performance computing culture commonly used codes .... like the environment that spawned the SLAC-enhancements to the (370) ASM-H. big deal was made of things like getting codes to fit within the 64 instruction pipeline of the 195.

extraneous references to SLAC modifications
http://www.xephon.com/arcinframe.php/m090a06

search engine for *high-performance* and *codes* turns up various extraneous references

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

A POX on you, Dennis Ritchie!!!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A POX on you, Dennis Ritchie!!!
Newsgroups: alt.folklore.computers
Date: Sat, 06 Mar 2004 18:03:25 GMT

bhk@dsl.co.uk (Brian {Hamilton Kelly}) writes:
[I'm just reposting this; I now have suggestions from others that my post wasn't carried by some servers, because although it bore a Date of 21st Feb, it wasn't successfully injected until 29th. AIUI, some servers may have discarded it as "too old" rather than making it available for download to clients.]

an old rex(x) b'day thread:
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000b.html#30 20th March 2000
https://www.garlic.com/~lynn/2000b.html#31 20th March 2000
https://www.garlic.com/~lynn/2000b.html#32 20th March 2000
https://www.garlic.com/~lynn/2000b.html#33 20th March 2000
https://www.garlic.com/~lynn/2000b.html#44 20th March 2000

--
Anne & Lynn Wheeler - https://www.garlic.com/~lynn/

If there had been no MS-DOS

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If there had been no MS-DOS
Newsgroups: alt.folklore.computers
Date: Sat, 06 Mar 2004 17:51:50 GMT

Brian Inglis writes:
Widespread availability was a cost issue, not a functionality issue.

Terminals went on everyone's desk when they became cheap enough. PCs went on everyone's desk when they became cheaper than terminals.

I've rarely worked in the computer industry, but my impression from those inside was that hardware went out the door for demos or sales, and those in the industry had a harder time getting equipment than those outside, in businesses buying from the vendors. It *MAY* have been better in industry software development groups, but I wouldn't have bet on it.

it wasn't only cost of the terminal ... but cost of the online infrastructure that the terminal was connected to. then all the datacenter infrastructure to deal with people sitting at their terminals and calling up and complaining about service and response time (i.e. number and frequency of interactions with the datacenter increased by several orders of magnitude ... aka ... potentially every keystroke).

for really large organization that both produced terminals and software, terminals going to customers would show up on quarterly bottom line as revenue ... while terminals going to employees would show up as expense. if there was large customer demand for terminals requiring some allocation decision ... which is better revenue or expense?

there are also somewhat related issues .... i once had a conversation with guy running datacenter for large development lab about installing an enhancement to the resource manager that provided deterministic resource scheduling by group. the offer was decline ... because then it was just another thing that the datacenter manager had to deal with ... the political fights with the heads of different groups about the settings that the deterministic group resource allocation should have. if it was accepted to be (relatively) total anarchy ... then the datacenter manager couldn't be blamed or held accountable (as to which group was getting more or less resources than some other group).

in the wake of Jim Gray's MIPENVY ...
https://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2002o.html#75 They Got Mail: Not-So-Fond Farewells

a study was commissioned that went around to various research institutions and universities documenting computing facilities available. partial short summary from that survey:
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)

some past postings related to corporate terminal justifications
https://www.garlic.com/~lynn/2000.html#6 Computer of the century
https://www.garlic.com/~lynn/2002j.html#33 VT50, VT51, VT52, VT55, VT61, VT62 terminals (was Re: Weird...)
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)

--
Anne & Lynn Wheeler - https://www.garlic.com/~lynn/

Anyone Still Using Cards?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Anyone Still Using Cards?
Newsgroups: alt.folklore.computers
Date: Sun, 07 Mar 2004 17:09:07 GMT

arargh403NOSPAM writes:
Chicago - Yes.

Originally designed to deliver goods and fuel (coal and to remove the clinker) to buildings in the downtown area, later used (by accident) to deliver a flood to a large part of the downtown area, and now, AFAIK, mostly used for fibre optic (and probably other) cables.

at about that time we were out hawking ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
we had coined the terms disaster survivability and geographic survivability.

a number of operatins had done all sorts of industrial provisioning including service diverse routing. one operation had identified a building (for a datacenter) in a downtown metropoilitan area that had different water mains on opposite sides of the building, different electrical power grid service on opposite sides of the building and service from four different telco offices arriving at the building from four different directions. during this period that datacenter was taken out by explosion of electrical transformer in the basement (which included the contaimination of the bldg environmental by PCB). It was also in this period that the chicago flood took out a number of "hardened" datacenters.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

If there had been no MS-DOS

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If there had been no MS-DOS
Newsgroups: alt.folklore.computers
Date: Sun, 07 Mar 2004 17:48:16 GMT

jmfbahciv writes:
Of course it opened new doors. What the PC did was give computer access to the hairy masses. Computer centers at universities were beginning to become Nazis about who had access to their timesharing machines, were severely limiting bit storage capacities, and were beginning to become very proprietary about who got to read sources. Most kiddies wanted to play games. Most installations removed those games.

of course one of the issues was that these datacenters were funded to accomplish some set of goals and objectives for a large and diverse population. many of the timesharing infrastructures of the period were prone to all kinds of resource diversion and other hacks by a relative small (and usually unidentified) subset of the general (student) population (situations not all that different from current internet issues).

however at this period ... such hacking 1) compromised the funded datacenter objectives, 2) in many cases could put the jobs of the datacenter staff at risk, and 3) the risk originated from a population that weren't necessarily a major part of the directly funded datacenter objectives (and therefor was fairly straighforward to put restrictions on the population from where the risk originated).

the current differentiation with the internet ... is that it is currently difficult to differentiated the source of servere risk (relatively small population) from the general target service population.

i have a similar posting about road thruput ... that adverse driving habits of less than one percent of the population can severely degrade heavy traffic thruput on major roads (for all drivers). It only takes one or two cars out of a hundred that

1) frequently changing lanes in heavy traffic ... taping breaks, darting into small adjacent openings, both of which result in cars behind them suddently applying breaks (and break lights) which then propagates to possibly several hundred following cars and frequently is the cause of severe accordion effects of traffic flow

2) drving in the far, high-speed lane and waiting until they are 100 feet or so before an exit before they realize they have to exit, hitting the breaks and negotiating 2-4 lanes in order to crowd into the front of the exit lane (effectively bringing to stop several hundred cars behind them).

for the 2nd scenario ... several places have implemented barricades that extend for quite a distance on the exit lane ... as well as express lanes where exits are relatively infrequent. these address the bad driver exit behavior ... but doesn't address the lane changing jitter/brownian-motion behavior (with the following brake light cascading effect)

the assertion is that activities by relatively small percentage of drivers will severaly degrade the driving environment for all drivers under heavy traffic conditions (and in fact can actually precipitate the transition from moderate traffic to extremely heavy traffic because of the drastic reduction in the traffic thruput). this is parallel between the highway system and the internet ... that activities by a very small percentage of what appears to be the general propulation result in severe degradation of the overall environment ... and it not possible to address the problem by simply denying the use of the facilities to easily identifiable small subset of the population from which the risk originates.

lots of topic drift ... back to some specific posts about timesharing
https://www.garlic.com/~lynn/submain.html#timeshare

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

IT jobs move to India

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IT jobs move to India
Newsgroups: alt.folklore.computers
Date: Sun, 07 Mar 2004 18:27:58 GMT

"Jack Peacock" writes:
Every country has the sovereign right to decide what their tax structure should be. Demands like that can backfire...what would happen if the EU demanded the US double it's income tax rates and mandate 6 week vacations so Europe would be more competitive?

long ago, i was teaching an extended class during first shift someplace in europe ... and also coming in early and staying late doing various online stuff.

i asked if i could come in all day sat ... and was told that they could arrainge it if i really needed to ... but he already had a lot of paperwork to fill out for the gov. (in response to reports submitted to the gov. about my coming in early and leaving late) .... and there would be a lot more gov. paperwork that he would have to do if I did come in on the weekend.

apparently the convention had just switched from 5week vacation to 6week vacation .... and these particular employees had already been used to having 6weeks. the volumes of submitted gov. reports was supposedly based on some of the employees being used to having a week more vacation than everybody else ... and they thought that when everybody else (in the country) was increased from 5weeks to 6weeks, their vacation should be increased from 6weeks to 7weeks.

it was apparently disgraceful to work 14-16 hrs a day, seven days a week.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

IT jobs move to India

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IT jobs move to India
Newsgroups: alt.folklore.computers
Date: Mon, 08 Mar 2004 04:48:44 GMT

"Stimpy" writes:
It's effectively illegal since the introduction of the European Working Time Directive. This attempts to limit how much time over and above the contracted hours can be worked.

There is currently a facility to allow workers to voluntarily opt out but this is to be tightened up in a couple of years. It's all to do with helping break the 'long hours are good' culture and encourage a better work-life balance as well, of course, as helping those workers being forced/pressurised to work overtime

i suppose they wouldn't like it at all that when i was in school they would let me have the datacenter on the weekends starting at 8am sat ... i could then pull a 48hr shift w/o sleep until 8am monday ... and then go to classes ... misc. past posts mentioning pulling 48hr shift and then going to class
https://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
https://www.garlic.com/~lynn/98.html#55 Multics
https://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
https://www.garlic.com/~lynn/2002o.html#1 Home mainframes
https://www.garlic.com/~lynn/2002o.html#2 Home mainframes
https://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Parallel programming again (Re: Intel announces "CT" aka

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parallel programming again (Re: Intel announces "CT" aka
 "IA-32e")
Newsgroups: comp.arch
Date: Mon, 08 Mar 2004 18:46:08 GMT

"Stephen Fuld" writes:
While I am not necesarily opposed to a higher gas tax, you have to be carefull about trying to make wholesale changes quickly. For example, in the US, many people work at jobs that are far enough from where they live (both by their won choices) that they must use a car to get from one to the other. They have built their life around those choices. If you suddenly dramatically increased the gax tax, it would cause major dislocations as people couldn't afford to get to their jobs, or would have to decrease their life style (i.e purchase less good) because they would be spending more on gas. If that happens, our economy suffers. You can't change "just one thing".

another way it is expressed is that cheap gas has subsidized numerous life-style choices ... or .... it allows individuals to occupy economic (environment) niches that wouldn't be possible w/o the availabiilty of cheap gas. one could assert that the difference in the price versus the value (of gas) is the subsidy that supports such life-style choices. in general, the difference between the price and the value subsidizes lots of standard of living issues ... not just distance from work. cheap food is also predicated on cheap transportation (as well as various farm machinery).

there is also the issue that the highway costs are essentially proportional to the use by heavy trucking. much of the gas tax is used for transportation infrastructure maintenance ... with significant amount of that tax coming from recreational & life-style driving ... even tho recreational & life-style driving has little or no impact on highway infrastructure costs. So in addition to the heavy trucking transportation industry effectively being subsidized by cheap gas ... the highway infrastructure in support of heavy trucking transportion is further subsidized by spreading the gas tax across all driving ... not just heavy trucking that is primarily responsible for the costs.

some specific references to road design/maintenance being driven by heavy trucking and that road use by cars, pickups, two-axle vehicles, etc having effectively no impact on highway wear & tear:
https://www.garlic.com/~lynn/2002j.html#41 Transportation
https://www.garlic.com/~lynn/2002j.html#42 Transportation

in any case, there has been significant exploitation of economic/environmental niches through-out the infrastructure predicated on availability of cheap gas. you might not even be able to determine all such dependencies w/o actually drastically increasing the price of gas.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

PSW Sampling

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PSW Sampling
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 08 Mar 2004 19:10:17 GMT

shmuel+ibm-main@ibm-main.Patriot.net (Shmuel Metz , Seymour J.) writes:
That term covers a multitude of sins; it doesn't really say what you are trying to do. What do you mean by "address space monitor"? Are you trying to produce a histogram of problem program instruction executions? All instruction executions? Something else entirely?

long ago and far away (mid-70s) the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

shipped a product called vs/repack.

at its core it had an instruction simulator that ran traces on application execution ... recording at 32byte boundaries, execution fetches, data fetches and data storage. It was typically setup to dump out the storage use maps every 2000 or so instructions. This information was used by vs/repack application using cluster analysis to do program & module reordering for optimal page set size and paging characteristics.

just the map was also used for various internal development projects identifying hotspots and areas for redesign/rewrite (in some cases, long before it was released as a product). it was used (early '70s on cp/67) in the port of apl\360 to cms\apl redoing storage allocation & storage garbage collection. apl\360 typically ran 16-32kbyte workspaces where the whole workspace was swapped in/out in single operation. move to cms\apl (on cp/67 with 360/67) was a virtual paged environment where workspace might be up to 16mbytes. The storage allocation for the 16kbyte swapped environment was horribly inefficient in a large virtual memory environment.

it was also used by places like the IMS development group ... looking at where IMS was spending all of its execution time.

There was a co-project which involved modifying the CP/67 kernel. A new feature was added to the CP/67 that allowed a fixed number of valid pages being made available to a virtual process. The process was allowed to fault on that many pages until it had reached the valid virtual page limit. At that point, the list of valid virtual pages were recorded, and then had the invalid page bit set (they were allowed to sit around in storage). This kernel modification ran significantly faster than the instruction emulation implementation and there were several studies done comparing the quality of the data gathered by the kernel modification for limited virtual page numbers versis the data gathered by the instruction simulation implementation. For most of the areas that vs/repack was used in ... there was little difference seen in the quality of the results between the two methods of gathering information for studying program/application behavior.

early post on psw sampling with respect to microcode support:
https://www.garlic.com/~lynn/2004c.html#5 PSW sampling

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

More complex operations now a better choice?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More complex operations now a better choice?
Newsgroups: comp.arch
Date: Tue, 09 Mar 2004 15:07:24 GMT

glen herrmannsfeldt writes:
I have sometimes wondered if S/360 (and a little less, its successors) should be considered RISC. Pretty much only two addressing modes. Three instruction lengths, coded by the first two bits of the opcode. Instructions on 16 bit boundaries. Though there are some pretty complicated instructions in there, too.

one could make the case that 801 was re-action to the failure of FS ... misc. FS references:
https://www.garlic.com/~lynn/submain.html#futuresys
which was supposedly to have been the follow-on to s/360.

the 801 presentation ... misc 801 references
https://www.garlic.com/~lynn/subtopic.html#801

that i remember from '76 or so .... was no SMP support, no cache consistency, no protection domain, and various hardware/software trade-offs that effectively moved stuff from hardware into software. thruput optimization came purely from combination of extremely simple instructions and compiler technology (i.e. it was possible for the compiler to accurately model the simplified hardware instruction processing ... and generate instruction sequences for optimal hardware thruput).

protection would be provided by a combination of compiler technology and checking at bind/load time (i.e. compiler wouldn't generate insecure code and the binder/loader would make sure that executable came from valid compiler).

virtual memory was combination of inverse tables, software loading of hardware lookaside table, and small number of segment registers. the small number of segment registers was compensated for by a lack of protection domain and that in-line application code could change segment register values as easily as it could change general register values.

FS had gone to extreme of complex (object?) instructions, something like generic ADD instruction would figure out whether the operands were interger, floating-point, string, etc ... and magically do the appropriate thing. 801 had gone to the opposite extreme ... making the hardware implementation as simple as possible (not just instruction specification) and attempting to move all complexity into software technology. a side-effect of the extreme 801 hardware simplification was possibly being able to (almost) implement a processor in a single chip of the day.

one could also make the case that in FS ... somplexity had been chosen for the sake of complexity ... with little or no other supporting business reason. however, there has been some claims that the overall FS system complexity (not just instructions) would result in an extremely complex overall system ... effectively creating barrier to entry for PCM (plug compatible manufacture) controllers ... something that I've been blamed for helping create from project that I worked on as undergraduate ... misc. 360 pcm refs:
https://www.garlic.com/~lynn/submain.html#360pcm

some specific references/quotes about the FS complexity issue:
https://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
https://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Jargon Files Wanted

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Jargon Files Wanted
Newsgroups: alt.folklore.computers
Date: Wed, 10 Mar 2004 05:30:23 GMT

Steven Ehrbar writes:
2.9.8

i've got
jargon271.ascii
jargon296.ascii
jargon298.ascii

www.212.net has some version of ibm jargon
http://www.212.net/business/jargon.htm

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

More complex operations now a better choice?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More complex operations now a better choice?
Newsgroups: comp.arch
Date: Wed, 10 Mar 2004 17:17:53 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
This is why a lot of people are proposing a CISC ISA, which gets translated into a RISC code for execution. As in the Crusoe, Pentium 4 etc. Actually, as in the Perq, if I recall.

and all the low-end 360s & 370s ... with vertical microcode ... it was the high end 370s that instructions were handled by complex horizontal microcode. the low-end 360s/370s were frequently rated in the avg. number of microcode instructions per "machine" instruction. The high-end horizontal microcode machines were more commonly rated in avg machine cycles per "machine" instruction (in part because a horizontal microcode instruction could be doing several things simultaneously & somewhat asynchronously).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

More complex operations now a better choice?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More complex operations now a better choice?
Newsgroups: comp.arch
Date: Wed, 10 Mar 2004 19:50:10 GMT

"Mike Cowlishaw" writes:
When Java came out I used to enjoy making the comparison with S/360. All the initial machines were interpreters of the S/360 'byte codes'. Only later were there real hardware S/360 machines...

and at a 1996 java conference ... i joked with the Sun general manager that "owned" java about virtual machines circa mid-60s on 360 .... cp/40 on modified 360/40 and then later ported to 360/67 as cp/67 (of course he had previously been at Los Gatos lab and one of the two people responsible for vs/pascal ... and had come to sun after previously being vp of software development at the "old" mips.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Moribund TSO/E

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 10 Mar 2004 20:40:25 GMT

ccampbe2@ibm-main.csc.com (Colin Campbell) writes:
I had never thought much about the state of TSO/E until this thread started. I first used TSO about the time it was introduced, around 1975. As a young programmer who had been working with Time-Sharing on the GE-635 for awhile, I wondered what took IBM so long.

I have used it ever since, and in my shop, all the programmers are logged on for the greatest part of their workday. Of course, we use ISPF under TSO/E. I'm struggling to imagine an alternative method of getting our day ot day work done.

it wasn't that it took ibm so long for time-sharing ... there was the whole project mac scenario ... some of it repeated:
https://www.garlic.com/~lynn/2004c.html#11 40yrs, science center, feb. 1964
as well as the whole tss/360 (and tss/370) follow-on stuff that floundered.

TSO was mostly glorified conversational job entry ... that happened to talk to terminals. I had done something similar in the late 60s ... putting in terminal support in HASP and implementing the CMS editor syntax for program submission.

circa 1974, CERN presented a report at SHARE on its TSO/CMS bake-off ... which was one of the reasons that CERN (as well as SLAC) heavily went vm/370 & CMS. that in part contributed to evolution of HTML ... since CERN then was GML/SGML user (and GML had originated on CMS at the science center).

recent posting with some reference to the CERN TSO/CMS bake-off
https://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370.

note also various of the time-sharing service bureaus in the early 70s were CMS based (either originally from CP/67 and then later VM/370):
https://www.garlic.com/~lynn/submain.html#timeshare

probably the largest such time-sharing service operation in the 70s were the internal HONE systems (initially cp/67 but then converted all to vm/370) which supported all of the world-wide sales, marketing, branch, and field people (aka in the late '70s, just the US HONE complex had something approaching 40k defined users):
https://www.garlic.com/~lynn/subtopic.html#hone

for strange connection ... as undergraduate putting TTY support into cp/67 and then TTY and 2741 support into HASP ... led me to trying to make the 2702 do something that it couldn't do (although the whole thing with SAD command being able to specify the line-scanner for each port sort of implied it should have been able to dynamically assign any line-scanner to any line). That in turn led to undergraduate project where some of us reversed engineered the IBM channel interface and built our own control unit (that would support both dynamic terminal identification and dynamic line-speed identification). Which in turn gets us blamed for originating the IBM PCM controller business
https://www.garlic.com/~lynn/submain.html#360pcm

And the IBM PCM controller business was supposedly one of the primary justfications for FS. recent posting with some FS references
https://www.garlic.com/~lynn/2004c.html#22 complex operations now a better choice?
and a lot more FS references:
https://www.garlic.com/~lynn/submain.html#futuresys

and the 801 activities can be considered a reaction to the glorious falure of FS (going to nearly the opposite extreme with KISS):
https://www.garlic.com/~lynn/subtopic.html#801

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Moribund TSO/E

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 10 Mar 2004 23:04:41 GMT

thomen@ibm-main.us.ibm.com (Mark Thomen) writes:
Ummmm, I think I'd have to disagree. CRBE (Conversational Remote Batch Entry) and CRJE (Conversational Remove Job Entry) both preceded the introduction of TSO. I worked at OSU, which was a Beta test site for TSO and had run both CRBE and CRJE well before that. While those systems were "conversational job entry" in format, TSO was a major step forward, had significant additional function, and was quite different than the design and implementation of CRBE/CRJE. TSO never looked back, and continued to add much more function. SPF was a god-send and the usage of TSO exploded after that, but I would never have considered TSO simply a job entry system.

it may be true that TSO was/is better than some specific CRJE implementation. however TSO would never be confused for a any kind of competitive time-sharing environment (including per the CERN TSO/CMS bake-off report presented at SHARE circa 1974); i.e. tso is online support for a batch environment, aka the glorified conversational job entry phrase as per original comment:
https://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E

also as per above, as an undergraduate in the late '60s, I had put in (2741 & TTY) terminal support into HASP ... implementing an online environment that included support for the CMS editor syntax (although the code was written from scratch to fit into HASP). I considered it relatively tolerable implementation for an online environment supporting a fundamental batch infrastructure .... with syntax and response much better than later TSO implementation that I saw.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Moribund TSO/E

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 10 Mar 2004 23:11:43 GMT

ccampbe2@ibm-main.csc.com (Colin Campbell) writes:
I agree with Mark. My first use of TSO was to develop what I believe was the first JCL syntax checker and standards enforcement tool. I used the EDIT, ASM, and TEST commands all day long for weeks, hardly ever submitting a job. I could not believe how much simpler TSO made the job.

are you saying that TSO was a competitive time-sharing offering ... or it was better than various specific CRJE implementations that you had previously dealt with?

in the HASP scenario that I mentioned ... I could also edit, assemble, and test all day long sitting at a tty or 2741. however, i would still consider it online support embedded in a batch paradigm system. also, the editor syntax (that i had borrowed from cms) and the response time was better than I saw from subsequent TSO implementation.

original post:
https://www.garlic.com/~lynn/2002c.html#26 Moribund TSO/E

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

separate MMU chips

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: separate MMU chips
Newsgroups: comp.arch
Date: Wed, 10 Mar 2004 22:50:10 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
The System/360 and System/370 did not do that, because they did not architect the relevant data separately from the interrupt PSW, so all imprecise interrupts were necessarily non-recoverable. But that was a design decision, and could have been done differently.

I was told (long ago and far away) that a major difference between 360/195 and 370/195 ... was that a lot of ibm standard mainframe RAS instruction retry was added for the 370/195 ... which might have gone a long way to cleaning various imprecise interrupt issues (there was something about the 195 being fast enough and there was so many components that a soft failure could be expected on the order of daily). quick use of search engine about instruction retry for 195 just turns up some of my old postings.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Moribund TSO/E

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 11 Mar 2004 00:10:55 GMT

... and for something completely different ... the person referenced in the following regarding java virtual machines
https://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?

in the early to mid 80s, between his stint at Los Gatos lab and MIPS ... helped form a startup to do a 3270 controller clone. the sole justification for the company and the controller was that TSO editing would be offloaded into the controller ... because TSO was so very, ... very, ... extremely, ... bad

This was also in the period when the (really bad) performance of 3274 was not considered an issue (since nobody would ever need less than one second resposne) ... aka 3270s were designed for online use, not time-sharing use ... posting with some extract from studies of the period:
https://www.garlic.com/~lynn/2001m.html#19 3270 protocol
(and I was demonstrating .11sec trivial system response on heavily loaded systems)

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Moribund TSO/E

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 11 Mar 2004 03:55:43 GMT

some futher topic drift with respect to 3270, cms, & tso response:
https://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
and
https://www.garlic.com/~lynn/2001m.html#19 3270 protocol

this was during the heyday of reports about productivity of subsecond response (aka quarter second or less) and people optimizing lightly loaded TSO systems being able to demonstrate one second system trivial response (see more detailed discussion in above "3270 protocol" posting).

in this period ('80, '81), STL was bursting at the seams and the decision was made to move approx 300 IMS (development) programmers to an off-site location something like five miles away (old bldg 96, part way between main san jose plant site and STL). The IMS programmers had been used to something like quarter second response on local 327x boxes with VM/CMS ... and were decidedly opposed to the idea of having to suffer with the standard SNA remote 327x solution (especially with VM/CMS ... TSO users seemed to be significantly less sensitive to the extreme incremental response penalty inflicted by remote SNA terminal operation or even for that matter, local SNA terminal operation.

after a lot of investigation, it was decided to deploy a (non-IBM) channel extender that ran over T1 lines between STL (bldg-90) and remote location (bldg-96). Local 3270 controllers were then used in the remote location .... with emulated local channel connectivity back to the mainframes in the STL machine room.

the actual lash-up was subchannels on the T3 collins digital radio (aka microwave) that ran between STL and the main plant site (you can see the repeater tower on top of the hill above Santa Teresa that divides south san jose from coyote valley (drivers with radar detectors also take a hit on 85 when they cross the line between the repeater tower and the dish on top of bldg-12). Then there was dish from roof of bldg-12 to the roof of bldg-96 (aka bldg-12 on the main plant site was relay between bldg-90 and bldg-96).

in any case, after it was all up and running, users claimed to see no percevied response time difference between the vm/cms response on local 3270s in STL ... and the vm/cms response on "local" 3270x in bldg-96.

some misc. references to the bldg 90/96 channel extender (for the IMS group) are included in postings about the high speed data transport (HSDT) project:
https://www.garlic.com/~lynn/subnetwork.html#hsdt

there was one anomoly that cropped up with the move of the ims development people to bldg-96 ... after the local 3270x were moved ... the thruput of the affected mainframes increased by 10-15 percent. It turned out that prior to the move, the 3270 controllers were pretty evenly distributed across all available channels ... shared with disk controllers. What was discovered was that the channel extenders (that replaced the 3270 controllers as directly attaching to the real mainframe channels) had significantly lower channel busy overhead for doing the identical operations.

as an aside ... a similar deployment was then implemented in boulder for the IMS FE support team ... but in boulder, there was use of infrared optical modem between the datacenter bldg and the bldg. with the ISM FE support team ... some past threads:
https://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
https://www.garlic.com/~lynn/99.html#137 Mainframe emulation
https://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001e.html#72 Stoopidest Hardware Repair Call?
https://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives

the boulder installation presented some additional challenge. The transmitters/receivers were mounted on poles on top of the bldgs. the normal movement of the sun across the sky would cause uneven heating and uneven expansion/contraction of the bldgs during the course of the day ... sufficient to throw the beams out of alignment.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Moribund TSO/E

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 11 Mar 2004 15:00:29 GMT

IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
Ummmm, I think I'd have to disagree. CRBE (Conversational Remote Batch Entry) and CRJE (Conversational Remove Job Entry) both preceded the introduction of TSO.

are you referring to a specific CRBE/CRJE implementation?

when an undergraduate I had put (TTY & 2741) terminal support into HASP ... and facility that supported the CMS editor syntax (not the actual code since i had to write it from scratch to fit it into HASP). this i considered to have much better response and useability than the later TSO implementation (of course i could be a little biased). although I could "edit, asm, and test" all day long ... it was still basically a conversational front-end to a batch system ... with a little slight of hand monitor. This was running on a MVT18 system on 360/65. I don't think that anybody would confuse my conversational HASP hack or TSO with any kind of competitive time-sharing offering.

i had purposefully used "glorified conversational job entry" in lower case to differentiate it from specific CRBE/CRJE implementations that other people might be familiar with.

misc. previous posts in this thread:
https://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
https://www.garlic.com/~lynn/2004c.html#27 Moribund TSO/E
https://www.garlic.com/~lynn/2004c.html#28 Moribund TSO/E
https://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
https://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

separate MMU chips

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: separate MMU chips
Newsgroups: comp.arch
Date: Thu, 11 Mar 2004 15:21:04 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
[*] If I recall, MVC with overlapping source and target that took a page miss half way through was one such. I vaguely remember some reference to a change to the microcode to touch both the first and last bytes before starting the copy to reduce this effect. But I could be imagining the situation.

possibly a m'code bug that was the reverse situation?

One of the reasons that the 360/67 had to have a minimum of 8 TLB entries was that an "execute" of an MVC instruction:

• "execute" instruction could cross a page boundary • MVC instruction could cross a page boundary • source could cross a page boundary • destination could cross a page boundary

which would require resolving a maximum of eight virtual page addresses before starting the operation.

even in non-virtual-memory mode .... a MVC instruction is required to validate starting/ending locations of both source and destination before beginning the operation (i.e. 360 storage protection with destination crossing 2k boundary).

all 360 instructions were required to do this. it wasn't until the introduction of the long instructions with 370 that the requirement was somewhat relaxed ... i.e. the long instructions were defined as if they performed a byte at a time.

This gave rise to a microcode bug in the 370/125 implementation of long instructions which used the old 360 rules ... checking start & ending locations of source & destination before starting the operation (instead of checking at each byte). VM/370 at boot had used the move long instruction (MVCL) to both clear memory and test for size of real storage ... when the MVCL instruction interrupted it would have cleared all of available real storage and the registers would indicate the last available real storage location. The 370/125 microcode bug resulted in the instruction not even starting operation ... effectively appearing to vm/370 boot as if there was no real storage.

misc. past refs:
https://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
https://www.garlic.com/~lynn/2003j.html#27 A Dark Day
https://www.garlic.com/~lynn/2004b.html#26 determining memory size

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Playing games in mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Playing games in mainframe
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 12 Mar 2004 17:10:52 -0700

steve_mark_waugh@ibm-main.hotmail.com (Stephen Waugh) writes:
Are there any games written in REXX that could be downloaded from the internet? If anyof you has one, please pass me the code.

long ago and far away, the person that wrote REX(X), wrote a multiuser spacewar game using IUCV. Users could be on the same machine or using networking of IUCV, anywhere on the internal network ... aka the internal network was larger than arpanet/internet from just about the beginning until about mid-85 ... minor refs:
https://www.garlic.com/~lynn/internet.htm

a problem arose that various people starting writing automated players ... which would win because they just played faster. to somewhat compensate, the game was modified so that energy reserves were depleted non-linear as the interval between actions dropped below threshold.

another is an early adventure was moved/ported from SAIL machine in fortran on tymshare's time-sharing service ... vm/cms based ... misc:
https://www.garlic.com/~lynn/submain.html#timeshare
aka there were a whole load of interesting systems within 10-20 mile area of stanford.

I ran into one of the tymshare people about this time and made arraingements to get a copy of the source. I then made (compiled) copies available internally (and would send people that made 300, a copies of the source). At one point, there was some claimed that whole labs were doing nothing but playing adventure. At STL finally everybody was told that they had something like 8hrs grace and after that, adventure playing would not be tolerated during normal working hrs. Also, one of the peeople at STL that made 300pts and got a copy of the source, converted it to PL1 and added something like another 150-200 pts to the game.

There was also some contention about whether is was better to have a publicly available "game" area (for off-shift use) or a witchhunt to eradicate all non-business applications from systems. My position it would be better to have a publicly available "game" area, since people could be so inventive about disguising their files.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Computer-oriented license plates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer-oriented license plates
Newsgroups: alt.folklore.computers
Date: Sun, 14 Mar 2004 09:14:12 -0700

Dave Daniels writes:
But what are the chances that most people who even notice think 'HPO' is something like 'IPO' and just assume you work in finance?

Dave Daniels (who remembers that HPO was blummin' expensive compared to VM/SP)

The origins of HPO was the research manager available on vm/370 release 3. However, most of the actual code in the resource manager was various kinds of restructuring ... that included organization for multiprocessing; in fact the multiprocessing support was built based on that restructuring. The problem came when it was decided to release multiprocessing support in VM/370 release 4.

Up until the resource manager, scp/kernel code was free and other kinds of code was charged for. It was decided to change the rules, and decision was that the resource manager would be the first charged for SCP code (i got to spend six months with the business people working out process for charging for SCP/kernel code). The new rule was that direct hardware support was free but that anything else (including scp/kernel code) could be charged for.

The problem with multiprocessing support in release 4 was that it was dependent on a lot of the "charged for" resource manager. The resolution was to take about 80 percent or so of the code that had been in the resource manager (and which the multiprocessing support was dependent on) and move it into the (free) base release 4. The remaining code was still called the resource manager and the charge was the same that it had been in release 3 (even though there was significantly less code).

... start shadow page table description ...
For release 5, the resource manager was packaged with some other code and renamed SEPP/BSEPP. The big addition in SEPP was enhanced virtual relocation performance. When running a virtual machine that utizlied virtual memory features, the CP kernel had to emulate the operation of the hardware TLB (table look aside buffer). The virtual guest had page tables which contained page numbers that corresponding to virtual machine addresses. The CP kernel supported this with "shadow" page tables that converted the virtual guests page number to a real page number. Everytime the virtual guest changed address space ssegment register, CP would invalidate all the shadow table entries. This was big problem with MVS production guests since there was lot of changing the address space segment register ... with CP constantly clearing the (only) shadow table for that virtual machine.

The new code in SEPP added support for cache of shadow tables per virtual machine ... allowing CP to remember the information for several virtual guest address spaces. With the new HPO code (in release 5), when the virtual machine guest operating system changed the virtual address space segment register, the CP kernel checked to see if it was changing to a "cached" shadow table. If it was changing to a address space that wasn't cached, CP would clear a least recently used address space shadow table and re-use it. This offered a significant performance improvement for a MVS virtual guest operating system ... since CP was longer constantly clearing the (only) shadow table.

some more detail on shadow page tables:
https://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation

... end shadow page table discription ...

For what would have been VM/370 relase 7, the whole base, SEPP, and BSEPP was collapsed into a single offering and renamed VM/SP (system product, aka charged for) ... with effectively the BSEPP pricing (and there was no longer a free base).

original resource manager announcement (the original charged for SCP/kernel code ... being first wasn't a technical issue, it was the six months with the business people talking about the business end of new pricing policy):
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

misc. scheduling, performance postings
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

misc. multiprocessing postings
https://www.garlic.com/~lynn/subtopic.html#smp

VM/SP had some enhancements that resulted in a number of installations experiencing a noticable performance degradations. The most investigated was a major change for multiprocessing support. The original multiprocessing support done way back on the resource manager on release 3 (and released to customer in release 4) made an assumption about both the virtual machine execution and the kernel execution on behalf of that virtual machine defaulting to run as a single thread, typically on the same processor. Through-put concurrency (in multiprocessor environment) was gained by running lots of concurrent virtual machines. This was the minimal SMP pathlength for the maximam multiprocessor thruput (as well as tending to retain some cache consistency).

There was a decision for VM/SP to target customer installations with primary workload of a single large virtual guest operating system with little or no other workload (say a single MVS guest as well as the TPF installations running 3081s and supporting airline control program applications). The idea was to attempt to force the CP kernel work for a specific virtual machine to run asynchronously with respect to that virtual machine. The virtual machine guest would do something like a start i/o fast, which would enter the CP kernel, the CP kernel would queue a request and do a signal processor and then return to the virtual machine (under the assumption that most of the CP kernel code would operate asynchronously on another processor in parallel with the virtual machine operation). This essentially attempted to turn what had been a single-threaded, single-cpu workload into something that ran somewhat concurrently on two processors ... especially in an environment where there was little or no other workload to make use of more than one processor.

The problem was that the additional queueing and inter-processor signalling would consume about ten percent (total) of each processor. For the majority of environments that had sufficient number of concurrent virtual machines to consume all available processing power (on all available processors), they didn't need the loss of ten percent of each processor. This VM/SP design target was specifically to address the customer environment of a single threaded/processor workload that was running on a two-processor system with the 2nd processor idle, aka the 10 percent loss of each processor was supposedly offset by increased use of otherwise idle cpu cycles. The other issue was that VM/SP was in the time-frame of the new 3081, which was originally targeted to be multiprocessor only and there would never be a single processor option (even if the customer only had a single threaded/processor workload, they couldn't buy just a single processor). However, there was enuf pressure (i believe mostly from the TPF customer set, at that time, TPF didn't have multiprocessor support), eventually they went back and offered a single processor machine called the 3083.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

If there had been no MS-DOS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If there had been no MS-DOS
Newsgroups: alt.folklore.computers
Date: Sun, 14 Mar 2004 13:37:04 -0700

"Charlie Gibbs" writes:
I remember several years ago, when mention was first made of that study showing that people are four times as likely to have accidents if they're talking on a cell phone while driving. There were local rumblings about banning the use of cell phone while driving. This triggered a huge ad blitz by the cell phone companies. The issue was quickly and quietly dropped.

i believe that the current stats have it only a little less that DWI as cause of accidents (responsible people don't let their friends talk and drive?).

--
Anne & Lynn Wheeler - https://www.garlic.com/~lynn/

Memory Affinity

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Memory Affinity
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 14 Mar 2004 22:25:12 -0700

old_systems_guy@yahoo.com (John Mashey) writes:
Google groups search comp.arch: memory affinity will get lots of hits

1) This technique is one of several related affinity scheduling techniques.

2) In Uniform Memory Access SMPs, as caches got larger, it became well worthwhile doing *cache affinity scheduling*. In this case, the OS tries to schedule a process back onto a CPU that it has used recently.

This probably goes back 15-20 years, but I'm sure at least to 1993 [IRIX did this on SGI Challenges; I don't remember if it did it on earlier SMPs.] I'd guess somebody did it in the 1980s.

3) on ccNUMA machines, memory affinity scheduling has been around at least since 1996/1997 [SGI Origins had it]. There's no obvious reason for doing it on a typoical UMA SMP. Maybe Convex Exemplars did it earlier. Here's a pointer to one reference that explains the SGI version:

how bought 76-77 ... instead of 96-97 :-)

for (internal) smp support on vm/370 release 3 ... for the HONE system (time-sharing system complex that supported world-wide sales, marketing, branch and field people, US complex had something approaching 40k defined users in the late '70s).

The 370/158-3 uniprocessor was about a one mip machine. For SMP/two processor, the cache cycle time was slowed down by ten percent to handle the cross-cache invalidates. The hardware thruput of a two-procssor machine was therefor effectively 1.8times a single processor machine (for the same workload). Doing lots of I/O would result in lots of I/O interrupts and frequent switching from kernel (i/o) interrupt handling and application code .... and the caches were small enough that interrupt handling & application resume pretty much involved totally replacing the cache lines.

It turned out I did some slight of hand in the multiprocessor support that tended to keep low i/o rate application code on one processor and high i/o rate application code on the other processor. The result was that the processor with low i/o rate application code was hitting 1.5mips (because of improved cache hit ratio) while the processor with high i/o rate application was seeing MIP rate around .7. So instead of two processors each with avg. mip rate of .9 for aggregate of 1.8, one processor was 1.5 and the other was .7 for an aggregate of 2.2mips.

The other gambit which wasn't so much affinity ... but relates to switching back and forth between kernel and application when there are high i/o rates. This dates to circa 73 or 74 and applies to machines whether uniprocessor or multiprocessor. The i/o interrupt rate was monitored and when it exceeded some threshold ... the system was put it a mode where i/o interrupts were disabled ... but a fine-grain timer was set. Applications were allowed to progress up to the timer interval ... at which time, the system would check and clear all pending I/O interrupts. The trade-off was potentially slight delay in handling an interrupt ... but once interrupt handling was started, an attempt was made to clear all pending interrupts (while the interrupt handling code remained in cache). The choice of the I/O interrupt rate threshold and the timer interval could actually result in increasing both application thruput (because of the increase in cache hit) as well as i/o (because the system was more efficiently processing the interrupts).

Later there was an affinity command that supported additional efforts to bind a process to a processor cache ... but i can't find a specific reference to which release it appeared ... late 70s or early 80s.

recent post with some discussion of mid-70s smp support:
https://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates

a couple older postings on processor affinity
https://www.garlic.com/~lynn/96.html#0b Hypothetical performance question
https://www.garlic.com/~lynn/2000c.html#14 thread scheduling and cache coherence traffic

lots of past smp postings
https://www.garlic.com/~lynn/subtopic.html#smp

total topic drift on some 60s & 70s time-sharing systems
https://www.garlic.com/~lynn/submain.html#timeshare
and lots of postings on the HONE systems:
https://www.garlic.com/~lynn/subtopic.html#hone

misc. dates & info of 370 models:
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS370.html
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS370C.html
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_profiles.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

ATA drives and vibration problems in multi-drive racks

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ATA drives and vibration problems in multi-drive racks
Newsgroups: comp.arch,comp.arch.storage
Date: Sun, 14 Mar 2004 21:44:07 -0700

ben@inka.mssm.edu (Benjamin Goldsteen) writes:
In any case, one of the best things about using RAID of low-end drives in place of tape libraries is that the thing works like a gaint disk drive and all the software can use it easily. No complicated, expensive HSM or backup/archive software -- just put filesystems on it and use the familiar tools. This is especially attractive in the smaller installation markets. Of course, one always has to analyze the situation before deciding on the solution. Blanket solutions are typically wrong.

there is the issue of off-site backup .... full-sets that are shipped off weekly ... with weekly and monthly rotations so there is possibly 6-8 sets off-site someplace.

one attempt with disks was with triple redundant hot-pluggable RAID ... a full triple was unplugged and set-off site ... the rotated-in set would then be plugged in and resync'ed. There was period while there was only simple redundant.

the other is to just have a large bank of pluggable/unpluggable drives and treat/use them similar to tape backup ... weekly unhooking a whole bank for shipment offsite and re-initializing the set brought back on-site. the issue here is that there is possibly fewer (human) mistakes as to which drives are to be plugged out/in.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Memory Affinity

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Memory Affinity
Newsgroups: comp.arch
Date: Sun, 14 Mar 2004 22:38:33 -0700

gherbert@gw.retro.com (George William Herbert) writes:
He mentioned that several other systems had been built with that capability before. I think Amdahl or Auspex was one of them, but I can't recall the details clearly... I should have posted more quickly after the conversation.

the Amdahl machines were mainframe "370-clones" ... and ran the same mainframe software as standard 370 mainframes ... see discussion of other recent posting in this thread:
https://www.garlic.com/~lynn/2004c.html#37 Memory Affinity

ampex (as opposed to auspex) had "bulk" memory product for 360 mainframes. You could find 8mbytes of a ampex memory on various customer 360 mainframes. A 360/50 might have 128kbytes to 512kbytes of standard 2mic memory and you could add 8mbytes of ampex 8mic memory. There was various strategies of using the ampex memory for purely data ... and/or lower-usage executables. It could also be found on 360/65 and 360/75 which might have 256kbytes to 1mbytes of standard 750ns memory and 8mbytes of 8mic ampex memory. Again the strategy was to have the higher use instructions/data in the faster memory. Some strategies even involved copying instructions out of 8mic memory to 750ns memory before execution.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Microprocessor History Site

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microprocessor History Site
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 14 Mar 2004 23:50:45 -0700

dkanter@onebox.com (David Kanter) writes:
I came across a website some months ago that listed many old and relatively current microprocessors. It also had the corporate history for the companies that made these chips and how to identify their MPUs. The site also had the history of key figures in the industry such as Shockley, Kilby, Noyce, Moore etc.

there is the stale cpu info page:
http://bwrc.eecs.berkeley.edu/CIC/archive/cpu_history.html
which has a pointer to great microprocessors of the past and present:
http://www3.sk.sympatico.ca/jbayko/cpu.html
currently v13.3.0 updated as of 12/2003 and has lots of pointers to other sources.

long ago and far away, i did some stuff with interdata/3 and then interdata/4 ....
http://users.rcn.com/crfriend/museum/machines/id4.html

there is also the "other" scamp ... the original/precursor to the ibm/pc
http://www-1.ibm.com/ibm/history/exhibits/pc/pc_1.html
http://www-1.ibm.com/ibm/history/exhibits/pc/pc_2.html
https://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor

another history site:
http://www.luminquest.com/HOC/Computerhistory1.htm

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

If there had been no MS-DOS

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If there had been no MS-DOS
Newsgroups: alt.folklore.computers
Date: Mon, 15 Mar 2004 10:12:57 -0700

hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins) writes:
My father has long proposed banning not only automatics, but sychrnoized transmissions for the driving test.

I'm still trying to figure out where I learned to double clutch--I'd always known about it in theory, but I found myself doing it automatically last time I drove something huge.

i learned to drive summer I turned 9 on old 38chevy(?) flatbed w/o syncro-mesh (did have a peddle on the floor to engage the starter motor). i was tall for my age so i could reach the peddles.

https://www.garlic.com/~lynn/38yellow.jpg

38chevy?

i found later that most synchromesh tended to not be between second and first. Most people that learned on synchromesh had to come to a stop to put the vehicle in first gear ... however it could be done by appropriate use of double-clutch.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Moribund TSO/E

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Moribund TSO/E
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 15 Mar 2004 10:38:24 -0700

Anne & Lynn Wheeler writes:
... and for something completely different ... the person referenced in the following regarding java virtual machines
https://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?

in the early to mid 80s, between his stint at Los Gatos lab and MIPS ... helped form a startup to do a 3270 controller clone. the sole justification for the company and the controller was that TSO editing would be offloaded into the controller ... because TSO was so very, ... very, ... extremely, ... bad

or to quote some corporate saying ...
there are no problems, just opportunities

TSO difficulties can provide opportunities.

possibly part of the motivation for thinking that some TSO market segment might be interested in better human factors was the STL situation remoting part of IMS development (which occurred slightly before the formation of the 3270 clone startup to offload TSO editing). These weren't actually TSO users ... but it somewhat highlighted that interactive users could become attached to quality sub-second service

previous posting regarding remoting IMS developers:
https://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E

--
Anne & Lynn Wheeler - https://www.garlic.com/~lynn/

why and how VeriSign, thawte became a trusted CA?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: why and how VeriSign, thawte became a trusted CA?
Newsgroups: comp.security.misc
Date: Mon, 15 Mar 2004 14:57:50 -0700

Toby A Inkster writes:
Their certificates are trusted because they pay browser manufacturers lots of money to add them to the default "trusted certificates" lists.

lots of past posts related to merchant comfort certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

we were asked to work with this client/server startup company that wanted to handle payments on the server. this startup also had this thing call ssl ... so one of the things we had to do was go around and have a look at the various business processes of at least some of the operations. misc past historical references:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

If there had been no MS-DOS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: If there had been no MS-DOS
Newsgroups: alt.folklore.computers
Date: Tue, 16 Mar 2004 09:57:16 -0700

iddw@hotmail.com (Dave Hansen) writes:
I believe that, at least until recently, land line companies charged extra for access to touch-tone dialing. I know my in-laws didn't have it until last year (I think it costs them US$1.00 per month). You'd think it would make more sense to charge extra for pulse dialing...

there were possibly ancient issues where telephone companies had to justify to some gov. public utility agency the installation of new switch that supported touch tone. the PUCC then decided that the cost of the new switch had to be paid for by the people that used the new features ... and the poor people with the old phones shouldn't have to carry any of the cost ... and the PUCC set the surcharge for the new features. the issue then is ever getting such surcharges removed.

i've read of accounts of PUCCs not approving installation of newer switches supporting DSL because all of the poor people in the community that don't need DSL and should not have to pay for newer hardware that supported newer features.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Detecting when FIN has arrived

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Detecting when FIN has arrived
Newsgroups: comp.protocols.tcp-ip
Date: Tue, 16 Mar 2004 18:06:20 -0700

Rick Jones writes:
I myself am curious to know what an application would do with this knowledge? Off the top of my head I cannot think of anything.

I _suppose_ that modulo the portaiblity of URGent data handling, couldn't cooperating applications send a single byte of URGent data just before the FIN as a "signal" that they were sending a FIN?

some of this is sort of related to RFC on lack of out-of-band signalling channel:
https://www.garlic.com/~lynn/internet.htm#28 Difference between NCP and TCP/IP protocols
https://www.garlic.com/~lynn/2000.html#73 Difference between NCP and TCP/IP protocols

from rfc721 out-of-bnad control signals in a host-to-host protocol, summary at:
https://www.garlic.com/~lynn/rfcidx2.htm#721
from index
https://www.garlic.com/~lynn/rfcietff.htm
clicking on the "(.txt=nnnn)" field in the summary retrieves the actual RFC.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

IBM 360 memory

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 memory
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 17 Mar 2004 08:36:28 -0700

venkatk_78@yahoo.com (Venkatesan) writes:
IBM 360 Model 65 and 75 addresses are divided into two separate main memory units( with all even number words in one unit and all odd number words in another unit). Can some one please tell me what is the reason behind doing so

is this one of those school home-work thingies? they most frequently show-up in this newsgroup at the start of some semester.

interleaved memory .... memory cycle was 750ns ... for double word (8 byte) memory access.

the (old) 360/65 functional characteristics manual gave instruction execution times with formula including instruction fetch time, any address decode ... with incremental time whether base and/or index register was involved, and the actual execution. instruction fetch was double word at a time ... so formula for 2byte instruction, the formula included 1/4th 750ns for instruction fetch (i.e. amortize the 8byte instruction fetch across the instructions involved).

360/75 had the same memory access time, but other components of 75 instruction timing was much faster than 65.

these machines were (mostly) non-cache machines (the only 360 that had a cache was the 360/85) which made the instruction timings fairly deterministic. however, since the memory bus was shared by i/o ... and there was no cache to help mask memory access latency ... heavy i/o contention for the memory bus could show up in actual instruction execution times.

The exception was the 360/67 multiprocessor which had multi-ported memory with independent path for i/o. there was additional latency for the multi-ported capability ... some memory fog ... on the order of 75ns (ten percent) or so ... making the memory cycle time for 360/67 multiprocessor on the order of 825ns. A single processor 360/67 of a partitioned multiprocessor would have slower instruction formulas than a "simplex" 360/67 with single-ported memory (because of the slightly longer memory access times). However, under heavy I/O conditions, the simplex 360/67 actually had lower cpu thruput because of heavy memory bus contention.

The 360/67 (simplex, which was basically a 360/65 with TLB/DLAT added, a multiprocessor 360/67 had a number of differences, even compared to a multiprocessor 360/65) when operating in virtual memory mode also had an additional 150ns memory access latency for DLAT (aka TLB) operation ... aka for simplex 360/67, virtual memory access time went from 750ns to 900ns (assuming entry was in the DLAT and no DLAT miss).

quick search engine on (ibm) interleaved memory
http://www.columbia.edu/cu/computinghistory/36091.html
http://portal.acm.org/citation.cfm?id=807295&dl=ACM&coll=portal

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

IBM 360 memory

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 memory
Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l
Date: Wed, 17 Mar 2004 11:38:25 -0700

CJT writes:
How many 360/67's were ever built? We had one at U. Mich. (running MTS), but I had the impression at the time that it was not a common machine.

original posting:
https://www.garlic.com/~lynn/2004c.html#46 IBM 360 memory

i don't know the exact number ... i would guess on the order of 100(?) maybe more. most of them were originally sold as tss/360 machines to universities and places like ford & gm. possibly only a dozen continued to run tss for some time (i think there was something about a dozen or so members of the share tss/360 group around 1970), the rest either a) just used them in straight 360/65 mode with standard os/360, b) ran mts, or c) ran cp/67.

the cp/67 time-sharing services then bought some number of them:
https://www.garlic.com/~lynn/submain.html#timeshare
as well as misc. businesses that decided they needed cms for one reason or another (like cms\apl with large workspaces).

there were misc. like the boeing huntsville 360/67 multiprocessor ... which ran a modified version os/mvt13 in virtual memory mode with no paging; aka the system supported a lot of long-running 2250 applications ... and mvt had a problem with memory fragmentation of long running applications. virtual memory was used to provide contiguous appearing memory locations. there was also the one-of-a-kind 3-way 360/67 multiprocessor at lockheed that was part of the manned orbital lab project (with a lot of redundancy & recovery features added to it).

quite a few were deployed inside IBM for generic (CMS) online access ... including the original HONE system
https://www.garlic.com/~lynn/subtopic.html#hone

there were a number used for 370 testing before 370 hardware was available ... a specially modified version of CP/67 was created that emulated all the new 370 instructions and any other differences between 360 and 370 (TOD clock, etc). These were used for testing for testing operating systems for vanilla 370 (original 370 w/o virtual memory) as well as later testing for emerging changes for virtual memory support.

when 370 machines with virtual memory support first started appearing (long before customer ship and other operating system support), a further modification to cp/67 kernel was made to support the 370 virtual memory architecture (there were a number differences between 360/67 and 370 virtual memory definition).

several past postings on the cp/67 "l", "h", and "i" kernels:
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
https://www.garlic.com/~lynn/2002i.html#55 wrt code first, document later
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
https://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
https://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
https://www.garlic.com/~lynn/2004b.html#31 determining memory size

i've made some observations that there was nearly as many 360/67 systems as total multics systems (over a span of different machine generations). cp/67 (as well as follow-on vm/370 before moving out to burlington mall) and multics were done at 545tech sq ... so there was some naturual tendancy for some comparison. recent science center posting:
https://www.garlic.com/~lynn/2004c.html#11 40yrs, science center, feb. 1964
and lots more observations:
https://www.garlic.com/~lynn/subtopic.html#545tech

in the vm/370 time-frame, i've commented that it wasn't really fair to compare the total number of vm/370 customer installations to the total number of multics installations ... or even to compare the number of internal corporate vm/370 installations to the total number of multics installations. At about the time the internet number of nodes exceeded the number of nodes on the internal network (mid '85), most of the internal network nodes were multi-user vm/370 (time-sharing) nodes, while an increasing number of internet nodes were workstations and PCs. misc. refs:
https://www.garlic.com/~lynn/internet.htm

in any case, at one time I was building custom, highly modified vm/370 systems and shipping off distribution tapes to internal operations. at one time, For awhile, the number of the systems that I was directly supporting was about the same as the total number of multics systems ... so that was a more comparable comparison (the total number of multics system vis-a-vis the number of systems that I was directly supporting) than either the total number of vm/370 installations or even the total number of internal corporate installations.

later when I got to release the resource manager ... I was responsible for all education and documentation as well as 1st, 2nd, and 3rd level support for the first six months after product release. I was told that within a couple months after first release, the number of resource manager licenses had gone over 1000. a couplre recent postings on resource manager
https://www.garlic.com/~lynn/2004c.html#15 If there had been no MS-DOS
https://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

IBM 360 Memory

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 Memory
Newsgroups: bit.listserv.ibm-main
Date: Wed, 17 Mar 2004 11:41:11 -0700

venkatk_78@yahoo.com (Venkatesan) writes:
Hi, In IBM 360 Model 65 and 75 address are staggered in two separate main memory units( all even number words in one unit and all odd number words in another unit). Can someone please let me know whats the logic behind this technique?

this is possibly school-work? ... and also posted elsewhere ...from comp.arch
https://www.garlic.com/~lynn/2004c.html#46 IBM 360 memory
https://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

[OT] Lockheed puts F-16 manuals online

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] Lockheed puts F-16 manuals online
Newsgroups: comp.arch
Date: Wed, 17 Mar 2004 11:49:31 -0700

Robert Myers writes:
In one of my earlier forays on comp.arch, I mentioned, to loud guffaws, Wang's ill-fated paperless office as a glimpse of why we have so far seen only the tip of the iceberg of computer use. Not to be discouraged, I later mentioned the use of computers to store and disseminate information about extremely complicated engineering systems. I may even have mentioned aircraft. One of our more respected posters who is in the aerospace biz expressed his skepticism to the extent that he didn't see many autocad files changing hands.

Still lots of paper in the office, and autocad files still haven't replaced paper (nonblue) blueprints, but fighter aircraft manuals are well into the paperless revolution:

http://www.forbes.com/home/newswire/2004/03/17/rtr1302075.html

misc. topic drift .... the official "light-weight" fighter was F15 by M/D. when boyd was going after a real fighter plane ... there was huge amounts of politics since it was seen as competition with the F15 ... however he finally succeeded and the F16 was done by G/D.

lots of boyd stories & references ... including several referencing the f15/f16 politics
https://www.garlic.com/~lynn/subboyd.html#boyd

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

[OT] Lockheed puts F-16 manuals online

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] Lockheed puts F-16 manuals online
Newsgroups: comp.arch
Date: Thu, 18 Mar 2004 10:13:30 -0700

Robert Myers writes:
What is slightly bizarre about this is that Lockheed had every niggling detail of project managment (milestones, manhours, and money) on computers decades ago, so the story shows how slowly what should be an obvious step is really taking root.

so here is a little more detail about the general dynamics F-16
http://www.csd.uwo.ca/~pettypi/elevon/baugher_us/f016.html from
https://www.garlic.com/~lynn/subboyd.html#boyd2

so even some guys had spreadsheet type software for project management (back in the 70s) .... detailed designs were still paper, not just the prime on the contract, but all the subs & the sub-subs for sub-assemblies and sub-sub-assemblies. also each run of planes would have some unique characteristics ... and basically its own paper manual with the components that correspond with that manufacturing run. then manuals for specific plane would have to be updated to correspond to any retrofits that specific plane might have (major components, replacement parts, sub-assemblies, etc). For the F16 this was all going on starting in the 70s (see more detail in the above).

some of the big pushes for machine readable as original possibly started showing up in the 90s ... boeing doing some stuff in the 7-5/6/7-7 series ... but also requiring that something like thousands of subcontractors providing parts ... also had to supply all of their details in machine readable (instead of paper) also.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

[OT] Lockheed puts F-16 manuals online

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] Lockheed puts F-16 manuals online
Newsgroups: comp.arch
Date: Thu, 18 Mar 2004 12:43:52 -0700

Robert Myers writes:
I think you've got the real reason why what should be a no-brainer is happening so slowly. The on-line documentation is like a loose thread sticking out of a sweather: pull on it, and you get the whole ball of yarn.

so another organization starting to deal with it in the 90s was the automobile C4 project .... however this was specific for new designs and not vehicles that were produced 20+ years earlier.

the avg. (US) auto cycle from start to rolling off the line was seven years. one of the issues was that the original design may have been predicated on specific supplier parts .... but over the seven year cycle, the supplier could change specification for some of the parts ... and it was difficult to get the info fed back into the overall process. one of the specific examples given in a c4 meeting was vette with pretty tight tolerances "under the skin" ... and something like shocks or batteries changed spec during the design/build cycle ... and violated the volume/space tolerances under the skin/surface of the design. going to dataprocessing base was to not only better keep track of such things ... but also enable shortening the cycle ... initial objective was to cut in half from seven years to something like 3.5 years.

once you have everything on softcopy compatible common base ... then it is easier to go to all softcopy manuals/publickations. however, retrofitting that to aircraft that have been around for 25-30 years and have 25-30 year old paper process is something more of a challenge.

misc past c4 references
https://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
https://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
https://www.garlic.com/~lynn/2003i.html#61 TGV in the USA?
https://www.garlic.com/~lynn/2003i.html#65 TGV in the USA?

note that ibm had somewhat easier time providing softcopy of many of its publications (although i don't know about underlying component engineering and maintenance documents).

cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

was doing its publications and manuals in script in the 60s. I believe the first major general corporation publication done in script (aka science center invented GML that was supported by the script command ... GML precursor to SGML, HTML, XML, etc) was 360/370 principles of operation (you can somewhat tell the early ones since they were printed on 1403 printers and then photo-offset for printing). Part of the justification for doing the 370 principle of operations was that it was actually a subset of the "redbook" architecture purblication (distributed in ox-blood red 3ring binders). The full architecture manual was constantly being updated with all sorts of interesting things ... and then the document could either be printed as the full manual ... or as the PoP subset. During the 70s a large percentage of new corporate publications were being done in script/gml. as a result, by the late '90s, the majority of all corporate publications were soft copy of one kind or another.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Detecting when FIN has arrived

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Detecting when FIN has arrived
Newsgroups: comp.protocols.tcp-ip
Date: Thu, 18 Mar 2004 13:02:43 -0700

Villy Kruse writes:
Anyone ever seen "Starlan". I've seen that mentioned in connection with TLI. Anyway, TLI was originally included with SVR3 but it did not have any transport at all. That transport was then usualy provided by a third party and added by the vendor. The ISO OSI protocol was also supposed to have been implemented "real soon now" back then.

lots of people were claiming ISO OSI ... in part because so many of the govs. around the world were mandating it ... including the US federal gov. (remember GOSIP?).

there was a little problem with OSI ... it was from the 70s that effectively reflected end-to-end telco copper wire. ISO (and national ISO chartered organizations) had guidelines that they weren't allowed to do standards that violated OSI. Circa 1990, there was attempt to take HSP protocol to ANSI x3s3.3 (us standards handling osi level 3&4, networking and transport protocol). HSP was high speed protocol that would go directly from level 4/5 interface to MAC interface.

HSP had (at least) two OSI violations that precluded standards work by ANSI/ISO:

1) it bypassed the level 3/4 interface ... and therefor an OSI violation

2) it went directly to LAN/MAC interface ... which was nn OSI violation; aka LAN/MAC covered levels 1, 2, and part of level 3. MAC interface sits somewhere in the middle of OSI level 3 ... making LANs violation of OSI and any protocol that talked to LAN/MAC interface by definition then violated OSI.

misc. past posts, having to do with OSI, HSP, GOSIP, etc
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
past thread/posts relating to interop '88 conference which had a lot of vendors demo'ing OSI products:
https://www.garlic.com/~lynn/subnetwork.html#interop

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

defination of terms: "Application Server" vs. "Transaction Server"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: defination of terms: "Application Server" vs. "Transaction  Server"
Newsgroups: bit.listserv.ibm-main
Date: Thu, 18 Mar 2004 16:17:24 -0700

john.mckown@ibm-main.uiciinsctr.com (McKown, John) writes:
I vaguely know what a "Transaction Server" is. Eg. something like CICS or IMS/DC. How does that differ from an "Application Server" such as WebSphere?

I've tried a google search, but just don't seem to be able to find something to match my simple mind.

typically transaction may have a specific integrity definition including stuff like acid-properties, locking, commit, recovery, etc. a transaction server would possibly provide two-phase commit support implementing transaction semantics. a transaction server might even provide transaction routing .... tracking application network locations and routing incoming transactions to appropriate applications for actual execution (with the two-phase commit, back-out, routing, etc. services provided by the transaction server).

remember the old tuxedo stuff that AT&T then spun off to BEA ... or camelot at CMU (joke about ibm paying for it three times); ibm providing funding to cmu, then providing much of seed funding when cmu spun-off camelot as transarc, and then buying transarc outright.

past post about acid properties
https://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends

misc. past camelot &/or tuxedo posts:
https://www.garlic.com/~lynn/2000.html#64 distributed locking patents
https://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002o.html#32 I found the Olsen Quote
https://www.garlic.com/~lynn/2003.html#46 Horror stories: high system call overhead
https://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
https://www.garlic.com/~lynn/2003k.html#58 What is timesharing, anyway?

also try serarch engine for both acid and tpc ... also tpc-a, tpc-b, tpc-c, etc.

for some topic drift, besides camelot, mach was also done there, which now shows up as apple operating system ... as opposed to pink. misc. pink references:
https://www.garlic.com/~lynn/2002i.html#60 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002j.html#76 Difference between Unix and Linux?
https://www.garlic.com/~lynn/2002m.html#60 The next big things that weren't
https://www.garlic.com/~lynn/2003e.html#28 A Speculative question

the other object operating system of the period, besides pink, was spring; pink somewhat morphed into taligent and then died away. some of spring sort of continued on in java.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

[OT] Lockheed puts F-16 manuals online

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] Lockheed puts F-16 manuals online
Newsgroups: comp.arch
Date: Thu, 18 Mar 2004 16:52:06 -0700

Robert Myers writes:
I suspect there are many tales like this hanging around in all kinds of industries. If people get over the hump of putting everything on the computer, they'll win over the long haul, but to get over the hump, they have to use precious investment capital one way or another, and so they put off doing it.

another simple example (again from automobile industry) there was some comment about GM needing to get 50,000 suppliers to support EDI 821/822 records just for simple area of purchase orders and payments.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Idea for concurrent transactions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Idea for concurrent transactions
Newsgroups: comp.databases,comp.databases.theory
Date: Thu, 18 Mar 2004 20:38:24 -0700

Paul writes:
Two database systems that I know a bit about use MVCC (also called record shadowing or record versioning - I like the shadowing term myself).

The two systems are Interbase/Firebird and PostgreSQL - if you look on www.ibphoenix.com at the docs section, you should be able to find stuff that is a bit more than "gloss-over-the-details". Also, on the PostgreSQL site, the docs there might be of help.

I believe that Informix uses it, and also Oracle some of the time.

illustra (originally montage) was versioning/shadowing ... remember data blades? they were bought by informix ... now incorporated into universal server

misc. search engine illustra
http://philip.greenspun.com/wtr/illustra-tips.html
http://www.seyboldreports.com/SRDP/0dp10/D1011012.HTM
http://www.dbmsmag.com/int9402.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

Bushwah and shrubbery

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Bushwah and shrubbery
Newsgroups: alt.folklore.computers
Date: Fri, 19 Mar 2004 09:03:42 -0700

Brian Inglis writes:
DES is broken and passe, the Flemish Rijndael is the new US NIST Advanced Encryption Standard.

slightly more correct, single-key DES was not renewed because with tens of thousands of dollars in equipment and 24hrs (or some such) you could brute force the key value. for lots of things that DES was being used for, this wasn't sufficient security. for dukpt (derived unique key per transaction) with single-key DES on $100 dollar ATM transaction ... it probably is still useful (in fact dukpt is being mandated) since the cost to brute-force such a key takes longer than the value & elapsed time of the transaction.

note that triple-des is still approved for a number of things (either two-key or three-key des) ... since the key size is on the same order as the shortest approved AES key. One of the advantages of AES is that the specification allows for much longer keys ... which is useful if you are encrypting information that must remain secure for 30-40 years.

a couple past postings reference dukpt:
https://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/2003g.html#9 Determining Key Exchange Frequency?
https://www.garlic.com/~lynn/2003g.html#42 What is the best strongest encryption
https://www.garlic.com/~lynn/2003o.html#46 What 'NSA'?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

[OT] Lockheed puts F-16 manuals online

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] Lockheed puts F-16 manuals online
Newsgroups: comp.arch
Date: Fri, 19 Mar 2004 09:21:12 -0700

"Del Cecchi" writes:
That was a pretty mild flame in response to your flame of Lockheed. And in this special case of the F16 I'm sure there are, whether various folks agree with the policy, government imposed restrictions on the export of the data. Some of the data might even be classified, so there has to be some sort of controls in the data access to only allow people to see the data they are supposed to be able to see.

or different levels of classifications on different parts of components, sub-components, &/or sub-assemblies for different planes.

wasn't it a JAG show with some test pilot being downed in some foreign country (a f18 or f14?). there was some highly (as opposed to possibly mildly or lowly) classified electronics installed in the plane ... with some special chips that had backdoors. they wanted the foreign gov. to think that they were getting real chips ... which that gov. would duplicate for all of their equipment. the whole thing was elaborate ruse to make the foreign gov. think that they were dealing with the real thing. harm severely complicated the whole thing by trying to get the plane back before the foreign gov. were able to get the chips.

so the paper system could have a variety of 5-25 year old pages from possibly thousands of different suppliers ... and different pages might have a variety of different classification levels ... requiring different pages at different classification levels to be kept and handled separately. after years of upgrades and maintenance ... the appropriate collection of pages for any specific plane might be nearly unique .... including things like the maintenance log itself.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

real multi-tasking, multi-programming

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: real multi-tasking, multi-programming
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 19 Mar 2004 14:57:12 -0700

Chris_Craddock@ibm-main.bmc.com (Craddock, Chris) writes:
OTOH Multi-tasking in the context of z/OS and its predecessors means splitting an application into multiple parts (nominally represented by a TCB each) so that portions of the SAME job could execute either in parallel on multiple cpus, or at least be able to continue processing while other portions are waiting. This is a fairly subtle difference and really bears on the z/OS processing concept.

multitasking in non-ibm, non-tcb has tended to be multithreading ... i.e. multiple tasks within the same address space .... since so many had come at multitasking from a environment where task==address space.

multithreading with things like posix threads (within the same address space) or simulated with different address space tables that mapped to same, shared virtual memory.

the ibm tcb genre have come up from a single real memory ... which went thru some evolution along the way using virtual memory to simulate a large real memory.

when the work on compare and swap was being proposed for 370 by the cambridge science center:
https://www.garlic.com/~lynn/subtopic.html#545tech
(original mnemonic was chosen because CAS are the initials of the person that was at CSC primarily responsible for the invention) ... the POK owners of the 370 architecture claimed that it would not be possible to get an SMP-only justified instruction into 370. What was needed was a use for compare and swap that also worked in non-multiprocessor environments. That was when cambridge came up with the programming notes (originally part of the instruction description in the principles of operation, but since moved to appendix) for compare and swap use in multithreaded applications doing various types of things like queue updating. The idea was the operation was atomic and could proceed with concurrent activity going on and enabled for interrupts (and would be equally applicable to whether a multithreaded application was running in a single processor environment or a multiprocessor environment).

lots of old SMP postings ... including past threads involving compare and swap:
https://www.garlic.com/~lynn/subtopic.html#smp

recent observation about 40 years since norm was asked to got to cambridge to set up the science center
https://www.garlic.com/~lynn/2004c.html#11 40yrs, science center, feb. 1964

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

real multi-tasking, multi-programming

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: real multi-tasking, multi-programming
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Sat, 20 Mar 2004 08:54:56 -0700

Chris_Craddock@ibm-main.bmc.com (Craddock, Chris) writes:
No. Multi-programming (literally "more than one program/job") can be done on a uni and was originally invented as a means of improving resource utilization. Practically every OS these days fully qualifies as a multi-programming OS regardless of the number of cpus or their memory architecture.

....


OS/360 ... PCP
... MFT ... Multiprogramming with Fixed number of Tasks
... MVT ... Multiprogramming with Variable number of Tasks

then later


VS1
VS2/SVS
       VS2/MVS

code name for VS2/SVS development was AOS2 (advanced operating system 2). It started out effectively as 16mbyte virtual machine running MVT ... w/o CP/67. Basically MVT was hacked with some cribbed POK-grown code and pieces of CP/67 strapped into MVT kernel with baling wire.

Set up low-level MVT boot/ipl to build a 16mbyte virtual address table, and low-level MVT interrupt handler to process virtual page interrupt. A copy of CCWTRANS & UNTRANS modules from CP/67 were hacked into the side of IOS. CCWTRANS was the routine in CP/67 that ran the applications (virtual machines) copy of CCWs and built a shadow copy for the real I/O. The purpose of this was to 1) replace the addresses in the CCWs with real addresses (in place of the virtual addresses from the application's CCWs) and 2) fix/pin all the virtual pages in real storage for the duration of the I/O. UNTRANS was called at the completion of the I/O to 1) based on the last real CCW executed, figure out the corresponding virtual CCW and 2) unfix/unpin the virtual pages associated with the I/O operations.

previous post:
https://www.garlic.com/~lynn/2004c.html#58 real multi-tasking, multi-programming

I was a undergraduate at university in jan. 1968 when 3 people from cambridge science center came out to install cp/67. This was something like version "2" of cp/67. It had a ten-level queue dispatcher and no page thrashing (aka multiprogramming level) controls. A couple months later the lincoln labs dispatcher was distributed for cp/67 (in jan. the university was the 3rd cp/67 installation after cambridge itself and lincoln labs). The new lincoln labs code had a two level dispatcher and a scheduler with eligible list that attempted to address the page thrashing issue.

The lincoln labs page thrashing (multiprogramming level) control was fairly simplistic; when virtual machine became executable, it was put in the dispatch list if the total number of dispatchable tasks were less than some limit, otherwise it was put in the eligible list. The maximum multiprogramming level (for page thrashing controls) was a table set by lincoln labs based on the number of 256k real storage boxes on the 360/67. The values in the ables were set based on the type of workload run on lincoln labs machine.

During the spring of 1968, I rewrote a lot of the cp/67 kernel code to significantly reduce the pathlength and overhead of CP/67 and presented a summary at fall '68 share meeting in Atlantic City.

During the late summer of 1968 I started rewriting the page replacement and page thrashing control infrastructure ... changing the eligible list/dispatch list to much more dynamic based on actual measurements of page thrashing (as opposed to using a fixed multiprogramming level based on amount of real storage).

During 1969, this evolved into 1) a somewhat different concept about application real storage requirements ... compared to the working set acm paper that had been published in '68, 2) used global LRU replacement algorithm compared to the local LRU replacmeent algorithm described in the ACM working set paper, 3) dynamic multiprogramming level adjustments (dispatch list and eligible list) for page thrashing controls, 4) resource tracking for fairshare and non-fairshare scheduling, and 5) dynamic adaptive resource managment/scheduling. IBM was picking up some amount of the code and shipping it to customers in standard CP/67 release.

In the early '70s, the grenoble science center published an ACM paper on "working set dispatcher" which was a relatively faithful implementation of the '68 ACM working set paper ... done on cp/67. The grenoble science center had a 1mbyte 360/67 (154 4k pages after fixed kernel requirements) and ran very similar workload as the cambridge science center which had 768kbyte 360/67 (104 4k pages after fixed kernel requirements). The issue was that the cambridge system was running the dynamic adaptive stuff that I had done as undergraduate with global LRU replacement algorithm ... and even though the cambridge machine was smaller (104 4k pageable pages vs. 154 4k pageable pages) it supported about twice the number of users (75-80 compared to 30-35 for grenoble) with better interactive response and about same overall throughput. My dynamic adaptive stuff and global LRU replacement just worked more efficiently than the relatively static stuff described in the '68 ACM working set paper.

misc. fairshare & dynamic adaptive
https://www.garlic.com/~lynn/subtopic.html#fairshare
misc. page repalcement
https://www.garlic.com/~lynn/subtopic.html#wsclock

some posts about issues that came up in late '70s about wsclock and global LRU page replacement algorithm:
https://www.garlic.com/~lynn/93.html#4 360/67, was Re: IBM's Project F/S ?
https://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
https://www.garlic.com/~lynn/2001c.html#10 Memory management - Page replacement
https://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2003k.html#8 z VM 4.3
https://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?

some posts referencing Atlantic City '68 share presentation on some of the extreme optimization work that I had done os MFT. i took the stage2 deck (output of stage1) ... put job cards on each of the exec steps, and carefully re-arranged the order of the move/copy statements within various exec steps and re-arranged the order of the exec steps to carefully control the placement of files & pds members on disk ... in order to optimized the arm seek motion ... and to allow stage2 sysgen to proceed in normal production jobstream (as opposed to under stand-alone "starter system"). It also describes some of the rewrites on the cp/67 kernel for highly optimized, introduction of fastpath, etc
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
https://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
https://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
https://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001h.html#12 checking some myths.
https://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
https://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
https://www.garlic.com/~lynn/2004.html#48 AMD/Linux vs Intel/Microsoft

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

IBM 360 memory

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 memory
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 20 Mar 2004 07:59:23 -0700

"Stephen Fuld" writes:
Not to mention the 2741 "golf ball" terminals. Both standard and APL balls available :-) I remember when it was running OS, it was running the WatFor compiler for student Fortran jobs.

sitting on top of my screen at the moment are:

1) apl golf ball, #988, its in golf ball plastic case, bottom "ibm blue", top clear.

2) block of plastic (almost some exact size as the golf ball case) that came from the slac/fermilab booth at supercomputer 2001 ... "beam tree" ...
http://sc2001.fnal.gov/beamtree
http://sc2001.slac.stanford.edu/beamtree

3) flat plastic desk paper-weight that has six chips and reads awd austin, gtd burlington, power architecture, 150 million ops, 60 million flops, 7 million transistors

university i was at had also gotten 360/67 ... but realized fairly early that tss/360 wasn't going to amount to much. they were selected for cp/67 installation in jan. 1968 (3rd installation after cambridge and lincoln labs).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

IBM 360 memory

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 memory
Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l
Date: Sat, 20 Mar 2004 09:33:51 -0700

Jay Maynard writes:
Not quite...there were 13 customers supported for TSS/370, some for quite some time. IBM supported it on an RPQ basis for them until 1987. I know of at least one that liked TSS so much that they bought Amdahl processors for some time in retaliation for TSS getting dropped.

TSS definitely had some advanced algorithms, and was designed for the very top end of the line - as in, off the top of the 360's capabilities. It definitely wanted a multiprocessor box and lots of real memory. Once you got to a high-end 370, it supposedly ran quite well.

melinda's account goes into a lot more detail ...
http://www.leeandmelindavarian.com/Melinda#VMHist
but during tss/360's heyday in the 60s ... cambridge had something like 12 people working on cp/67 and cms (as well as coming up with GML, editors, interacitve computing, GML ... which begate SGML, HTML, XML, etc). Mohansic had something like 1200 people working on tss/360.

during this period, there was a joke about IBM rewarding people for development disasters ... because people tended to get promoted and paid based on the number of people reporting to them. If you were able to get the job done with 12 people ... you got paid based on having 12 people reporting to you. If your development project ran into extreme disaster and had to baloon up to a bloated 1200 people ... then you got more promotions, prestige and money. an executive's goal became not to have a really good development project ... but to have one that was a true disaster ... so they could justify a hundred times as many people.

tss/360 had concept of virtual memory and one-level store ... but almost not concept of performance techniques and dynanic adaptive anything. besides tss/360 horribly long pathlengths there were some static things that they just didn't stop and think about. CMS used a lot of compilers and other applications from os/360 which were optimized for memory constrained environment ... i.e. overlays of 50kbytes ot 100kbytes with efficient transistion from one overlay to the next. TSS/360 would just lay such stuff out in virtual memory and do simple 4k, single page fault at a time. So under CMS, it would attempt to bring in the 50k-100k piece of the compiler ... and then at change of phase bring in the next 50k-100k segment (attempting to do as a single I/O each time). TSS/360 might have it all as a 1mbyte, and have to individual page fault, each individual 256 4k page. When running on 512kbyte real machine ... it might have to page fault various of the 256 4k pages multiple times.

In any case, at about the time CP67/CMS was supporting 30 users doing fortran program edit, compile and test ... TSS/360 on the same hardware, would be supporting 4 users doing same fortran program edit, compile and test with worse response.

A typical configuration might be 768kbyte real machine, 2301 (fixed head) paging drum, 8-16 2314 packs for system, paging, application. A simple example of not having dynamic adaptive was that when user hit interactive edit return on 2741 (after having been think-time idle), TSS would attempt to pre-fetch the appropriate pages into real storage and then write them out to the 2301 (effectively pre-staging them from 2314 to 2301 by dragging them thru real memory). When the edit transaction was complete and the user was idle/thinking again ... TSS would stage all the pages back to 2314 from 2301 by pulling them thru real memory. TSS would always do this ... even if there was only a single user on the system and there was absolutely no contention for either real memory or the 2301.

So there is the folk tale about when tss/360 was decommitted and the group supposedly dropped from 1200 people down to 20 or so people. Now, instead of having a couple dozen people assigned to every module, a single person now had responsibility for a large number of different modules. Supposedly, one such person discovered that the original TSS/360 specs required that the TSS/360 scheduler be called whenever anything happened ... on the off-chance that a task state had changed. The resulting implementation had every module in the system calling the scheduler. The scenario was that on a kernel call ... the processing might involve sequential execution thru several dozen kernel modules. Supposedly after decommitment (with multiple modules per person as opposed to multiple people per module), somebody realized that it was only necessary to call the scheduler once, at the end of the kernel call processing sequence ... and not in every module. Supposedly, the resulting change to single scheduler call took a million instructions out of the avg. kernel call pathlength.

There is this joke, that even with CMS having more compact real storage requirements and much more efficient transitions between program execution phases ... so that the number of page faults was drastically reduced ... I had done cp/67 pathlength optimization so that the total instructions to 1) take page fault, 2) execute page replacement algorithm, 3) perform page write for the replaced page, 4) task switch to different process during page fault processing, 5) perform page read for the replaced page and 6) task switch back to the faulting process was on the order of 500-600 instructions (total). TSS/370 may have eventually gotten their pathlength down to 1k-2k instructions (and VS2 was like 10k instructions). Furthermore, the science center was later able to show that the page replacement algorithm that I had invented not only had drastically shorter pathlength ... but also typically made significantly better replacement choices (some cases 1/10th the total pathlength for a ten times better choice).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

previous, next, index - home