From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: First video terminal? Newsgroups: alt.folklore.computers Date: Mon, 01 Jan 2001 19:06:01 GMTbhk@dsl.co.uk (Brian {Hamilton Kelly}) writes:
At CSC (4th floor, 545 tech sq, cambridge) had special 1/2in(?) laminated board with a cut-out the size of the typerwriter ... that laid on the top of the 2741 frame & wrapped around the typerwriter body with a couple inches on one side and 18"-24" on the other side and back ... providing enuf room to support paper feed tray in the back and papers to one side of the keyboard (the board could be flipped so the space was either to the left or the right of the keyboard).
The paper-feed tray was like a wide in/out basket but large enuf to hold standard printer fan-fold paper ... bottom tray had room for about 6in stack of paper and return paper then would feed on to the top tray. I started out using standard green-bar fan-fold paper ... nominally reversed so it printed on the white-side.
I haven't had a real 2741 at home in nearly 25 years ... but some how the table top and paper tray made it into the garage and sat around gathering dust ... managing not to get thrown away even with 3-4 moves over the period (although i still have an "apl" golfball printing element).
random 2741 refs:
https://www.multicians.org/mga.html#2741
https://www.multicians.org/terminals.html
https://www.garlic.com/~lynn/2000f.html#6
http://www.classiccmp.org/mail-archive/classiccmp/1998-05/0875.html
https://web.archive.org/web/20020806100512/http://www.classiccmp.org/mail-archive/classiccmp/1998-05/0875.html
http://www.deadmedia.org/notes/17/170.html
http://www.totse.com/en/hack/understanding_the_internet/excerpt2.html
https://web.archive.org/web/20020225064928/http://www.totse.com/en/hack/understanding_the_internet/excerpt2.html
http://www.geocities.com/siliconvalley/2260/gli_00.html
http://www.enteract.com/~enf/afc/wp
https://web.archive.org/web/20020621232833/http://www.enteract.com/~enf/afc/wp
http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8705.mm.www/0110.html
http://www.unb.ca/web/transpo/mynet/mtx20.htm
some photos
http://www.cns.ufl.edu/info-services/history/nhp75A.jpg
http://www.keysan.com/ksu0675.htm
http://www.ibmtypewriters.com/reconselectric.htm
following gives description of the CCN computing facility at UCLA in
'71 (360/91kk, i/o configuriaton, 10 dail 2741 interfaces, etc)
http://www.rfc-editor.org/rfc/rfc90.txt
note in the following "history of the internet in new brunswick", 110
baud was teletype speed and 134.? baud was the 2741 speed. the
reference to "local" office connecting to "VM mainframe in Toronto"
was a "HONE" clone.
http://personal.nbnet.nb.ca/laurie/internet.html
random hone refs:
https://www.garlic.com/~lynn/2000f.html#62
https://www.garlic.com/~lynn/2000.html#75
https://www.garlic.com/~lynn/2000f.html#30
https://www.garlic.com/~lynn/2000g.html#14
https://www.garlic.com/~lynn/2000g.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM) Newsgroups: comp.arch Date: Mon, 01 Jan 2001 21:40:50 GMTIain McClatchie writes:
they also had a nifty scheme for communication channel with 15/16ths R/S and for uncorrected blocks ... (selective) transmit the 1/2 rate Viterbi instead of the original block (i.e. both the original block and the Viterbi 1/2 rate block could have uncorrected errors and still resolve correct data). there was also some dynamic adaptive stuff that if uncorrected block rate got too high ... switch to transmitting 1/2 rate viterbi along with the original block (within the 15/16s R/S channel).
the problem at the time was finding circuits that would do R/S for more than mbit speeds.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: A new "Remember when?" period happening right now Newsgroups: alt.folklore.computers Date: Mon, 01 Jan 2001 22:09:51 GMTre:
happened to run across apl\360 user's manual, ibm thomas j. watson research center.
the body of the manual was edited and composed on apl\360 using variations of a text-processing package designed and implemented by M. M. Zryl (IBM Research), and patterned after a Fortran system due to A. P. Mullery (IBM Research). August 1968 APL\360: User's Manual A.D. Falkoff K.E. Iverson Acknowledgements The APL language was first defined by K.E. Iverson in A Programming Language (Wiley, 1962) and has been developed in collaboration with A.D. Falkoff. The APL\360 Terminal System was designed with the additional collaboration of L.M. Breed, who with M.D. Moore*1, also designed the S/360 implementation. The system was programmed for S/360 by Breed, Moore, and R.H. Lathwell, with continuing assistance from L.J. Woodrum*2, and contributions by C.H. Brenner, H.A. Driscoll*3, and S.E. Krueger*4. The present impelemntation also benefitted from experience with an earlier version, designed and programmed for the IBM 7090 by Breed and P.S. Abrams*5. The development of the system has also profitted from ideas contributed by many other users and colleagues, notably E.E. McDonnell, who suggested the notation for the signum and cicular functions. In the preparation of the present manual, the authors are indebted to L.M. Breed for many discussions and suggestions; to R.H. Lathwell, E.E. McDonnell, and J.G. Arnold*5 for critical reading of successive drafts; and to Mrs. G.K. Sedlmayer and Miss Valerie Gilbert for superior clearical assistance. A special acknowledgment is due to John L. Lawrence, who provided important support and encouragement during the early development of APL implemenation, and who pioneered the application of APL in computer-related instructions. 1 I.P. Sharp Associates, Torotno, Canada 2 General Systems Architecture, IBM Corporation, Poughkeepsie, N.Y. 3 Science Research Asscoiates, Chicago, Illionis 4 Computer Science Department, Stanford University 5 Industry Development, IBM Corp, White Plains, NY.=======================
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: First video terminal? Newsgroups: alt.folklore.computers Date: Tue, 02 Jan 2001 02:23:55 GMT"John Bowen" writes:
It wasn't all because of the tilt/rotate ... there were some people that would slam their fist into the keyboard for one reason or another (especially if you had dedicated machine time over the weekend and had been up for 40+ hrs straight and there was a problem where the solution was difficult coming).
once cp/67 was up and running enuf for production, it was less of a problem since CP supported logging on as the operator from the machine console or any available 2741 (some security was added to limit the definition of "any").
The 1052-7 had another "nasty" feature that periodically caught people. There was a small finger that sensed whether there was incoming paper to the carriage. Frequently there were two boxes behind the 1052-7, one to feed the 1052-7 carriage and the other was for output after it had been printed. The input/feed was underneath the output/printed and frequently couldn't be seen.
More than once, the "finger" would sense that it had reached the end of paper and signal intervention required to the CPU. However there were no lights indicating the problem ... and OS/360 when it got an intervention required from the 1052-7 would ring the bell and stop all operations. There were numerous times where it took between 30minutes to 3hrs for somebody to realize that the reason that the system had apparently died was because the 1052-7 had run out of paper (since the input feed wasn't easily visible).
In the early '80s, I wanted one of those Field Engineering briefcases which were actually fancy toolboxs. The first couple times I requested one, it was rejected because I wasn't in IBM field engineering. Finally, I found a generic part number for the briefcase where it could be ordered w/o having to ask IBM. It still came with a number of specialized tools that I had seen used for repairing 2741s, selectrics, 1052s, etc.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Sv: First video terminal? Newsgroups: alt.folklore.computers Date: Tue, 02 Jan 2001 17:00:07 GMT"Nico de Jong" writes:
2702 supported 16 (maybe up to 32?) low-speed lines
2703 was similar to 2702 but supported up to 128 lines.
2701 supported only a few lines ... but had an RPQ that allowed supporting T1 (1.5mbite/2mbit) lines. It was the only IBM controller that supproted T1 lines until the 90s.
Federal System Division got a Zirpel T1 RPQ card for the S/1 in the mid-80s that saw limited deployment ... and you could get a 3rd party card that directly attached a S/1 to a channel. The internal network had a number of these. However, in the mid to late 80s it was becoming difficult to acquire S/1 boxes to house Zirpel cards (although possibly not as hard as it was to acquire 2701 boxes).
The only other choice was HYPERchannel starting in the early '80s, you could get an A220 adapter for channel attach and 710/715/720 adapters for driving T1/T2 links. My wife and I ran a backbone attached to the internal network with this technology. It was also possible to connect an HYPERchannel LAN to a S/1 via a A400 adapter and get T1 connectivity that way (with or w/o the S/1 having a channel attach card).
There were plans in the late '80s for the 8232 (i.e. PC/AT with channel attach card and LAN cards ... providing mainframe gateway to T/R and enet LANS) that saw development of a PC/AT T1 card, but I don't know of any that were actually sold to customers. This was about the same time as the annual Super Computer conference held in Austin where T3 HYPERchannel adatpers were being demonstrated.
The 3705/3725 communication controller mainstay (during the 70s & 80s) didn't support full-speed T1 ... although there La Gaude may have had one or two test boxes in the late '80s. The 3705/3725 market saw a number of customers using "fat pipe" support to gang 2, 3, and 4 56kbit links into a single simulated trunk; but saw now evidence of customers with more than 4 56kbit links in fat pipe configurations. One of the issues that was possibly overlooked was that T1 tariffs were typically about the same as 5-6 56kbit links. At the time when there were no 3705/3725 mainframe customers with more than 4 56kbit lines in a fat-pipe configuration there were 200 easiliy identified customers using mainframe HYPERchannel T1 support.
While NSFNET1 in the late '80s called for full-speed T1 trunks, it was actually done with multiple PC/RTs each with LAN card and a 440kbit card (although RT had a AT bus and the PC/AT T1 card targeted for the 8232 could have fit on the RT bus) ... with multiple 440kbit circuits multiplexed by an IDNX box through T1 trunks provided by MCI.
random refs:
https://www.garlic.com/~lynn/2000.html#77
https://www.garlic.com/~lynn/93.html#15
https://www.garlic.com/~lynn/93.html#16
https://www.garlic.com/~lynn/93.html#17
https://www.garlic.com/~lynn/94.html#23
https://www.garlic.com/~lynn/96.html#9
https://www.garlic.com/~lynn/96.html#27
https://www.garlic.com/~lynn/96.html#30
https://www.garlic.com/~lynn/99.html#36
https://www.garlic.com/~lynn/99.html#63
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#67
https://www.garlic.com/~lynn/99.html#70
https://www.garlic.com/~lynn/2000b.html#38
https://www.garlic.com/~lynn/2000b.html#66
https://www.garlic.com/~lynn/2000c.html#36
https://www.garlic.com/~lynn/2000c.html#37
https://www.garlic.com/~lynn/2000c.html#65
https://www.garlic.com/~lynn/2000f.html#6
https://www.garlic.com/~lynn/2000f.html#31
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Sv: First video terminal? Newsgroups: alt.folklore.computers Date: Tue, 02 Jan 2001 23:38:46 GMTjsaum@world.std.com (Jim Saum) writes:
I ran across later versions of the Perkin/Elmer box still in production use as late as 1996 (& some conjecture that the wire-wrap channel attach board had possibly not changed since the original implementation).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk drive behavior Newsgroups: comp.sys.ibm.pc.hardware.storage,comp.arch.storage,comp.arch Date: Wed, 03 Jan 2001 00:39:47 GMT"Bill Todd" writes:
i know many unix vendors "qualify" drives (mostly SCSI) as having fully transferred data to local memory and guarantee that a sector/block write either doesn't occur or occurs completely & correctly (akin/similar to TPC ACID properties) regardless of power failure scenerios.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM Model Numbers (was: First video terminal?) Newsgroups: alt.folklore.computers Date: Wed, 03 Jan 2001 18:11:27 GMTLars Poulsen writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: finding object decks with multiple entry points Newsgroups: bit.listserv.ibm-main Date: Wed, 03 Jan 2001 18:44:48 GMTJay_Carr@AMWAY.COM (H Jay Carr) writes:
Name - ESD Card Formant Col Meaning 1 12-2-9 punch 2-4 ESD 8-10 blank 11-13 Variable field count 13-14 Blank ESDID ESDID for first SD, XD, CM, PC, or ER 17-84 variable field, repeated 1 to 3 times 17-24 name 24 ESD type code 26-28 Address 29 Alighment for XD, otherwise blank 30-32 Length, LDID, or blank... pg. 275 ESD Type 0 processing
This routine makes Reference Talbe and ESID Table entries for the
card-specified control section
This routine first determines whether a Reference Table (REFTBL) entry
has already been established for the csect=specified control
sectionn. To do this, the routine links to the REFTBL search
routine. The ESD Type 0 Card Routine's subsegment operation depends on
whether there already is a REFTBL entry for the control section. If
there is such an entry, processing continues with operation 4,
below. If there is not, the REFTBL search routine places the name of
this control section in REFTBL, and processing continues with
operation 2, bleow.
.... pg. 276 ESD type 1
This routine establish a Reference Table entry for the entry point
specified on the ESD card, unless such an entry already exists.
... ESD Type 2
This routine makes the proper ESID table entry for the card-specified
external name and places that name's assigned address (ORG2) in the
reference table relocation factor for that name.
.. pg. 277 ESD Type 4
This routine makes Reference Table and ESIDTAB entries for private code CSECT
... pg. 278 ESD Type 5 & 6
Thie routine makes Reference Table and ESIDTAB entries for common and psuedo-register ESD's
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: tweak ui & right click pop-up window Newsgroups: netscape.public.mozilla.general Date: Wed, 03 Jan 2001 20:02:06 GMTOn all releases of netscape 4.x (and earlier), I can right-click on a url, get a pop-up window, move to "open in new window" selection and click (opening the URL in a new window).
On mozilla 15, 16, 17, 18, 0.6, etc and netscape 6.xs, if I right click on a URL, i get the pop-up window but if i move the mouse at all the pop-up window immediately disappears (no ability to select "open in new window").
I am running tweak ui with mouse settings set to "follow" ... i.e. x-mouse mode ... on nt4sp6 ... which may or may not have anything to do with it.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH Newsgroups: alt.folklore.computers Date: Thu, 04 Jan 2001 22:37:58 GMTseebs@plethora.net (Peter Seebach) writes:
much of the time operating system developers think in terms of state machine logic ... bits being on or off ... and rarely need to resort to math ... maybe increment or decrement and sometimes compare against a value. frequently multiplication & division isn't even necesary.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 1142 reader/punch (Re: First video terminal?) Newsgroups: alt.folklore.computers Date: Fri, 05 Jan 2001 14:23:12 GMTNick Spalding writes:
the university then started running the 360/30 in 1401 emulator mode ... booting from "MPIO" card deck. My first programming job (summer '66) was to duplicate the 1401 "MPIO" function in 360 assembler. I got to design my own memory manager, task manager, device drivers, interrupt processes, etc.
I don't know how long they had the 2540/1403n1 prior to getting the 360/30 ... my first exposure was about the time the 360/30 came in and the 1401 was still there and they would periodically move the unit record back and forth between the 1401 & 360/30.
I would get a dedicated machine time on the 360/30 ... typically weekends when I could get the machine for 48hrs straight. One of the first things I learned was to not start until i had cleaned the tape drives and took the 2540 apart and cleaned everything. If I was diligent about cleaning every 8hrs or so (of use), things ran a lot smoother.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Small IBM shops Newsgroups: bit.listserv.ibm-main Date: Fri, 05 Jan 2001 15:03:21 GMTpanselm@EARTHLINK.NET (Phil Anselm) writes:
random ref:
https://www.garlic.com/~lynn/95.html#13
the interesting thing is that a lot of the CKD stuff now is being emulated by controllers using drives that are effectively same hardware as being used in high-end scsi drives.
however, by definition a small shop would tend to have smaller requirements ... and if it wasn't a small shop and did have database and thoughput requirements that would saturate a standard Intel motherboard ... then it wouldn't likely be considered a small shop (entry-level hardware with less processing & I/O capacity for small shops ... is not likely, by definition, to also be a high-end supercomputer capable of sustaining terabytes/sec thruput).
on the other hand ... numa/q has some interesting scalling characteristics both in terms of i/o and processing power (even if only considered as an entry-level enterprise server).
misc. ref:
http://www.sequent.com/hardware/numaq2000/
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH Newsgroups: alt.folklore.computers Date: Fri, 05 Jan 2001 15:59:10 GMTjmfbahciv writes:
the paradigm change also cut the scheduling function pathlength by two orders of magnitude and reduced aggregate cpu consumption by 20% in high activity environments and delivered a significantly more uniform response for interactive and batch workloads (and in some cases, reduction of a factor of 10 in the average trivial interactive response while still running the processor at 100% saturation).
what i found was that in some cases, i could sometimes get between one order and two order of magnitude performance improvement in pathlenth by careful state analysis and code re-ordering (low level device drivers, interrupt handlers, etc).
however, for resource scheduling and various algorithms (page replacement, disk arm motion, etc), I found that it was useful to do a paradigm shift and solve the problem using a statistical, probablistic approach. Sometimes I found that individuals used to deterministic state machine solutions had difficulty making the paradigm switch and dealing with not quite so deterministic, probablistic solutions (especially when the paradigms were interwoven threads in the same module and set of instructions).
Simple example was when I initially added multiprocessor support to a kernel. i arrainged it so that dispatching function fell out pretty much as a probablistic event which bothered a lot of the more traditional operating system implementers .. although it had the characteristic that the thruput increase was almost exactly proportional to the increase in the available hardware, i.e. a uniprocessor ran at "1", going from a single processor to a dual processor decreased machine cycle time by 10% to handle hardware cross-cashe consistency protocols ... resulting in a two processor configuration having being rated at 1.8 a uniprocessor. Average overall performance improvement was 1.8 although there was some interesting situation where thruput increase was 2.5 single processor (because some interesting probablistic side-effects of maintaining cache locality).
In any case, the code was eventually enhanced to be deterministic which required a lot of cross processor signaling and lock spins. The result was that cross processor signaling and lock spin overhead went from nearly zero percent of total cpu utilization to over 10% of total cpu utilization and most of the interesting cache locality side effects disappeared, but heh, it was very deterministic.
problem determination skills for deterministic solutions work well when dealing with a stricly deterministic sequences ... but frequently fails when the events aren't strictly deterministic sequence ... for instance program failure in a low-level device driver vis-a-vis poor system performance.
another simple example was there were numerous instances where somebody more trained in traiditional deterministic solutions would modify a module with some of my problistic threads ... and while the code wouldn't fail, the overall system performance would get worse for apparently unexplicable reasons.
Another example is I believe there was a paper in the late '60s describing working set and page management algorithms (possibly slightly related to dartmouth?). At about the same time, I did something that was significantly less deterministic and much more probablistic. This caused something of a festouche in some qtrs. (even close to 15 years later). In any case, there was an implementation as described in the research literature using the same operating system and same hardware ... and then there was my solution. I was able to demonstrate better level of interactive performance and workload thruput... using the same workload on the same operating system and the same processor hardware ... but with more than twice as many users (running the workload) and 1/3 less real storage.
random refs:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/93.html#4
https://www.garlic.com/~lynn/93.html#5
on the other end ... I once helped out the disk engineering & development operation. they had an environment with disks & controllers under development and test that frequently weren't working to spec. A traditional mainframe operating system in that environment tended to crash & burn within 10-15 minutes. I redid the I/O supervisor so it was absolutely bullet-proof and wouldn't crash ... so that instead of testing a single unit at a time, they could be testing 6-12 different units concurrently using the same processor. This pretty much involved a very deterministic state machine solution (although there were a little bit of probablistic things having to do with hot interrupts which needed to be fenced/masked).
random refs:
https://www.garlic.com/~lynn/98.html#57
https://www.garlic.com/~lynn/99.html#31
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM Model Numbers (was: First video terminal?) Newsgroups: alt.folklore.computers Date: Fri, 05 Jan 2001 21:58:58 GMTjsaum@world.std.com (Jim Saum) writes:
SLC
ICS
TXT
REP
RLD
END
LDT
from Control Program-67/Cambridge Monitor System User's Guide, GH20-0859-0,pgs 521-523
SLC definition
col meaning
1 12-2-9 punch ... ldentifies card as acceptable to the loader
2-4 SLC
5-6 blank
7-12 hexadecimal address to be added to the value of the sumbol, if
any, in columns 17-22. must be right-justified in these columns
with unused leading columns filled with zeros
13-16 blank
17-22 symbolic name whose assigned location is used by the loader
must be left-justified in these columns. if blank, the address
in the abolsute field is used
23 blank
24-72 may be used for comments or left blank
73-80 not used by the loader, the user may leave these blank or insert
program identification for his own conveniences
ICS
col meaning
1 load card identification, 12-2-9 punch
2-4 ICS
5-16 blank
17-22 control sectionname, left justified
23 blank
24 , (comma)
25-28 hexadecimal length in bytes of the control section
29 blank
30-72 may be used for comments
73-80 not used by the loader
REP
col meaning
1 load card identification, 12-2-9 punch
2-4 REP
5-6 blank
7-12 hexadecimal starting address of the area to be replaces as assigned
by the assembler. must be right-justified with leading zeros
13-14 blank
15-16 ESID -- external symbol identification, the hexadeecimal number assigned
to the control section in which replacement is to be made. the
LISTING file produced by the compiler indicates this number
17-70 a maximumm of 11 four-digit hexadecimal fields, separated by commas
each replacing one previously loaded halfword
71-72 blank
73-80 not used by the loader
--------- bit.listserv.ibm-main response ---------------
From CMS Program Logic Manual (360D-05-2-005, Oct. 1970), pg. 292 Name - ESD Card Formant Col Meaning 1 12-2-9 punch 2-4 ESD 8-10 blank 11-13 Variable field count 13-14 Blank ESDID ESDID for first SD, XD, CM, PC, or ER 17-84 variable field, repeated 1 to 3 times 17-24 name 24 ESD type code 26-28 Address 29 Alighment for XD, otherwise blank 30-32 Length, LDID, or blank... pg. 275 ESD Type 0 processing
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM Model Numbers (was: First video terminal?) Newsgroups: alt.folklore.computers Date: Sat, 06 Jan 2001 01:43:10 GMTAnne & Lynn Wheeler writes:
from terminal characteristics
2741 Characteristics
The IBM 2741 Communication Terminal consists of an IBM Selectric
typewriter mounted on a typerwriter stand. The stand includes the
electronic controles needed for communications, a cabinet for mounting
a data-phone, a rack for mounting a roll of paper, and a working
surface. For use with the CP/CMS system, the 2741 should be equipped
with the Transmit Interrupt and the Receive Interrupt features.
The 2741 has two modes of operation: communicate mode and local
mode. The mode of the terminals is contrlled by the terminal mode
switch, ahich is located on the left side of the typerwriter
stand. When in local mode, the terminal is disconnected from the
computer. It then functions as a typerwriter only, and no information
is transmitted or received. When in communicate mode, the terminal may
be connected to the communication line to the computer. The power
switch on the right side of the keyboard must be set to ON before the
terminal can operate in either communicate or local mode. The
procedure for establishing connections with the computer and the
terminal switch settings which should be used are discussed below
under "2741 Initiation Producedures".
Either of two 2741 keyboard configurations may be used in accessing
the CP/CMS system. These are the PTTC/EBCD configurations (shown in
Figure 1) and the standard Selectric configuration (shown in Figure
2). On either keyboard, the alphameric and special character keys, the
space bar, power switch, the SHIFT, LOCK, TAB, tab CLR SET, and MAR
REL keys all operate in the same way as standard Selectric typewriter
keys.
On most 2741 terminals, the space bar, backspace, and hyphen/underline
keys have the typamatic feature. If one of these keys is operated
normally, the corresponding function occurs only once. If the key is
pressed nad held, the function is repeated until the key is
released. The RETURN and AATN keys have special significance on the
2741 keyboard.
The RETURN key is hit to signal the termination of each input
line. When RETURN is hit, control is transferred to the system, and
the keyboard is locked until the system is ready to accept another
input line.
The ATTN key is used to generate an attention interrupt. It may be hit
at any time (since it is never locked out) and causes the keyboard to
be unlocked to accept an input line. Refer to "Attention Interupt" for
a discussion of the transfer between enviornments that occurs when the
attention interupt is generate.
The 2741 paper controls (such as the paper release lever, line-space
lever, impression control lever, etc.) are identical to the
corresponding controls on an IBM Selectric typerwriter and operate
accordingly.
An invalid output character (one which cannot be typed by the terminal
and for which no keyboard function, such as tab or carriage return,
exists) appears in terminal output as a space. For a further
discussion of 2741 characteristics refer to the 2741 component
description manual (GA24-3415).
1050 Characteristics
The IBM 1050 terminal is composed of the 1051 Control Unit and a 1052
Printer-Keyboard. The 1051 Control Unit includes the power supplies,
printer code translator, data channel, and control circuitry needed
for 1050 operation. To be used with the CP/CMS system, the 1051 should
be equipped with the Time-Out Suppression and the Transmit Interrupt
and Receive Interrupt special features. The 1052 keyboard is similar
in appearance to the standard IBM typewriter keyboard. Figure 3 and 4
illustrate the 1050 switch panel and keyboard. The alphameric and
special character kyes, the space bar, LOCK, SHIFT, and TAB keys, and
the paper controls operate in the same way as those on a standard IBM
typewriter. The following keys are of special significance on the 1052
keyboard:
RETURN. If the Automatic EOB special feature is included on the
terminal being used, and if the EOB switch on the switch panel is set
to AUTO, the RETURN key may be used to terminate an inpute
line. Otherwise, (if the Automatic EOB special feature is not availabe
on the terminal being used, or if EOB on the switch panel is set to
MANUAL) the character transmitted when RETURN is hit is considered
part of the input line.
ALTN CODING. This key, when pressed and held while one of the other
keys is hit, Originates a single character code such as restore,
bypass, reader stop, end of block (EOB), end of address (EOA), prefix,
end of transaction (EOT), or cancel. Note that input lines from 1050
terminals not equipped with the automatic EOB special feature must be
terminated by pressing the ALTN CODING key and holding it down while
hitting the 5 key. This procedure causes a carriage return at the
tmerinal.
RESET LINE. Hitting this key (at the left side of the keyboard) causes
an attention interupt (provided the terminal is equipped with the
Transmit Interrupt special feature). The RESET LINE key may be hit at
any time, since it is never locked out, and causes the keyboard to
accept on input line. Refer to "Attention Interupt" for a discussion
of the transfer between environments which occurs when an attention
interrupt is generated.
RESEND. This key and its associated light (both located on the right
of the keyboard) are used during block checking. The light comes on
when an end-of-block character is sent by the terminal; it is turned
of when receipt is acknowledged by the system. If the light remains
on, indicating an error, RESENT may be hit to turn off the light, and
the previous input line may then be reentered. While the light is on,
no input is accepted from the keyboard.
LINE FEED. This key causes the paper to move up one or two lines,
according to the setting of the line space lever, wihtout moving the
typing element.
DATA CHECK. This key should be hit to turn off the associated light
(to its left), which comes on whenever a longitudinal or vertical
redundancy checking error occurs, or when power is turned on at the
terminal.
1050 Initiation Procuedures
The procedure for preparing the 1050 for use are descriped below. When
these steps have been performed, log in.
1. After making sure that the terminal is plugged in, set the panel
switches (shown in Figure 3) as follows:
Switch Setting
SYSTEM ATTEND
MASTER OFF
PRINTER1 SEND REC
PRINTER2 REC
KEYBOARD SEND
READER1 OFF
READER2 OFF
PUNCH1 OFF
PUNCH2 OFF
STOP CODE OFF
AUTO FILL OFF
PUNCH NORMAL
SYSTEM PROGRAM
EOB see below
SYSTEM (up)
TEST OFF
SINGLE CY OFF
RDR STOP OFF
If an EOB switch appears on the terminal, it may be set to either AUTO
or MANUL. If it is set to AUTO, the RETURN key may be used to
terminate an input line. If the EOB switch is set to MANUAL, or if it
does not appear on the terminal, all input lines must be terminated by
hitting the 5 key while the ALTN CODING key is pressed and held down.
TYPE 33 TELETYPE Characteristics
The KSR (Keyboard Send/Receive) model of the Teletype Type 33 terminal
is supported by CP-67. The Type 33 KSR includes a typewriter keybarod,
a control panel, a data-phone, control circuitry for the teletype, and
roll paper. The Type 33 KSR keyboard contains all standard characters
in the conventional arrangement, as well as a number of special
symbols. All alphabetic characters are capitals. The SHIFT key is used
only for typing the "uppershift" special characters. The CTRL key
(Control key) is used in conjunction with other keys to perform
special functions. Neither the SHIFT nor CTRL key is self-locking;
each must be depressed when used.
In addition to the standard keys, the keyboard contains several
non-printing keys with special functions. These function keys are as
follows:
LINE FEED generates a line-feed character and moves the paper up one
line without moving the printing mechanism. When the terminal is used
offline, the LINE FEED key should be depressed after each line of
typing to avoid overprinting of the next line.
RETURN is the carriage return key and signifies the physical end of
the input line.
REPT repeats the action of any key depressed.
BREAK generates an attention interupt and interrupts program
execution. After breaking program execution, the BRK-RLS button must
be depressed to unlock the keyboard.
CNTRL is used in conjunction with other keys to perform special
functions. The tab character (Control-I) acts like the tab key on the
2741. COntrol-H acts like the backspace key on the 2741. Control-Q and
Control-E produce an attention interrupt like BREAK if the teletype is
in input mode. Control-S (X-OFF) and Control-M act as RETURN. Control-D
(EOT) should not be used as it may disconnect the terminal. Control-G
(bell), COntrol-R (tape), Control-T (tape), and all other Control
characters are legitimate characters even though they have no
equivalent by the 2741.
HERE IS and RUBOUT are ignored by CP-67.
ESC (ALT MODE on some units) is not used by CP-67, but generates a
legal character.
The control panel to the right of the keyboard contains six buttons
below the telephone dial, and two lights, a button, and the
NORMAL-RESTORE knob above the dial. THe buttons and lights are as
bollows:
ORIG (ORIGINATE). This button obtains a dial tone before dialing. The
volume control on the loadspeaker (under the keybarod shelf to the
right) should be turned up such that the dial tone is audible. After
connection with the computer has been made, the volume can be lowered.
CRL (CLEAR). This button, when depressed, turns off the typerwriter.
ANS (ANSWER). This button is not used by CP-67.
TST (TEST). This button is used for testing purposes only.
LCL (Local). This button turns on the typerwriter for local or offline
use.
BUZ-RLS (Buzzer-Release). This button turns off the buzzer that warns
of low paper supply. The light in the BUZ-RLS button remains on until
the paper has been replenished.
BRK-RLS (Break-Release). This button unlocks the keyboard after
program execution has been interrupted by the BREAK key.
REST. This light is not used by CP-67.
NORMAL-RESTORE. This knob is set to NORMAL, except to change the
ribbon, in which case the knob is twisted to the OUT-OF-SERV
light. The knob is then set to RESTORE and returned to NORMAL when the
operation has been completed.
OUT-OF-SERV (Out of Service). This light goes on when the
NORMAL-RESTORE knob is pointed to it for ribbon changing.
Most teletype units have a loadspeaker and a volume control knob (VOL)
located under the keyboard shelf. The knob is turned clockwise to
increase the volume.
TYPE 35 TELETYPE Characteristics
THe KSR (Keyboard Send/Receive) model of the Teletype Type 35 terminal
is supported by CP-67. The Type 35 KSR, like the Type 33 KSR, includes
a typewriter keybarod, a control panel, a data-phone, control
circuitry, as well as roll paper. The Type 35 has basically the same
features as the Type 33. The additional features of a Type 35 are the
following:
LOC-LF (Local/Line Feed). This button operates as the LINE FEED button
without generating a line-feed character. It is used along with the
LOC-CR.
LOC-CR (Local/Carriage Return). This button returns the carrier as
RETURN does without generating an end-of-line character. LOC-CR is
normally used only to continue a line of input to the next line.
LOC-BSP (Logical/Backspace). This button generates a character but it
has no meaning with the KSR model.
BREAK. This button generates an attention interrupt and interrupts
program execution. After execution has been interrupted, BRK-RLS, and
then the K buttons must be depressed to unlock the keyboard.
K (Keyboard). This button unlocks the keybarod and sets the terminal
for page copy only.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Sv: IBM 1142 reader/punch (Re: First video terminal?) Newsgroups: alt.folklore.computers Date: Sat, 06 Jan 2001 17:22:10 GMT"Nico de Jong" writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 1142 reader/punch (Re: First video terminal?) Newsgroups: alt.folklore.computers Date: Sat, 06 Jan 2001 18:28:53 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
from Control Program-67/Cambridg Monitor System Installation guide, GH20-0857-0 (Oct. 1970), pg. 23, sample real I/O source deck
RIOS RIALIO TITLE="SAMPLE SYSPLEX"
SYSRES SYSRES=230,SYSTYPE=2314,SYSVOL=CPDISK1,SYSERR=004, x
SYSDNC=198,SYSWRM=202
SYSGEN SYSOPER=OPERATOR,SYSDUMP=CPSYS,SYSERMG=020, x
SYSCNSL=009,SYSPRT=030,SYSPUN=032,SYSCORE=768K
OPCONSOL DMXDV RDEVPNT=PRINTER1,RDEVADD=009,TYPE=1052
PRINTER1 DMXDV RDEVPNT=CARDRD11,RDEVADD=030,TYPE=1403
CARDRDR1 DMXDV RDEVPNT=PUNCH1,RDEVADD=031,TYPE=2540RDR
PUNCH1 DMXDV RDEVPNT=TERM01,RDEVADD=032,TYPE=2540PCH
TERM01 DMXDV RDEVPNT=TERM02,RDEVADD=020,TYPE=2702T,SAD=1
TERM02 DMXDV RDEVPNT=TERM03,RDEVADD=021,TYPE=2702T,SAD=2
TERM03 DMXDV RDEVOBT=TERM04,RDEVADD=022,TYPE=2702T,SAD=2
,,,,
TERM4E DMXDV RDEVADD=04E,TYPE=2703T,SAD=4
DRUM2 DRDEV RDEVCU-R2820A,RDEVADD=100,TYPE=2301,DECUPTH=80
R2820A DRCU DEVLIST=DRUM2,RCUADD=0,CUTAIL1=CHAIN1,RCUPATH=80
CHAN1 DRCH RCULIST=R2820A,CHANADD=1,CHANPNT=CHAN2
....
as an aside, SAD command on the 2702/2703 bound the line-scanner to a
particular line. Standard installation had 2741 line-scanner at SAD1,
TTY line-scanner at SAD2, and 1052 line-scanner at SAD3.
As an undergraduate, I added the TTY support to CP/67 and after looking thru all the manuals believed that I could do dynamic terminal type recognition and not require a preconfigured SAD command for specific lines. Didn't make a lot of difference for directly wired terminals but in dial-up ... it allowed a single phone number rotery pool for all terminals (i.e. all terminals could call the same number)
I tested it all out and it actually worked with TTY terminals working on 2741 dial-up "lines". Then the IBM CE got around to telling me that for the 2702 there was a hardware short-cut, while the type of line-scanner could be dynamically set with the SAD command, specific line frequency oscillators was hardwared to specific lines (i.e. 110 baud terminals weren't spec'ed for running on 134.5 baud lines).
That led to the university project where four of us built a 360 channel connection board & the first 360 plugged compatible 360 controller (initially out of an Interdata/3) to replace the 2702. The Interdata/3 directly implemented the line-scanner function in software ... including initially strobbing the signal raise/lower at a very high rate to determine the edges and dynamically calculate the baud rate.
random refs:
https://www.garlic.com/~lynn/96.html#30
https://www.garlic.com/~lynn/99.html#12
https://www.garlic.com/~lynn/2000c.html#36
https://www.garlic.com/~lynn/2000c.html#37
https://www.garlic.com/~lynn/2000g.html#42
https://www.garlic.com/~lynn/2001.html#3
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk caching and file systems. Disk history...people forget Newsgroups: comp.arch.storage Date: Sat, 06 Jan 2001 19:58:53 GMT"Jean Dion" writes:
then came out with ?(memory failing, may have been victoria or something like that)/3880-13 controller track disk cache a year or two later ... again from tucson.
DPR originally had some things that were path specific with respect to reserve and errors. I did a revamp of the implementation that used much shorter pathlength & memory in the controller that eliminated the problem and also made it much simpler to virtualize (in general KISS) ... at the time it wasn't adopted (early '83), I have no idea if anything like it was subsequently put in place. In any case, for the original DPR some of the recovery scenerios almost impossibly complex in multi-complex configurations (and needed involve operator intervention in some cases).
One of ESCON problems has been simulating bus&tag half-duplex synchronous operation which runs into latency problems at more than very trivial distances (until you get to aggregation of transfer thruput, most of the fiber is significantly faster than the disk requirements and the bottlenecks become command execution latency ... both processor & drive as well as transmission, & in half-duplex round-trip delays). It was one of the things in SSA and over 10 years ago gave 9333s significantly higher thruput compared to standard SCSI (even given effectively same drive mechanics). 9333 was initially done on 80mbit/sec serial computer and used asynchronous packetized SCSI commands and data so there was much less of end-to-end latency issues.
One of the announcements that goes along with FICON is better command queueing at the processor ... something we worked on over ten years ago (a couple of us even did a invention disclosier on it at the time).
random refs:
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/2000b.html#38
https://www.garlic.com/~lynn/2000d.html#13
https://www.garlic.com/~lynn/2001.html#12
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk caching and file systems. Disk history...people forget Newsgroups: comp.arch.storage Date: Sat, 06 Jan 2001 20:01:38 GMT"Rob Peglar" writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk caching and file systems. Disk history...people forget Newsgroups: comp.arch.storage Date: Sat, 06 Jan 2001 22:10:41 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk caching and file systems. Disk history...people forget Newsgroups: comp.arch.storage Date: Sun, 07 Jan 2001 03:25:09 GMT"Rob Peglar" writes:
LANL, LLNL, UCSD-SCC/GA, NASA/AMES, misc others had done similar things.
the hippi switch & IPI-3 disk controller standard meetins had requirements so that equipment could be configured to operate similarly to the NCAR configuration (i.e. 3rd party transfers, permissions established by the "server" ... but allowed direct data transfer w/o having to flow thru the server).
gary c. was one of the prime backers behind the national storage lab effort.
random refs:
http://whatis.techtarget.com/WhatIs_Definition_Page/0,4152,212937,00.html
https://web.archive.org/web/20010331072346/http://whatis.techtarget.com/WhatIs_Definition_Page/0,4152,212937,00.html
http://www.storagesolutions.com/topic01.htm
http://www.nersc.gov/~jed/talks/net-tutorial/sld085.htm
http://www.llnl.gov/liv_comp/siof.html
https://web.archive.org/web/20010615025517/http://www.llnl.gov/liv_comp/siof.html
https://www.garlic.com/~lynn/2000f.html#30
https://www.garlic.com/~lynn/2000c.html#65
https://www.garlic.com/~lynn/2000b.html#29
https://www.garlic.com/~lynn/2001.html#4
https://www.garlic.com/~lynn/2000.html#90
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk caching and file systems. Disk history...people forget Newsgroups: comp.arch.storage Date: Sun, 07 Jan 2001 06:50:08 GMTAnne & Lynn Wheeler writes:
I developed and help deploy such a oolution for the IBM IMS development and support teams in 80/81 (remoted numerous nominally "channel attached" devices supported 300+ people to a remote location several miles away from the data center). One installation was about 300 people for the IMS development team at the STL lab. The other was another 300 or so IMS field support people at the boulder complex.
random ref:
https://www.garlic.com/~lynn/2000c.html#65
Most things worked fine except for IBM CKD disk controllers and drives. They had special timing/latency constraints for some specific operations. The A515 was an enhanced remote device adapter that providing some extra features to overcome the CKD disk timing/latency constraints. This allowed NCAR (and others) to directly attach IBM disk farms to HYPERchannel networks and make them available to the HYPERchannel network connected processors ... things like crays and/or other processors even though they weren't IBM mainframes.
There were some little gotchas like ibm field engineering expected to provide service and support for such hardware when they were directly connected to ibm mainframe channels.
For the non-SAN (i.e. like at NCAR) implementational that just used HYPERchannel as a mainframe "channel extender" (simulating local ibm mainframe operation even though the actual processor and the devices separated by long distances), I had a problem crop up over 10 years after I did the stuff for STL/boulder/IMS groups. With HYPERchannel there could be various kinds of network transmission errors and/or congestion problems that wouldn't occur in a normal, locally connected mainframe connection. At the mainframe, I would trap those conditions and reflect a simulated "channel check" operation to the mainframe operating system. The mainframe operating system would do various recording and diagnostics things and then retry the operation.
Ten years after I had done the implementation at STL, I was contacted by some IBM RAS monitoring guy. A new mainframe processor had been out for a year and they were reviewing the error reporting summaries for all customer installations for the year. They were expecting an aggregate total of 3-4 channel checks to have been recorded across all machines at customer shops (not per machine per month, or per machine per year, but across all machines for the year). However, there were something like 15-16 aggregate channel checks recorded. This had a lot of people concerned regarding the predicted RAS qualities of the new processors. The finally tracked it down to installations running remote device HYPERchannel support. The solution was to change the HYPERchannel software to simulate an "interface control check" rather than a "channel check". It turned out that "interface control check" followed pretty much the same error retry flow as "channel check" handling ... so the operation would be retried the same way whether "interface control check" or "channel check" was reflected.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: stupid user stories Newsgroups: alt.folklore.computers Date: Sun, 07 Jan 2001 16:32:02 GMTjmfbahciv writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: stupid user stories Newsgroups: alt.folklore.computers Date: Sun, 07 Jan 2001 17:05:05 GMTab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
having video cameras are an inhibitor for large number of attacks, i believe justified as much for attacks on people using the machines as attacks on the machines themselves.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: stupid user stories Newsgroups: alt.folklore.computers Date: Sun, 07 Jan 2001 17:12:14 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk caching and file systems. Disk history...people forget Newsgroups: comp.arch.storage,alt.folklore.computers Date: Sun, 07 Jan 2001 20:59:57 GMT"Jean Dion" writes:
One of the major uses of this was the airline reservation system which would have full-blown configuration. By the mid-70s, the airline res system also got an enhancement for the 3830 supporting fine-grain locking. Prior to that serialization was done with a "reserve" command at the drive level. With the 3830 fine-grain locking support, access to sub-areas could be serialized.
About the same time, some people at Uithoorn (an ibm location running a clone of the branch office HONE system for europe) developed a I/O protocol for IBM drives analogous to the processor compare&swap instruction (without requiring fine-grain locking enhancement in the 3830 ... although it required extra disk revolutions) for processor serialization.
The US HONE used that and other functions in 1978 to build what was
the largest single-system image cluster system in the world at the
time. It provided online service for all the branch & field service
people in the US ... system possibly had between 30,000 and 40,000
user account definitions. Because of concerns regarding things like
natural disasters, by 1980 or so, the california location was
replicated in both dallas and boulder ... with load-sharing &
fall-over capability extended from intra-cluster to across the three
locations.
https://www.garlic.com/~lynn/2000g.html#27
The basic filesystem paradigm dates from the origin of the system/360
in the early '60s. At that time there was huge excess I/O capacity and
severaly constrained real memory. Some of the trade-offs made to meet
that design point (little or no caching) facilitated lack of
filesystem inconsistency and ease of concurrent filesystem cluster
implementation. However, by at least the mid-70s some of the
trade-offs had reversed but the pieces of paradigm were very well
entrenced (optimal trade-off of some of the implementations could have
changed while still maintaining file system consistency a eash of
cluster implementation).
https://www.garlic.com/~lynn/94.html#35
https://www.garlic.com/~lynn/2000f.html#18
https://www.garlic.com/~lynn/2000g.html#51
https://www.garlic.com/~lynn/2001.html#12
However, because of the lack of real memory for things like caching, system thruput was a lot more sensitive to data ordering on disk. During the late '60s, by careful system build with nearly hand ordering of placement of standard system files and data, I could show a 2.5 to 3 times thruput speedup for various jobs (compared to off-the-shelf system build).
see misc. footnotes regarding process used for OS/360 MFT11 and MFT14
in the following
https://www.garlic.com/~lynn/94.html#18
-- Anne & Lynn Wheeler | lynn@garlic.com -
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM/SP sites that allow free access? Newsgroups: comp.lang.rexx Date: Sun, 07 Jan 2001 21:13:37 GMTrichgr@panix.com (Rich Greenberg) writes:
random ref:
https://www.garlic.com/~lynn/94.html#22
https://www.garlic.com/~lynn/99.html#222
https://www.garlic.com/~lynn/2000g.html#40
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Competitors to SABRE? Newsgroups: alt.folklore.computers Date: Mon, 08 Jan 2001 16:39:27 GMTCharles Richmond writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH Newsgroups: comp.software-eng,comp.programming,alt.folklore.computers Date: Mon, 08 Jan 2001 17:50:58 GMTspinoza9999 writes:
during the early '80s, i was indoctrinated by an individual that studied and dealt with large organizational dynamics.
One of his observations was that many of the executives and upper management in US corporations had been US military officiers during world war two. at issue was that the US going into the war lacked a large trained professional army ... they were turning out 90 day wonders (and some cases large groups of cannon fodder). In order to deal with the lack of experience, the military created a very rigid & top heavy management structure with decisions made as high as possible and lower echelons expected to follow tatical directions to the letter with no latitude for deviation.
He contrasted the german military that was 3% officers and a large professional army with the US that had 15% or so officers. The german military (as an organization) tended to expect that the person on the scene would be making tactical decisions (contrasted with the US military in WWII that dictated little or no tactical latitude).
He predicted that US corporations were going to take some time to recover from the ingrained executive management style of these former WWII military officers.
He periodically quoted Guderian directions going into the Blitzkrieg, verbal orders only. The idea was that his men would not have to worry about post-blitzkrieg audit ... looking to place blame because somebody made a local decision that might not be 100% perfect in hindsight. The overall strategic plan was laid out and the person on the spot was expected to actively deal with tactical issues.
A possible corollary is that the only way to never make a mistake is to never do anything.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH Newsgroups: comp.software-eng,comp.programming,alt.folklore.computers Date: Tue, 09 Jan 2001 15:24:46 GMTspinoza9999 writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH Newsgroups: comp.software-eng,comp.programming,alt.folklore.computers Date: Tue, 09 Jan 2001 16:53:02 GMT& a web pointer
http://www.belisarius.com/
https://web.archive.org/web/20010722050327/http://www.belisarius.com/
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Competitors to SABRE? Newsgroups: alt.folklore.computers Date: Tue, 09 Jan 2001 22:22:52 GMTdon@news.daedalus.co.nz (Don Stokes) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where do the filesystem and RAID system belong? Newsgroups: comp.arch Date: Tue, 09 Jan 2001 23:28:02 GMTGreg Pfister writes:
in the 80s, there was study done by some companies with significant (absolute) dependencies on their data processing operations. A major data processing disaster that had the facility out of commission for a week would bankrupt the company. cost for a duplicate data processing facility would be less than one week's business (in the case of one company, 24hrs profit covered lease for 50story building for a year and all the salaries of people working in the building, plus the data processing center ... and the business totally was dependent on its data processing center).
The geographic distance that the study quoted (for geographic survivability) was somewhere between 40 and 45 miles (significant "problems" very rarely found to span more than a 40 mile diameter). You did have to pay attention to telco center, power feeds & the like.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Competitors to SABRE? Newsgroups: alt.folklore.computers Date: Tue, 09 Jan 2001 23:46:24 GMTEric Sosman writes:
As an aside, with year at 365x24=8760hrs, 800K hr MTBF is 100 years. The number now is less of a factor for any particular user/drive and more of a factor in calculating the percentage of drives that will fail under warranty and have to be replaced.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where do the filesystem and RAID system belong? Newsgroups: comp.arch Date: Tue, 09 Jan 2001 23:56:01 GMTlindahl@pbm.com (Greg Lindahl) writes:
http://smithae.com/optima.html
https://web.archive.org/web/20021010110155/http://www.smithae.com/optima.html
http://www.optimabatteries.com/main.htm
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where do the filesystem and RAID system belong? Newsgroups: comp.arch Date: Wed, 10 Jan 2001 14:53:39 GMTPaul Repacholi writes:
random ref to a large clustered data center in CA that then replciated
in Dallas and Boulder because of concerns related to CA properties
https://www.garlic.com/~lynn/2001.html
https://www.garlic.com/~lynn/2000g.html#14
https://www.garlic.com/~lynn/2000g.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Competitors to SABRE? Newsgroups: alt.folklore.computers Date: Wed, 10 Jan 2001 17:53:14 GMTEric Sosman writes:
i started noticing the disk problem in the late 70s. following is some comparisons of the issues from the early 80s (predating some of the common RAID studies) and leading to stripping, arm optimization, load balancing, etc.
random refs:
https://www.garlic.com/~lynn/95.html#8
https://www.garlic.com/~lynn/95.html#9
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Competitors to SABRE? Newsgroups: alt.folklore.computers Date: Thu, 11 Jan 2001 00:13:20 GMTEric Sosman writes:
however, at 800k MTBF for disk drives ... disk drives (and in fact much of other hardware components) hardware failures as starting to become only a minor component of availability statistics for a service.
following is minior reference to large financial server that has 100%
availability for over six years
https://www.garlic.com/~lynn/99.html#71
i.e. what percent improvement in system availability does RAID provide ... or is it now such a trivial cost that it is hardly worth trying to analyse the cost/benefit ratio.
from a performance standpoint ... in the early '80s we actually worked on a controller microcode enhancement that would limite data capacity that could be placed under any specific arm ... as an extra charged performance feature (i.e. for shops that didn't have the discipline to do it as a policy; i.e. sell a 3380 as only being able to hold 300mbytes as opposed to full 630mbytes, and charge extra for it).
in the late '80s and early '90s actually did some work on "qualifying" raid drives with regard to availability. there were surprising number that had to be "fixed" because some really anomolous failure mode was overlooked (i.e. given all possible states that the RAID could be in, were all immune if a power failure happened to occur at that particular moment).
some of this I somewhat kicked off in the disk behavior thread running
in comp.arch & comp.arch.storage with the following
https://www.garlic.com/~lynn/2000g.html#43
https://www.garlic.com/~lynn/2000g.html#44
https://www.garlic.com/~lynn/2000g.html#47
https://www.garlic.com/~lynn/2001.html#6
a problem that I actually worked on a couple years ago that cost quite of bit money was a clustered configuration with (operating system provded device level) software mirroring using independent controllers and series of independent disks. It was a large production data base on multiple drives. At one point there was a problem in one of the controllers which had to be serviced by the manufactur, which replaced the controller. Part of the administrative process wasn't completed and the serial id for the controller wasn't entered into the operating systems registry. As a result, when the operating system booted, it didn't recognized the controller and issued a cryptic, undeciferable message. Since this was operating system level, device level mirroring, it was masking all errors (like being unable to write to the mirrored copy). Sometime later one of the drives connected to the "good" controller had a problem ... which also happened to be the drive containing the database data dictionary & logs. Because this was a mirrored configuration the operating system continued to do error masking because of the assumption that data was still being written to the mirror ... which it wasn't actually doing because the mirrored controller wasn't in the registry. It took the DBMS another couple hrs to actually fail ... and by that time the disks were in terrible inconsistent state.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Life as a programmer--1960, 1965? Newsgroups: alt.folklore.computers Date: Thu, 11 Jan 2001 16:30:20 GMT"Mike" writes:
the higher performance 370 machines had quite a time constantly checking the instruction decode pipeline to see if there was a modification done to some instruction (alrady in the pipeline) by an operations further up the pipeline. this tends to still exact a performance penalty either in terms of performance slow-down or lots of extra circuits to constantly check for the possibility.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk drive behavior Newsgroups: comp.arch Date: Thu, 11 Jan 2001 16:41:06 GMT"Bill Todd" writes:
However, allowing the record(s) to migrate as addenda to the distributed locking messages tends to introduce a huge amount of complexity because of the log merge problem during recovery (considering all possible failure modes). Fine-grain timer synchronization across all ndoes in the cluster helps ... or some form of monotonically increasing virtual timer.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where do the filesystem and RAID system belong? Newsgroups: comp.arch Date: Thu, 11 Jan 2001 17:07:00 GMT"Aaron R. Kulkis" writes:
i thot i remember seeing some reference to half of the federal disaster flood insurance each year goes to the state of mississippi(?). it was in conjunction with observation about each year after the flood (& after previouly having rebuilt on flood plain) ... the individuals claim that they had no idea that there would be flood (and this has been going on for as many years as there has been federal disaster flood insurance).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where do the filesystem and RAID system belong? Newsgroups: comp.arch Date: Thu, 11 Jan 2001 17:22:00 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Life as a programmer--1960, 1965? Newsgroups: alt.folklore.computers Date: Thu, 11 Jan 2001 18:18:12 GMTEric Chomko writes:
one of the successes of 360 (& various other mainframes) wasn't about the ease or difficulty of batch for program development but the predictability and reliability of batch for production work, like payroll checks, bill statements, etc. (nuts & bolts of corporations) ... a factor that continues today (the systems weren't necessarily targeted for program development &/or people use ... they were targeted for executing corporate business processes).
while people may prefer to use interactive system, many would loadly complain if some of the services they consider basic bread & butter became less predictable because of larger reliance on direct human element (this even extends to webserver domain ... batch based systems tend to have more built in facilities for automagically handling all the details).
even in batch sysetms, the "operator" (human element) is now being identified as one of the major failure modes. One of the large financial services identified automated operator as one of the two major factors in them having 100% availability for the past several years.
random ref:
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/99.html#18
https://www.garlic.com/~lynn/2000f.html#53
https://www.garlic.com/~lynn/99.html#4
https://www.garlic.com/~lynn/99.html#51
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Options for Delivering Mainframe Reports to Outside Organizat ions Newsgroups: bit.listserv.ibm-main Date: Thu, 11 Jan 2001 18:31:37 GMTJoseph.Wenger@CA.COM (Wenger, Joseph) writes:
A lot of AFS (along with DFS, NFS, and Locus) feed into the OSF distributed file system work. Locus might be considered one of the original enterprise file system (basis for aix/370/ps2 in the past).
random refs:
https://www.garlic.com/~lynn/2000c.html#0
https://www.garlic.com/~lynn/2000e.html#27
https://www.garlic.com/~lynn/2000.html#64
https://www.garlic.com/~lynn/99.html#2
https://www.garlic.com/~lynn/99.html#63
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what is UART? Newsgroups: comp.arch Date: Thu, 11 Jan 2001 18:48:19 GMT"dannynews" writes:
Universal Asynchronous Receiver/Transmitter. This is a device in a computer or modem that will change serial data (the way data comes in over the phone line) to parallel, and vice versa.
......
COM port is something that the software addresses ... buried deep down inside the hardware associated with a COM port can be a UART chip.
Earlier generation of machines, UART function were performed by something called line-scanners.
random ref:
https://www.garlic.com/~lynn/2000c.html#36
https://www.garlic.com/~lynn/2001.html#5
https://www.garlic.com/~lynn/2001.html#17
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Small IBM shops Newsgroups: bit.listserv.ibm-main Date: Thu, 11 Jan 2001 18:54:58 GMTeheman@VNET.IBM.COM (Gary Eheman) writes:
I haven't done much work in the FCS standards area for some time, but I can remember lots of churn going on that effectively looked like somebody trying to map various bus&tag half-duplex conventions at the FCS3/4 layer.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What is wrong with the Bell-LaPadula model? Orange Book Newsgroups: comp.security.misc Date: Thu, 11 Jan 2001 19:12:35 GMTbcahillcissp writes:
definition that I happened to have handy ( see rest of
references/definitions at: https://www.garlic.com/~lynn/secure.htm,
this one is from rfc2828):
Bell-LaPadula model
(N) A formal, mathematical, state-transition model of security policy
for multilevel-secure computer systems. (C) The model separates
computer system elements into a set of subjects and a set of
objects. To determine whether or not a subject is authorized for a
particular access mode on an object, the clearance of the subject is
compared to the classification of the object. The model defines the
notion of a 'secure state', in which the only permitted access modes
of subjects to objects are in accordance with a specified security
policy. It is proven that each state transition preserves security by
moving from secure state to secure state, thereby proving that the
system is secure. (C) In this model, a multilevel-secure system
satisfies several rules, including the following:
'Confinement property' (also called '-property', pronounced 'star property'): A
subject has write access to an object only if classification of the object
dominates the clearance of the subject.
'Simple security property': A subject has read access to an object only if the
clearance of the subject dominates the classification of the object.
'Tranquillity property': The classification of an object does not change while the
object is being processed by the system.
[RFC2828] (see Bell-LaPadula security model) (see also confinement property, simple
security property, tranquillity property, security model) (includes -property, lattice
model)
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Competitors to SABRE? Newsgroups: alt.folklore.computers Date: Thu, 11 Jan 2001 20:17:39 GMTEric Smith <eric-no-spam-for-me@brouhaha.com> writes:
I once saw something that looked a little like a lathe with 500 5.25in (high-density?) floppy disks all pressed together & spinning. an access arm would travel horizontally and when it got to the target floopy, it blew compressed air to create gap between the floppies and the r/w qhead would insert into the gap. I'm pretty sure it never made it out of the lab.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Options for Delivering Mainframe Reports to Outside Organizat ions Newsgroups: bit.listserv.ibm-main Date: Thu, 11 Jan 2001 21:47:59 GMTkpneal@POBOX.COM (Kevin P. Neal) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What exactly is the status of the Common Criteria Newsgroups: comp.security.misc Date: Thu, 11 Jan 2001 22:06:00 GMTbcahillcissp writes:
by comparison, common criteria supports protection profile definitions for specific environments ... for instance there are smartcard protection profiles, firewall protection profiles, certification authority protection profiles, etc, i.e. rather than generic operating system support for high assurance, protection profile definitions can take into account the overall environment, including compensating processes at application or possibly business level.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Competitors to SABRE? Newsgroups: alt.folklore.computers Date: Fri, 12 Jan 2001 16:03:25 GMTjchausler writes:
datacell was more like a washing machine with tub partitioned into ten cells. each cell held strips. the tub rotated around to position the desired cell and then the desired magnetic strip would be "picked" out of the cell (i.e. strip was moved to the read/write head ... not the read/write head moving to the strip, the air flow trick was suppose to help get the strip pushed back down inside the cell). one of the failure modes was pushing/dropping the strip back down into the cell ... if it didn't align ... the strip would "accordion" and have to be replaced. ipl'ing the machine had this rythmic kachunk, kachunk, whirl sound ... as the device/cell label strip was read out of each data cell, put back in and then rotated to the next cell.
IBM 360 "disk seek" ccw op has had addressing BBCCHHR ... i.e. bin, bin, cylinder, cylinder, head, head, record ... the bin/bin was for selecting the 2321 cell/bin number (two bytes for bin, two bytes for cylinder, two bytes for head, and one byte for record).
university i was at had data cell. part of library automation project funded by navy research (ONR). we also got to be betatest site for CICS ... 2nd half of '69. I got to shoot various bugs to get it up and operational.
random refs:
https://www.garlic.com/~lynn/2000.html#9
https://www.garlic.com/~lynn/2000b.html#41
https://www.garlic.com/~lynn/2001.html#17
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH Newsgroups: comp.software-eng,comp.programming,alt.folklore.computers Date: Fri, 12 Jan 2001 17:29:12 GMTcjsonnack@mmm.com (Programmer Dude) writes:
fortran g compile was compile fortran program generate a "text"
(i.e. binary) deck written to disk ... for some of the format for such
a deck:
https://www.garlic.com/~lynn/2001.html#8
https://www.garlic.com/~lynn/2001.html#14
link-edit would read the "text" deck and combine it with any library programs (like fortran libraries, scientific subroutine library, MPX library, etc), resolve external symbols, etc and write it back out to disk in "load module" format. link-edit would also be used to generate program libraries. there were 3(?, maybe 4) different versions of link/edit. link/edit was so complicated that it normally didn't all fit in memory at once ... so it had program phases that overlayed each other. The different versions tended to be how the overlays were organized & the minimum memory that they could operate in.
during "go" (program execution) it was possible to dynamically call program load to bring in additional program libraries.
"go" (load) would bring the load module back into memory, update any address constants, etc. and begin program execution.
a FORTG (one step) reference:
https://www.garlic.com/~lynn/94.html#18
because the job scheduler was so expensive for each step .. there was a lighweight "loader" developed that did the link/edit & go in a single step.
Then there were various lightweight monitors that called fortran g compile and then the loader ... in a single step ... effectively piping the output from one into the input of the other.
Then of course WATFOR came along ... which was a fortran compile & execution environment ... i.e. it generated very fast psuedo code and then executed it directly.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk drive behavior Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.storage,comp.arch.storage Date: Fri, 12 Jan 2001 20:50:11 GMTDefault <the-funny-thing-is--and-I-have-this-from-a-reliable-source--spammers-do-not-like-long-addresses@o-o.yi.org> writes:
in the 60s ... i initially carefully placed almost all system data on disk and saw significant thrput enhancement ... avg. arm latency was reduced by careful placement of data ... and got 60-70% reduction in elapsed time.
misc. refs:
https://www.garlic.com/~lynn/2001.html#26
https://www.garlic.com/~lynn/94.html#18
I then replaced FIFO arm scheduler with a very simple minded ordered seeek arm scheduler. This had the effect that as workload increased (in terms of concurrent tasks/users), the rate that individual tasks slowed down was raduced and the peak, sustained I/O rate per arm increased. The degree that different queuing algorithms differ is going to be to the degree that there is multiple concurrent requests in the queue and how they go about re-ordering the sequence that they are executed. If there is only one or two concurrent requests in the queue, there will be little or no difference between algorithms in the order that the requests get executed.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FBA History Question (was: RE: What's the meaning of track overfl ow?) Newsgroups: bit.listserv.ibm-main Date: Fri, 12 Jan 2001 23:37:01 GMTFarleyP@BIS.ADP.COM (Farley, Peter x23353) writes:
random refs:
https://www.garlic.com/~lynn/97.html#16
https://www.garlic.com/~lynn/97.html#29
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FBA History Question (was: RE: What's the meaning of track overfl ow?) Newsgroups: bit.listserv.ibm-main Date: Fri, 12 Jan 2001 23:54:34 GMTi even tried using the argument that over the next 20 years (i.e. by at least 2000) that as they moved from CKD to FBA they would much more than make up the FBA costs by not having to do a whole lot of questionable acts to enhance CKD. Part of it was based on experience trying to remote disks and provide various enhanced services as described/referenced in some of the HYPERchannel work with remote device adapters:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 3390 capacity theoretically Newsgroups: bit.listserv.ibm-main Date: Sat, 13 Jan 2001 00:02:38 GMTroberto_ibarra@PISSA.COM.MX (Roberto Ibarra) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 3390 capacity theoretically Newsgroups: bit.listserv.ibm-main Date: Sat, 13 Jan 2001 00:07:31 GMTAnne & Lynn Wheeler writes:
yotta [Y] 1 000 000 000 000 000 000 000 000 = 10^24 zetta [Z] 1 000 000 000 000 000 000 000 = 10^21 exa [E] 1 000 000 000 000 000 000 = 10^18 peta [P] 1 000 000 000 000 000 = 10^15 tera [T] 1 000 000 000 000 = 10^12 giga [G] 1 000 000 000 (a thousand millions = a billion) mega [M] 1 000 000 (a million) kilo [k] 1 000 (a thousand) hecto [h] 100 deca [da]10 1 deci [d] 0.1 centi [c] 0.01 milli [m] 0.001 (a thousandth) micro [µ] 0.000 001 (a millionth) nano [n] 0.000 000 001 (a thousand millionth) pico [p] 0.000 000 000 001 = 10^-12 femto [f] 0.000 000 000 000 001 = 10^-15 atto [a] 0.000 000 000 000 000 001 = 10^-18 zepto [z] 0.000 000 000 000 000 000 001 = 10^-21 yocto [y] 0.000 000 000 000 000 000 000 001 = 10^-24--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disk drive behavior Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.storage,comp.arch.storage Date: Sat, 13 Jan 2001 16:23:04 GMTAnne & Lynn Wheeler writes:
the big benefit of simple elevator algorithm under heavy load (lots of concurrent work and long queues) is that drive could reach to 40-50 disk I/Os per second (instead of 25-30). these were 800byte to 4k byte transfers where arm latency dominated compared to transfer time and rotational delay (majority of disk service time was spent in moving the arm, so any decrease in avg. arm movement time had proportionally larger affect on total request service time).
the one caveate in all this was a service delay algorithm that I saw go into effect at large cal. financial institution in the late '70s. The claimed they measured higher transaction thruput running custom code on 370/158 than sabre/acp/tpf on 370/168. They had lots of lightweight transactions with relatively predictable execution patterns.
When a new transaction request arrived, if the current disk arm position was further than some distance from the disk location containing the transaction data; the new transaction could be delayed until 1) the arm moved closer to transaction's target location, 2) a sufficient number of other requests had arrived requiring the arm to be in the same disk locality, or 3) maximum number of delay time had elapsed. The algorithm had a tendency to burst/batch process sets of transactions with similar disk arm locality (it also was controlled by the avg. load at the moment, delaying wouldn't occur if system load was relatively light and the probability was low that other requests would arrive before the max. delay interval had expired).
This particular transaction load thruput was totally dominated by disk arm motion (i.e. by comparison cpu utilization, data transfer, etc were all trivial).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Review of Steve McConnell's AFTER THE GOLD RUSH Newsgroups: comp.software-eng,comp.programming,alt.folklore.computers Date: Sun, 14 Jan 2001 17:03:18 GMTjmfbahciv writes:
humans can use word processor to edit a program. however, i also know of lots of cobol code that is referred to "edit" ... which is doing automated validation of keypunched and/or typed information by humans (i.e. the human isn't doing the editing, automated program is edit/validate what the human has typed). This can include consistency/sanity checks ... like does the city/state correspond to the zip-code.
in the following, main stroage can be disk. program library can be a newly created file containing only the one load module which is passed to a "GO" step and then deleted. "object" modules are generated by compilers (and possibly other things) in addition to assemblers.
attached from glossary in IBM High Level Assembler Release 4
Installation & Customization Guide (sep. 2000):
linkage editor. A program that resolves crossreferences between
separately assembled object modules and then assigns final addresses
to create a single relocatable load module. The linkage editor then
stores the load module in a program library in main storage.
linkedit. To create a loadable computer program by means of a linkage
editor.
load module. An application or routine in a form suitable for
execution. The application or routine has been compiled and
linkedited; that is, address constants have been resolved.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH) Newsgroups: comp.software-eng,comp.programming,alt.folklore.computers Date: Mon, 15 Jan 2001 02:48:57 GMT"G Swaine" writes:
360 defined ebcdic which allowed 256 punch combinations ... i.e. eight-bit value in a col.
the 360 object cards (output of compilers, assemblers, etc) that contained actual machine instructions were 12-2-9TXT cards i.e. they had 12-2-9/x'02' punched in col.1 and TXT in cols 2-4).
col 1 12-2-9 / x'02' 2-4 TXT 5 blank 6-8 relative address of first instruction on record 9-10 blank 11-12 byte count ... number of bytes in information field 15-16 ESDID 17-72 56-byte information field 73-80 deck id, sequence number, or bothin the 360 assembler, the first TITLE statement with a non-blank name field would place that name field in cols 73-80 of all ouput object cards/records.
following refs has discussions of several object file formats (unix a.out,
ms-dos exe, unix elf, microsoft portable executable, coff, omf)
http://www.iecc.com/linker/linker03.html
http://compilers.iecc.com/comparch/article/93-08-117
random refs:
https://www.garlic.com/~lynn/2001.html#14
https://www.garlic.com/~lynn/2001.html#59
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where do the filesystem and RAID system belong? Newsgroups: comp.arch Date: Tue, 16 Jan 2001 15:40:21 GMTlindahl@pbm.com (Greg Lindahl) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: California DMV Newsgroups: alt.folklore.computers Date: Tue, 16 Jan 2001 17:30:52 GMTbbreynolds@aol.comskipthis (Bruce B. Reynolds) writes:
misc. comments
I was at university in '69 and we were (a?) betatest site for CICS, I got to do various support and debugging on it.
Series/1 had two infrastructures/systems ... "official" one from Boca ... RPS (joke that it was some transplanted IBM Kingston engineers that were trying to re-invent OS/MFT on 16-bit mini) and EDX (event driven executive) that was done by some grad. students at San Jose Research for the physics department ... EDL was part of the EDX infrastructure (not aware of DMV with something else also called EDL). The S/1 stuff would have been mid-70s, not 60s.
there were competitive benchmarks for DMV infrastructure of both Tandem and IBM equipment in 1988 and 1989.
newsclip from San Jose Mercury News, 16 Oct 89
Tandem prepares to enter a new stage of competition with IBM
- savors a decisive victory in a head-to-head showdown with IBM
- California Department of Motor Vehicles
. DMV is one of the largest state agencies anywhere
. heavily reliant on computers
. closely watched by many other prospective purchasers
. Used IBM computers to maintain its huge databases for 20 years
- 30 million vehicles
- 20 million driver's licenses
- 900,000 transaction by officials/law enforcement daily
- Laura Gruber, overseeing a project to modernize DMV databases
. 1986: $40 million project to modernize hardware/software
. "system is nearing the end of its life cycle"
. 1988: DMV narrowed it to 2 vendors; IBM and Tandem
. 3-1/2 months of testing by DMV
- IBM 3090-400S passed only 2 of 10 tests
- Tandem 2-VLX passed 9 of 10 tests (failed one)
- IBM senior managers "were aghast" at the results
. "They don't know how to deal with the awesome disparity"
- Tandem executives
. Before the test, were confident they would beat IBM
. But they didn't expect such a decisive outcome
. "We not only surprised the world, we surprised ourselves"
"If the tests were repeated today, the findings would be much more lopsided."
- Tandem used 2 VLX computers, introduced in April 1986 for the tests
- Cyclone, introduced today,
"is 3-5 times more powerful than the VLX models that trounced
IBM's workhorse mainframe"
- Contract negotiated by the agency requires Tandem to supply its top model
. As of now, that's Cyclone
. Agency has taken delivery of one VLX
. Has begun to develop software for the new system
Tandem, formed in 1974
- specialized on highly reliable, fault tolerant computers
for online transaction processing
. continuous operation
. fast, frequent updates to data bases
- New York Stock Exchange
. Keeps track of securities trading
. Has used Tandem for years
. Served as a test site for Cyclone
. Cyclone was an outgrowth of the Exchange's difficulty in handling
enormous volumes of trades during the market crash 2 years ago
- Trade volume exceeded 600 million shares, Oct 19, 1987
- Stock Exchange immediately began planning for a computer
system to handle a 1-billion share day
- Gerald L Peterson, Tandem senior VP for sales/marketing
. "We locked ourselves in a room for 6 weeks,
and made some very basic decisions about our product strategy."
. Many computer companies were moving toward increased reliance
on workstations and PCs
. There was a lot of feeling that workstations would take over
the world ... high-end systems would go down the tubes
. They concluded the computer business was heading in 2 directions
- Large corporate customers were consolidating databases
and putting work stations on the desk top ... simultaneously
- They decided to go after the very large databases
and provide tools for connecting to workstations
- Most large databases were designed 15-20 years ago
. reside on traditional mainframe computers
. ill-suited for transaction processing
. companies are looking for fast access to their data
- If Tandem was going to be in that business,
. they needed a big machine
. they had to confront IBM, which has dominated that market
. Tandem adjusted its requirements for Cyclone
- to handle many of the traditional mainframe jobs
- still being primarily suited for online transactions
. "Competing so directly against IBM mainframes is pretty scary,
but when you think about it, there's no place you can hide
today from IBM."
. "Besides, we've been taking business away from IBM for years ...
we're used to it."
. "We've been marching up that hill for years"
. "Our sales force has always had very good weapons,
now we're going to give them an atomic bomb."
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Are the L1 and L2 caches flushed on a page fault ? Newsgroups: comp.arch Date: Tue, 16 Jan 2001 21:16:50 GMTkarthik_p writes:
the introduction of the 168-3 did have a problem. 370 architecture supported both 2k & 4k pages (based on mode bit for whole address space). Normal "high-end" operating systems used 4k pages ... some of the lower-end 370 operating systems used 2k pages. One of the features of the 168-3 (compared to the original 168) was it doubled the size of cache ... and used the "2k" bit to index the additional entries and the 168-3 was operating in 2k-page mode, only half of the cache was active. The other characteristic was that whenever a switch occurred between 2k-page mode and 4k-page mode ... the complete cache was flushed.
Many environments tended to only run in one more or another. However, some customer installations had tasks which intermixed 2k-page virtual memory and 4k-page virtual memory ... and any time a task switch occurred involving different modes, the complete cache was flushed. These customers experienced a noticeable performance degradation upgrading from 168-1 to a 168-3 (with twice the cache size). The additional cache was only available for select subset of the workload ... but there was a very expensive complete cache flush that could occur at task switch.
following from:
https://web.archive.org/web/20010218005108/http://www.isham-research.freeserve.co.uk/chrono.txt
Product
or Event Ann. FCS Description
IBM S/370 ARCH. 70-06 71-02 08 EXTENDED (REL. MINOR) VERSION OF S/360
IBM S/370-155 70-06 71-01 08 LARGE S/370
IBM S/370-165 70-06 71-04 10 VERY LARGE S/370
IBM S/370-145 70-09 71-08 11 MEDIUM S/370 - BIPOLAR MEMORY - VS READY
AMH=AMDAHL 70-10 AMDAHL CORP. STARTS BUSINESS
IBM S/370-135 71-03 72-05 14 INTERMED. S/370 CPU
IBM S/370-195 71-07 73-05 22 V. LARGE S/370 VERS. OF 360-195, FEW SOLD
Intel, Hoff 71 Invention of microprocessor
IBM 168 72-08 73-08 12 VERY LARGE S/370 CPU, VIRTUAL MEMORY
IBM OS/VS1 72-08 73-?? VIRTUAL STORAGE VERSION OF OS/MFT
IBM OS/VS2(SVS) 72-08 72+?? VIRTUAL STORAGE VERSION OF OS/MVT
Intel DRAM 73 4Kbit DRAM Chip
IBM 168-3 75-03 76-06 15 IMPROVED MOD 168
IBM 3033 77-03 78-03 12 VERY LARGE S/370+EF INSTRUCTIONS
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Are the L1 and L2 caches flushed on a page fault ? Newsgroups: comp.arch Date: Tue, 16 Jan 2001 21:27:39 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: California DMV Newsgroups: alt.folklore.computers Date: Tue, 16 Jan 2001 23:40:35 GMTklatteross@aol.commmm (Ross Klatte) writes:
minor correction ... ibm mainframes would tend to be mostly cobol & bal/assembler (aka machine language). EDL/EDX was run on the series/1 minicomputer. There aren't many series/1s around any more. Last one I actually saw was five years ago that was a telecommunications interface into the mastercard network.
While the mainframes went thru many generations with backward compatibiilty from the mid-60s to the current day ... I would expect any series/1 that were still around were manufactured 15-20 years ago.
i did search on series/1 ... turned up a lot of resumes ... but a couple
others ..
http://www.rs6000.ibm.com/resource/pressreleases/1998/Jul/datatrend.html
http://www.migsol.com/edx.htm
http://www.rit.edu/~kjk2135/RTOS.htm
http://www.dtrend.com/app_migration.html
... as to the previous bomb reference ... it might have referred to the ability to convert a customer base that was/is firmly entrenced in their devotion to mainframes.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what is interrupt mask register? Newsgroups: comp.arch Date: Wed, 17 Jan 2001 15:40:21 GMT"dannynews" writes:
the 360/67 introduced the concept of channel controller and consolidated channels across all processors in a multiprocessor (two to four) configuration. the 360/67 aloo introducted "control registers" to contain additional control information (like virtual memory segment table pointer) not available in the basic 360 machines. in order to accommodate each processor being able to address up to 47 i/o channels, the i/o channel interrupt masks were moved from the PSW to one of the control registers and the seven i/o interrupt mask bits in the PSW redefined. One of the redefined bits was to mask off all i/o interrupts. If the PSW I/O interrupt mask bit was enabled then the processor would use the selective channel i/o mask bits to determine whether or not to present i/o interrupt from that specific channel.
the 67 also had extended external interrupts and machine checks. the corresponding bits in the psw became summary masks (for all classes) and the detailed masks for specific external and machine check interrupts were moved into one of the control registers.
the 360/67 put a psw-mode bit into one of the control registers. on power/on/reset, the psw-mode bit default to standard 360 psw. changing the control register psw mode bit switched the psw mode format from standard to (67) extended.
the other four interrupt masks (fixed point overflow, decimal overflow, exponent underflow, and significant) stayed in the PSW.
360/67 was one of the later 360s, not announced until aug. of 65 and started shipping june of '66.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: future trends in asymmetric cryptography Newsgroups: sci.crypt Date: Wed, 17 Jan 2001 16:01:44 GMTrasane_s writes:
several process scenerios have been looked at that once two entities establish some sort of (business or other) relationship, that certificates for the purpose of establishing some level of reliance between two parties become redundant and superfluous ... especially with respect to online electronic transactions that might involve timely and/or aggregated information (compared to stale &/or privacy information bound into certificates).
there has been a mapping of the recently passed account-based secure payment objects standard to an account-based public key authentication process (as opposed to a certifcate-based public key authentication process).
misc. refs at
https://www.garlic.com/~lynn/
https://www.garlic.com/~lynn/8583flow.htm
http://lists.commerce.net/archives/ansi-epay/200101/msg00001.html
https://web.archive.org/web/20020225043356/http://lists.commerce.net/archives/ansi-epay/200101/msg00001.html
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: California DMV Newsgroups: alt.folklore.computers Date: Wed, 17 Jan 2001 16:18:50 GMTbbreynolds@aol.comskipthis (Bruce B. Reynolds) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what is interrupt mask register? Newsgroups: comp.arch Date: Wed, 17 Jan 2001 21:53:42 GMTKonrad Schwarz writes:
control register 6
bits 0 1 ----- 0 0 only CPU machine checks will be recognized 0 1 cpu and channel controller 1 machine checks will be recognized 1 0 cpu and channel controller 0 machine checks will be recognized 1 1 all machine checks will be recognisedCPU and channel controllers were independent processors sitting on the memory bus ... any of them could indicate machine check.
also in CR6 were bits 26, 27, 28, 29 ... for masking external signals 2-7 indicating specific CPU malfunction alert.
i.e. control registers were processor specific ... so a processor could enable/disable malfunction alerts from other processors ... and/or once it was determined that a specific processor was no longer usable and/or active turn off getting any additional malfunction alerts from that machine.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what is interrupt mask register? Newsgroups: comp.arch Date: Wed, 17 Jan 2001 23:40:50 GMTcecchi@signa.rchland.ibm.com (Del Cecchi) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what is interrupt mask register? Newsgroups: comp.arch Date: Thu, 18 Jan 2001 16:01:46 GMTKonrad Schwarz writes:
when i was an undergradudate, a couple of us were building a 360 control unit replacement which required building a card that interfaced/attached to the 360 channel (somewhere this effort is documented as originating the 360 OEM control unit business ... oem - other equipment manufactur). the cpu and channels shared the memory bus. one of the other things that was on the memory bus was the location 50 "timer" ... i.e. 32bit word at location x'50' in low-storage. the timer would tic every 13.? microseconds (this was high-resolution timer on 360/67, the lower-end machines had timer that tic'ed less frequently) and attempt to update the value at location x'50'. if the timer tic'ed again before it was able to obtain the memory bus to update location x'50' from the previous tic ... the machine would red-light/check-stop.
one of the problems that we caused when we were testing our board was holding the memory bus for two consecutive timer tics ... w/o freeing the memory bus to allow other accesses.
random refs:
https://www.garlic.com/~lynn/99.html#12
https://www.garlic.com/~lynn/2000c.html#36
https://www.garlic.com/~lynn/2001.html#5
...............
conditions that would cause machine check interrupt and store
indication code (from system/360 model 67 reference data "blue card"
229-3174):
more than one associative register contains identical information, or
one of the comparing circuits is at fault (67 had a fully associative
table look aside buffer for virtual address lookup)
a successful compare is achieved with a virtual address that is higher
than the address in the segment table
the virtual address portion of the translated address just stored in
the associative array does not compare with the virtual address that
should have been stored
a reset of the load-valid bits in the associative array was
unsuccessful
parity of the adder sum is inconsisten with the predicated parity
parity of the virtual address was incorrrect when received by the
associative array
parity of the data word from storage was incorrect when received by
dynamic address translation circuity
parity of instruction bits 8-15 was incorrect when received by dynamic
address translation circuitry
..............
reference to esa/390 principle of ops (don't know of anyplace that has
a 360 principle oof ops online):
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/CONTENTS?SHELF=#A%2e6%2e2
chapter 11 on machine-check handling
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/11%2e0
11.4 check-stop state
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/11%2e4?SHELF=
from above:
In certain situations it is impossible or undesirable to continue
operation when a machine error occurs. In these cases, the CPU may enter
the check-stop state, which is indicated by the check-stop indicator.
In general, the CPU may enter the check-stop state whenever an
uncorrectable error or other malfunction occurs and the machine is
unable to recognize a specific machine-check-interruption condition.
The CPU always enters the check-stop state if any of the following
conditions exists:
PSW bit 13 is zero, and an exigent machine-check condition is
generated.
During the execution of an interruption due to one exigent
machine-check condition, another exigent machine-check condition is
detected.
During a machine-check interruption, the machine-check-interruption
code cannot be stored successfully, or the new PSW cannot be fetched
successfully.
Invalid CBC is detected in the prefix register.
A malfunction in the receiving CPU, which is detected after accepting
the order, prevents the successful completion of a SIGNAL PROCESSOR
order and the order was a reset, or the receiving CPU cannot determine
what the order was. The receiving CPU enters the check-stop state.
(c) copyright IBM corp.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: California DMV Newsgroups: alt.folklore.computers Date: Fri, 19 Jan 2001 04:19:24 GMTjsaum@world.std.com (Jim Saum) writes:
random refs.
https://www.garlic.com/~lynn/99.html#70
https://www.garlic.com/~lynn/99.html#67
https://www.garlic.com/~lynn/2000b.html#66
https://www.garlic.com/~lynn/94.html#33a
https://www.garlic.com/~lynn/99.html#12
https://www.garlic.com/~lynn/2000c.html#36
https://www.garlic.com/~lynn/2001.html#5
https://www.garlic.com/~lynn/2000c.html#43
https://www.garlic.com/~lynn/94.html#33b
https://www.garlic.com/~lynn/2001.html#71
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: how old are you guys Newsgroups: alt.folklore.computers Date: Fri, 19 Jan 2001 15:24:55 GMTroggblake@inamme.com (Roger Blake) writes:
To: cohrs-arch@media-lab.media.mit.edu Subject: ccir info 5sep90, draft 25aug90 (part 1 of 2) TO: US CCIR Study Group 11, Interim Working Party 11/9 FROM: Architecture Working Group (Chair: Gary Demos) Committee On Open High Resolution Systems DATE: 5 September 1990 SUBJECT: Considerations for Cross Industry Harmonization of HDTV/HRS As an informal group of professionals working in the computer, broadcasting, imaging and entertainment industries, we are highly supportive of recent CCIR initiatives to harmonize technical standards for high resolution/high definition television systems across industries. Concurrent with these CCIR developments, we too have been studying the technical questions that would facilitate the growth of cross-industry HRS/HDTV. Out of that experience, we offer the attached submission as an appropriate set of issues for IWP 11/9 to consider. The list is by no means complete and likely will need refinement in light of future consideration. I. Scalable High Resolution Systems Issues A. List of industries which could benefit from compatible HDTV/HRS system architectures. B. List of current and possible future applications of HDTV/HRS across industries. C. Design criteria, common parameters, and requirements in order for HDTV/HRS to operate across industries and applications. Design criteria are not meant necessarily to be absolute constraints, but rather to offer a starting point for deliberations and a measure of the results of the deliberations. A list of criteria might include:--
o application to film and video post production o application to computer workstations and personal computers o transmission/distribution through (and among) terrestrial broadcast (6 MHz), cable, satellite, fiber, computer networks, videotape, videodisk, theatrical release, etc. o down conversion to NTSC, PAL, and SECAM o high-quality flicker-free viewing in various environments (e.g., viewing distance, angle, lighting) o handling of still frame images The demands of different industries and applications vary. For example, some industries use imaging which is not spatially bandwidth limited, including computer displays containing text, windows, and graphics. Flicker rates higher than 70 Hz may be required for such imagery when displayed on CRT displays while active matrix flat panel displays may be flicker-free at much lower rates. It has also been found that interlace is not acceptable on CRT computer display screens. As another example, broadcast television motion update rates for sports and other coverage may have a minimal threshold which is possibly near 45-50 Hz. D. Scalability in resolution, temporal rates, colorimetry, and intensity dynamic range, as a criteria for international standards for high resolution systems. In an ideal world, one could scale from any resolution set (vertical, horizontal, temporal) to any other resolution set with no loss in image quality, and with minimal computational cost. Unfortunately, we do not live in an ideal world. Even if we could afford arbitrary complexity of filtering hardware to scale between any two resolutions, we still incur a certain amount of information loss during the resampling process among many transcoding sets. Indeed, it may turn out that only a small set of transcoding sets exist for which the transcoding cost and information loss is minimal. Nevertheless, different industries require imaging systems across a wide spectrum of resolutions and frame rates. It is desirable that such systems easily exchange data and program material between them. This feature of interoperability is critical and the confluence of computing, telecommunications. and entertainment demands a solution. What forms should the scalable video standard take? The issue is slightly more complex than for other standards, since it is intended to be very general, to cut across many industries, and to permit other imaging standards to be subsets of it. E. Form of technical guidelines that would permit optimal scalability among members of a family of resolutions, temporal rates, colorimetry, and intensity dynamic ranges. There are many interesting and important resolutions, temporal rates, colorimetry, and intensity dynamic ranges that will not be in a transcoding set which permits maximum signal preservation with minimal computation. For example, when using certain values as a base resolution for a transcoding set (and allowing factors of two or three for fractional or whole number scaling), neither NTSC, PAL or CCIR 601 fall into the set. Two options exist for such cases. Option 1 consists of acknowledging that such sets exist, but not recommending what to do about them. Option 2 consists of providing guidelines to be used when transcoding between these sets. Option 2 guidelines might include: (a) how to scale to resolutions not in the set (i.e., what are the appropriate filtering techniques at reasonable cost), (b) a rigorous quantification of the effective resolution loss for those transcoding sets/filters, and (c) alternatives for transcoding that could minimize information loss but which modify picture organization (such as the use of border areas or side cuts). F. Planned extensibility of international standards and guidelines for these extensions for future improvements in resolutions, temporal rates, colorimetry, and intensity dynamic range. To ensure a long-lived useful standard (or family of standards) in light of rapid technological advances, it seems desirable to accommodate future resolution increases -- thus, an extensible family of resolutions, temporal rates, colorimetry, and intensity dynamic range.
For example, when transcoding an image from sampling rate A to rate B, the higher the beat frequency from A to B, or the shorter the repeat distance of the cross sampling process, the simpler the required digital processor. Also, the shorter the repeat distance of the cross sampling process, the better the perceived quality of the resulting image, particularly for image features with high spatial frequencies approaching or above the Nyquist rate (e.g., alternate black and white pels). A simple fraction rule characterizing the gross sampling ratio, such as: a/b = 2^n 3^m where n=..,-1,0,1,.. m=-1,0,1 yields filters which provide effective and convenient transcoding among signals. This produces ratios of the form of: 1/4, 1/3, 3/8, 1/2, 2/3, 3/4, 1, 4/3, 3/2, 2, etc. The ramifications of such a simple fraction rule are fundamental to digital signal processing (c.f., Nyquist, Shannon). Qualitative considerations suggest that the penalty can be very large as one departs from a simple ratio of two small numbers. It is widely known that observers tend to judge images based on the quality of the worst (as opposed to the overall average) artifacts contained. Therefore, it is reasonable to focus on the highly aliased portions of resampled images, i.e., those portions where the ramifications of the simple fraction are most critical. The testing choices here are important to make quantitative measurements meaningful. G. Qualitative and quantitative methods for choosing candidate base resolutions and temporal rates for an extensible standard. The simple fraction rule suggests the selection of a basis value for resolution and temporal rate from which can be derived an extensible compatible family. A list of criteria for selecting a basis might include: ease of constructing low cost frame buffer memories, ease of frame buffer memory addressing, ease of transcoding to international video or imaging standards, ease of converting from existing film/video libraries, ease of building cameras and production equipment, etc. Until such criteria are derived and priorities and ramifications are characterized across industries and applications, it is difficult to compare the merits of alternative basis proposals. H. Use of linear, logarithmic, quasilog, and XA-11 transfer functions in the intensity representation used for digital pixel values across industries and applications. I. Characterization of errors introduced in conversion between these different pixel representations, and guidelines for required number of bits allocated in each representation. The digital representation of pixels using linear light (lux) can give excellent results for spatial filtering operations. However, a logarithmic representation seems more appropriate at times for storage in image memories and frame buffers. In graphics arts applications, a quasilog representation is common. Thus, it is important to try to characterize a representation that is amenable for use across industries and applications. J. Merits of regional sync among multiple sources to minimize buffering and latency when accepting simultaneous signals from multiple sources. Local transmission buffering to allow vertical retrace synchronization to the nearest temporal basis rate sync time could be beneficial as a global assist for efficiency and economy. Transmission buffering at the regional repeaters for signals, such as terrestrial broadcast transmitters, cable head ends, computer interactive video sources, and network nodes, would be beneficial. It would minimize buffering at every display, and would potentially minimize latency during channel or signal source switching. Also, it would enable multiple channels to be displayed simultaneously on a single screen without full frame buffering for each channel. Certain signal sources, such as direct broadcast satellite, may not be able to synchronize regionally due to large coverage areas and inherently large propagation delays in the signal transit from satellite to receiver dish. For those sources where local interlocked sync is possible, benefits to the capability and economy of the high resolution receiving system will accrue. II. Signal, Compression, and Transcoding Issues A. Relationships between various compression techniques and potentially different requirements across industries and applications. Compression is expected to be an important part of high resolution system architectures in order to conserve storage, memory, and transmission bandwidth. Compression algorithms with a minimum of loss exist with broad applicability. High quality compression algorithms are showing continuous improvements and significant performance. Since images may be compressed and decompressed at a number of digital processing steps, compression algorithms which do not significantly degrade the image after the first compression will be useful in applications where an image must be reconstructed close to the original such as in certain post-production activities, scientific imaging, etc. B. Optimal transcoding between different compression algorithms for digital video data. The maintenance of maximum signal when a compressed digital video sequence is converted from one compression format to another needs to be considered. Since compression will be a critical component of any digital video system and interoperable systems are desired, then how to transcode in the compression domain needs to be understood as well. Signal to noise ratio (SNR) degradation when performing compression transcoding operations might be a useful metric. C. Definition of a quality space over which one can evaluate the merits of various transcoding schemes. There arm at least three metrics for evaluating the quality of compressed/transcoded imagery. These are: (1) linear information loss, such as signal-to-noise ratio (SNR) and peak signal-to-noise ratio, (2) structural information loss, such as degradation of edges or smooth surfaces, annoying quantization noise, etc., and (3) subjective and perceptual measurements. These metrics and others could form the basis for a test suite for different algorithmic approaches. D. Scalable approaches in image transmission/storage systems based on block transform and/or sub-band decompositions. High-frequency signal components can be used by receivers which have the necessary display resolution. Decoding of successively higher resolution imagery can be performed by receiver modules which increase in complexity and expense with signal bandwidth. A family of bandpass or lowpass signals transmitted by the source can greatly reduce the For example, a full resolution signal can be accompanied, without compression, by a complete set of downsampled counterparts at powers of two ratios, at only a 1/3 increase in bandwidth. The question is, by what factor is it reasonable to increase transmission bandwidth to minimize the cost of flexible reconstruction at a variety of different receivers? The answer greatly impacts the question of scalable resolution and the tactics for effecting it in the receiver. E. Relative merits of using YUV encoding with unequal channel resolutions for data reduction (as compared to RGB with equal resolution) for different applications. The eye's sensitivity to U and V resolution and brightness appears less than Y in many demonstrations. However, for the case of blond hair, flesh tones, gold lettering, or blue water, the reduced sharpness in V will often create a perceptible blur. That is, if a U or V channel is seen juxtaposed to a strong Y channel, its relative perceived information level will be higher. However, when the information is primarily contained in U or V, and these channels are isolated from changes in Y or each other, it has not yet been demonstrated that the degradation is acceptable. Also, the use of blue-screen composites or other special effects techniques may require U or V signal integrity beyond normal perceptual requirements. For these reasons further investigation of RGB formats, or other amounts of data reduction in the resolution of U and V, different from the usual 2:1 in Y, and 2:1 or 4:1 in V, might be warranted. Other color spaces are also commonly used such as Hue Saturation and Value (HSV), and Yellow, Cyan, Magenta, and Black (YCMK, used in printing). Investigation of the ramifications of conversions between different color spaces, in light of resolution differences in different color components, might be worthwhile. F. Interlace and interoperability among systems and applications. From a purely technical perspective, interlace may be viewed as a lossy form of image compression which is irreversible and prone to artifacts. Also, interlace may be less appropriate for certain applications, such as computer displays. An investigation of the difficulties which would come from an interlaced system in attempting to achieve interoperability across industries is warranted. G. The role of frame buffers in system architectures, and their affect on decoupling transmission rate, display update/refresh rate, and capture rate. Frame buffers are likely in many high resolution systems. These and other portions in the chain from image capture to image display need not necessarily operate identically, but rather may each be independently optimized. However, if links in the chain operate differently, it is potentially valuable to make each link be compatible through the chain as a family. H. The role of pre- and post-filtering in the overall design of high resolution architectures. High resolution images are typically sampled and then communicated or stored using a possibly noisy channel before being displayed. The resultant image quality can be substantially improved if the image is properly filtered prior to sampling (pre-filtered), and then properly filtered again prior to display (post-filtered). The nature of the filters giving optimum performance depend very much on the statistical character of the imagery, the nature of any channel (or other) noise, and the perceptual characteristics and preferences of the viewer. Since there is no single optimum pair of filters, certainly across multiple industries and applications, and since images may not be displayed until much later when displays and user preferences are different, it may be desirable to label high resolution data with the prefilter used to generate it and perhaps with the identity of the recommended postfilter. This information could be provided directly or indirectly via the universal descriptor discussed below. I. Guidelines for image filtering in a scalable video system. One possibility for how to offer guidelines for transcoding between different resolution sets (in and out of a family) is to provide a mechanism for a parameterised filter. The parameterised filter would take the desired source and target spatial resolutions for a transcoding operation and return the appropriate filter kernel and filter width. There could be two modes: transcoding with whole numbers and transcoding with fractional numbers. J. Considerations with respect to the image-capture mechanism. Transcoding from one video format to another generally involves filtering (interpolation) and resampling. In considering the entire process from the real-world original to the final real-world display, it is desirable to have precise knowledge of the complete processing chain. The focal plane image is often limited in quality due to quantum effects and/or optical deficiencies, either inherent or due to imperfections of components. It is also helpful to know the linear and/or nonlinear processing to which the optical image was subjected before the video signal was created. These effects depend, among other things, on the physics of the devices and the signal processing that was used. If presented with a video signal whose gestational characteristics are not well known, optimal transcoding may not be possible. To put it another way, there may well not be a single best way to transcode between two different formats if the video signals were derived in widely differing manners. Further study may produce recommendations for standard image- capture techniques to avoid these problems. K. Relationships between flying spot analog systems and digital fixed pixel raster systems. Flying spot digital systems do not have the same sharpness as fixed pixel raster systems. Flying spot analog systems may degrade upon being digitized, due to the spot motion and coverage being sampled on discrete pixels. Examples of fixed pixel raster devices are CCD camera sensors and active matrix flat panel displays. Some CRT film scanning systems also use "point plot rasters" where the spot samples each pixel without motion. And in CRT computer displays, a flying spot CRT displays a frame-buffer digital image. All of these examples may produce complex relationships that need to be studied to determine optimum interoperability parameters. L. Range of acceptable number of A/D and D/A transformations for various applications. Each time an analog value is digitized, and each time a digital value is converted to analog, signal error is introduced. These errors are generally given the term "quantization error", but the nature of these errors can be very complex. In general, the error may be reduced when a greater number of bits are used for the digital representation, but issues such as logarithmic or linear representation, color, and other factors may be significant as well. To minimize errors introduced at each analog to digital (A/D) and digital to analog (D/A) conversion, or for some specified level of signal preservation, recommendations may be required as to the number of conversions acceptable for different applications.