Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
So did Jay mean that CP/CMS sucks at batch? Surely VM can support
batch just fine under some other supervisor?

cms has a cmsbatch ... that isn't even up to the level of os/360 PCP.
cmsbatch is sort of like automated terminal session.

but of course you can run some other (much more batch oriented)
operating system in a virtual machine ... and do you batch work there.
In fact, LPARS are a form of VM subset running in the microcode &
hardware (on the bare metal) ... and I would guess that nearly all of
the ibm mainframes these days run in LPAR mode. In that sense nearly
all ibm maainframe workload running in the world today is running in a
form of VM ... one way or another (including batch, oltp, dbms, etc)

Home mainframes

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
At that shop (Alphatext), OS/VS1 was the "guest" operating system.
It's MFT on steroids. There was an initiative to move to MVS in
guest mode, but the division was killed before that happened.
It would have been interesting to compare CMS and TSO on the 4381,
but not everyone is as blessed as, say, the Wheelers, in career
opportunities. --> B-) <--

most guest operating systems run slower in a VM virtual machine than
they would on the bare metal (because of the need for VM to simulate
lots of the supervisor state instructions and various other
characteristics). However, starting on 148 with VS/1 & VM microcode
assists and various tweaking of VS/1 operations ... there were lots of
customers that were able to show VS/1 running faster under VM than on
the native hardware.

lets say i fell into the career opportunities ... by spending a lot of
late nights at the university computing center ... until they give me
the whole machine room from 8am sat. until 8am monday ... and the
responsibility for supporting the production operating systems. After
that I usually tried to schedule things so my first class on monday
wasn't until 10am ... it would give me a chance to shower. Pulling a
48hr shift w/o sleep and then doing monday classes sometimes was
interesting activity.

Home mainframes

and although i didn't get as much sleep pulling 48hr shifts (and then
going to class) it was more interesting than the job i had up until
then washing dishes in university cafeteria (and i was getting paid
for spending time at the computing center)

SEYMOUR.J.METZ@CUSTOMS.TREAS.GOV (Shmuel Metz , Seymour J.) writes:
RPS was first introduced for the 2305 disk, on the 360/85 and 360/195. The
next RPS devices were the 3330-1, 3330-2 and 3330-11. RPS was old hat by
the time the 3350 came along, much less the 3350, 3375, 3380 and 3390.

Don't forget the 3340 and 3344, or the FBA disk drives (3310, 3370).

2305 also had multiple exposures ... eight logical addresses mapped to
the same physical device (all addresses could read all locations).

3344 was multiple emulated 3340s on a 3350 physical drive. the big
difference between 3344 & 3340 from programming standpoint was that
the 3344 needed special RAS alternate track support (and the number of
3340 cyls. reduced by the cyls used for alternate tracks).

3350 had a fixed-option for the first two cylinders. i tried to get
multiple exposures for the 3350 .. so i/o could be
initiated/performed/overlapped (on the fixed heads) while the arm was
in motion/busy ... but didn't happen.

the one from SGML ... is goldfarb csc report ... mentioning APL at CSC
(in addition to cp/67, the internal network, and misc & sundry other
stuff .. gml also originated at CSC; gml is actually goldfarb, mosher
and lorie ... and i bet everybody thot it stood for generalized markup
language ... ancestor to to all the current MLs, HTML, XML, etc).

David Ball writes:
I remember reading datasheets on the iAPX432 back in about 1981, but
I never heard much else about it. As I recall, it had some weird
things in the architecture, like bit addressed memory and some OS
primitives implemented in hardware.... Seems like I recall some kind
of job descriptor block and the CPU hardware could handle scheduling
with multiple CPU's.... OTOH, I read all this back in 1981 and I
could be mistaken...

Are ssl certificates all equally secure?

ga@braindamage.org (Beavis) writes:
It seems that the various certificate authorities have somewhat
different requirements for verifying identities. My question is this:
Does it matter?

Suppose that I buy my somesite.com certificate from agent X, which
goes to great lengths to verify that I am in fact the owner of
somesite.com.

Now suppose that "hacker B" buys a somesite.com certificate from agent
Y, who is not as careful and ends up giving "hacker B" a somesite.com
certificate even though he has no rights to somesite.com.

Now it seems that "hacker B" can intercept "secure" connections to
somesite.com using his bogus certificate.

If this is true then is there any point in my buying from agent X? It
seems that the whole system is as weak as its weakest certificate
authority.

If not, why not?

SSL certificates security:

1) integrity of the certificates themselves

2) integrity of the business processes that the certification
authorities use for creating certificates (side note ... technically
they aren't certificate authorities, they are certification
authorities; aka they are certifying somebody else's information).

3) integrity of the business processes of the authoritative agency
responsible for the information being certified by the certification
authority (aka frequently the certification authority is not the
authoritative agency with regard to the information being certified).
In SSL certificates ... it is who owns the domain name ... and so the
domain name infrastructure is the authoritative agency as to actually
who owns which domains. one of the failure modes has been domain name
takeover, and then get a certificate.

basically the browsers just accept all certificates that have been signed
with a private key ... which the browser has the corresponding public key
in an internal table.

So the strength of the infrastructure is effectively as strong was the
weakest length ... which might actually not be the crypto integrity of
the certificate or the business integrity of the certification
authority ... but could extend all the way back to the authoritative
agency responsible for the information being certified.

PLX

SEYMOUR.J.METZ@CUSTOMS.TREAS.GOV (Shmuel Metz , Seymour J.) writes:
Memorex reliability may not have been as good as IBM, but it was far
better than Itel. However, The STC Superdisk (we called it superdog) was
reminiscent of Itel, or the 2321 on an off day; 4 3330 stacks with a
single access mechanism.

one of the guys that i worked with was being recruited for CTO at a
hardware RDBMS company (after their current CTO had left to form a
software RDBMS company) ... and I was asked to come along also. The
two that had originally formed the company (hardware RDBMS company
carried their name) had previously done memorex disks/controller
... and before that one of them had been engineer on 2321 (there has
been this joke about there only being 200 people in the industry).

... in some sense certification authorities are analogous to notary
public, they will certify that they've seen something like a driver's
license.

one problem might be that the notary doesn't examine the driver's
license close enuf to see if it is really valid. another problem might
be that the driver's license is so simple that everybody in the world
might be running around with a fraudulent/counterfeit driver's
license.

in a hypothetical situation, just because the notary's seal is
impossible to duplicate ... and every notary is absolutely guaranteed
to faithfully have executed the appropriate process .... it still
might not be true if the driver's license a trivial to counterfeit.

one of the primary, original reasons for ssl certs is concern about
the integrity of the domain name infrastructure. however,
certifications authorities are dependent on domain name infrastructure
as the authoritative agency regarding domain name ownership. so there
is something of a catch-22 (aka you want a ssl cert to be used because
you can't trust the domain name infrastructure ... but the
certification authorities are dependent on the domain name
infrastructure for the information they are certifying ... the same
information you aren't trusting).

in any case, some of the proposals (by the certification authority
industry) for improving the integrity of the domain name
infrastructure (so that they can trust it) ... also goes a long ways
towards allowing everybody to trust it (significantly negating the
need for ssl certificates).

jcmorris@mitre.org (Joe Morris) writes:
I doubt seriously that any of the regular readers of this newsgroup
need to have the concept of "late night work on the computer" explained
to them... <g>

Joe Morris (who for many years saw sunrise only when leaving the office)

it wasn't so much the all nighters and then rest ... it was the 48hr
shift and then go to class. later there was this joke about working
1st shift in bldg.28/sjr, 2nd shift in bldgs14/15/disk engineering,
and 3rd shift in bldg90/STL.

I was at dinner 3-4 weeks ago with a group and somebody was telling
story about (20+ yeargs ago) sitting in a 1st floor conference room in
bldg.90/STL and watching the sun come up over the east hills ... and a
janitor caming around outside sweeping the concret footing of the bldg
(and wishing he could change places with the janitor since some
acceptance testing we were working on hadn't been going well; he was
with a non-ibm hardware vendor).

bldg.90/stl is set in coyote valley (was almost named the coyote lab)
and since it was built has been the only bldg (although at one time
tandem had option to build big campus complex and move all its
operations ... and then later cisco seemed to have bought the
option). the area around the bldg. is somewhat natural. The data
center is underneath everything and when it was first built ... was
subject to flooding.

sometimes i would work in bldg.90/stl during the day and ride my bike
to work. the valley had the interesting characteristic that there was
typically a strong head wind heading both directions (in the morning
the bay is warmer than the south valley/salinas ... and the air rises
over the bay and sucks air from south valley between the santa cruz
mountains and the east hills, in the afternoon, the south valley is
warmer than the bay and the wind reverses). This is the effect that
also moderates SanFran weather ... since the hotter it is in the south
valley ... the more air is being sucked from the bay ... and
eventually pulling it from the pacific thru the gap at the golden gate
(typically the hotter it is in the south valley, the greater the air
conditioning effect at the golden gate with stronger pull of cooler
air from the pacific)

Home mainframes

... although when i was at 545tech sq .... sometimes i would be
working late and miss the last B&M train out of north station ... and
have to work thru the west of the night and then walk over to north
station in the morning and catch the first train. this is when
lechmere was still big warehouse looking bldg with a large paved lot.
now that area has gone all really upscale (and the hotel that used to
be called the chart house is now a sonesta or renaissance or something
... and surrounded by lotus bldgs.)

previou biography was:
The Mind of War: John Boyd and American Security, Grant T. Hammond,
smithsonian institution press (the picture on the back cover of this
book is the cover for the new biography).

Peter Flass writes:
"Well" is really all in your definition. IMHO, if what you want to do
is run a bunch of compiles in the background it's fine, but you don't
get all the queueing and selection features MVS has. You also don't get
the facilities of JCL which, for all its faults, is a failrly powerful
languahe in itself. Think rinning a series of steps with condition code
testing. Think running a job that uses lots of tapes.

the other way of looking at batch vis-a-vis interactive paradigm
.... is that the batch sysetms evolved over a period of 40 some years
assuming that there was no human participation in the computing
process (outside of telling an operating to mount a tape) ... while
the interactive platforms have evolved over a 30plus year period
assuming that a human was there telling them what to do. The
assumptions are radically different and the solutions that evolved are
significantly different.

Lots of the interactive platforms, when something anomolous occurs are
expected to punt back and interact with the human. A lot of batch
systems have evolved to being dim/dark room operations .... where
there might not be a knowledgeable person within miles/hours.

An interesting aspect is trying to adopt interactive/desktop evolved
platforms for dim/dark room operations (no matter what happens, the
service keeps running 7x24). Everything that used to interrupt out to
the human for them to take care of ... has now got to be handled
automagically.

A couple examples/correllaries have been

1) large financial network that attributed 100 percent availability for
a six plus year period (at the time) to

2) for the original payment gateway as part of the invention of
e-commerce ... i contended that after the straight line application
code was written and fully operational ... that there was about four
times as much more code written (that was possibly ten times more
complex) to turn the "application" into a "service" (for 7x24
operation). related assurance references
http://www.garlic.com/~lynn/subintegrity.html#assurance

Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
Were any of the VM microcode assists ever explained in documentation
available to customers?

Have the same VM assists been available on most models since then, or
are they model-specific?

there were essentially two types of microcode assists

1) privilege instruction execution using virtual machine rules
.... aka instead of generating a program interrupt for the privilege
instruction, the microcode of the machine recognized that it was in
virtual machine mode and executing the instruction using virtual
machine rules. The first such set of this started with assist
microcode on the 370/158. Various machines have extended until the SIE
instruction in 370-XA and then carrying forward until present day with
LPARs. This eliminated having to interrupt the CP kernel to simulate
the privilege instruction. I believe that all machines that supported
370-XA (and later architectures, aka starting with 3081 20-some years
ago) supported SIE. I believe all current machines support LPARs.

2) vm cp kernel code that was copied into microcode originally for
138&148 machines. 370 on the low & mid range machines was
microcode on some native processor engine with a typical microcode:370
instruction ratio of about 10:1 (aka there were about 10 microcode
instructions executed for every 370 instruction). Basically a
variation on the "B2xx" op-code was inserted into the 370 instruction
stream with various parameters (including pointer to various 370
addresses when it was done). The various B2xx functions would
duplicate (in microcode) the 370 kernel instruction sequence at
approximately ten times performance improvement.

This was VM ECPS for the 138/148 and started out with the microcode
group in endicott saying that they had 6000 bytes of microcode space
and they wanted to pick approximately 6000 bytes of the highest used
CP kernel instructions. The following describes the 6000 bytes of cp
kernel 370 instruction that were selected for replication in
microcode:
http://www.garlic.com/~lynn/94.html#21 370 ecps vm

The 138/148 also supported the #1 enhancement for various privilege
instructions that was done for the 370/158 plus a couple additional
instructions that hadn't been done by the 158 microcode assist. For
the most part, these "assisted" instructions executing in almost the
same time/performance as they would in non-virtual machine mode
(nearly zero virtual machine simulation overhead).

For the situations were CP kernel was necessary (privilege
instructions not simulated by the microcode, task-switch, virtual
memory page exceptions, page i/o, etc), the special ECPS B2xx
instruction reducted 80 percent of kernel execution time to 8 percent.

VS1 operating system then also had ECPS microcode assists done for it
on 138/148 machines. And there were also a different sent of things
done for the VS1 operating system where, if it knew it was running in
a virtual machine utilized some new interfaces to operate much more
efficiently (in some cases relying on the CP kernel to perform
functions that it would otherwise do itself ... eliminating some
exectuion duplication).

The overall effects might cut cp kernel execution as a percent of
total execution from possibly forty percent (with absolutely no
microcode help and/or guest operating system sensitivity) to possibly
4-5 percent. In some cases with the VS1 guest operating system
enhancements, that 4-5 percent CP kernel time might have originally
been 6-10 percent VS1 operating system time (if running on the bare
iron) .... resulting in the situation that some customers saw higher
thruput with VS1 running in a virtual machine than if it had been
running on the bare metal.

Anne & Lynn Wheeler writes:
This was VM ECPS for the 138/148 and started out with the microcode
group in endicott saying that they had 6000 bytes of microcode space
and they wanted to pick approximately 6000 bytes of the highest used
CP kernel instructions. The following describes the 6000 bytes of cp
kernel 370 instruction that were selected for replication in
microcode:
http://www.garlic.com/~lynn/94.html#21 370 ecps vm

at the same time I was working on 138/148 ECPS ... I was also working
on a thing called VAMPS ... which was a multiprocessor architecture
involving 370/125. The 115&125 basic hardware had a 9-ported
internal bus for up to 9 microprocessors. In the 115, all the
microprocessor engines were the same ... just with different
programming; implementing the various controller functions as well as
the 370 cpu (i.e. 370 microprocessor engine was identical to the other
microprocessor engines ... but with microcode that implement 370
instruction set). The 125 was identical to the 115 except the
microprocessor engine used for the 370 CPU was unique and faster than
all the other microprocessors. VAMPS was a project that would deploy
two to five 125 processor engines on the internal 9-port internal bus.

A problem was that the 138/148 ECPS effort was trying to make the
whole 138/148 product line VM (i.e. all machines would be shipped with
VM ... in much the same way all machines currently ship with LPAR
support). The 138/148 group then viewed the 5-way VAMPS effort moving
up into their targeted market segment. So things eventually escalated
until there was an executive meeting with the 138/148 group on one
side of the table and the VAMPS group on the other side of the table
... and I had a seat on both sides. I also had to carry the majority
of the argument for both sides ... logically switching sides of the
table depending on which side of the argument I was taking at that
particular moment.

tjpo@AIRBORNE.COM (Patrick O'Keefe) writes:
Hmm. The 1130 I remember had cartridge about a foot in diameter, one platter or maybe 2.
Could be the "frisbee" mentioned above. I think the 1130 had a lot of scientific or engineering
programs available. I know it had an available CALCOMP drum plotter with an IBM label on it.

cambridge science center had a 2250mod4 (I had used a 2250m1 at the
university, which was direct 360 channel attach controller) 2250m4
basically was a 2250 with 1130 as the "controller". somebody ported
spacewars from pdp1(?) to the 1130 (2250m4). The 2250 keyboard was
split in half for two players ... each player using their half of the
keyboard for direction control, movement and firing.

the same person did the initial "network" connection done between the
1130 and the 360/67 ... and evolved it into cpremote, vnet, rscs (and
the internal network).

One of the things that both SNA and early arpanet did wrong was not
having a gateway layer. One of the reasons that the internal network
was larger than the arpanet/internet into the 1985 timeframe was that
the internal network effectively had gateway support in every node
... something that the internet didn't get until 1/1/83 ("great
switchover").

There is also the point that SNA never even had a "network layer"
(besides not having a gateway layer).

SEYMOUR.J.METZ@CUSTOMS.TREAS.GOV (Shmuel Metz , Seymour J.) writes:
There was a multiple utility program for the 1401 that let you run copies
concurrently, but it didn't let you run other applications in parallel
with that. The SPOOL support for the 1410/7010, like the SPOOL for the
7070, 7080 and 7090, let you run the utility functions in parallel with
another application.

my first student programming job was duplicating a 1401 program that
did UR<->tape as front-end for 709. The 1401 bootable carddeck
had "MPIO" written on it. While I was working on it, the unit record
gear was switched back & forth between the 1401 and the 360/30
... when the 1401 was then removed and the 360/30 alternated between
1401 emulation mode and 360 mode. I never programmed the 1401. I did
run MPIO ... testing to see if MPIO and what I was doing generated the
same results.

I got to design my own interrupt handler, device driver, storage
management, dispatcher, etc ... and eventually could handle both
tape->printer/punch and cardreader->tape simultaneously ... and
assembler deck grew to somewhat less than a box of cards (2000). I had
conditional assembly for either stand-alone operation (my own device
drviers, interrupt handlers, etc) or under os/360 (I believe at the
time PCP release 6).

One of the issues was that assembling it for running under PCP ... I
had five DCB macros. The stand-alone version would assemble in around
20 minutes. The PCP version (with DCB macros) would take more than
twice that, .... you could watch the lights on the 30 when it hit a
DCB macro ... each one taking approx. five minutes elapsed time (and
adding nearly a half hour to the total assembly time).

Rather than read/feed/select-stacker ... I would do separate read and
feed/select-stacker CCW operations. If the card was BCD the read would
complete and then I would do feed/select-stacker. If the card was
binary, the read would fail, and I would reread in column binary (read
80 rows into 160 bytes).

The Hitchhiker's Guide to the Mainframe

"Charlie Gibbs" writes:
I realize that the 360 assembler's macro language is a real bear,
but I still couldn't understand why it took so damned long to
assemble. The disk-based assembler on the Univac 9300 (Univac's
answer to the 360/20) took similarly long - I had one program
of about 2000 statements which took 40 minutes to assemble.
I wrote my own assembler, which satisfied my design criteria by
supporting the full language and doing the job in half the time.
(It also added a cross-reference listing, which the Univac
assembler lacked.) On a single-tasking machine where programmers
had the lowest priority, this boosted my productivity significantly.

I heard a story that the person that was writing the decoder was told
that they only had ??bytes (some very small number) ... and so
(re)read the records of the lookup table from disk on every
statement. DCB macro was in library and was at least several hundred
records by itself. Say nominal 20 I/Os per second from 2311 .. 1200
I/Os per minute ... 6000 i/os in five minutes (or possibly 6000 disk
i/os for every DCB macro).

Suppsedly somebody investigated and realized that the person doing
that part of the implementation had been terribly over constrained and
relaxing it a little bit (keeping lookup table in memory instead of
sequentially reeading records from disk) speaded up the assembler
significantly.

sortly after going to 545tech sq I got to take home a "portable" 2741,
if I remember correctly a Anderson/Jacabson in two 40(?)lb suitcases
and an acoustic modem. After a couple months this was replaced with a
real 2741.

Cambridge had a clear plastic flat cover to place over the top opening
(holes cut for the paper release) made for all the 2741s to help cut
down on the noise (about 1/4in plexiglass, it rested on the paper
release, front & sides leaving gap in the rear for paper feed).

They also had table tops made. They were basically 3/4in plywood with
formica laminate that sat on the 2741 frame with a cut-out for the
typewriter case ... about 24in on one side and back and 6in on the other
side. This table top could be flipped over ... placing the 24in side
for paper to either the right or the left (of the keyboard). I had
kept the table top and plastic cover long after I no longer had a 2741
(until just 4-5 years ago). I still have a APL golf ball tho.
http://www.columbia.edu/cu/computinghistory/2741.html

Slow assemblers/Macros?

"Charlie Gibbs" writes:
I remember "air conditioner wars" between myself, who believes that
the purpose of air conditioning is to make things comfortable, and just
about everybody else, who believe that the purpose of air conditioning
is to make things COLD. What these people failed to realize is that
the machines could tolerate any of a fairly wide range of temperatures,
as long as it remained constant. Once I got the temperature set so
that both I and the machines were comfortable, there were no problems.
But these people just couldn't stand the thought of a shirtsleeve
machine room environment, so they'd crank the thermostat back down.

there was a story about everybody getting pc/rts in their office in
the relatively new almaden research building. supposedly the pc/rts
put out so much heat that if everybody turned them off at the end of
the day and turned them back on in the morning ... the building air
conditioning never was able to stabilize because the BTU swings were
so large inside the building ... so they recommended just leaving them
on all the time.

lwinson@bbs.cpcn.com (lwin) writes:
For some reason, IBM sold us a 6670 in the early 1980s to use
as an inexpensive low volume mainframe report printer in a remote
location. It was a bit of pain since we had to add PL/I to our
system and it did not appear as a normal HASP remote unit.

6670 first showed up in the late '70s (I think we got our first one
sometime in 79) ... it was pretty much an IBM copier/3 with a computer
interface. one of the research groups put some amount of time in
supporting postscript for the 6670. the print qaulity was excellent,
it could duplex (print both sides), and it had two paper feed drawers
... i.e. you could put colored paper in the alternate and use it for
easy output job seperator. since most of the job seperator page was
empty ... one of the people hacked the line driver to print random
entries from the jargon file on the rest of the seperator page.

this caused an incident during an audit ... when one of the top cover
sheets sitting on the 6670 when an auditor came around ... had the
definition for auditor (i.e. people that go around stabbing the
wounded) ... and they thot it was done on purpose for them to read.

"keep-it-clean" <keep-it-clean@worldnet.att.net> writes:
In any case, it certainly seems fair to include "relocatability" in this
context as part of an assembler's functions assuming the underlying hardware
design is amenable to it.

360 had registers that could be used for addressing and mechanism for
establishing current address (balr rX,0) for relative addressing (to
"using" off some register).

All this was (normally) done before program began execution. Once
program started execution it was effectively bound to a specific
physical address.

The original stuff that I had done in late CP/67 time frame and ported
to early vm/370 was paging access method (mapping the cms file system
to a page mapped paradigm) and relocating shared segments (R/O shared
segments). The CP support for relocating shared segments was physical
address insensitive/agnostic (aka the same shared image/segment could
appear simulataneously in different address spaces at different
logical addresses). A subset of the relocating shared segment support
was released in VM/370 version as "discontiguous shared segment"
support. The released version of the code only supported fixed
address sharing (aka the same shared object/segment had to occupy the
same logical address in in every address space). At least one problem
was that relocatable paradigm in os/360 ... which CMS tended to follow
... was that relocatable adcons were actually fixed addresses at
execution/runtime ... they were only relocatable in the sense that the
relocation was done early at bind/load time ... so what appeared in
memory at runtime was a fixed address.

For code that occupied truely relocatable shared segments ... I had to
go thru and sensitive all the address constants for address
independent operation. I had to make them "abolute" at least as far as
the loader/binder was concerned (aka had no RLD entry and had
difference between two ESD entries). Basically, I manually created
"relative" (or displacement) adcon/address that was then combined with
a dynamic (process/address space specific) address in a register (at
execution/run time).

A residual of all this appeared in bits and pieces of the product code
shipped to customers ... including a CMS SVC202 defined in page zero
(aka NUCON dsect). If the first byte following the svc202 was a zero
(invalid instruction), the whole four bytes following the svc202
instruction was assumbed to be a four byte address constant
field. Standard CMS SVC202 processing had a normal return to the
instruction following the svc instruction, unless the first byte was
zero, in which case the normal return is four bytes after the svc
instruction ... and any immediately following address constant is
assumed to be the non-normal/error return. Frequently this adcon was
AL4(+4) (but could be the address of an error handling routine, the
"L4" was telling the assembler to ignore forcing to a four byte
boundary which was normal for address constants) which is a relative
adcon from the syntactical standpoint ... but is turned into a
relocatable adcon ... and then is filled in with a fixed address by
the loader. If there was an error and no adcon, the system call would
invoke a system error handler rather than returning for application
specific error handling (which might include terminating the program).

To make this work in relocating shared segments ... making executable
code address location insensitive, I replaced all "inline" svc202
calls with a BALR (branch and link) to a fixed svc202 system call
instruction in page zero (CMS NUCON dsect) of the address space. Later
CMS implemented the convention that if the adcon was AL4(1)
.. i.e. absolute address of one, that return was to be made to the SVC
address plus four (regardless of whether there was an error or not
... basically the equivalent of AL4(+4) but w/o need of real address.
The calling program could then determines if there was some sort of
unusual return from the system call by checking the condition code
and/or a register contents.

Relative addresses (as opposed to what os/360 calls relocatable
addresses) have not been a os/360 standard construct.

the code wasn't necessary for standard discontiguous shared segments
released in the product ... however, it was part of all the CMS fixups
that I had done to put put additional CMS code in shared segments and
make that code "address location" insensitive (i.e. no inline
"relocatable adcons"). while not all the CP code to support address
agnostic shared segments was included in the initial "discontiguous
shared segment" product offering ... all the the CMS changes that I
had done shipped pretty much "as is" (i.e. they weren't going to
distinquish between changes to make CMS program code "R/O" as opposed
to the changes needed to make CMS program code address constant free).
After doing some amount of CMS kernel code ... I also did fixup on
IOS3270, BROWSE, and FULIST in similar manner.

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
Another relocation was the first 4K of real addresses. (No handy
PoO book now.) Why was this specified, where and when was it ever
done? It was defined for more than one processor accessing a bank
of core, but did VM ever use it physically?

in a real shared memory multiprocessor ... all processors shared the
same physical address structure. however, must interrupt handlers were
in the habit of storing their current registers in "absolute" (as well
as the hardware storing the interrupting address in absolute page
zero). This didn't work well with multiple processors sharing the same
page zero. For multiprocessor mode, there was a processor specific
control register that contained the real address of that processors
page zero. Each processor as it came up was to uniquely select some
real 4k page and load it into the page zero control register. All real
page zero addresses for a processor (program or things like hardware
interrupts) would be retargeted to the 4k location specified in the
page zero location. The 370 implementation had an "interesting" side
effect that if a processor attempted to address the 4k page address in
the page zero register ... it would be retargeted to the absolute page
zero (otherwise there was no way of referencing the real/real/absolute
page zero). (assuming i remember correctly) the 360 implementation
didn't have this reverase retargeting side effect (aka 360/67
multiprocessing "lost" the real page zero).

on 16nov2002 11:59:59 wrote:
Once converted from 360 to 370 architecture (real fun!), PARS
was (and TPF is) one of the few systems that runs significantly better under
VM than native.

PARS/ACP/TPF didn't have multiprocessor support. One of the initial things
for 3081 was using VM to support two processors and then running two copies
of TPF under VM (one for each processor). Eventually there was a single
processor 3083 delivered ... I believe pretty much because of the TPF market.

6670

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
I sometimes think that TLA recycling is getting out of hand... when
I glimpsed "OPD" I immediately thought of ICL's remodelled Sinclair
QL. Oh well...

and then there is ROMP ... Research OPD Mini Processor ... which was
going to be the processor in the OPD displaywriter follow-on. When
that project got can'ed they were searching around for something to
use it for and came up with unix ... and so it was retargted as the
PC/RT with the company that had done the AT&T unix port for pc/ix
... doing a port for ROMP (so it has C language and unix operating
system instead of pl8 language and the cpr operating system). This
then spawns RIOS follow-on chip to ROMP and rs/6000 (and eventually
power/pc).

hansp@aconit.org (Hans B Pufal) writes:
Among the classic exhibits are a Bull Gamma 3, the panel from an IBM
360/67, a (working) 1130, a (working) PDP-8/m, a Telemechanique 1600,
a Micral N, a Thomson MO5, and a Goupil 2.

... aka (ibm) grenoble science center. in the early '70s they had a
1mbyte 360/67 running CP/67 release 3. They modified it to implement
what they called a "working set dispatcher" (and eventually wrote an
article that appeared in ACM). About the same time, I was doing some
work on CP/67 release 3 ... incoporating some page thrashing controls
that I had originally started while an undergraduate at the university
... and the summer I spent helping sent up BCS at boeing. This had
some fundamental differences compared to the grenoble work
... including using (clock) global LRU replacement algorithm
... instead of a local LRU replacement algorithm aka working set
dispatcher. In any case, the cambridge system with 768k real storage
(about 105 available 4k pages after kernel fixed storage reguirements)
supported nearly twice as many users at approximately the same thruput
as the grenoble system with 1mbyte real storage (about 155 available
4k pages after kernel fixed storage requirements) ... aka the grenoble
system had nearly 50 percent more real storage for applications and
ran nearly the same CMS type workload ... on nearly the same operating
system on nearly the same hardware (and the cambridge system supported
nearly twice as many users at approximately the same
thruput/response).

This became important when approx. ten years later somebody was trying
to get their PhD from stanford with a thesis regarding clock global LRU
replacement strategies.

the teddy bear started out as the SHARE VM user group mascot ... in
much the same way as the paddle for the SHARE MVT user group symbol
(as in "up the creek w/o a paddle"). the share issue was that the
official corporate position has been to kill the product (pretty much
consistent since before cp/67 product announcement 35 years ago)
... and the only thing keeping it alive was customer demand ... and
one of the customer's last refuge was the SHARE VM user group ... as
in place of last resort ... or security blanket.

share has this sticky labels in the shape of teddy bear ... for
putting on your share badge ... indicating committee
affiliation. sometimes they are just plain paper with sticky back
... and sometimes they have actually have a fuzzy layer.

scids (evening share ... nominally society for continuous inebriation
during share) now has committee tables where people can get together
and ask questions. the committee tables now have their symbol or totum
(which has somewhat turned into asking the teddy bear questions or
getting answers from the teddy bear ... at least at the vm committe
table).

peter@abbnm.com (Peter da Silva) writes:
AFAICT the only thing that the shipping OSF/1 on the Alpha took from IBM
was the license. DEC OSF/1 was pretty much a stright 4.3-Reno on Mach, with
the good bits of System V userland ported on top of it. The non-AT&T BSD
was Net-2 and 4.4-Lite, and that was after Reno shipped.

but who funded the organization that did mach, andrew, camelot,
etc. athena at mit was jointly funded by dec and ibm ... however cmu
got all its money from one source. there was some story that they paid
at least three different times for the same set of code that came from
there (as part of the cmu & then transarc saga).

note the above reference should read that ibm decided not to produce
sun machine ... and so SUN was formed. ... also the company in provo
that was spawned out of the DataHub effort is still around ... but not
doing quite as well as it once was.

Follklore

Joe Morris writes:
...and I'm chuckling as I wonder how many new readers of any of the
"green card" threads in this newsgroup are wondering why we're
discussing immigration matters and/or Cantor & Siegel (sp?)...

in the mid-90s ... i was once having dinner in old town mexican
restaurant in scottsdale. a couple and a man came in and was seated
behind me. I then got to listen to the man for an hour explain to the
couple the intricate ins & outs of spamming, how he could send out
email to everybody in the world, how he frequently got shutdown
... but he had pre-initialized a hundred userids at ISP around the
country and he could switch userids faster than the ISPs could shut
him down. He also had suggestions for the couple about configuring
their servers so that they had nothing that could accept incoming
email (which would likely to be complaints about the spamming).

META: Newsgroup cliques?

jmfbahciv writes:
He may even have had a valid point with his complaint. It's just
too bad he had to spoil it with his final line. Until I read
that last line, I was going to reply to him and suggest he write
the FAQ. Instead, I revised the spelling and told him to something
more productive....for him, that is.

and if you consider the thousands of newsgroups ... the idea that they
all should show some uniformly consistent, standard whose sole purpose
is for the education of others ... the next step after asking about
only having politically correct styles ... is about having politically
correct subjects and replies.

some newsgroups could actually be for the practitioners (past or
present) actually discussing something w/o regard for
non-practitioners. comp.arch might be a more extreme example ... where
people that haven't done their prep (or ask for help in doing homework
assignment) can get taken to task or even ignored.

A counter analogy might be a 9 year old wandering into some post-doc
project in say related to subatomic particles and complaining that it
is their fault that he (the 9 year old) doesn't understand and can't
contribute.

there are some mailing lists and newsgroups that actually have a heavy
orientation towards major objective of education and knowledge sharing
and they are the most likely to have FAQs. taking an alternative view,
one might make the position that any reasonable person would interpret
the absence of a FAQ as possible indication that the major motivation
for participating in the newsgroup isn't knowledge sharing for
addressing the latest & badest security failures.

So I tried this //vm.marist.edu stuff on a slow Sat. night,

ab528@freenet.carleton.ca (Heinz W. Wiggeshoff) writes:
and up pops a pic of a regular contributer _wearing a tie_.
I'm sorry sir, that's a disgrace to the newsgroup.

i had to put on a tie for the picture (it went up on display wall of
people getting corporate awards) ... however you can see that i'm also
wearing a wool (woolrich) hiking shirt ... and you can't see that i'm
wearing hiking boots with deep lugs; before they put sidewalk on
stretch of cottle (which has since been turned into highway 85)
... there used to be problem about me tracking mud around the halls of
bldg. 28.

META: Newsgroup cliques?

Brian Inglis writes:
We do -- as a bunch of consistently curmudgeonly Auld Farts of
Computing -- nothing was said to you that hasn't been said by one
of the regular posters to another regular poster -- and possibly
more abruptly in those cases.
Our community norm for consideration may be expressed somewhat
differently than in other communities -- just 'cos mama bear
whacks baby bear a couple of hundred metres down the mountain
does not mean she's not considering baby's welfare.
I've been at sessions where HR people sat in and were
amazed/appalled/shocked at how computer people interacted
together to get decisions made and get a job done -- it ain't
pretty but it's pretty functional.

one boyd story was when he was head of lightweight fighter design at
the pentagon ... a one star observed him repeatedly in long stormy
arguments with mear lieutenants and captains ... and thot it was
unmilitary and used it as an excuse to fire him (not exactly one of
the stories in the latest biography). of course ... all of these
lieutenants and captains were PHDs in aeronautics ... so they at least
had some modicum of qualifications to participate in the discussions.

peter@abbnm.com (Peter da Silva) writes:
AFAICT the only thing that the shipping OSF/1 on the Alpha took from IBM
was the license. DEC OSF/1 was pretty much a stright 4.3-Reno on Mach, with
the good bits of System V userland ported on top of it. The non-AT&T BSD
was Net-2 and 4.4-Lite, and that was after Reno shipped.

the other thing that went on in the early OSF meetings was the
distributed file system stuff ... meetings had people from UCLA Locus,
CMU AFS, austin DFS, and some apollo (hp). AFS could do local (disk)
caching of full objects. Locus could do partial object (disk) caching
as well as process migration (including heterogeneous under specific
conditions). There was also some of the MIT Kerberos stuff for
distributed authenticated tokens.

Howard S Shubs writes:
This isn't a public resource. None of USENET is public. Ever since NSF
stopped funding the internet, and possibly before, USENET was paid for
by the people using it.

usenet grew up pretty much independent of internet. there was various
kinds of gov. funding for arpanet and internet ... but by the time of
NSFNET-1 backbone ... the NSF funding was small percentage of total
resources (even for NSFNET-1 backbone itself). a contrived argument
might be that various commercial entities may have declared some their
internet contributions as educational/deductable contributions and
therefor got a (gov) tax break.

use of RADIUS

"W. B." writes:
Check out page 296 on that manual that I previously gave you a link to.
They have an example on how to use the authentication+ssl. The actual
authentication mechanisim be it RADIUS or internal, is up to you however.
Looks like the Netscreen would probably be a sound choice for your
application.

this public key mode is akin to the public key mode defined in the
ietf pk-init draft for kerberos (aka be able to register a database of
users and their public keys ... nearly identical to the way that
userid/passwords are registered ... and then be able to authenticate
a digital signature using user's registered public keys).

this is different than using SSL to establish an encrypted session and
then enter a password ... basically a digital signature is used instead
of a password ... and the userid/password database has the user's public
key registered in place of a password

THIS WEEKEND: VINTAGE COMPUTER FESTIVAL 5.0

"Charlie Gibbs" writes:
Maybe it's security - there's only one entrance or exit to watch.
I first saw this technique with the latest generation of Safeway
stores, although that might just be because (since we're in Canada)
the Wal-Mart invasion is still in its early stages in our area.
(It's strange how people are so up in arms about big-box stores
moving in, considering how enthusiastically they flock to such
stores once they open.)

there are some numbers regarding the use of greaters at the store
entrance significantly cutting amount of shoplifting (the use of
greaters more than pay for themselves in reduction in crime)
... apparently there is some psycology with thieves and being
greeted. i've also heard of some study about the introduction of the
stores in the UK showing up in reduction in the national avg. cost of
living.

my memory may be slipping; i'm looking for positive information
regarding whether it was 360/195 or 370/195 ... they were very similar
machines (370/195 had a couple extra of the pre-virtual memory 370
instructions & 370 TOD clock but never got virtual memory ... 370/195
also had better hardware fault retry than 360/195). the machine was
decommisioned at sjr sometime in late nov. or early dec '78).

jorn@enteract.com (Jorn Barger) writes:
But human motives are at the root of the XML/semantic-web
problem-- even Yahoo's root categories offer a crude model
of human motivations (business, entertainment, reference,
etc).

So the 'irresistible force' of TimBL's W3C is now in full
collision with the immovable object of psychological
analysis. [2] And if something's got to give, I'd predict
it will be a more-general appreciation of this _blind spot_
in the sciences, and a deeper critique of the current
methodology of the social sciences. [3]

When I talk about my various projects over the last three
decades, involving literature, Joyce, timelines, Anti-Math
[4], and fractal-thickets [5], the compsci crowd has been
inclined to snicker (and the lit crowd to sneer, as well).

But there we have XML, and there we have a billion poorly-
classified webpages, and the twain just ain't meetin',
using any known knowledge-representation. So who's in
denial now?

one you missed was ted nelson & xanadu ... the originator of
hypertext. a basic issue between xanadu and w3c was bi-directional
links. w3c allowed lots of links to appear and grow with-out reguiring
the overhead of bi-directional synchronization. as a result there is
lost information at the convenience of significant distributed
freedom. this is an issue that there is possibly more knowledge in the
(bi-directional) relationship of web pages ... than possibly in any
specific classification of the pages themselves. to some degree the
classification issue is a characteristic of search engines and the
desire to use search engines to discover similar things.

possibly the most thoroughly implemented taxonomy is UMLS at NLM
(something like 25,000 concepts and 250,000 terms last time i worked
on it) that is used to classify medical knowledge. There was recent
presentation that I was at claiming that there is still at least a 50
percent variation in the classification of medical documents by
professionals at the NLM (i.e.. two professional classifiers with the
same training would have a 50 percent difference in the
classifications they gave a medical document). Some have made the
observation that the "web" is starting to reach the seach complexity
level that NLM reached around 1982.

Brian Inglis writes:
Don't know if those algorithms are implemented, but IBM VM
certainly used disk RPS features, and afc regular Lynn Wheeler
may have worked on some of them. ISTR some FTR buffer
optimizations and some paging optimizations to write pages on the
next free block under a head. RPS misses were a big concern for
IBM at one time and changes were made to software to avoid them.

I did some simple ordered seek queuing for cp/67 which carried
over into vm ... bascially an elevator algorithm.

on rotational stuff there were a couple of issues ... optimizing
transfer efficiency and minimizing channel busy. Most of optimizing
transfer efficiency (in vm paging and cms file system) was careful
ordering ... while the 370 "RPS" stuff was primarily minimizing
channel busy. The "RPS" stuff didn't actually enter into arm
scheduling (i.e. know the current rotational position and schedule the
arm motion to a different cylinder position to just in time to pick up
a record rotating under the head

CKD disks have a search support that examines record header content to
see if it is the desired record to be transfered. because of memory
issues in the '60s the match data was in processor memory ... which
had to be retrieved as each record rotated under the head. This
resulted in dedicating (shared) channel, (shared) controller, and disk
until the correct record was found. Worst case scenario could be a
multi-track search on 3330 locking up resources for 19 revolutions at
60 revs/sec (i.e. disk operations that took 1/3 second elapsed time).

RPS was introduced in the 3330s which had 20 surfaces/heads ... but
only 19 data surfaces. The 20th surface was dedicated to rotational
positioning information. If you had carefully pre-organized your data
on track surfaces ... you could record the approx. record start
position of each record. You could move the arm into position with a
seek command ... and then instead of busying the channel and
controller until the record had rotated under the head ... the new
command could instruct the disk to go off by itself and not bother
anybody until the rotation had spun around until a specific location
was under the head. At that point the disk was suppose to attempt to
reconnect to the processor .. by gaining access to the controller and
channel.

This RPS (rotational position sensing) attempted to minimize channel
and controller busy during disk non-data-transfer operations (but not
directly optimize the motion of the disk arm itself). The downside to
RPS was that if either the controller or channel happened to be busy
at the moment the disk wanted it ... there was an RPS-miss and the
disk had to wait a full revolution to try again. Again the issue was
constraint on electronic memory ... there was no track buffering
available. Full track buffering came in later that minimized the
requirement that there be end-to-end synchronization between the disk
head and all the components back to the processor memory.

The issue of taking into account rotational positioning with respect
to arm motion has somewhat been dependent on real-time knowledge of
existing rotational position at the moment it was decided to move the
arm ... as well as all the possible target locations for the arm
motion. To be really qeffective that somewhat implies having the
queue of requests stored outboard in the disk itself ... and implement
the service strategy directly in the disk electronics.

VM attempted to make up for the deficiency in not having real-time
information about arm location ... by having a regular ordering of
data on disk ... and being able to batch multiple requests in a single
operation on a per arm position basis. Given that you might be doing a
full disk rotation transfer of data per operation ... there was less
advantage loss by not supporting arm rotational position in the arm
motion scheduling algorithm (which the processor didn't actually know
at any particular instant).

cstacy@dtpq.com (Christopher C. Stacy) writes:
Ted Nelson wrote his concept of hypertext in a self-published
paperback sort of hippie-looking book called "Computer Lib And
Dream Machines" in 1974. His idea was based on an indexing
system using numeric codes called "tumblers". By the time I
had first heard of it around 1979, he had still been unable to
implement it at all, and was reportedly wandering around trying
to find a programmer.

cstacy@dtpq.com (Christopher C. Stacy) writes:
Some of the first real Hypertext systems were implemented in the
early and mid 1970s. For example, the EMACS "Info" subsystem
used both hierarchical table-of-contents and hyperlinks.

XML, AI, Cyc, psych, and literature

jorn@enteract.com (Jorn Barger) writes:
Doug Lenat's Cyc Project [1] is generally considered to be
more airy than engineery, I think-- they're trying to market
it as a universal ontology for intercommunication between
databases, and XML has turned that into a hot market, but
as far as I know the Cyc solution is just too clumsy to seem
practical.

i've had very little to do directly with Cyc ... other than possibly
running into doug at various MCC meetings (when mcc still existed).
Did do some work with some other semantic related operations at MCC
tho.

COIN project at MIT has also done a lot of work on things like
semantic operation of database integration ... somewhat focused
opportunities with mergers of financial institutional ... and being
able to consolidate data processing operations.

so ... slightly to bring it to a.f.c. ... one of the primary players
at COIN was the person that wrote the original SCRIPT for cp/67 cms at
the cambridge science center (all these many years ago in the
mid-60s). Then in 70, G. M. & L. created GML (also at the cambridge
science center) which was then integrated into SCRIPT (so script had
support for both dot-type formatting controls and GML type formating
controls). The GML effort then spawned SGML, HTML, XML, ECML, FSML,
etc.

i didn't say that it addressed classification ... it was different
ways of finding documents. the example is the UMLS taxonomy for
classification of medical knowledge. Classification isn't being done
as an end in itself aka classification is being done not for the sake
of performing classification ... and then not used for any reason
... it is typically used as an aid for people finding related
documents or documents of particular kind. In the NLM case, there are
professional classifiers that are trained in the taxonomy. References
to medical knowledge are entered into the library including references
using the classification. one of the uses of the taxonomy in NLM is
not only the classification themselves the systematic use of
broadening and narrowing ... a "broaden" term will increase the hits
... a "narrowed" term will decrease the hits. Besides having
professional classifiers ... people are trained both in the terms but
also in being able to broaden/narrow the search space.

another way of finding related documents is having direct pointers to
related documents. in fact, i heard a presentation that the major
search engines will weight/order hits in part based on them being
referenced by other documents.

kpneal@POBOX.COM (Kevin P. Neal) writes:
Well, this answers the question "Why use SMTP instead of sendmail?" but
does not address why IBM had to reinvent the wheel (again).

Why didn't IBM just add SPOOL support to sendmail? It's not like the
source is hard to come by or anything.

original IBM tcp product was for VM written in Pascal ... including
the SMTP processor. This was ported to MVS (for the mvs
product)... even down to the point of emulating some of the CP kernel
interfaces used by the VM product. This included SMTP support for
standard spool (running on either platform).

at the time there were lots of vendors writing their own tcp/ip
software support ... so that was not particularly unusual.

I had done the RFC 1044 support for the product. The base product had
around 44kbyte/sec thruput consuming nearly a full 3090 engine (either
vm or mvs). The rfc 1044 support was able to achieve around 1mbyte/sec
thruput (limited by channel hardware) using only a modest amount of a
4341 engine.

I also wrote an IBM mail<->822 translator in REXX. Originally this was
used for people with both VM userid and unix workstation ... you could
sent things up so that all your incoming IBM email (in a variety of
formats) would be translated/gatewayed to 822 and forwarded to your
unix workstation.

the 3880-13/sheriff disk caching people had some interestisng
performance numbers they advertized. this was 20 years ago. the
3880-11/ironwood was a record/page cache .. targeted at 4k page/record
data. 3880-13/sheriff was a full-track cache. they published some
numbers that sheriff had better than 90 percent cache hit ratio. this
was for application reading sequential data with 10 records per track;
aka the application would read the first record on the track ... which
caused the whole track to be brought into cache. the program then
would sequentially read the other 9 records on the track ... all being
cache hits ... resulting in the 90 percent cache hit ratio. a trivial
change in the data definition for the application ... specifying
full-track (aka 10 record) buffered reads would have changed the cache
hit ratio from 90 percent to zero percent (aka every application read
would have resulted in a cache miss).

This one has nothing about Word or wordprocessing, so I feel you've
wasted my time (so I'm now inclined to ignore all your links in the
future).

which is a comment about the convention of changing or not changing
subject line during thread drift. the english on that reference is
from the subject line of the posting ... and presumably you could go
to google and find the complete thread with all postings with that
subject line ...

jorn@enteract.com (Jorn Barger) writes:
I was trying to emphasize that there's a continuum, and embedded
formatting is not necessarily at the 'evil' end. My question
about Goldfarb-et-al was really, "How did this weak hypothesis--
that separating structure from formatting is desirable-- become
the unquestioned doctrine of a semi-fascist hate-cult?" ;^/

we all worked on the same floor at 545 tech sq. in the late '70s i
tranferred to the west coast (about the time-frame of sgml). within a
year ... "G", "L" .. as well as the guy at cambridge that is
responsible for the internal network also followed. "L" went to work
on BLOBs in system/r and r-star. "G" continued on with sgml activity.

somewhat in parallel ... CERN had done the big tso/cms bake-off report
approx. '74 and adopted vm/cms. Their sister location SLAC and CERN
had very similar vm/cms operations and put a lot of effort into it and
also shared things between the two locations. That could have
contributed to the pretty independent evoluation of HTML from people
at CERN ... compared to what "G" was doing first at tech sq ... and
then out in san jose. I believe slac claims to have the olddest web
server in existence (or possibly referring to the content on their
server ... or the lineage of that server).

A lot of the other stuff came out of the browser culture ... much of
it went on pretty independent of GML/SGML/HTML culture. My wife and I
spent a year working with this small client/server startup on being
able to support financial transacgtions on the server. We were mostly
dealing with the people on the server side for the creation of
electronic commerce ... and had much less contact with the people on
the browser side.

in the following posts there are some URL references specifically drawing
connections between electronic commerce, x9.59 and server stuff
http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer and electronic commerce

Christopher Browne writes:
A digital certificate might be somewhat more robust than a simple 9
digit decimal number, but nonetheless if it is as centralized as the
SSN, it will suffer from similar sorts of vulnerability to attack.

It may very well be preferable for different sectors of society to use
different kinds of identity certificates, thus making them more
resistant to attack.

independent of digital certificates and certification authorities ...
digital signatures and asymmetric cryptography can be used for
authentication. in its simplest form .... substitute shared-secret
authentication (that exists in large number of existing business
processes) with digital signature authentication. This can be done w/o
the existing business processes w/o resorting to certification
authorities by registering the public key in place of a shared-secret.

The obvious advantage of public key authentication is that the public
key is only used for validating a transaction, request, message ... it
can't be used for originating requests. This eliminates the master
file harvesting that goes on today for fraud purposes ... that can
enable fraudulent transactions aka acquiring the master file of
shared-secrets allows fraudulent transactions to be originated ... somebody
harvesting a master file of public keys ... doesn't enable origination
of fraudulent transactions. Slightly related thread on security
proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61Security Proportional To Risk

This use of digital signature technology is totally independent of
whether certification authorities and digital certificates are
involved at all.

The issue of certification authorities and digital certificates were
targeted at an offline world ... i.e. when there isn't online access
to the authoritative agency responsible for the information ... a
stale, static subset of an authoritative agency's information can
be encapsulated in a digital certificate and made available for use by
relying-parties that don't oltherwise have online technology.

The issue that the original x.509 identity certificate activity ran
into problems with .... was that frequently it wasn't predictable what
kind of information relying-parties might be interested in ... as a
result there was an initial effort to overload such certificates with
huge amounts of privacy information. Before any significant deployment
of such implementations went into effect, most business operations
realized such collection of information represented huge privacy
violations and possibly even liability problems.

Note that in the (some still emerging) world-wide, online, all the
time environment ... if anything of value is involved ... an online
reference is made to the responsible authoritative agency for
up-to-date information (rather than superfluous stale information
contained in a digital certificate). That somewhat leaves digital
certificates useful for the remaining offline environments and/or
online environments involving transactions of no-value.

"Andrew Swallow" writes:
Does this reduce the certificate to containing the keys for the indexes such
as the person's name, nationality and (passport?) serial number?

For physical inspections a copy of the person's photograph, occupation, date
of birth, sex, height, finger print and physical signature would be useful.

I suspect that what is required comes down to -
1. A passport whose electronic copy is protected by a digital signature.
2. Databases indexed by passport number.
3. International rules on the format for passport numbers.

in the financial transaction case ... the transaction contains the
number ... there is digital signature ... and any appended digital
certificate contains just the account number and the public key.

The transaction is routed to the online authority by the number in the
transaction, the online authority retrieves the respective account
record by the number in the transaction. The account contains a copy
of the public key ... which is used to validate the digital signature.

The existance of the certificate in such an environment is trivially
shown to be redundant and superfluous ... since the number has to
occur in the transaction ... and the public key (effectively) will be
in the account record.

So in a business sense ... either there has to be a unique (redundant
and superfluous) certificate for each business operation ... each with
its own business unique number ... ar all businesses in the world
agree on the single common unique number of each unique person.

In the reference to a recent posting on the subject ... there is
mention of the alternative FSTC FAST model ... the end-user makes a
signed assertion as to some piece of information and the relying-party
sends off that assertion to the appropriate authoritative agency for
confirmation. This is in effect, the real-time, online information
paradigm ... as opposed to the certificate, offline, stale information
paradigm. The advantage of real-time, online is that it is real-time,
and online ... it also can handle assertions that have to do with
aggregation (like limit on number of transactions in a period or
things like max. spending or credit limit ... like financial
transactions).

Another trivial advantage is that I can assert that I'm over 21 and
live in a location that is allowed to purchase wine. I don't actually
have to provide either my birth date or address ... the authoritative
agency then just confirms or rejects my assertions.

Part of this is clearly delineating the difference between
authentication (and authorization) vis-a-vis identification. Let's say
I'm issued hardware token that has both PIN and biometric matching
capability ... that performs digital signatures. If i correctly enter
my PIN and/or biometric information ... the hardware token validates
such information ... and then performs a digital signature operation
... the authoritative agency can authenticate & authorize me ... w/o
having to actually identify me on every transaction. The appropriate
operation of the hardware token is sufficient to indicate valid
3-factor authentication (aka something you have, something you know,
and something you are) w/o having to actually perform an
identification operation.

The distinction is that the vast majority of the operations don't need
to proove your identity as part of authorizing a transaction ... they
just need to authentication that you are authorized to do what you are
asserting. This can be a US citizen, greater than 21 years old, or
some other characteristic.

The vast majority of equating digital certificates to paper/physical
credentials are left over from pre-online (let say pre-1970s). Starting
in 1970s ... almost everything involving any operation or transaction
of value started migrating to online operations. The
credit/debit/financial world started migrating to online in the 1970s
(in some respect some of the certificate proposals in the 90s for
financial operations were in effect trying to turn the clock back at
least 30 years).

One could claim that customs and immigration just need a number to get
online information. While it is nice to have an offline document that
has your face ... what they really want to do in the modern online
world is to reliably match you up with online information .... which
not only has a little ticker that says you might actually be a us
citizen ... but possibly how many times you have taken international
trips in the last 30 days ... what sort of things have you been
declaring or not declaring ... and/or to see if there are any
real-time alerts (which typically wouldn't have been inserted in your
passport at the time it was manufactured). Again .. the assertion that
anything that involves anything of real importance will reference
online information ... and it is only left to the no-value, offline
operations where a certificate for use for no-value things is of
interest.

A side issue then arises that if the certificate is not useful for
things of value and importance and only useful for things of no-value
and no-importance ... what sort of value proposition is there for
creating and supporting certificates (if they aren't going to be used
for operations of value and importance)?

Who would pay for a complex certificate infrastructure if such an
infrastructure is only of use in no-value and no-importance
operations?

National ID

Brian Boutel writes:
Do you always have to sign it? Here in NZ, while that is still
possible, most people key in a PIN.

I suppose that works because we have a single nationwide EFTPOS
network, using the same cards as ATMs, and all major credit cards use
it too. Virtually all shops and cafes have a terminal. I haven't seen
a zipzap for years. The terminal prints a slip, and you either key in
a PIN or sign the slip.

?smartcard+fingerprint

m.lyubich@computer.org (Mykhailo Lyubich) writes:
does anybody know a successfull integration of the smartcard and the
fingerprint sensor, which is possible to buy on the market?

part of the problem is that iso7816 smartcard standard includes card
"flexibility" standards that creates problems for most fingerprint
sensors (fabrication of a fingerprint sensor that can be embedded in a
smartcard meeting iso7816 smartcard standards ... and still continue
to work).

now there are some that have "line" sensors that you have to drag your
finger across for the reading. These line sensors have much less
problem meeting flexibility standards for smartcards. The problem is
that they seem to be finding that to get good readings from dragging
your finger across a line sensor ... you just about have to have
"guides" ... typically ridges on both sides and/or depression. These
"guides" then tend to violate the flexibility standards.

however, the line sensors do seem to have a number of operational
characteristics

there were a number of USB dongles that had built-in line fingerprint
sensor ... and the keyfob/dongles had depression/groove for guiding
the finger as it is being dragged across the sensor. the USB dongles
have many of the charageristics of a smartcard just not in an iso7816
form-factor and/or with iso7816 contacts.

smartcard+fingerprint

Jan Panteltje writes:
Dunno, but in a recent test in the Dutch magazine C'T it was shown
that not any fingerprint sensor was worth any thing as far as security goes.
One would even activate (you could get access) by breathing on it.
The condensation made the finger print of the previous person appear....
Combining it with a smart card would give it the same security as a
smartcard alone.
Hope that is a hint.

one of the things that the line/swipe sensors do ... besides being
more flexible (although there is now the guide question) ... is image
from previous sensings are left on the device. the issue has been that
it has been hard adapting full print sensors to the iso7816 smartcard
flexibility standard. there has been somewhat more success adapting
the line sensors that you drag your finger across to the 7816 card
flexibility standard. however there is now starting to be some
evidence that a guide is needed while dragging the finger across ...
which now also now tend to have problems meeting flexibility standard.

Certificate Authority: Industry vs. Government

"Andrew Swallow" writes:
Outside of the USA everyone pays for their own passport. Photographs and
embedded chips are already being added to credit cards.

The advantage of a photograph on the document is that the clerk can verify
that the certificate has not been stolen. The electronic photograph and
finger print do the same.

Verification of the person against the certificate is an anti-fraud matter
of high value and major importance.

Andrew Swallow

a couple of issues ... one is the assumption that financial
institutions can rely on merchant clerks for properly doing the
checking. in fact, there have been quite a few scenarios where it has
been demonstrated that the consumers financial institution might not
always be able to rely on the merchant bank or the merchant. The
merchant (and therefor the merchant's bank) interest is that every
transaction be approved. frequently clerks are under time constraints
on how fast they get a transaction thru the system.

the counter example is that the consumers financial institution can
rely on the correct operation of the card ... regardless of whether
there is a clerk at a POS ... or the POS is totally unattended. If the
correct operation of the card includes two-factor (something you have
and something you know) or even three-factor (something you have,
something you know, and something you are). as more and more things
move into distributed, network environment ... with transactions
potentially involving international oeprations ... having to rely on a
clerk (which may or may not actually exist) is actually quite
problematical. Lets say it is the clerk at mcdonalds (i think I saw in
the news this morning ... that mcdonalds will start accepting debit &
credit cards) ... do you believe the mcdonalds clerk is going to
police whether a card has been stolen or not? Or let say it is a gas
pump or a atm machine that has no clerk.

there is on going thread in alt.folklore.computers that started out
regarding national id .... about the number of people who have used
another family member's credit card; say somebody's daughter is using
their father's credit card that includes their father's picture, name
and signature ... and no problem taking the card into a "strange"
(i.e. totally unknown to any family member) merchant and successfully
using the card.

now as to somewhat parallel thread on token & fingerprint. One of the
issues about having fingerprints with match on card for payment cards
... isn't necessarily that fingerprints are actually more secure
... it is that some significant percentage of the population write
their PIN number on their payment card. There is small added
difficulty for a theif using a fingerprint stolen card ... than a PIN
stolen card ... where the PIN has been written on the card.

in any case ... there is a big different with regard to who is being
relied on to perform the operation ... and whether their financial
interests in any way coincide with the responsible parties or the
consumers or anybodies (or even if there is a "who" to actually rely
on).

one of the tasks given the x9a10 committee for work on x9.59 standard
was to preserve the integrity of the financial infrastructure for
all electronic retail payment transactions (aka retail, internet,
non-internet, face-to-face, point-of-sale, clerk present, no clerk
present, totally automated, non automated). misc. x9.59 references

the meaning was suppose to be that PINs are a problem when people
write them on their card. for some, the solution of fingerprint (or
other biometrics) for payment cards might not be considered more
secure than general PINs ... but they are possibly more secure than
PINs written on cards (i.e. it is harder to lift & duplicate a
fingerprint on a card ... than it is to lift and duplicate a PIN on a
card).

smartcard+fingerprint

Francois Grieu writes:
This interesting argument goes against sensors on the Smart Card iself, as
the owner of a Smart Card is the same from transaction to transaction.

which is one of the supposed advantages of the line sensors where the
finger is drawn across the sensor. there is still the issue of picking
up a latent print on the card itself and duplicating that print
... dragging it across the line sensor. as in the ongoing certificate
thread in this n.g., ... there is some likelyhood there is latent
print on the card which could be lifted, duplicated and dragged across
the sensor ... but that technology typically is considered more
difficult than lifting a PIN written on the card (aka the comparison
isn't between a latent print on the card and a really secret pin
... it is between the difficulty of lifting a latent print on the card
and duplicating that entry of that print ... vis-a-vis lifting a PIN
written on the card and duplicating the entering of that PIN)

smartcard+fingerprint

Peter Fairbrother writes:
I'd guess that there are more fingerprints on cards (which are after all
shiny and good surfaces for fingerprints) than PIN's written on cards. The
tech to duplicate them isn't hard, it's like making a PCB, which anyone can
do. And the user can't be expected to keep his prints off cards as a
security requirement.

but a person could choose to register a finger that has the lowest
probability of being on the card.

so one way is to offer it as a personal choice option .... those
people who find the conveninece of fingerprint &/or are otherwise
inclined to write their PIN ... might find fingerprint a preferrable
choice to PIN. Others might wish to have 16 digit PINs that they can
remember and regurgitate effortlessly. the financial institution might
then use compensating procedures depending on which choice was
exercised.

Some of the writing PINs seems to be somewhat associated with
frequency of using the card .... people who almost never use any card
... and therefor are not inclined to remember the PIN ... or people
that use lots of different cards ... and are possibly inclined to
mis-remember PINs and/or not remember for infrequently used cards
(unless they've been able to set them all the the same value).

Defeating telemarketers

Pete Fenelon writes:
I hate telephones. More specifically, I hate telephones ringing
when I don't want them to. I've always taken the attitude that
my telephones are for my convenience, not for other people's, and
therefore my numbers are given out on a "need to know" basis.
Caller-ID blocked whenever possible, too. Certainly works for me.
The only marketing calls I get are from the phone company... and
they've been told firmly that I won't be buying any more services
from them (my voice line is merely a legacy that I need to keep
around to have an ADSL line; I think for six months there wasn't
even a phone plugged into it; I make 95% of my voice calls on my
cellphone which just about uses up the free allocation of minutes)
I don't even give out my DDI office number outside the company if
I can avoid it.

i was at a presentation a couple weeks ago where somebody explained
how the telezappers work (radio shack, etc) ... which emit a tone to
tell the telemarketers to go away. telemarketers are typically
computer programmed dialing ... the computer listens for somebody to
pick up before transferring it to the first available person in the
stable. if it gets various kinds of telephone company error messages,
it marks the number as not in operation, hangs up, and goes on to the
next number. the telephone company error message that indicates that a
number is not in operation starts with specific/unique three tones.
the telezappers reproduce the same tone. the person demonstrated by
whistling the tone (i.e. if you don't want to buy a telezapper, learn
to whistle that tone).

Anne & Lynn Wheeler writes:
so one way is to offer it as a personal choice option .... those
people who find the conveninece of fingerprint &/or are otherwise
inclined to write their PIN ... might find fingerprint a preferrable
choice to PIN. Others might wish to have 16 digit PINs that they can
remember and regurgitate effortlessly. the financial institution might
then use compensating procedures depending on which choice was
exercised.

as part of the x9.59 standards work to preserve the integrity of the
financial infrastructure for all payments ... the work looked at how
to provide high integrity transactions for all environments (including
things like unattended POS terminals or internet ... etc, where there
isn't a human to examine the card).
http://www.garlic.com/~lynn/x959.html#x959

in x9.59 digitally signed transactions ... the environment performing
the signing operation could be somebody's PC software, single factor
authentication hardware token, 2-factor authentication (something
you have and something you know ... like a PIN), or 3-factor
authentication (something you have, something you know, and something
you are ... like biometric). if the hardware token performs the PIN
and/or biometric matching ... then the digital signing and transport
of the transaction can be identical regardless of the method of the
originating environment.

note however, the relying-party ... like a financial institution
responsible for resolving the transaction can have assurance factors
built into its transaction risk management operation; ... aka various
assurance related items are "registered" and are used by the
transaction risk management infrastructure as part of transaction
operation. Some assurance items can be token/no-token, kind of token,
PIN/no-PIN, biometric/no-biometric. Other assurance factors might
involve the end-points ... like is a particular transaction involving
a hardware token used in conjunction with a FINREAD complient terminal
or not. It is potentially possible that the same hardware token
operate in a number of different modes for different kinds of
transactions ... and the risk management infrastructure dynamically
adjusts to the specific operational environment for the specific
transaction (possibly personal choice with regard to kind of token ...
but personal choice might change for different kinds of transactions).

this somewhat relates to security proportional to risk. from a risk
management standpoint ... "security" can also translate into amount of
assurance (possibly level of certification of various components) or
amount of insurance. some related discussions of adaptable/agile assurance
with regard to things like hardware tokens or no hardware tokens:
http://www.garlic.com/~lynn/x959.html#aads

jbmiller@world.std.com (Janice Miller) writes:
It still probably depends. When I went to Cascade (frame relay and ATM
switch manufacturer, now part of AT&T) seven years later, in 1993, I was
the first woman in Engineering, and there were guys in software five, ten
years older than me, who had never, in their entire careers, worked with a
woman engineer. In support or tech. writing, yes, but never in
engineering. There didn't seem to be much crossover between system
software and network switch firmware (I was in network management), though
other companies, some of them, had more women. It's kind of interesting
that the proportion of men to women seems to stay nearly constant in an
organization, over several years, even when the headcount increases by
quite a bit. Comms software at Data General, when I was there, stayed
pretty constant at about 1/3 women.

my wife and i were doing some consulting for an operation 5-6 years
ago ... and they found out that the project was going to have an audit
and we were asked to handle the review. we did presentation and
answered lots of questions. towards the end ... the person doing the
audit got a little less formal and we were sitting around with others
kibitzing. somebody brought up what schools people had attended. he
mentioned a particular university and my wife asked him what years and
what school. she then commented that she was the only female in the
engineering graduate school at that time. He replied ... no you
weren't ... and mentioned somebody ... my wife said that was her. He
looked at her again and said something about her having gotten a lot
older ... so she told him that he had also. random ref:
http://www.garlic.com/~lynn/99.html#15 Glass Rooms (was Re: drum memory (was: Re: IBM S/360))

after school she worked in the JES group in gburg and then was con'ed
into going to pok to be responsible for loosely-coupled (aka cluster)
architecture. there she originated peer-coupled shared data
... which saw some deployment as IMS hot-standby ... and then much
later as parallel sysplex.

Charles Richmond writes:
Back in the "old days", all real programmers wore hiking
boots...in case a mountain springs up in the machine room.

that was the stl/bldg90 machine room that had the springs ... not
bld28. stl went in at the north end of coyote valley ... on a flat
area just at the foot of some hills. during the raining season the
machine room would flood.

Pismronunciation

nxk3@po.cwru.edu (Natarajan Krishnaswami) writes:
On Sun, 1 Dec 2002 10:10:30 +0100, Joachim Pense wrote:
No, QUEL was an developed independently from SQL at Berkeley (See e.g.
Date's book on Databases). The Berkeley based DBMSs INGRES and POSTGRES
first ran with QUEL, and later adopted SQL; so for users of these systems,
SQL looks like a successor of QUEL.

AIUI, the name SEQUEL was a mild jab at the Ingres folks by the System
R folks. Structured English QUEry Language. (The vowels were dropped
to avoid a trademark lawsuit, so "English" was dropped from the
expansion: acronym/backronym feedback!)

Pismronunciation

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Now there's something you don't hear about very often. I've seen
the odd glancing reference to it on AFC over the years, but I get
the impression it's not something that anyone's dealt with much.
I first read about it in a computing magazine 20-odd years ago when
I was a spotty youth, and haven't picked up (groan) much about it
since...

i think it was one of the few things that they came up with that
the PC/RT VRM was used for.

when the 801 displaywriter follow-on got killed ... and the decision
was made to remap the hardware to the technical workstation market
with a unix port ... the group that had done the pc/ix port was hired
to do a similar one for the pc/rt. however, instead of just doing a
unix port ... they had an idea to use all the pl.8 displaywriter
programmers to develop a machine abstraction layer written in pl.8 for
the unix port to be done to. this supposedly would insulate the unix
port from the low level characteristics of the romp ... and greatly
speed up the port (in hindsight ... the port took significantly longer
than if it had been to the bare metal ... and it created an
environment where all the pc/rt device drivers were non-standard and
duplicated ... first a somewhat unix looking device driver built to
the vrm interface ... and then a vrm device driver).

in any case, pick was one of the few other things that actually ran on
the vrm layer ... and you could run pick concurrently with unix (aka
the vrm was a psuedo virtual machine capability).

Charles Richmond writes:
Actually, I was referring to a miraculous occurance...that a
mountain would suddenly just rise up from the computer room
floor. I had no intention of invoking water of any sort...

i was wearing boots as solution to the pretty deep mud that could
occur walking to work .. bldg. 28, before they built the new facility
up on the hill. I never walked to work at the new building
... although there was some mornings & weekends that i would run up to
the front entrance and back home (about 7 miles round trip ... but it
was that long steep hill that would get me).

The New York Times
December 1, 2002
They Got Mail: Not-So-Fond Farewells
By KATHERINE ROSMAN

For three hours, Lincoln Ornston sat at his computer typing, deleting,
rephrasing and searching for the words and tone befitting the occasion.
After practicing law for nearly four years at O'Sullivan LLP, a Manhattan
firm, Mr. Ornston understood the necessity of precise language.

When he had completed the document, which he had written as a mock press
release, he e-mailed it to about 140 colleagues:

NEW YORK, NY (BUSINESS WIRE) May 31, 2002 - O'Sullivan LLP (the "Firm")
today announced the departure of Lincoln Ornston ("Shine" or "Uncle
Junior"), the baldest, baddest associate to ever roam the halls of the
vaunted NYC venture capital powerhouse.

The memo continued for a page and a half in this vein, referring to two
partners by name as "tormentors," gently digging at law firm culture and
quoting a Dickens character: "the law is a ass [sic], a idiot."

[MIP envy]
n. The term, coined by Jim Gray in 1980, that began the Tandem Memos
(q.v.). MIP envy is the coveting of other's facilities - not just the
CPU power available to them, but also the languages, editors,
debuggers, mail systems and networks. MIP envy is a term every
programmer will understand, being another expression of the proverb
The grass is always greener on the other side of the fence.

jmfbahciv writes:
I've never heard of the term "MIP envy". I'm not sure I
suffered from it. Perhaps that [not suffering] was a side effect of
being in the Monitor group?

i think not too long after i went to cambridge ... somebody asked me
if it was really necessary that i use as much processing as the whole
rest of the organization.

later, one of the benefits of rewriting the i/o supervisor for the
disk engineering labs was that a lot of processing power became
available; even with a dozen test cells operating concurrently the
machines were still close to zero percent cpu utilization (which they
found better than being able to only operate a single test cell at the
time at near zero percent cpu utilization).

Snow White (IBM) and the seven dwarfs (RCA, Univac, GE, Honeywell,
CDC, Burroughs, and NCR) had all emerged in the computer industry
before SDS was formed in 1961. (DEC was formed in 1959 just prior to
SDS.) SDS had about 1% of the total computer market when it was
acquired by Xerox in 1969 to become XDS.

If anyone wanted to advance XDS to dwarf status when first GE [1970]
and later RCA [1971] withdrew from the computer industry nobody said
so. The references after those withdrawals were rather "and then there
were six," and later, "and then there were five."

Xerox withdrew from the mainframe computer industry on July 21, 1975
-- never quite achieving dwarfdom.

... snip ...

and of course melinda's virtual machine history has a lot of stuff of
early virtual memory in the area of 545 tech. sq. and multics deciding
on ge over ibm ... and various results.
http://www.leeandmelindavarian.com/Melinda/

both multics and science center were in 545 tech. science center had
the cp/67 & cms stuff and spawned vm/370 group. it also had goldfarb,
et al that did gml which spawned sgml, html, xml, etc. also had the
work on the internal network which also spawned bitnet and earn.

boston programming center was also in 545 tech sq ... with people like
nat rochester and jean sammet. when bpc was shutdown the people were
absorbed into either the development group (which had split off from
science center ... and eventually moved out to the old sbc bldg. in
burlington mall) or the science center.