2005 Newsgroup postings (05/04 - 05/18) Lynn Wheeler

2005 Newsgroup Postings (05/04 - 05/18)

Where should the type information be?
Single System Image questions
Single System Image questions
IBM 360 channel assignments
IBM 360 channel assignments
Single System Image questions
Software for IBM 360/30 (was Re: DOS/360: Forty years)
IBM 360 channel assignments
keysigning: identity checks
Exceptions at basic block boundaries
Exceptions at basic block boundaries
Exceptions at basic block boundaries
practical applications for synchronous and asynchronous communication
Today's mainframe--anything to new?
Today's mainframe--anything to new?
Exceptions at basic block boundaries
Today's mainframe--anything to new?
Exceptions at basic block boundaries
Exceptions at basic block boundaries
Blowing My Own Horn
Key pair & Certificate lifetimes
Thou shalt have no other gods before the ANSI C standard
Today's mainframe--anything to new?
Single System Image questions
Description of a new old-fashioned programming language
couple more Q's on basic public key encryption techniques
Crash detection by OS
How do you get the chain of certificates & public keys securely
Crash detection by OS
Dealing with warning that certifcate can't be trusted?
Query on Load Balancer with SSL
IBM 1130
Software for IBM 360/30
Software for IBM 360/30
some walk down history lane
Systems Programming for 8 Year-olds
Security via hardware?
Software for IBM 360/30
Systems Programming for 8 Year-olds
Attacks on IPsec
Software for IBM 360/30
Systems Programming for 8 Year-olds
Systems Programming for 8 Year-olds
Systems Programming for 8 Year-olds
First assembly language encounters--how to get started?
First assembly language encounters--how to get started?
Password question

Where should the type information be?

From: lynn@garlic.com
Subject: Re: Where should the type information be?
Newsgroups: comp.arch.arithmetic,comp.arch,alt.folklore.computers
Date: 4 May 2005 07:50:15 -0700

Brian Inglis wrote:
Most programs (e.g. ftp, HLLAPI, telnet/tn3270) I've used interconvert the characters unavailable on the other's keyboard: [ ] to =A2 =AC in arbitrary order; conversions between EBCDIC solid and broken vertical bars and the ASCII vertical bar are idiosyncratic, to say the least.

some of this may be my fault. three people came out from CSC the last week of january, 1968 to install cp67 at the university. at that time, cp67 only contained 1052 & 2741 terminal support. I had to add TTY/ascii terminal support. I started out by borrowing ebcdic<->ascii translate tables from BTAM ... and tweaking them to make them more conducive for cp67 operation.

one of the cp67 characteristics was terminal character & line delete operation. on the right side of 2741 keyboard, there is key with at-sign lower-case and cent-sign as upper-case. the convention in cp67 was that at-sign (lowercase key) deleted the next character to the left (already entered) ... multiple at-signs would delete multiple adjacent characters (already entered on the left). The cent-sign (uppercase on the at-sign key) would delete all characters to the left (already entered, to start of line).

i don't have reference right now ... but from vague memory ... i believe tty/33 had left/right brackets in approx. same position on the keyboard (so i fiddled the translate tables based on that).

the standard cp67 code had dynamic terminal identification for 1052 & 2741 (you didn't have to make fixed terminal type definitions associated with specific terminal controller port). I thot that i was going to be fancy and do the same thing when adding tty support. i also thot that i could have a single dial-up number for modem pool ... so all terminals could dial-in on the same number.

The dynamic terminal identification worked ... but the dial-in part didn't. While the code could dynamically determine the connected terminal ... the standard mainframe terminal controller interface couldn't handle the general case of arbitrary terminal connecting to an arbitrary controller port.

The terminal controller did have "SAD" command support so that an arbitrary line-scanner could be associated with an arbitrary port. The problem was that they had hardwired oscillators on each port ... which fixed the port baud rate. As long as different terminals shared the same baud-rate ... it was possible to use the "SAD" command support to associate the appropriate line-scanner with a port (which is why the 1052 & 2741 terminal support worked ... they had different controller line-scanner ... but the same baud rate).

Adding TTY support ... it was possible to dynamically define the terminal type (w/o requiring predefined terminal tables) ... but it wasn't possible to actually dynamically intermix connection of terminals with different baud rates on the same port.

this somewhat kicked off the clone controller project
https://www.garlic.com/~lynn/submain.html#360pcm

where the mainframe channel interface was reversed engineered and a channel interface board built for an Interdata/3 ... and the Interdata/3 was programmed to emulate the ibm mainframe controller. In the interdate/3 impementation ... support was added to do high-speed probe of in-coming signal on ports to dynamically determine connecting terminal baud rate.

Single System Image questions

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Single System Image questions
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 04 May 2005 11:43:21 -0600

bs2k1 writes:
Hi, I have a few quick questions on the topic of Single System Images.

1. What are the reasons that a Single System Image is used? 2. Why would you have more than one SSI in a cluster? 3. If you have more than one SSI why would it be useful to do this?

Thanks.

Bill.

homework question, right?

the hone system provided dataprocessing support for world-wide sales, marketing, and field personnel. in the late 70s, the US hone datacenters were consolidated in california. circa 1980, the US hone complex was pushing 40k user definitions.
https://www.garlic.com/~lynn/subtopic.html#hone

the typical HONE environment was complex set of cms\apl applications that migrated to apl\cms ... which were frequently very processor intensive. basically the us hone complex were the largest mainframe SMP of the period with max. number configured in a cluster with common disk farm.

with the consolidation of all the us hone datacenters, the "dumb" 3270 terminals were connected to frontend terminal concentrators which were interconnected to the backend HONE processor cluster. prior to the datacenter consolidation ... specific field connections went to a specific datacenter machine. with all the datacenters consolidated at a single lcoation with interconnected common disk farm ... it offered the opportunity of implementing single-system-image with load-balancing and fall-over/availability support.

the hone system had started out as a clone of the science center's cp67/cms system
https://www.garlic.com/~lynn/subtopic.html#545tech

i was done a lot of performance optimization work ... but there was also a couple projects at the science center doing performance modeling work. one was a sophisticated performance model implemented in cms\apl. some amount of this work provided basis for the original morphing of performance management into things like capacity planning.

the apl performance model was also used as a basis for controlling a large sophisticated set of automated (2000 that took 3months elapsed time to run) benchmarks
https://www.garlic.com/~lynn/submain.html#bench

as part of calibrating the resource manager in preparation for release.
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

the same apl performance model was also used for a HONE application called the performance predictor that customer sales people could run "what-if" questions about effects of change in customer hardware configuration or workload (i.e. in this period APL was used for a lot of applications that are currently implemented with spreadsheets)

the APL performance model was also used as an application that ran on every processor complex in the cluster and provided information to the front-end terminal concentrators on which processor to route login requests ... aka SSI load-balancing. The application was also aware of offline machines and/or machines about to become offline ... so it would avoid routing login requests to those processors in the cluster.

In the early 80s, the northern cal. HOME consolidated complex was replicated, first in Dallas and then again in Boulder ... handling load-balancing ... but also availability (some worry about earthquake disaster hitting the cal. datacenter.)

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

Single System Image questions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Single System Image questions
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 06 May 2005 09:12:25 -0600

bs2k1 writes:
Thanks everyone for you answers they have been very useful. Just one more question. - On a cluster that uses SSI can every computer in the cluster use the same SSI? What I mean is can different people use the SSI from different nodes?

in the 70s (when my wife was still in preschool) she was con'ed into going to pok to be in charge of loosely-coupled architecture ... this is the mainframe cluster stuff dating back to the 60s ... although didn't necessarily always totally represent SSI. during her stint ... she wrote Peer-Coupled Shared Data architecture ... but at the time ... POK was much more focused on big iron symmetric (shared-memory) multiprocessing ... rather than loosely-coupled ... so she didn't last long (some of her stuff didn't see light in the mainframe arena until more recent sysplex)

some Peer-Coupled references
https://www.garlic.com/~lynn/submain.html#shareddata

in late 80s we started ha/cmp (High Availability Cluster Multi-Processing)
https://www.garlic.com/~lynn/subtopic.html#hacmp

minor reference a little later
https://www.garlic.com/~lynn/95.html#13

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

IBM 360 channel assignments

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 channel assignments
Newsgroups: alt.folklore.computers
Date: Fri, 06 May 2005 10:38:05 -0600

Peter Flass writes:
As you probably know, byte multiplexor channels interleaved data from several I/O operations on a byte basis. Think "one byte from the card reader, one to the printer, ...". Selector channels only carried out one operation at a time. Block multiplexor channels interleaved data by blocks, that is, the channel could start several I/O operations going, and the CPU or control unit would only tie up the channel when it actually had a block of data to transfer.

Selector channels (IIRC) pretty much died out with the 360. After that all non character-type I/O was done by the block multiplexors, DASD, Tape, and what-have-you. Not as useful for tapes, but the channel could profitably disconnect for REW, FSF, etc.

byte multiplexor typically were unit record or telecommunication controllers. byte multiplexor could interleave multiple concurrent streams simultaneously.

when we were doing the telecommunication clone controller
https://www.garlic.com/~lynn/submain.html#360pcm

one of the first bugs testing hardware on 360/67 was locking out the high-speed timer. 360/67 had high-speed timer option that updating storage location 80 (x'50'). if channel continuously locked out the memory bus so that the timer had a second tic happen before it had a chance to update memory for previous tic ... then the machine would "red-light" (and stop with machine check).

360 had byte multiplexor and selector channels. block multiplexor was a sort of interleave selector channel introduced with 370. block multiplexor allowed the 3330 "set sector" feature to suspend channel program processing until the controller raised reconnect.

in 360 ... there was paradigm that you could effectively trade off lots of i/o channel capacity for processor real storage ... dasd/disk channel program would position the arm and then search for specific record identification.
https://www.garlic.com/~lynn/submain.html#dasd

these searches would tie-up up the selector channel, controller, and device. 3330 had 19 data tracks and a 20th hardware positioning track (sector). if you knew approximately the rotational position of the record you needed ... you could insert a SET-SECTOR ccw in the channel program ... that would disconnect from the channel until that position rotated under the head (on track 20) .. at which point, it would raise channel reconnect.

by the mid-70s, the trade-off was beginning to switch with much more abundant real storage and more constrained i/o capacity. i once was called into a large national retail customer that was experiencing unexplained severed i/o bottleneck thruput. they had multiple 168s in loosely-couple configuration with SVS. It turns out that they had a large application program PDS dataset with a three (3330) cylinder library directory. Standard os support used multi-track search of the program directory to find the index pointer to specific program image on disk. multi-track search would spin until it found the correct record ... or until end of cylinder (locking out the channel, controller, and device). for 3330 at 3600rpm and 19 tracks ... a full-cylinder search took appox. 300milliseconds elapsed time. On the avg. a search took 1.5 cylinders ... or about 450milliseconds ... plus time to load the program ... about .5seconds total. The whole multi-system complex was being limited to about two application program loads per second.

block multiplexor and 3330 set sector allowed for use of direct location positioning ... but os/360 had CKD multi-track search ingrained into various library and directory structures ... VTOCS, PDS, etc ... which continued to severely aggravate for years.

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

IBM 360 channel assignments

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 6 May 2005 14:23:41 -0700
Subject: Re: IBM 360 channel assignments

Eric Smith wrote:
Are you sure it appeared with the 370? I've seen references to the 2880 block multiplexor channel for use with the 360/65, /67, and /85.

2880 block multiplexor was needed for 3330/3830 set sector, channel disconnect/reconnect. i can see it being available on 360/85 since it sort of spanned end of 360 generation (being 1st cache machine) ... and possibly be retrofitted on RPQ basis to 65, 67, & possibly 75.

on standard 370 ... channels were integrated except for 165 & 168.

tried quick search engine ... which came up with a few refs
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos3.htm
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html

Single System Image questions

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

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 6 May 2005 15:55:04 -0700
Subject: Re: Single System Image questions

Jack Peacock wrote:
Yes and no. Yes if the joining node is compatible with the cluster resources, no if it requires resources (for example, special versions of the binaries to handle hardware incompatibilities) not shared with the rest of the cluster. If the system image is being shared across cluster nodes then by definition different users would be using it on different nodes. A partial exception would be heterogeneous clusters with mixed processor architectures, where the image would only be available on matching hardware. Jack Peacock

ucla locus supported heterogenous operation .... with different architectures and even process migration across different nodes in the cluster. the palo alto science center had running across 68k and series/1 machines. it was later released as product ... aix/370 and aix/ps2.

Software for IBM 360/30 (was Re: DOS/360: Forty years)

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

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 6 May 2005 19:53:19 -0700
Subject: Re: Software for IBM 360/30 (was Re: DOS/360: Forty years)

Joe Morris wrote:
I doubt that I could locate a tape control unit SRL to check it, but I would expect that REW would return CE as ending status upon receipt of the command, and would subsequently return DE when the load point was reached. I would expect RUN to return CE+DE on receipt of the command since the device may never go ready again.

CE would release both the channel and control unit.

Sigh...with all the SYSGENs I ran over the years I never thought to squirrel away a copy of one so that I could look back on it years later...

i thot i usually the whole machine room to myself on the weekend ... but one weekend i got pre-empted because the ibm se and one of the univ. system programmers were doing a sysgen. i tried to work around them ... they spent something like 8 hrs do a stage1 & stage2 sysgen ... maybe 150 cards stage1 ... that in turn punched out a jobstream of about 2000 cards for stage2 sysgen. apparently something went wrong in the stage2 ... so they broke for dinner and were going to come back and redo the whole thing again from scratch.

while they were gone ... i made copies of both the stage1 deck and the stage2 deck to see what was going on.

they came back ... and did their thing ... but over the next couple weeks i tried to figure out what stage1 and stage2 were doing as well as what was on the starter system. they had done os/360 release 7 or 8? after some more work ... i asked if i could do the next sysgen in the standard system job stream. I did os/360 release 9.5 ... mostly using a starter system.

for os/360 release 11 sysgen, i ran stage1 in standard stream and got the stage2 sysgen deck ... and sent it off to be interpretted. i then broke the individual job steps apart and added job cards so many of them could be run as independent jobs ... instead of one long, single job stream. some of the stuff, i reorganized in attempt to better optimize placement of different stuff on disk.

i made a presentation on the work at share ... and also continued work on reorganizing the stage2 stream to better optimize the resulting system files.

IBM 360 channel assignments

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

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 7 May 2005 06:30:45 -0700
Subject: Re: IBM 360 channel assignments

Rob Warnock wrote:
The RCA Spectra-70 byte multiplexor channels provided a small-but-useful addition that added a bit of the block multiplexor functionality. A byte mux device could burst for a *few* bytes in a row (max 4, IIRC) for better performance than a standard byte mux. The device had to be designed to know about the extra wire on the bus/tag interface that requested this function, whose name was...

for 3380 drives, they introduced data streaming. selector & byte multiplexor had bus&tag synchronous hand-shake on every byte ... that limited normal stuff to about 200ft and something like 2301 drum (over 1mbyte/sec) to maybe 70-80ft.

data streaming up that to 8bytes and supported 3mbyte/sec up to 400' (later raised to 4.5mbyte/sec).

part of the problem with escon (fiber 200mbit/sec) is that it tended to preserve the end-to-end half-dupliex operation. escon had been laying around pok for quite some time before it saw the light-of-day. one of the rs/6000 engineers took the basic escon ... up'ed it to 220mbit/sec, used much cheaper optical drivers ... which was announced as serial-link adapter (SLA) for rs/6000.

we had been going to hippi and fcs meetings and when the engineer started looking at moving sla to 800mbit ... we talked him in working on fiber-channel standard instead. he became editor of the FCS document. one of the issue in FCS was some number of the pok channel engineers were participating in the standards meetings and they were constantly trying to overlay the escon half-duplex operational model on basically a full-duplex operation.

keysigning: identity checks

From: lynn@garlic.com
Newsgroups: comp.security.pgp.discuss
Date: 7 May 2005 07:56:53 -0700
Subject: Re: keysigning: identity checks

Richard Johnson wrote:
Indeed. Don't lose sight of the fact that the transport mechanism has nothing to do with the validity of key->person mapping. Making the email address part of the identity is improper. Email is a transport mechanism only, not an identity.

typically signing ... within 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are

amounts to something you have authentication ... that the originating party has access to and use of the private key ... that is used for signing ... and the corresponding public key can be use to verify.

authentication doesn't require identification ... for instance ... i could supply a public key at the same time i apply for ISP (& email) account. the public key can be used with any of my digital signatures to indicate that subsequent communication is associated with the same entity that opened the email account. in that sense ... a sequence of emails all signed with the same private key (and verified with the same public key) may be assumed to have originated from the same entity (based on something you have authentication ... and regardless of the originating email address).

another example is the whole SSL domain name certificate scenario. The current scenario has the certificate applicant supplying a bunch of identification information. The certification authority then takes that identification and attempts to match it up with the identification material on file with the authoritative agency responsible for domain name ownership (the domain name infrastructure), which is a costly, complex, and error-prone process.
https://www.garlic.com/~lynn/subpubkey.html#sslcert

somewhat from the certification authority industry is proposal that when somebody applsies for a domain name, they register a public key at the same time. any future communication is digitally signed by the domain name owner, and the domain name infrastructure can verify the digital signature with the onfile public key. There is no sense of requiring "identification" of the domain name owner ... just the sense that the person communicating is the same person that opened the domain name account (authentication).

For ssl domain name certificate application, the domain name owner just digitally signs the application. the certification authority now just retrieves the on-file public key ... aka certificate-less operation
https://www.garlic.com/~lynn/subpubkey.html#certless

and verifies the digital signature on the application. This converts a costly, complex, and error-prone identification process into a much cheaper, simpler, and reliable authentication process.

Exceptions at basic block boundaries

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Exceptions at basic block boundaries
Newsgroups: comp.arch
Date: Sat, 07 May 2005 10:18:20 -0600

"Eric P." writes:
Really? And all these years I thought it was. Live and learn. What's a Storage Key? Is there a table of per-frame words describing the state of each frame which includes the Access and Dirty flags that is managed by the MMU?

storage key is from original 360 .... could have store &/or fetch protection as optional feature. each 2k area of storage could have a storage key (as part of optional storage key feature). a storage key could have value 0-15 (4bits) and the currently running psw could have key value. for non-zero psw keys ... store operations had to have corresponding storage key value set. optional fetch proectio feature was a 5th bit in the storage key ... turning on the fetch protecture feature (same rules as store protection).

360/67 then had the reference and change bits in the storage key. to check the value of the reference &/or change bits ... you had to use the storage key isntruction.

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

Exceptions at basic block boundaries

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Exceptions at basic block boundaries
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 07 May 2005 12:54:33 -0600

"Eric P." writes:
Actually I don't think it must do any more work than it already has to. In other words, from what I can see, moving the flags wouldn't save the OS any significant work.

With Global Working Set Management (like Linux) when a frame gets recycled the OS has to chase down all the PTE references and patch them. So it can pick up the state flags then.

With Local Working Set Management (like VMS & WNT) as a virtual page falls out of the works set list, the OS propagates the Accessed and Dirty flags from the PTE into the frame state descriptor and decrements the reference count. When the reference count goes to zero, the frame goes to either the modify or valid list.

So if there is a benefit to moving the flags to a central table, it looks like it would have to be for other reasons.

360/67 & 370 used shared segments for sharing of pages ... i.e. implicit only one PTE per page frame (multiple different address spaces or segment tables ... and pointers to the same page table ... collection of PTEs).

360/67 only had 1mbyte segments (256 pages) and originally CMS only had something like 3-4 pages set up for shareable. So cp67 did have a hack for shared-pages that involved (a small number of) multiple different PTEs in different address spaces pointing to the same real page.

370 came out with options ... 2kpages and 4kpages and 64k (16 page) segments and 1mbyte (256 page) segments. CMS was restructure to have a single shared segment. The base 370 architecture also defined a feature where the segment table pointer (to the page table) could have a read-only flag ... so you could have store-protect on a shared-segment basis (similear but different to the 360 real memory storage protect based storage keys).

note that in the original 370 announcement, there wasn't mention of virtual memory support ... which was a later enhancement. the low & mid-range 370s ... it just required microcode change. But for the 370/155 & 370/165 it required significant hardware retrofit to the machines already in customer shops. At one point ... the 165 engineers raised an issue that they could ship basic virtual memory hardware support six months earlier if they could drop some of the stuff in the define virtual memory architecture (like shared segment protection). A business decision was finally made to drop the extra features from all 370 virtual memory implementations ... in order to have six month earlier announce & ship of virtual memory.

This caused quite a hardship for the CMS shared segment (across different virtual address space) protection ... and they finally had to come up with a hack kluge.

i had originally came up with global LRU page replacement algorithm in the 60s as an undergraduate and added it to cp67 (and it was picked up and shipped in the standard product). this was about the same time as the ACM article appeared on working sets and local page replacement algorithm.
https://www.garlic.com/~lynn/subtopic.html#wsclock

Over ten years later ... somebody was trying to get a stanford phd on global page replacement algorithm and there was quite a bit of opposition from the parties associated with local page replacement. I was asked if i could contribute.

It turns out that the grenoble science center had an ACM paper published in the early 70s on modifications they made to cp67 for local page replacements ... and performance measurements they ran on cp67 machine they ran at grenoble (360/67 with 1mbyte real storage, 154 4k "pageable pages" after fixed kernel requiremetns); 30-35 cms users with mixed-mode workload,

About the same time, cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

was running similar workload with 75-80 users on a 768k real storage 360/67 (104 4k pageable pages after fixed storage requirements) using a version of cp67 running my local page replacement algorithm ... and having about the same response and thruput as the grenoble machine (twice as many users and 1/3rd the real storage).

I provided old plots and papers ... and the person eventually got their phd.

misc. past posts mentioning shared segment protection:
https://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line

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

Exceptions at basic block boundaries

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Exceptions at basic block boundaries
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 07 May 2005 13:46:11 -0600

"Eric P." writes:
370 has a inverted page table so it would have no option. In a hierarcical table, since the PTE contains the frame number you could always retreive those bits as though they were in the PTE. So existing designs would most likely contnue to work.

360/67 and 370 had hirrarchical tables ... slightly different ... enuf to make virtual machine implementations of the different tables something of a pain.

370 architecture had Segment table with segment table entries that pointed to page tables. architecture provided option support for selection of either 2k or 4k pages and either 64k segments (16 pages) or 1mbyte segments (256 pages). base 370 architecture allowed for implementation of either "STO" associative TLB (i.e. the physical address of the segment table origin was used to tag entries in the TLB, effectively address space associative) or "PTO" associative TLB (i.e. the physical address of the page table origina was used to tag the entries in the TLB). In STO-associative, shared pages (same PTE belonging to shared segment/pagetable, but different address spaces) would have different entries in the TLB. In PTO-associative implementation, there would be a single TLB entry for shared PTEs.

I believe all 370s implemented STO-associative ... even tho the architecture allowed for PTO-associative.

low-end & mid-range 370s tended to have small TLB that had all entries flushed every time address space (segment table pointer) was changed ... so there was no concept of having concurrent entries for same shared PTE for different address spaces.

370 165/168 had 128 entry TLB and a 7-entry "STO-stack" ... and each TLB entry had a 3-bit identifier that corresponded with an entry in the STO-stack. Changing address space (loading new STO value in CR1) would check to see if the STO value was already in the STO-stack ... if so, it just srarted using that value. If not, one of the entries in the STO-stack would be selected for replacement ... and all of the associated TLB-entries would be flushed.

One of the problems with the introduction of the 168-3 ... was they doubled the cache from 32kbytes to 64kbytes ... and used the 2k bit as one of the address bits for indexing cache entries. When in 2k virtual page mode ... the 168-3 ran with only 32k cache active (only using full 64k cache when in virtual 4k page mode). There was a customer that had mix-mode workload with VS1 running under vm/370 with cms and other stuff. VS1 was a 2k virtual page operating system ... and vm/370 had to provide its virtual machine operation with 2k virtual page shadow page tables. The customer upgraded from 168-1 to 168-3 doubling machine cache ... and thruput got much worse. In theory running with half 168-3 cache should have been no worse than 168-1 ... however, every time vm/370 switched between virtual page mode (2k->4k or 4k->2k), the hardware cache had completely flush all entries because the mapping process changed.

801/risc defined inverted page tables
https://www.garlic.com/~lynn/subtopic.html#801

i've made the assertion that 801/risc was in some sense a reaction to the failure of FS
https://www.garlic.com/~lynn/submain.html#futuresys

with the swing to the complete opposite end of hardware complexity ... instead of maximum hardware complexity ... have maximum hardware simplicity ... and move a lot of issues into software, pushing the envelope on compiler (pl.8) and operating system (CPr) technology.

in the late 70s ... there was a push to migrate the scores of different internal corporate microprocessors to an 801/risc architecture. for instance all of the low-end and mid-range 360s and 370s had been a variety of microprocessor engines that were coded to emulate 360/370 (avg. about ten native microprocessor instructions per 360/370 instruction). the follow-on to the 4341 mid-range processor was nominally going to be a native mode 801/risc processor. the issue was that silicon state of the art was getting to the point where you could just about do the full 370 in silicon chip ... rather than having to emulate it. i helped write the drafts that argued having the 4341 follow-on be a native silicon implementation (with much better price/performance) than a native 801/risc with 370 "microcode" emulation (at a 10:1 penalty).

in the early 80s, research had a joint project with office products division to use an 801/risc chip; ROMP with CPr (implemented in PL.8) as a displaywriter follow-on. one of the CPr (pl.8) issues was loads of stuff had been moved from hardware to software ... there were inverted page tables, no hardware protection domains ... any inline software could execute every instruction and access every machine facility. Things like protection and security were issues provided and supported by correct compiler generated code and correct operating system loading.

Instead of segment and page tables, there were 16 segment registers that could be loaded with 12bit "segment" identifier. The top four bits of a 32bit virtual address was used to select a segment register which pulled a 12bit segment identifier. The 12bit segment identifier plus the remaining 28bit virtual address was used to index TLB entry. In 370 terms, it was a PTO-associated TLB with 256mbyte segments ... because each TLB entry was associated with a specific segment value (as opposed to a virtual address space value). Write-ups even referred to the ROMP chip having 40bit virtual addressing ... from TLBs being tagged with the 12bit segment associative value (combined with the 28bit virtual segment displacement value). In theory, inline application code would dynamical change segment register associative values ... as easily as more familiar code could change address pointers in general purpose registers.

The displaywriter project was killed, and the group decided on retargeting the platform to unix workstation market (PC/RT). One of the things that had to be added back in was hardware support for protection domains. The company that had been hired to do the AT&T unix port for ibm/pc (pc/ix) was hired to do a similar port for "AIX". However, you had all these pl.8 programmers ... so instead of having the AIX port done to the bare hardware ... an abstract virtual machine was defined for the AIX port ... and the pl.8 programmers were put to work implementing the VRM ... which talked to the real hardware and provided the abstract virtual machine interface. There was some claim that this could be done faster and easier than having the outside company doing an ATT unix port to the native hardware.

The counter was when the palo alto science center did a BSD port to the native ROMP hardware with less resources than was used in either the ATT "AIX" effort to VRM and/or the VRM effort.

The follow-on chipset for ROMP was RIOS/power. it still had inverted tables, 16 segment tables registers ... but they had doubled the segment-associative number of bits from 12bits to 24bits ... as a result, you may trip across early descriptions of power referring to its 52bit virtual address capability.

a couple recent posts that talk about the transition from free software to priced/licensed software ... and some impact of FS on the transition.
https://www.garlic.com/~lynn/2005g.html#51
https://www.garlic.com/~lynn/2005g.html#53
https://www.garlic.com/~lynn/2005g.html#54
https://www.garlic.com/~lynn/2005g.html#57

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

practical applications for synchronous and asynchronous communication

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

From: lynn@garlic.com
Newsgroups: comp.os.misc, comp.arch, comp.protocols.tcp-ip, alt.folklore.computers
Date: 7 May 2005 16:45:57 -0700
Subject: Re: practical applications for synchronous and asynchronous communication

Rob Warnock wrote:
Except that when you lose a token due to bit errors, Token Ring becomes async, too!! [Something the TR proponents conveniently forgot to mention during those heated debates...]

pc/rt had done a custom 4mbit t/r card for its 16bit bus. but the rs/6000 was forced to use the ps2 microchannel 16mbit t/r card (32bit bus) ... rather than doing its own. One of the issues with the ps2 microchannel 16mbit t/r card ... was that the per-card thruput was actually lower than the custom pc/rt 4mbit t/r card (ps2 16mbit t/r design point was hundreds of PS2s sharing the same 16mbit t/r).

my wife had co-authored and presented a response to a gov. secure campus-like network RFI ... in it, she had postulated some of the fundamentals of 3-tier architecture. We then expanded on that in conjunction with ethernet and other technology and started presenting it at customer executive meetings.

we got hammered from the SAA and T/R crowd .... who possibly could be characterized as trying to put the client/server genie back in the bottle ... and we were out pitching 3-layer architecture, middleware, etc.
https://www.garlic.com/~lynn/subnetwork.html#3tier

one of the things that the t/r group were claiming was enet typically degraded quickly to less than 1mbit thruput. the assumptions for this appeared to be an early 3mbit enet technology before there was listen before transmit. In this timeframe there was an ACM sigcomm article that measured in most typical enet deployments ... it degraded to 8.5mbit effective thruput under worst case scenario ... all stations in tight low-level device driver loop constantly transmitting minimum sized packets. By comparison, it was rare to see 16mbit t/r getting better than 8mbit effective thruput ... and its nominal message latency was typically much greater than the nominal enet latency.

disclaimer ... my wife is named as co-inventor on one of the early token passing patents from the 70s.

some past postings on the enet & t/r issues ...
https://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
https://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
https://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?

some old 3-tier postings:
https://www.garlic.com/~lynn/96.html#16 middle layer
https://www.garlic.com/~lynn/96.html#17 middle layer
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?

Today's mainframe--anything to new?

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

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 8 May 2005 07:57:08 -0700
Subject: Re: Today's mainframe--anything to new?

jsav...@ecn.ab.ca wrote:
No, probably that stuff is done from a keyboard and display, using whatever a z/990 uses for a BIOS. After all, it uses custom microchips that handle the 370 instruction set, not SSI, so there's nowhere to *connect* the front panel lights.

FE service people had requirements that they could bootstrap diagnosis starting with probes and scope. the 3081 starting with TCMs where there wasn't anyplace to put probes ... and so there was a service processor that had manufactured probes into all sorts of places ... and the serice processor could be probed (and replaced).

the 3090 started out with going to have a 4331 running a custom vm370 release 6 ... as the service processor (possible to scope the 4331). before the 3090 shipped, this was eventually upgraded to a pair of 4361s as service processors (still using a highly modified vm370 release 6).

i provided some amount of code enhancements for the service processor code. the group supporting the highly modified vm370 was also one of the internal sites that picked on my debug analysis tool for supporting their operation (it never got released to customers ... but majority of the internal locations started using it ... including PSRs supporting customers).
https://www.garlic.com/~lynn/submain.html#dumprx

3090 also introduced expanded store. the constant march of ambundance of electronic memory was continuing. i had previously made comparison between 360/67 and 3081 and relative system disk performance declining by a factor of ten times. along the way, the abundance of electronic memory was being used to compensate for deficiency in disk performance (aka various kinds of caching). the problem with 3090 era was that you could get a lot more electronic memory than you could physically package within normal memory latency. as a result, they went to another memory level ... that was software managed as 4k pages. basically they used the paging metaphor for software to stage data between regular memory and expanded store in 4k page operations. the expanded store had a special high-speed and wide bus.

later when kingston was trying to craft hippi support on 3090 ... the standard 3090 i/o interfaces couldn't handle the rate ... so they cut into the side of the expanded store bus to do the hippi attachment.

in the 3090 time-frame ... Amdahl had come up with hypervisor support ... basically an abbreviated virtual machine with dedicated real storage allcoation. you could run vm370 in normal operation providing normal virtual machine ... and mvs in the hardware hypervisor with almost no virtual machine degradation. IBM responded with 3090 PR/SM which has since evolved into current day LPARS (logical partitions).

we had been attending hippi, fcs, and sci meetings (hippi basically by lanl trying to standardize the cray 800mbit/sec copper channel, fcs, by llnl trying to standardize a 1gbit fiber version of some serial technology they had, sci was some other fiber stuff out of SLAC).

ibm mainframe had done something with 200mbit escon ... which had been laying around pok since the late 70s. one of the rs/6000 engineers had taken escon ... increased it by about 10percent to 220mbit, redid it with much cheaper optical drives ... (sla, seial link adapter). escon .. while pairs of unidirectional fiber ... preserved the half-duplex paradigm from the bus&tag cables. The rs/6000 engineer then started work on 800mbit SLA ... but we eventually manage to talk him into moving to FCS ... and he became the editor of the FCS standards document. There was some amount of contention in FCS meeting from POK channel engineers attempting to overlay the half-duplex paradigm (from escon and bus&tag cable) on the fundamentally full-duplex FCS.

the current generation of that is ficon ...
http://www-1.ibm.com/servers/eserver/zseries/connectivity/ficon_recov...

note in the above reference ... we had coined the terms and defined disaster survivability and geographic survivability for ha/cmp ... as contrast to simple disaster/recovery
https://www.garlic.com/~lynn/subtopic.html#hacmp

another ficon description
http://www.cisco.com/en/US/netsol/ns512/networking_solutions_white_pa...

... aka ficon is the upper layer protocols on top of FCS to turn a native FCS full-duplex paradigm ... into the old-style bus&tag half-duplex paradigm.

Today's mainframe--anything to new?

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 8 May 2005 10:00:09 -0700
Subject: Re: Today's mainframe--anything to new?

Alexander Schreiber wrote:
And then there is the story about Cray selling a building used for manufacturing the machines. It was in a part of the US that gets pretty cold winters and had _no_ heating installed since it was kept comfortably warm by the waste heat turned out by a few Cray systems running tests before shipment.

The new owner however seemingly could not afford to "just power up a few Crays" to keep the building warm and had to install heating ;-)

the brand new research building .... almaden up on the hill .. moving out of bldg. 28 on the main plant site ... was completely wired with CAT4 and other stuff for t/r thru-out the bldg.

they installed a whole bunch of ibm pc/rt with enet (they did a lot of tests and found out that they got significantly better thruput using the CAT4 for 10mbit enet than they could get from 16mbit t/r).

in a energy conservation move ... there was guideline that all PCs should be powered down when people left at the end of the day. they tried it for awhile and the building maint. people complained. they claimed that the heating/cooling hadn't been designed to handle the wild temperature swings caused by powering up several hundred pc/rt in the morning and then powering them down in the evening.

Exceptions at basic block boundaries

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 8 May 2005 13:06:51 -0700
Subject: Re: Exceptions at basic block boundaries

Eric P. wrote:
The grenoble changes must have been a very early attempt at Local Replacement. Since there is no such performance disparity between Local and Global these days so I can only guess that the grenoble mods did not use the same mechanism as the current approaches.

working set tended to assign a task a set number of real pages. when a task faulted, local LRU replacement would select one of the tasks own pages for replacement. in global LRU replacement, all pages belonging to all tasks were examined for replacement.

in the tightly constrained real memory of the period ... and the normal ebb and flow of program behavior .... at any point in time ... there could be a page belonging to some other task that was much more ideally suited for replacement than a task's own page.

in effect, global LRU replacement rank all virtual pages in real memory as to their appropriateness for replacement ... instead of lots of little private rankings for each task. the analogy is somewhat akin to financial institutions having lots of tellers .... but a single queue for all tellers (as opposed to one queue per teller).

as real storage configurations increased ... and it was found that you had spare real storage for lots of other things ... like file caching ... the degree that a system was bottlenecked became less ... and the degree that overall system throughput was tightly tied to real memory sizes drastically decreased (and with the decrease in how tightly overall system thruput was tied to memory and paging ... there was also a corresponding decrease in the degree that different paging algorithms affected overall system performance).

In a real-memory constrained system where there is an extremely close relationship between overall system thruput and the importance of each individual page replacement decision ... differences in page replacement algorithms were much more pronounced.

For instance, in the early 80s ... big pages were introduced with 3380 disks. basically instead of doing single 4k page replacement at a time ... paging was done in blocks of ten 4k pages at a time (40k bytes per transfer).

Typical real storage sizes had gotten much larger ... by possibly a factor of 50 times ... but disk (arm) thruput had only increased by less than factor of 5 times. The total amount of pages moved with big page implementation was possibly 30 to 50 percent larger than the same workload in a environment doing single page at a time replacement. Because of the large shift in the bottlenecks from being real storage contrained to being disk arm constrained .... the importance in the quality of the page replacement decision had declined significantly .... it was more importan that you could move ten times as many pages per transfer .... even if 30 percent of the page transfers turned out to be wrong or unnecessary.

at the same time grenoble had published the local lru replacement paper .... cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

had developed a number of very sophisticated performance modeling tools. some of this was the origins of the transition of performance management into capacity planning. other was an apl-based model that was made available on the internal HONE system
https://www.garlic.com/~lynn/subtopic.html#hone

called the performance predictor that allowed world-wide sales and marketing people to do customer what-if scenarios (change workload, change hardware, etc ... in this period, APL was frequently used for a number of things that spreadsheets were later used for).
https://www.garlic.com/~lynn/submain.html#bench

some of the technology involved taking detailed instruction/page reference traces and running it thru very detailed even modeling that implemented a wide variety of page replacment algorithms .... numerous (global LRU) clock variations; local LRU; belady's OPT ... aka given perfect fore-knowledge ... always make the optimial replacement decision; true, exact LRU and others.

Part of this work was used to examine application program repackaging for better virtual memory operation (aka the transition that many applications were making in the 70s from real memory environment to virtual memory environment). In the mid-70s, a version of this technology was also released to customers as a product called VS/Repack. A early version of the vs/repack technology was also used in the morphing of apl\360 from real-memory environment to cms\apl in a virtual memory environment (and extreme highlighting of why the apl\360 memory management and garbage collection had to be redone for a virtual memory environment).

Besides extensive live performance test with variety of global LRU and local LRU replacement ... there was also extensive modeling down across wide variety of different applications as well as various kinds of global LRU and local LRU implementations. Except for some pathelogical scenarios ... global LRU always beat local LRU.

another interesting characteristic was that the various LRU approximation replacement implementations (whether global or local) ... it appeared to characterize them in how close they came to "true", "exact" LRU (i.e. with full instruction trace and storage reference ... it was possible to model "exact" LRU replacement ... as opposed to simply approximate LRU that implementations typically tried for).

For some reason, i came up with a slight of hand in a clock, global LRU implementations ... that seemed to be an improvment ... but the modeling people even found something unexpected. Rather than being almost as good as "true" LRU replacement (as all the other LRU approximate implementations had been) ... it turned out to be better than "true", "exact" LRU. Caused quite a bit of head scratching (this wasn't involved in the grenoble/cambrige, local/global LRU comparison)

The question in the grenoble/cambridge, local/global LRU replacement ... was whether a page belonging to the current task with a page fault .... out a better choice for replacement than all possible virtual pages in virtual memory. Pure local LRU replacement could never consider this as an option. Global LRU could consider all virtual pages currently resident in real memory as to possible optimal page for removal/replacement (even virtual pages belonging to other tasks).

Today's mainframe--anything to new?

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

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 9 May 2005 10:37:41 -0700
Subject: Re: Today's mainframe--anything to new?

Morten Reistad wrote:
Of course there is measurement and security overhead; but you are in error about performance and security monitoring being contrary. They are different views of the same observations. The challenge is to build the reference model, and describe what is "normal" and what is "abnormal"; and to also define dependency chains. If your power is out you will have lots of other alarms, which should be ignored by the on-site troubleshooters until power is restored. (but off-site troubleshooters want to see them, as they may have alternate facilities).

Likewise, you don't want to see noise from attacks you know you are immune against going up the chain of escalation. But there is still lots of chatter from old virii and worms on the Internet. For some unknown chatter you just want to block the IP address with just a routine message to operators/logs.

The point about being unobtrusive in monitoring is also important. Use of statistical methods is important.

two things that frequently affect performance, integrity, and availability (and frequently then are also considered security issues) are complexity and implicit design issues. implicit design issues may propagate into complexity and exposures later on ..... because implicit consideration may not faithfully survive multi-year product lifetimes (if they are implicit ... lots of people may not understand implicit issues later on).

i've frequently found when i make implicit things, explicit; along with simplifying complexity can improve performance, integrity and availability ... all at the same time.

ten some years ago ... i gave a talk at a usc graduate student seminar why tcp/ip didn't meet business critical dataprocessing requirements. this was about the time we were working with small client/server startup in silicon valley that wanted to do payment transactions ... misc. ref
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

more recently, i've frequently commented that much of the state-of-the-art may be comparable to the '60s aftermarket seatbelt situation ... and that safety and integrity is much better when it is built in from the ground up.

Exceptions at basic block boundaries

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

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 9 May 2005 12:40:17 -0700
Subject: Re: Exceptions at basic block boundaries

Michel Hack wrote:
NO -- as I said several times already, in S/370 the C&R bits have nothing to do with the MMU (as MMU is commonly understood, i.e. that part that deals with address translation). It is part of the memory subsystem -- the part that manages real addresses and selects physical memory chips/banks/whatever. Each physical page contains effectively 4097 bytes, the extra byte holds the storage key inherited from S/360 and the Change&Reference bits added when an MMU was added (360/67 and S/370). There is no separate "table"

-- these extra bits are accessed or set using special instructions (Set Key, Get Key, Reset Reference Bit and report its previous state). Lynn Wheeler explained much of this already. (On older machines this "Key array" used special hardware; on modern machines with industry-standard memory interfaces there may well be a table in memory somewhere, but it would be accessible only to microcode.)

on older machines ... there tended to be special key array ... in part because the feature was optional and orderable separately. except for 360/67, the 360s didn't have virtual memory support ... but you could order the optional storage protection feature ... which included the storage protection key array. this was basically 4bits per 2k bytes of real storage.

the ssk & isk instructions were privilege and available ... and i suspect that if the feature wasn't installed, ssk didn't do anything ... and isk just forced a zero value.

you could also optionally order storage protection feature with or w/o fetch protection. the default was just store protect. if you had the optional fetch protect ... it was a fifth bit in the storage key array ... which turned on/off fetch protection (using the same key value rules as store protect).

basically if storage protection feature was installed and a non-zero value was loaded into the PSW key field (a preivilege operation) ... then the non-zero PSW key field value had to match the storage (2k) area protection key.

360/67 required the storage protection feature be installed ... and they defined two addition bits per storage key (per 2k area of storage); one bit indicating storage area had been modified and the other bit indicate the storage area had been referenced. Bits could be reset using the same ssk instruction that set the storage key ... and interrogated using the isk instruction.

cp67 running on 360/67 provided virtual machine support ... including virtual 360/67 operation ... as a result it had to have private tables that shadowed the real machine values (for the virtual machine). cp67 for each 4k page location had an 8byte swaptable entry; basically two bytes of flags, two bytes that represented the virtual storage key values for the two 2k area keys, and a four byte field that gave the location of the page on disk (when it wasn't in memory). this was in addition to the 2byte PTE value.

any time cp67 would reset a change or reference bit ... it would first have to interrogate the current value(s) ... and save them to the virtual machines shadow in the coresponding "swaptable" entry. Anytime the virtual machine interrogated virtual storage keys (i.e. "isk" instruction) ... cp67 had to interrogate the real-value and OR it with the virtual machine backup value from the corresponding swaptable entry.

any time a virtual machine reset their virtual storage key change &/or reference values ... cp67 would have to first interrogate the real hardware value and OR the current hardware values with the saved cp67 values in the corresponding swaptable flag fields. it would then zero the hardware change &/or reference values ... and set the value specified by the virtual machine in the shadow key fields in the corresponding swaptable entries.

in effect, there were different change and reference shadow bits in a swaptable entry ... one pair for cp67 and one pair for the virtual machine. Anytime the virtual machine reset their bits ... the real hardware bits would be or'ed with the cp67 shadow bits and the real bits and the virtual machine shadows bits were zero. anytime cp67 reset changed &/or reference bits ... the real bits had to be interrogated and OR'ed with the virtual machine shadow bits before zeroing cp67's shadow bits and the real hardware bits.

If either cp67 or the virtual machine interrogated the bits ... the real hardware bits had to be OR'ed with the corresponding shadow bits.

Exceptions at basic block boundaries

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

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 9 May 2005 17:57:14 -0700
Subject: Re: Exceptions at basic block boundaries

in much the same way that cp67 had to maintain "shadow" virtual keys for virtual machines ... cp67 also had to maintain "shadow" segment & pagetables.

virtual machine would have "virtual" segment and page tables that mapped 2nd level virtual addresses to address of the virtual machine. cp67 would use virtual memory hardware to have virtual machine pagess at arbitrary real addresses.

when emulating a virtual machine operating system that supported its own virtual memory ... cp67 would build a shadow set of segment and page tables ... and use the DAT look-aside buffer hardware rules for managing the entries in the segment and page tables. Effectively, the shadow tables started with all the invalid bits set. the operating system in the virtual machine would load pointers to its memory translation tables and start execution ... which would immediately result in a fault that was fielded by the cp67 operating system. It would emulate the operation of TLB hardware for fetching the entry from the table in the virtual machine ... and then run it thru the "1st level" tables that mapped virtual machine addressed to real machine addresses (akin to the process that hardware TLBs use for loading entries).

Any time there was a 1st level virtual memory page replaced ... and the corresponding "real" PTE invalidated ... then all the shadow PTEs also got invalidated (since there wasn't a reverse mapping between individual first level tables and shadow PTEs). The emulation had quite a bit more reasons for invalidating shadow PTEs that possibly real hardware TLB might have ... akin to previous discussion where 168 had to replace a STO entry in the STO-stack and then all corresponding TLB entries that had been associated with the previous STO-stack entry.

the process was made recursive. there was a joint project between the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

and endicott to produce a virtual machine implementating 370 virtual memory architecture definition (some of the bits in the tables were different from that defined in 360/67, as well as control register usage, and some of the instruction definition).

This was before 370 virtual memory hardware was available and/or even virtual memory feature had been announced publicly.

The cambridge machine offered somewhat open time-sharing service
https://www.garlic.com/~lynn/submain.html#timeshare

that included various univ. students in the cambridge area (BU, MIT, Harvard, etc). the possibility of virtual memory for 370 was considered an extremely confidential corporate secret.

so there was the normal cp67 (cp67-l) running on the bare 360/67 hardware.

there was a modified version of cp67 (cp67-h) that ran in a 360/67 virtual machine ... and emulated the rules of 370 architecture definition ... rather than emulating the rules of 360/67 architecture definition .... however it mapped the 370 virtual machine formated PTEs into "shadow" tables that were in 360/67 format.

there was a highly modified version of cp67 (cp67-i) that ran in a 370 virtual machine ... that used 370 control instructions and 370 virtual memory architecture tables.

finally there was a cms that ran in a 370 virtual machine ... so the scenario was:
360/67 real hardware with real virtual memory support cp67-l ran on the 360/67 providing 360 & 360/67 virtual machines cp67-h ran in a 360/67 virtual machine providing 370 virtual machines cp67-i ran in 370 virtual machine providing 370 virtual machine cms ran in a 370 virtual machine

the above was operation and in regular use a year before the first 370 engineering machines were available with virtual memory hardware support.

360/67 didn't have a specific instruction for invalidating the hardware look-aside buffer. reloading the control register that was used for the virtual memory table pointer ... did flush all the entries in the look-aside buffer.

360/67 also didn't have separate instructions that allowed testing/changing page reference and/or changed bits. The bits were attached to the storage protection key array ... and so the standard isk & ssk instructions had to be used for accessing and manipulating the reference and change bits.

the original 370 virtual memory architecture defined PTLB (purge look-aside buffer), ISTE (invalidate segment table entry), and IPTE (invalidate page table entry). All three instructions were defined to also operate consistently on all hardware look-aside tables in a multi-processor configuration.

the low-end and mid-range 370s were primarily microcode. The 155 & 165 required extensive hardware for virtual memory support. Since 370s started shipping before virtual memory hardware was either announced or available. At one point the 165 engineers noted that they could ship basic virtual memory hardware support six months before they could have the "full" 370 virtual memory architecture supported. A business decision was made that all the extra features would be dropped from the 370 virtual memory announcement (for all 370 models ... even those models that had the extra features already implemented). PTLB was retained but ISTE and IPTE instructions were dropped. At least w/PTLB the flushing of the look-aside buffer was divorced from the instruction that changed the active virtual address apace (which was combined in the one instruction on 360/67).

370 also introduced the RRB instruction which tested the reference and change bits ... set the instruction condition code appropriately and zero'ed the reference bit. This was more efficient than retrieving the full key (w/isk), checking the specific bits, and resetting the key (w/ssk). the deficiency of the isk/ssk scenario was that it could miss bit state in multiprocessor environment ... where the RRB was defined as being multiprocessor consistent.

Blowing My Own Horn

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

From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: 10 May 2005 08:01:17 -0700
Subject: Re: Blowing My Own Horn

EA MacNEIL wrote:
"LPAR and PR/SM":
http://www.eservercomputing.com/ME2/Audiences/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=04EE2C13E2734B9F8970E4E393F5BC0E&AudID=174DB902288C4970A30C71C9427313A7

"Don't be Mislead by MIPS":
http://www.eservercomputing.com/ME2/Audiences/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=F0C43E81FF224DE0A44C45BC901CE3A7&AudID=174DB902288C4970A30C71C9427313A7

"The Case for Capacity Planning":
http://www.eservercomputing.com/ME2/Audiences/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=6D8F527A14924287A985059C3BFB4CCC&AudID=174DB902288C4970A30C71C9427313A7

and now for something a little bit different ....
https://web.archive.org/web/20190524015712/http://www.ibmsystemsmag.com/mainframe/stoprun/Stop-Run/Making-History/

recent post on genesis of pr/sm and lpar
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?

recent posts on genesis of capacity planning (evolution from performance maangement)
https://www.garlic.com/~lynn/2005h.html#1 Single System Image questions
https://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries

Key pair & Certificate lifetimes

From: lynn@garlic.com
Newsgroups: comp.security.misc
Date: 10 May 2005 08:41:50 -0700
Subject: Re: Key pair & Certificate lifetimes

John wrote:
Not necessarily so. Good PKI systems allow for a renewal of the certificate, whilst keeping the original keypair.

aka the certification of the public key in a certificate is somewhat independent operation of the certification of other information that might also be certified in the certificate. the reasonable lifetime of a public/private key pair can be totally unrelated to reasonable lifetime of any other information that is also certified in a certificate ... aka my previous posting
https://www.garlic.com/~lynn/2005g.html#39 Key pair & Certificate lifetimes

investigation into certificates with things like 8hr or 24hr lifetimes (because some of the certified information may reasonably expected to possibly have very short lifetime).

note that PKI and certification authority infrastructure design point was to address scenario where the relying party had not other recourse to the actual online or offline information about the subject (aka the offline electronic version of letters of credit from sailing ship days).

PKIs weren't originally viewed as substituting for situations where the relying party might have direct access to the real information (rather than having to relying on stale, static substitute information from certificates).

One of the scenarios about PKIs from the mid-90s ... would a relying party prefer to know

1) only know that the subject had a bank account from a specific institution at some point in the past (possibly several months) ... aka the stale, static, redundant and superfluous certificate scenario

2) have a real time response from the financial institution ... not only does the subject have a current bank account ... but the financial institution has determined there is sufficient balance to cover the transaction ... and has actually gone ahead and debit the account for the amount of the transaction.

There were actually some factions that appeared to be convinced that the first scenario was much more valuable than the second scenario.

Thou shalt have no other gods before the ANSI C standard

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

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 10 May 2005 15:53:32 -0700
Subject: Re: Thou shalt have no other gods before the ANSI C standard

Brian Inglis wrote:
Check to see if there were any changes in or near your house about that time of the year, and if not, email the FCC (fcci...@fcc.gov) and ask them if they know of any local changes to transmission sources, broadcast power, or patterns starting about that time of the year and day, as it started interfering with your AM reception. That's part of their job, and they should be knowledgeable and helpful.

one of the things we were doing in hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt

we put in tdma satellite system ... and had a transponder on sbs4 ... which went up on 41-d
http://www.nasa.gov/mission_pages/shuttle/shuttlemissions/archives/sts-41D.html

with some 4.5m dishes. there was public hearing about zoning for the dishes in various places ... and people showed up with very strong complaints about the radiation from the dishes. the dishes had 25watt transmitter with uplink power control ... nominal operation at maybe 1/3rd ... and only go to 25watts when there was heavy rain absorbtion.

calculation was done that if a crane suspended somebody directly above the dish when operating at full power ... they would get less radition than the neighborhood was constantly receiving from the nearby 50,000 watt FM transmission tower.

Today's mainframe--anything to new?

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

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 10 May 2005 16:31:12 -0700
Subject: Re: Today's mainframe--anything to new?

jmfbah...@aol.com wrote:
That change would have bugged me. I can't begin to describe the change of the feel of TOPS-10 when it went from master/slave to SMP. The difference is rather like moving one's seat from the back of a turtle to an SST's nose.

the original vm370 smp support had some fine-grain locking ... but had a global lock on much of the kernel. this bore some simularities to some of the smp kernel/supervisor spin locks of the period .... except there were a small number of very high-use/fastpaths that were enabled for concurrent kernel smp execution.

the other difference was that the majority of the global kernel locks from the period were "spin" locks ... a processor that attempted to enter the kernel would spin on the kernel lock until is was made available by some other processor. this is what i called a bounce lock (instead of spin lock)
https://www.garlic.com/~lynn/submain.html#bounce

where if a processor didn't obtain the (almost) global kernel lock ... it queued an extremely lightweight thread and went looking for other activity. as a result there was almost no measurable smp "overhead" (like you might find with spin locks). it also had the side effect of increasing the mip rate on high end cache machines ... since there was a tendency if a specific processor got into kernel mode ... and other processors also needed kernel services ... these other kernel services requests tended to queue against the processor already performing kernel services (better cache hit rate ... and therefor higher mip rate).

this continued for a couple of releases and then had a major rewrite ... which supposedly vastly improved the smp thruput .... but most customers saw 10-20percent thruput degradation. One large federal TLA was especially concerned.

It turns out that the smp rewrite for this release was targeted at a very specific customer situation. 3081s had been originally targeted at never being available in non-smp version. the problem was that the airline control program (acp or its more modern name transaction processing facility or TPF) didn't have smp support. there were some customers running tpf on multiple 370/195 because they needed highest thruput possible.

so one way of getting more thruput for tpf out of 3081 ... was to operate the 3081 under vm .... and provide two separate single-processor virtual machines .... and run two copies of tpf in the different virtual machines (in cluster) configuration.

another mechanism was to start overlapping some of the virtual machine emulation functions. normally, i/o operation emulation tends to be performed synchronously/serially with virtual machine execution. the smp enhancement for this particular release would split of things like SIOF and ccw translation as an independent task request, broadcast a signal processor and then resume virtual machine execution (instead of finishing the i/o emulation). other processors would get the broadcast signal processor ... and pick up the work request that had just been passed off.

the downside was that sigp broadcast, interrupt handling, and associated pathlength was started to consume 10% of total processing time of every processor in the smp complex (overhead which had not existed before). the only configuration that benefited was customer account who's workload consisted almost totally of a single processor guest operating system.

For many customers the significant diversion of processing power was obfuscated by some changes made to the way i/o interraction was performed on 3270 terminals .... such that multiple i/o operations tended to be batched as one operation ... making the 3270 terminal interactions appear to be much more responsive.

the problem with this specific large federal TLA was that it didn't have any 3270 terminals ... it was almost totally a glass-TTY operation. minor past passing posting
https://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?

and therefor there was no improvement in perceived 3270 interactions to mask the loss in processor capacity.

Single System Image questions

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 11 May 2005 05:13:49 -0700
Subject: Re: Single System Image questions

jmhbahciv@aol.com wrote:
I always have envisioned a global network facility that could take any user job that had a requirement for a million CPU-hours [well, back then I thought I was exaggerating] and return the results to the user when done. Imagine the efficiency improvements in research if scientists and their ilk didn't have to wrestle with computation glitches.

some topic drift

world's biggest grid goes thru its paces
http://www.vnunet.com/news/1162829

The World Community Grid (WCG) grid computing initiative started by IBM last November has added 100,000 PCs, workstations, and servers.
http://www.cbronline.com/article_news.asp?guid=BEAA2DE1-5D68-4BC6-A95

200 hundred digit number factored
http://en.wikinews.org/wiki/200_digit_number_factored

Description of a new old-fashioned programming language

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

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 11 May 2005 05:51:50 -0700
Subject: Re: Description of a new old-fashioned programming language

John Savard wrote:
My mythical architecture, like the IBM 360, uses base registers with most addresses. So only address constants, which may occupy either 32-bit words or 64-bit doublewords, need to be marked for relocation - and that would also apply to making them external.

In my language, usually, the same things would be external as in FORTRAN, subroutines and common blocks, but other things could be as well. I didn't see either the language or the architecture as requiring fundamentally new technology for loaders.

Naturally, with a 512-bit PSW, my architecture has a bit more to save and restore during every interrupt. When it has anything to save and restore at all, given register renaming.

the low-end and mid-range 360s & 370s had vertical microcoded engines ... look very much like normal instruction streams. they nominally avg. about ten native instructions per 360/370 instruction executed (i.e. the mip rate of the native processing engine needed to be ten times the rated 360/370 mip rate)

the high-end 370 had horizontal microcode engines ... they tended to directly activate operation of various hardware components ... like start move of some piece of data from hardware component to another hardware component. programmer then had to know how many machine cycles such operations take ... and not activate an operation until enuf machine cycles had passed before operating on data. these machines normally referenced the avg. number of machine cycles per 370 instructions (since a number of things were being overlapped). The transition from 370/165 to 370/168 involved going to faster main memory technology (2mics to about half a mic) ... but the machine cycle remained the same. However, there was optimization in instruction decode/execution and the avg. machine cycle per 370 instruction was dropped from about 2.1 to 1.6.

One of the areas that was getting new microcode was the various oeprating system assists ... like ECPS on the 148/4341 ... where 6k bytes of vm370 kernel code ... representing about 75% of kernel execution was moved to 6k bytes of native microcode (with a corresponding 10:1 speedup).
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

The horizontal micocoding of the higher end machines was a lot more complex and difficult. One of the things that Amdahl introduced was "macrocode" ... which was half-way between the horizontal microcode and normal 370 instructions. It looked and tasted a lot like a subset of 370 instructions ... along with eliminating support for self-modifying instruction streams (which had been causing a big performance hit in high-end machines ... constantly checking if the previous instruction had modified the following instruction). It allowd Amdahl to provide much more agile adaption of his machines than the corresponding ibm machines ... which were still somewhat bottlenecked by difficulty of horizontal microcoding.

One of the early features Amdahl implemented with macrocode was its hypervisor support .... allowing logical partitioning of the machine running independent operating systes. It was somewhat a subset of much of virtual machine function moved into the "macrocode" of the machine hardware. One limitation (compared to virtual machine support) was that it didn't do any paging ... it dedicated contiguous portion of real storage with "base & bound" relocation.

ibm was forced to respond to Amdahl's hypervisor with pr/sm on 3090 ... which was a much more complex undertaking ... having to be implemented in native horizontal microcode.

a couple recent mention of pr/sm (and lpars):
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2005h.html#19 Blowing My Own Horn

general collection of past m'code postings
https://www.garlic.com/~lynn/submain.html#mcode

couple more Q's on basic public key encryption techniques

Refed: **, - **

From: lynn@garlic.com
Newsgroups: sci.crypt
Date: 11 May 2005 08:16:12 -0700
Subject: Re: couple more Q's on basic public key encryption techniques

Carlos Moreno wrote:
Public-key encryption algorithms are extremely slow compared to symmetric encryption algorithms. That's why the most common use for public-key algorithms is just to encrypt a session key -- a session key is the encryption key to be used for the rest of the communication during the session.

public key infrastructures have also frequently assumed certification authorities and digital certificates as part of the basic operation.

the original design point for certificates was the offline, email paradigm ... where a relying/receiving party dials up their local electronic post office, exchanges email, and hangs up. they then find themselves attempting to deal with some email from somebody they have never communicated with before ... and have no prior knowledge about. appended certificates from trusted 3rd parties would provide some nominal information (when there was no other information available by any other means) ... akin to letters of credit from sailing ship days.

somewhat in the early '90s, the identity x.509 certificates wan into some problems. certificate authorities were finding that it was difficult to predict what all future relying parties might be expecting ... and so there was a tendancy to grossly overload such certificates with enormous amounts of privacy information.

in some cases, by the mid-90s ... there was beginning to be realization that digital certificates enormlusly overloaded with identity information represented significant liability and privacy concerns. as a result there was somewhat the appearance of relying-party-only digital certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

which only had certification concerning something like an account number and a public key. however, since it was no expected that thepub relying party to have all the relavent information indexed by the account number ... it was now apparent that the digital certificate was redundant and superfluous (and violated the original design point and requirement for digital certificates) ... aka the base message and a digital signature would surfice w/o requiring a redundant and superfluous digital certificate to be appended. some discussion of not needing redundant and superfluous digital certificates in public key infrastructures
https://www.garlic.com/~lynn/subpubkey.html#certless

another issue was that even a simple relying-party-only have been on the order of 4k to 12k bytes in size ... and were being proposed for appending to every financial transactions ... which had a nominal size of 60-80 bytes. in the financial transaction scenario, no only were any digital certificates redandunt and superfluous (negating the assumption that the relying/receiving party have no prior knowledge of the subject ... like there didn't exist a relationship between a banking customer and the banking customer's financial institution) but the appended digital certificate could represent a factor of one hundred times payload bloat for a standard financial transaction.

in this scenario ... any nominal public key processing overhead was totally dwarfed by PKI digital certificate payload bloat.

Crash detection by OS

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

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 11 May 2005 15:55:26 -0700
Subject: Re: Crash detection by OS

Del Cecchi wrote:
Since the "OS" not some magic thing but just instructions, if the processor is stuck in a tight loop, perhaps even in the OS code, any additional crash detection code will not execute. It takes an external action like an interrupt or something. Look up "watchdog timer" at least that's what we used to call them.

for ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

besides distributed lock manager, we had to do cluster membership management ... removal of member on possible failure as well as re-integrating a member back into the cluster.

we were able to draw on decades of experience with mainframe clusters ... as well as some of the vax/cluster history. for the distributed lock manager, we collected some information from some of the DBMS vendors that had done vax/cluster based implementations ... and had their list of things done wrong in vms. we had the advantage of a clean slate and starting from scratch.

for cluster membership management there was heartbeat timer (another name for watchdog) mechanism. a problem then becomes shooting down a cluster member that is believed to have failed. the long-time model has been mainframe loosely-coupled (cluster by any other name) where different processors had shared concurrent access to the same disk drives (dating back to the 60s).

the age-old scenario that you try to handle ... is somebody pushes the processor "STOP" button on the front-panel when the operating system is one instruction in front of a disk start i/o operation instruction. the rest of the cluster eventually decides the affected processor has failed ... goes into recovery and take-over ... and removes the "failed" processor from the active cluster membership ... and possibly re-assigns responsibility for resuming processes that were in progress on the failed complex.

the scenario then has the "START" button pressed for the "failed" processor and it proceeds to the disk start i/o operation. allowing the successful execution of such a disk start i/o operation may obliterate valid information that has gone on while the processor was in the stop state. For this scenario ... the cluster mechanism needs a methodology that fences off processors that are believed to have failed (i.e. removed from standard cluster membership).

misc. old ha/cmp reference:
https://www.garlic.com/~lynn/95.html#13

some number of past posts on distributed lock manager (or DLM ... which is unrelated to recent posts concerning DRM):
https://www.garlic.com/~lynn/2000.html#64 distributed locking patents
https://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
https://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001.html#40 Disk drive behavior
https://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002e.html#67 Blade architectures
https://www.garlic.com/~lynn/2002f.html#1 Blade architectures
https://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
https://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
https://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004m.html#0 Specifying all biz rules in relational data
https://www.garlic.com/~lynn/2004m.html#5 Tera
https://www.garlic.com/~lynn/2004q.html#10 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2004q.html#70 CAS and LL/SC
https://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
https://www.garlic.com/~lynn/2005.html#55 Foreign key in Oracle Sql

How do you get the chain of certificates & public keys securely

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

From: lynn@garlic.com
Newsgroups: comp.security.ssh
Date: 11 May 2005 17:34:15 -0700
Subject: Re: How do you get the chain of certificates & public keys securely

Richard E. Silverman wrote:
By "a priori trusted," I meant trusted via whatever mechanism outside the PKI proper you are using as the root of your trust (e.g. it came with the OS; you got it from your friend and checked the fingerprint over the phone, etc.). Sorry; I thought that was obvious.

basically relying parties .... entities that must put trusts in digital signatures maintain verification public keys in a trusted public key storage. there are a number of mechanisms that relying parties may be motivated for loading public keys into such a trusted public key storage.

some number of the implementations have trusted public keys that are used to directly verify subject digital signatures.

PKIs and digital certificates were originally created to address the scenario of the offline email environment from the early 80s ... where relying party (recipient) dials up the local electronic post office, exchanges email, and hangs up. The recipient is then dealing with an email from a total stranger that had no prior communication or knowledge of. This is the electronic analogy of the letters of credit from the sailing ship days ... where the certificate takes the place of having no other access to any information regarding the sender of the email.

In the early 80s, offline scenario ... the relying parties loaded public keys from 3rd party certifcation authories into their trusted public key storage. Then instead of directly using the public key for verifying the digital signature on the email ... they used the CA's public key for verifying a digital signature on the digital certificate (attached to the email) ... and then using the public key from the digital certificate for verifying the digital signature on the email (at least one level of indirection).

In the early 90s, there was some tendency for CAs dealing with x.509 identity certificates to increase the identity related information that might be included in a digital certificate ... not having perfect fore knowledge regarding what information future relying parties might actually need about a subject.

In the mid-90s some institutions were starting to become concerned about the liability and privacy issues associated with excessive privacy information that might be contained in a x.509 identity certificate. One solution was retrenching to relying-party-only certificaes
https://www.garlic.com/~lynn/subpubkey.html#rpo

which basically contained some form of account number and a public key. When a relying party received such an attached certificate, they used the account number to look up the actual information about the sender. However, this method violated the original premise of the purpose of digital certificates (the relying party having no prior knowledge of the sender) ... and it was then trivial to demonstrate that any such digital certificates and redundant and superfluous.

one of the infrastructures that looked at such relying-party-only certificates were some financial operations ... where there ware specifications for doing digitally signed payment transactions with attached digital certificates. one issue was that the nominal size of such payment transactions were 60-80 bytes in size ... and the digital certificates were on the order of 4k to 12k bytes. Not only did the relying party (the consumer's financial institution) already have all the related information contained in the redundant and superfluous digital certificates ... but attaching such a redundant and superfluous certificate to every payment also represented a factor of 100 times increase in payload bloat ... aka the consumer creates a payment transaction and digital signs the transaction ... then it packages up the payment transaction, the digital signature and the (enormous payload bloat redundant and superfluous) digital certificate ... and sends off the triple to the consumer's financial institution. The consumer's financial institution recieves the package, pulls the account number from the payment transaction, and reads all the information on the account (including the onfile public key). The redundant and superfluous digital certificate is discarded (w/o being used) and the digital signature is verified using the onfile public key. misc. description of certificate-less public key infrastructures
https://www.garlic.com/~lynn/subpubkey.html#certless

another example of a trusted PKI infrastructure is the current operation of the nominal SSL domain name server digital certificate
https://www.garlic.com/~lynn/subpubkey.html#sslcert

we were working with this small client/server startup in silicon valley that wanted to do payment transactions on their server:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

they also had this thing called SSL. As part of working on this stuff that eventually became called e-commerce ... we had to do some number of audits on these things called certification authorities.

A typical operation has somebody applying for a domain name server certificate and supplying some amount of identification information. As part of the certifying process, the certification authority has to go thru the error-prone, complex, and costly process of matching the supplied identification information with the identification information on file with the domain name infrastructure for the registered domain name owner.

Because of this expensive process and some number of other reasons ... there is a proposal that domain name owners register a public key with the domain name infrastructure as part of registering a domain name. Now when somebody applies for a SSL domain name server certificate they can digitally sign the application. The certification authority now can convert an error-prone, costly and complex identification process into a simple and straight-forward authentication process by retrieving the onfile public key from the domain name infrastructure for verifying the certificate application (note there is no certificate required when there is direct, online access to the actual information rather than being forced to make do with stale, static, redundant and superfluous digital certificate).

There is somewhat of a catch-22 for the certification authority infrastructure .... if it turns out that the certification authority can directly retrieve onfile, trusted public keys from the domain name infrastructure (for purposes of establishing the trust in domain name certified informationi) ... then possibly other parties might realize that they could also directly retrieve such onfile public keys ... negating the requirement for hsving SSL domain name certificates at all.

This is the scenario where the certification authority industry is looking at having the certification trust root be dependent on onfile, certificate-less public keys .... but onfile, certificate-less public keys could also result in negating the requirement for having the certificates at all (you no longer having requirement for stale, static standin ... if you have direct access to the real information).

Crash detection by OS

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Crash detection by OS
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 12 May 2005 09:58:11 -0600

"Eric P." writes:
Do you recall what the vendors thought was done wrong in the vms lock manager? I recall there was a brouhaha with Oracle over locking around 1985 or so but never found out what it was. I assume it could not be that fail-restart scenario as vms does handle it with quorums.

in the late 80s, four major vendors in the market segment were ingres, oracle, informix, and sybase (although not all with concurrent cluster operation ... some with simpler fall-over) ...

there was this top ten list ... might be in a box someplace.

One (that i remember some details about wasn't that vax/cluster didn't do fail/restart ... but) when a member did appear to fail ... there was an extremely long time to recovery/reconfiguration with the surviving members. one of the things was making cluster recovery/reconfiguration of members happen much faster.

there is lots of history leading up to that ...
https://www.garlic.com/~lynn/submain.html#systemr

having done some of the work for system/r (the original sql/relational) implementation in the late 70s, early 80s.

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

Dealing with warning that certifcate can't be trusted?

From: lynn@garlic.com
Subject: Re: Dealing with warning that certifcate can't be trusted?
Newsgroups: comp.security.misc
Date: 14 May 2005 05:13:39 -0700

murdocj wrote:
I have a basic question about dealing with certificates. Just yesterday (May 11th) I started getting an popup from Firefox saying that the issuer of the certificate of the hotmail site was unknown. This is weird because I've been accessing hotmail for months via Firefox, so I was worried that somehow I had been redirected to another site.

So my question is, when you get an error like this, how do you resolve what to do? How do you determine if you really should trust the certificate or if someone is trying to mislead you?

so three things could have changed

1) different certificate from the webserver 2) different firefox 3) firefox honors some certificate expire date

basically digital certificate are a form of standin trust. there design target was the offline email of the early 80s; recipient dials up their local electronic postoffice, exchanges email, hangs up ... and now much process email. They have new email from total stranger that they've never communicated with ... and have no resources for determining anything about the brand new correspondence.

the basic digital signature infrastructure has relying party/recipient with trusted public key repository for validating digital signatures. the trusted repository contains some information about the associated entry (like who they are, their current balance, etc) and the associated public key.

in the case of the offline email scenario from the early 80s with new communication from total stranger ... they needed some standin ... analogous to letters of credit from the sailing ship days. this is the digital certificate .... instead of just having direct information about the communicating parties in their trusted repository, they can also have information about trusted certifying authorities in their repositories. trusted certification authorities certify some information about an entity and package it along with the entities public key in a digital certificate.

no when relying party gets some correspondence ... they have the basic message, the digital signature on the basic message and an attached digital certificatee (signed by a certification authority). They retrieve the public key of the certification authority from their trusted repository and verify the digital signature on the digital certificate, they then retrieve the sender's public key from the digital certificate and verify the digital signature on the base correspondence (and use whatever information about the sending entity contained in the digital certificate).

Cerfified information tends to have expiration dates (frequently they are good for a year). Also some products ship trusted public key repositories embedded in their product ... the public keys in the embedded respositories also can have expiration dates.

possible (valid) reasons for the error:

1) hotmail's digital certificate could have expired and they had to get a new digital certificate. for some reason the new digital certificate could be signed by a certification authority that firefox doesn't know about (ask to view the digital certificate and see if it is newly issued and the identity of the certification authority).

2) a new firefox could have shipped ... and the contents of its embedded trusted public key repository could have changed (go look at the public keys in firefox's embedded trusted repository)

3) the public key (included in firefox's embedded trusted public key repository for the certification authority used for hotmail's digital certificate could expired. there are some number of embedded trusted repositoriies that are shipping with expired certification authority public keys ... an ongoing issue is should browsers and other products ignore such expiration dates ... or conform to specified processing defined for expired information.

the traditional mechanism for dealing with questionable information is to examine it closely ... and then see if it can be corroborated via other means.

Query on Load Balancer with SSL

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Query on Load Balancer with SSL
Newsgroups: comp.protocols.tcp-ip
Date: Sun, 15 May 2005 12:29:04 -0600

kejoseph writes:
I am trying to setup Load Balancer with SSL and have a few of the following very basic questions -

1. What does SSL encrypt ? The entire packet or just the payload (data) ? I assume its the latter but just want to confirm. 2. Can I use the Load Balancer (F5 or Cisco) to do pass-throught SSL. Meaning that the Load Balancer will NOT decrypt the packet but only load balance each request to the servers. This is the opposite of the load balancer decrypting the packet and passing the plain-text packet to the servers. I basically want SSL to go from the clients browsers all the way to the servers.

it can't encrypt the ip packet header with the to & from address (or tcp header) ... or there would be no way for any of the intermediate hops for routing the packet (aka packet would never make it thru the internet).

the issue is at what point does the load balancer ... do its thing. ssl exchanges a secret key for encrypting the (tcp session) packet payload ... and both end points have to be aware of the secret key for processing the payload.

if you are load balancing across multiple backend servers ... and only load balance at initial setup ... then the remaining packets in the session will continue to route between the same two end-points (and therefor you will have the two end-points that setup the session and know the session secret key ... will not change).

if you are load balancing across multiple backend servers ... on every packet ... then you have problems with the end-points for the established session not remaining the same (and it starts to break ... regardless of whether ssl is encrypting session packet payload or not).

in general, the load balancer should be establishing/fixing the route at tcp session setup ... and then the two end-points remain the same for the lifetime of the session. in this situation ... the fact that SSL (or anything else for that matter) is encrypting the payload within a tcp session should be transparent.

SSL has had problems with "application" firewalls ... where there is effectively a mini-webserver in the firewall ... which acts as a psuedo webserver to the real client, sanitizes the data/payload ... and then resends it ... acting as a psuedo client to the real webserver (i.e. there are two independent tcp sessions ... one between the real client and the application firewall ... and another between the application firewall and the real server). The webserver's private key (on which an SSL session is based) is normally only at the real webserver ... meaning the application firewall can't impersonate the real webserver when talking to the real client (one of the primary points of SSL ... was that only the real webserver has access to the specific private key ... preventing other entities from impersonating the real webserver ... including application firewalls).

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

IBM 1130

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 1130
Newsgroups: alt.folklore.computers
Date: Sun, 15 May 2005 19:53:29 -0600

Joe Morris writes:
The term commonly used for this was "mask".

ISTR that the 2741 had an optional feature that was probably extra-cost (the details of which are long gone from my memory) to suppress the local copy, allowing you to avoid having to make the application type the mask prior to soliciting a password.

And there was a special feature available that while not providing any full-duplex data capability, did allow the ATTN key to be used to interrupt output. My PPOE was a heavy user of ATS (and I used it to write my MS thesis; the first computer-printed theses to be accepted by the Graduate Office), and having that interrupt capability was a lifesaver.

dug out users guide ... there was some manual that actually gave the feature codes ... but can't find it at the moment.

pg. 17:
2741 CHARACTERISTICS

The IBM 2741 Communication Terminal consists of an IBM Selectric typewriter mounted on a typerwriter stand. The stand includes the electronic controls 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.

...

pg. 29:
7. Type your password, followed by a carriage return; the password may be edited. If the 2741 is equipped with the Print Inhibit feature, the password is not typed at the terminal as the keys are hit. The Print Inhibit feature applies only to the typing of a password. If the terminal is a Teletype 33 or 35, three lines of characters are overprinted before you are allowed to enter your password.

...

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

Software for IBM 360/30

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Software for IBM 360/30
Newsgroups: alt.folklore.computers
Date: Mon, 16 May 2005 06:36:15 -0600

Gene Wirchenko writes:
I say "boot", not "boot up".

IBM appears to have liked acronyms. Care for some DASD? (It sounds as if it should be a type of or d'oevre.)

note that IPL is the button that did initial program load ... someplace there were even some IMPL buttons ... initial micro-program load (aka microcode)
https://www.garlic.com/~lynn/submain.html#mcode

and of course, DASD is direct access storage device ... back when there were lots of other form factors besides disks ... drums, data-cells, optical photostore, etc. There was generalized architecture for supporting the technology ... regardless of the form factor.
https://www.garlic.com/~lynn/submain.html#dasd

and
https://www.garlic.com/~lynn/subtopic.html#disk

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

Software for IBM 360/30

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Software for IBM 360/30
Newsgroups: alt.folklore.computers
Date: Mon, 16 May 2005 06:38:47 -0600

... oh, and i stumbled across an online version of mike's jargon
http://www.212.net/business/jargon.htm

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

some walk down history lane

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: some walk down history lane
Date: Mon, 16 May 2005 08:34:40 -0600
Newsgroups: bit.listserv.vmesa-l

Systems Programming for 8 Year-olds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems Programming for 8 Year-olds
Newsgroups: bit.listserv.ibm-main
Date: Mon, 16 May 2005 15:26:50 -0600

R.Skorupka@ibm-main.lst (R.S.) writes:
I had similar situation: My son had to prepare some presentation and he chose mainframes as the topic. I delivered some pictures (BTW:I spent almost 1 hour to find in Internet good picture of punched card, and next half when searching for BIG photo of z/990 !!!), some "funny" facts - like "mainframe is bigger than fridge ...and there is refrigerator inside!", or "in the past mainframe had 64kB of RAM. Yes, it's 1000 times less than the oldest PC in your class." Another : "mainframes are veeeery expensive, entry level solutions is over 1M$, and believe me: no game will run on it".

... my first personal computer at the university was a 64kbyte (2**16) 360/30 that i had all to myself from 8am sat. until 8am monday morning (monday classes were a little difficult after being up for 48hrs straight) ... almost 40 years later i'm typing this on 4gbyte (2**32) personal computer (2**16 increase in amount of storage).

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

Security via hardware?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security via hardware?
Newsgroups: alt.computer.security,alt.folklore.computers
Date: Mon, 16 May 2005 20:09:14 -0600

misc. references
https://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
https://www.garlic.com/~lynn/2005g.html#54 Security via hardware?
https://www.garlic.com/~lynn/2005g.html#55 Security via hardware?
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?

the issue isn't worrying about the certification of who is using an authentication hardware token .... since there are huge number of existing business processes that are related to registering authentication information about parties in established relationships .... but this is worrying about the certification of the hardware token that is actually used to generate the digital signature.

rather than replacing large number of existing business processes related to establishment of relationships between entities (employer/employee, financial institution/customer, etc) ... this looks at the integrity certification of hardware token used in such authentication processes.

the nominal authentication process for digital signatures is straight-foward, something you have authentication ... from three factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

where the validation of a digital signature with a public key implies that the subject entity has access to and use of the corresponding private key. however, public key authentication registration frequently overlooks fundamental integrity issues regarding the access and use of such private keys .... are they purely software; are they contained in hardware token; were they generated inside the hardware token and have never existed outside the confines of a hardware tokem; if a hardware token is involved, what is the integrity of the hardware token.

There are several fundamental technical and business process integrity issues involved in the production, management, and use of private keys which can significantly affect the overall integrity of any operational infrastructure. This fundamental infrastructure integrity dependencies have been frequently overlooked when trying to convince infrastructures to eliminate there existing business relationship and registration processes (frequently involving paradigms that have evolved over hundreds of years) and instead substitute questionable certification authorities as the mechanism that establishes business relationships.

To some extent, the AADS model
https://www.garlic.com/~lynn/x959.html#aads
freed us up from focusing on replacing deeply ingrained business process relationship management (with certification authorities), allowing us to concentrate on other signficant infrastructure integrity issues. One such example is the business process knowledge about hardware token integrity characteristics used in authentication operations.
"Colorado Inventors Develop Method of Incorporating Security Certificate"

US Fed News (05/13/05)

Anne M. Wheeler and Lynn Henry Wheeler have developed a method of providing for reliably identifying a Security Profile of a device that generates digital signatures. According to the U.S. Patent & Trademark Office: "A method of providing for reliably identifying a Security Profile of a device that generates digital signatures includes for each of a plurality of devices manufactured in a secure environment, recording together the public key with a Security Profile of the manufactured device and generating a digital signature therefor to collectively define a Security Certificate, the public key and Security Profile thereby being securely linked together, (b) before each manufactured device is released from the secure environment, incorporating its respective Security Certificate into the manufactured device such that the Security Certificate is sent with a digital signature that is generated by the manufactured device using the private key." The patent has been assigned to First Data Corp., Greenwood Village.

misc. AADS related patent activity:
https://www.garlic.com/~lynn/aadssummary.htm

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

Software for IBM 360/30

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Software for IBM 360/30
Newsgroups: alt.folklore.computers
Date: Tue, 17 May 2005 04:09:11 -0600

coda writes:
No, you'll find no IMPL button on a System/360 Model 30. It's control store was Card Capacitive ROS. System/360's used a variety of read only control stores, so changing the microcode meant replacing parts (e.g., with parts that were personalized by punching holes in a card). Later models like the 85 and 25 had writable contol stores, the 85 using a volatile SRAM array and the 25 using a part of core memory.

sorry, i didn't mean to imply that the 360/30 had an impl button.

slight topic drift ... some past 545 tech sq. postings
https://www.garlic.com/~lynn/subtopic.html#545tech

one of the operations at 545 tech sq, was the boston programming center on the 3rd floor (before being absorbed by the vm370 group and then moving out to old sbc bldg. in burlington mall).

one of the things the boston programming center did was cps (conversational programmin system) ... and they also made microcode changes available for the 360/50 that improved the performance of cps.

impl button really didn't come into its own until after shugart invented floppy disks for microprogram loads.

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

Systems Programming for 8 Year-olds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems Programming for 8 Year-olds
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 17 May 2005 04:29:57 -0600

cfmtech@ibm-main.lst (Clark F. Morris, Jr.) writes:
Since there is a version of Star Trek on either the CBT tape or the MVT mods tape and a game actually became a production program in one shop as a means of getting sales people comfortable with the computer, I don't believe you. Granted these were for a standard 3277 or 3278 so the graphics weren't wonderful but there were games.

adventure was done in Fortran. i believe shortly after it was available on sail/pdp10 at stanford ... somebody from tymshare had ported it to cp/cms.

tymshare was one of the large cp/cms timesharing services in the 70s.
https://www.garlic.com/~lynn/submain.html#timeshare

possibly one of the largest such facility was when the US HONE datacenters were consolidated in cal. ... not very far from the tymshare datacenter. HONE was the internal timesharing service that provided support for world-wide sales, marketing and field people (for instance, starting with the 370 115/125 ... a salesman couldn't order a machine that hadn't been processed by a hone application). misc. past HONE postings
https://www.garlic.com/~lynn/subtopic.html#hone

... in any case ... i got a copy of adventure from tymshare very sortly after they had done the cp/cms port and I made it available internally. sort of as a policy ... I would distribute the executable internally ... but only send the source to people that had finished the game. At one point there was some claim that internal corporate productivity world-wide had significantly dropped because so many people were playing adventure on cp/cms. STL lab. declared a 24hr amnesty/grace and would then heavily penalize people caught playing adventure during normal working hrs.

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

Attacks on IPsec

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Attacks on IPsec
Newsgroups: sci.crypt
Date: Tue, 17 May 2005 05:03:03 -0600

"Simon Johnson" writes:
Only later did it get bogged down by the "idiot non-experts" who thought that it would be more efficient if integrity was optional, no-one needs anonymous Diffie-Hellman anyway, PKI will save the world, it'll only be used in tunnel mode, ... . Gah. The original group disown what is only now starting to be deployed.

my impression was that ipsec was being worked on for awhile in ietf ... but it involved hitting everybody's (normally kernel-based) stack (which in turn implies replacing everybody's kernel).

i think it was the ietf fall '94 meeting where what is now called VPN was introduced in gateway working group meeting. this had the advantage over end-to-end ipsec ... by not having to replace everybody's kernel. some amount of contention was sort-of resolved by labeling VPN as "light-weight" ipsec (as opposed to the regular, heavy-weight ipsec).

about that time-frame we were asked to work with a small client-server startup in silicon valley that wanted to have the server do payment transactions
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

and they had this thing they called SSL. The SSL implementation also had the characteristic that it didn't require replacing the kernel in order to achieve some level of added internet integrity.

now, the nominal design point for digital certificate-based PKI was the offline email world of the early 80s; somebody would dialup their local electronic post-office, exchange email, and then hangup. The issue if the recipient/relying-party had email from some entity that they never had communicated before ... how were they to establish any information about the sender in this offline, disconnected world communicating for the first time with a complete stranger (aka the letters of credit model from the sailing ship days).

nominally, in normal entity relationship management ... you have established some information resource about the entities you are dealing with (things like business accounts, financial accounts, accounts payable, etc) and have recourse to information about the party you are dealing with (and/or are able to directly contact responsible agencies for that information). the issue in the offline, disconnected environment, with first-time communication between two parties that have never communicated before and have no prior knowledge about each other ... how to provide some substitute for having the real information.

misc. posts about ssl certificate-based environments
https://www.garlic.com/~lynn/subpubkey.html#sslcert

misc. posts about public key certificate-less based environments
https://www.garlic.com/~lynn/subpubkey.html#certless

various passed early internet references
https://www.garlic.com/~lynn/internet.htm

other internet related history
https://www.garlic.com/~lynn/rfcietf.htm#history

misc. things like interop '88
https://www.garlic.com/~lynn/subnetwork.html#interop88

and doing rfc 1044 support
https://www.garlic.com/~lynn/subnetwork.html#1044

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

Software for IBM 360/30

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Software for IBM 360/30
Newsgroups: alt.folklore.computers
Date: Tue, 17 May 2005 09:34:31 -0600

Joe Morris writes:
Some buttons had a shortened form of the ID: "IML". And didn't the documentation for the 3274 refer to "IML"?

as part of doing some work for the disk engineering lab (building a crash proof operating system that could concurrently operate/test multiple testcells under development):
https://www.garlic.com/~lynn/subtopic.html#disk

found an idiosyncracy built into controllers. the 3274s when they first came out were especially prone to hanging and needing to be re-iml'ed. it turns out that if you hit every device address on the 3274 in quick sequential succession with hdv/clrio combination ... you could force it to re'iml (under program control w/o requiring manual intervention and some person to go over and hit the button on the controller). so we found that most controllers would react that way.

also, the channel director was introduced with the 303x boxes.

the 370/158 was a microcoded engine that timeshared the processor between 370 operation and the channel operation (i.e. it had integrated channels like most of the entry and mid-range machines, both 360 and 370). for the 303x channel director ... they took the 370/158 engine ... slightly repackaged the box ... using just the integrated channel micrcode (and leaving out 370 microcode and the timesharing between the two function).

a 3031 was effectively a two-processor 158 smp ... one processor running dedicated integrated channel microcode ... and the processor running dedicate 370 microcode. a 3032 was effectively a repackaged 168-3 that operated with 303x channel director. a 3033 started out being the 168-3 wiring logic remapped to faster technology and using 303x channel director.

it also turned out that if you were to hit all channel addresses on a 303x channel director in quick succession with clrio ... it would also cause it to re-iml (under program control w/o requiring somebody to walk over and hit buttons).

misc. past m'code postings
https://www.garlic.com/~lynn/submain.html#mcode

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

Systems Programming for 8 Year-olds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems Programming for 8 Year-olds
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 17 May 2005 09:47:29 -0600

in the early 80s ... the inventor of rexx did a distributed, multi-user star wars game for 327x that utilized cp/cms using iucv. iucv was used for both users running on the same mainframe as well as users coming in over network connection on the internal network (although remove users that were numerous hops away and/or on slow network links could be at a severe network latency disadvantage compared to "local" users in the game).

the internal network was mostly cp/cms machines (what mvs machines there were, were typically relegated to boundary nodes because of their dismal, deficient networking support) and larger than the whole arpanet/internet from just about the beginning to approx. mid-85. misc internal network posts
https://www.garlic.com/~lynn/subnetwork.html#internalnet

then somebody at sjr/bld28 developed an automated playing agent (for the game) ... which started to really trounce real human players (again because of difference in response/latency times). the game was then modified so that energy consumption was inversely proportional to interaction interval (for succesive interactions below some threshold). that resulted in the automated playing agent being modified to calculate (benefit tradeoff for) timing delays between succesive commands/interactions

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

Systems Programming for 8 Year-olds

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems Programming for 8 Year-olds
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 17 May 2005 09:50:01 -0600

Anne & Lynn Wheeler writes:
in the early 80s ... the inventor of rexx did a distributed, multi-user star wars game for 327x that utilized cp/cms using iucv.

... oops, fingerslip ... that wasn't a game ... it was an interactive computer demonstration application.

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

Systems Programming for 8 Year-olds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Systems Programming for 8 Year-olds
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 17 May 2005 12:52:38 -0600

Anne & Lynn Wheeler writes:
in the early 80s ... the inventor of rexx did a distributed, multi-user star wars game for 327x that utilized cp/cms using iucv. iucv was used for both users running on the same mainframe as well as

there was an iucv emulation done for mvs at one time.

the early mainframe tcp/ip product was done in vs/pascal on vm370; it used iucv to communicate between the ip network processing address space and various user application address space. the normal implementation had been clocked consuming a whole 3090 processor getting 44kbytes/sec.

i added rfc1044 support
https://www.garlic.com/~lynn/subnetwork.html#1044

to the product and in tuning tests at cray research between a cray and a 4341-clone it was getting 1mbyte/sec using only modest 4341 cpu (i.e. it was hardware limited by the 4341 channel interface) ... nearly 25 times the thruput for maybe 1/50th the cpu (overhead).

the base implementation was later ported to mvs (in part) by including an iucv emulation layer in mvs.

the communication division had been asserting that lu6.2 was significantly more efficient and higher thruput than tcp/ip ... and eventually they commisioned a contractor to do a vtam-based tcp/ip product implementation (to replace the iucv-based implementation ported from vm).

The initial tests resulted in the implementation being sent back to the contractor when tcp/ip showed significantly better thruput than lu6.2 (and so obviously there had to be significant bugs in the implementation that needed fixing ... or otherwise it couldn't have better thruput than lu6.2).

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

First assembly language encounters--how to get started?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First assembly language encounters--how to get started?
Newsgroups: alt.folklore.computers
Date: Wed, 18 May 2005 09:18:24 -0600

Roland Hutchinson writes:
Yes, I'm afraid it is. For first-language English speakers here, one language very imperfectly learned in high school (to satisfy requirements for getting in to college) and possibly revived for a semester or two (to satisfy requirements for getting _out_ of college) is pretty much the norm. Not too many college grads are even close to being comfortable reading a newspaper in their foreign language.

in the early 80s, a researcher sat in the back of my office for nine months, attended meetings with me ... took notes on how i communicated ... face-to-face, telephone, computer ... they had access to copies of all my incoming and outgoing email as well as logs of all instant messaging activity. this was published as a Stanford phd thesis, joint between language and computer ai ... and material for later papers and books ... misc. references:
https://www.garlic.com/~lynn/subnetwork.html#cmc

the researcher had spent many years as an ESL (english as second language) teacher (mostly outside the states). they once commented that i had a lot of characteristics of esl ... and there were jokes that i was more proficient in programming languages than english.

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

First assembly language encounters--how to get started?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First assembly language encounters--how to get started?
Newsgroups: alt.folklore.computers
Date: Wed, 18 May 2005 09:23:06 -0600

Anne & Lynn Wheeler writes:
in the early 80s, a researcher sat in the back of my office for nine months, attended meetings with me ... took notes on how i communicated ... face-to-face, telephone, computer ... they had access to copies of all my incoming and outgoing email as well as logs of all instant messaging activity. this was published as a Stanford phd thesis, joint between language and computer ai ... and material for later papers and books ... misc. references:
https://www.garlic.com/~lynn/subnetwork.html#cmc

i think the thesis had some statistic ... that for the nine months of the study ... my weekly avg. for electronic communication with unique, different people (or at least unique, different email addresses) ... was something like 275.

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

Password question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Password question
Newsgroups: comp.security.misc
Date: Wed, 18 May 2005 14:22:28 -0600

tewall writes:
Say I have a password like JenP4$$4PlayerS. I understand this is a bad (i.e. not strong) password for a number of reasons. It has combinations of words, abbreviations and palindromes. My question is, given that all 15 characters have to be used (that is, the password can't be split into smaller units, like 7 digits) even if you can split out the pieces of the words, palindromes and abbreviation, if there's say a million each of these, you take a million cubed, and that's still a very large number. So how weak is a password like this? What kind of resources would it take to break? (rough approximation)

rules for good passwords
https://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.

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

previous, next, index - home