1 INFO-VAX	Sat, 01 Nov 2003	Volume 2003 : Issue 605       Contents:H Re: Advertising  - was Re: [OT/FUN] HP live chat popped up when browsingP Re: Advertising  - was Re: [OT/FUN] HP live chat popped up when browsing  www.hp$ Articles that never make it to Mitre( Re: Articles that never make it to Mitre, Re: Authorised reseller application - UPDATE$ Re: Concurrent users from Accounting) Re: Database selection (was: Advertising) ! Re: INTRODUCING Virtual P*o*e*t*s 1 Object filesystem could be done in VMS as a layer  Re: SIMH: used with VMS?0 Re: UK source of 800/1600 BPI SCSI reel to reel?0 Re: UK source of 800/1600 BPI SCSI reel to reel?0 Re: UK source of 800/1600 BPI SCSI reel to reel? Re: used with VMS? Re: [Fwd: Re: World Wide Wake]  F ----------------------------------------------------------------------  # Date: Sat, 01 Nov 2003 01:39:49 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")Q Subject: Re: Advertising  - was Re: [OT/FUN] HP live chat popped up when browsing 6 Message-ID: <00A2835E.723BF18B@SSRL.SLAC.STANFORD.EDU>  W In article <3FA2B777.4090500@tsoft-inc.com>, David Froble <davef@tsoft-inc.com> writes:  >David J. Dachtera wrote:  >  > G >> I have recently been made aware (in a non-NDA environment yet!) of a J >> large religious sect that has a geneology database of cica. 5 petabytesI >> running on an OpenVMS + StorageWorks backend. Not sure which database,  >> but I'd guess Oracle.   >  > P >I get mildly amused when I see automatic assumptions that every application in Q >the world is using a relational database.  I will admit that for an application  K >that is mainly retrival of data a relational database is a good fit.  But  7 >Oracle?  Thought you were a proponent of 'affordable'?   O Besides, I would really have thought a geneaology database (tracking ancestors, E children, etc) would be an excellent fit for a hierarchical database.    -- Alan    --  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================    ------------------------------  % Date: Fri, 31 Oct 2003 19:58:44 +0100 * From: Paul Sture <nospam@sture.homeip.net>Y Subject: Re: Advertising  - was Re: [OT/FUN] HP live chat popped up when browsing  www.hp 0 Message-ID: <3FA2BEF4.295654E5@sture.homeip.net>   John Smith wrote:  >  > David J. Dachtera wrote: > > John Smith wrote:  > >> > >> Didier Morandi wrote:D > >>> Looking for info, I just went to my favourite OpenVMS pages onH > >>> http://h71000.www7.hp.com/openvms when a window suddenly popped upH > >>> on my M$ screen and a chat session started, powered by LivePerson. > >>> Here is the log: > >>> 	 > >>> --- 4 > >>> Please wait for an HP Sales Expert to respond.? > >>> Welcome to HP! My name is Gene. How can I help you today. D > >>> you: Hello Gene. Are you an OPS5 program or a real person? :-)8 > >>> Gene: I'm real, although I've been called. . . lol > >>> Gene: yes, I'm real & > >>> Gene: just making a little funny > >>> Gene: how can I help youH > >>> you: Good. So I leave you. I'm busy and you will be too. This game5 > >>> is nice. Have a good day. Cheers from Toulouse.  > >>> you: Didier < > >>> Gene: Thank you for visiting hp.com. Have a Great Day!; > >>> Chat session has been terminated by the Sales Expert. 	 > >>> ---  > >>>  > >>> Experimented that before?  > >>F > >> I didn't see it but I also have lots of 'features' disabled in my
 > >> browser.  > >>I > >> On another note, what struck me as I read the VMS home page were the ; > >> following words under a couple of the section headers:  > >>I > >> "OpenVMS offers immunity to both planned and unplanned downtime with 7 > >> proven, unmatched, continuous computing, including E > >> disaster-tolerant, multisite clusters spanning 500 miles - at an  > >> "open system" price." > >> > >> and > >>J > >> "OpenVMS is the acknowledged leader for enterprise-scale, bulletproofF > >> computing and continues to serve the 10 million users who rely onC > >> it. Simply put, nothing stops it! OpenVMS couples unparalleled @ > >> functionality with enhanced performance, providing the highA > >> availability and reliability that your applications demand."  > >>C > >> These two paragraphs alone could be a pretty good beginning of I > >> full-page newspaper ad in the Wall Street Journal. A few minor edits G > >> (get rid of the 10 million users b.s.) and the addition of another H > >> couple of paragraphs ('that's why XYZ and ABC Corp. rely on OpenVMSH > >> to serve millions of customers hourly without costly downtime'), etH > >> voila, an ad that conveys a powerful message to a powerful group ofF > >> readers, ones who sign cheques for large computer systems and for > >> large projects. > > H > > I have recently been made aware (in a non-NDA environment yet!) of aA > > large religious sect that has a geneology database of cica. 5 D > > petabytes running on an OpenVMS + StorageWorks backend. Not sure) > > which database, but I'd guess Oracle.  > >  > > Can you say, "scalability"?  > >  > > T'would make a good ad, eh?  > N > Interesting.... would these be the guys with the data center in the old salt > mine?  > ? > Just imagine the twists in the VMS marketing possibilities...  >  > [wicked humor]L > If the XXX Church can track [whatever] and [relationships] between people,N > just imagine what a similar OpenVMS system can do for your Homeland SecurityM > De.......er...police state.....er....Communist regime. The possibilites for M > abuses are endless. Coupled with implantable RFID technology you'll be able M > to know exactly where each of your citizens/subjects are at all times, whom K > they associate with and when, and when tied to financial, library, health N > and other records, and advanced heuristics, you'll also be able to know what- > they will do next -- even before they do!!!  > 8 > Be in totalitarian control. Only with OpenVMS from HP. > [/wicked humor]    Try plugging in:     vms iraq  ' into the IT section at www.jobserve.com  :-)    --  
 Paul Sture   ------------------------------  + Date: Fri, 31 Oct 2003 20:27:39 +0000 (UTC) - From: lewis@wheels.mitre.org (Keith A. Lewis) - Subject: Articles that never make it to Mitre . Message-ID: <bnugjr$neu$1@newslocal.mitre.org>   Kilgallen@SpamCop.net (Larry Kilgallen) writes in article <dfc2JoEhwIDM@eisner.encompasserve.org> dated 30 Oct 2003 16:27:01 -0600: m >In article <eWfob.423$Tn6.30218@news.uswest.net>, "Michael D. Ober" <obermd-.@.-alum-mit-edu-nospam> writes: O >> In an indexed RMS file, is there any performance benefit of using a power of   K Whenever Michael posts (from uswest.net), I can see the replies but not his J original article.  I heard that at some point in the past uswest had a lotF of spam.  Is that why?  Maybe now it's time to take it out of the spam	 filter...   0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  + Date: Fri, 31 Oct 2003 20:29:01 +0000 (UTC) - From: lewis@wheels.mitre.org (Keith A. Lewis) 1 Subject: Re: Articles that never make it to Mitre . Message-ID: <bnugmd$neu$2@newslocal.mitre.org>   wrong newsgroup!   ------------------------------  % Date: Fri, 31 Oct 2003 22:01:06 +0100 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>5 Subject: Re: Authorised reseller application - UPDATE : Message-ID: <bnuin3$1659g1$1@ID-143435.news.uni-berlin.de>  3 "Island" <dbturner@islandco.com> schreef in bericht ) news:vq5b6mafi99235@news.supernews.com... L > Well, after 4 months we still have received nothing, not even notification > of denial of authorization.  > L > If anyone within Compaq/HP knows anyone high up in the Supply chain within > HP, please let them know we   > are waiting to hear from them. > 2 > FYI - We ARE a SMALL WOMAN OWNED Company !!! :0) > L > Amazing - we have orders being offered to us left right and center for BIG > systems, and can't quote. J > Frighteningly though, our customers can't find anyone else to quote them as > well. J > AVNET and PIONEER seem to want to push Intel based stuff according to my	 > clients  >  > Hmm  >  > David  >  > --   > David B Turner! > Island Computers US Corporation  > 2700 Gregory St., Suite 180  > Savannah GA 31404  > Tel: 912 447 6622  > Fax: 912 201 0402  > Email: dbturner@hpaq.net > http://www.hpaq.net  >  >   F This is the most disturbing message I've read for years in this group.   ------------------------------  % Date: Fri, 31 Oct 2003 13:18:46 -0500 + From: "Martin O'Connor" <moconnor@dvfs.com> - Subject: Re: Concurrent users from Accounting : Message-ID: <bnu927$15lp5o$1@ID-118202.news.uni-berlin.de>   ": >K : > I ran systems with batch jobs that ran for days, sometimes weeks (a VAX K : > 11/785).  If the system crashed all this information was not written to  : > accounting file. : F : That is appropriate, since accounting is for billing purposes and ifE : the system crashed the user did not really get their money's worth.  :   ] Back in the mid 80's we were looking at using the VAX for electric power control systems. The d accounting was a stumbling block since most important stuff was done by detached processes that stayd up until the system is shut down. We had requirements for periodic accounting reports. We started toW pursue with Digital having the accounting information for active processes periodically d checkpointed. Since the company ended up killing the product we never went any farther  with Digitald on this item. I still think that checkpointing the information would be a very good feature and thenB system crashes only lose the information from the last checkpoint.   Marty    ------------------------------  # Date: Sat, 01 Nov 2003 02:29:01 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")2 Subject: Re: Database selection (was: Advertising)6 Message-ID: <00A28365.51A93D87@SSRL.SLAC.STANFORD.EDU>  c In article <qiv6Q26EMyUg@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  >In article <00A2835E.723BF18B@SSRL.SLAC.STANFORD.EDU>, winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") writes: > R >> Besides, I would really have thought a geneaology database (tracking ancestors,H >> children, etc) would be an excellent fit for a hierarchical database. > D >There is a danger in having those who know a lot of technology makeD >judgements based on just a smattering of domain knowledge.  I inferB >from your comment that you figure each person has just one fatherD >and one mother.  That is the same mistake made by those who attemptD >to design genealogy software and provide a single field for date of/ >birth, for instance, a VMS date-time quadword.  > E >In actual genealogy work, diverse data may indicate several possible F >birth dates for an individual, so the important thing is that each ofF >those dates are entered in the database with a full indication of theD >original source for that particular date assertation.  The VMS dateK >field is inadequate since it has no way to indicate "sometime in November" = >or "the 16th of some month in 1936, the writing is smudged".  > E >Similarly, the parentage of a person may be in dispute, and rigorous B >genealogists will preserve all evidence.  My wife points out thatH >patriarchal naming is rather backward, since the identity of the motherD >is much better known than the identity of the father.  But even the= >identity of the mother can be obscured by the mists of time.   - Nailed!  Larry is of course completely right.   E In my own defense, all I can say is that if I were really going to be H involved in developing a geneaological database, I would have acquired aC lot more domain knowledge before opening my mouth.  (And my bias is  relational, incidentally.)   -- Alan  --  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================    ------------------------------  % Date: Fri, 31 Oct 2003 19:24:59 +0100 * From: Paul Sture <nospam@sture.homeip.net>* Subject: Re: INTRODUCING Virtual P*o*e*t*s0 Message-ID: <3FA2B70A.73E882AE@sture.homeip.net>   Didier Morandi wrote:  >  > Nic Clews wrote: > % > > VAXman-, @SendSpamHere.ORG wrote: P > >>I know that p*o*e*t*s gatherings are popular in UK pubs; I wasn't aware thatP > >>they were held here in the states too! ;)   Perhaps, you'd care to enlighten< > >>those that do not know the significance of this acronym. > >  > >  > > p*** > > off 	 > > early  > > tomorrow's > > Saturday >  > or "everyone"  > F I've never heard that variation. Nic's is the most common definition .   --  
 Paul StureH Whose local Guiness outlet is having a Happy Hour at something daft like& 11:30 to 12:30 tonight, for Halloween.   ------------------------------  % Date: Fri, 31 Oct 2003 15:08:27 -0500  From: G Everhart <ge@gce.com> : Subject: Object filesystem could be done in VMS as a layer& Message-ID: <3FA2C13B.7040806@gce.com>  O I wrote the following around 1997 to some folks, but it never had any followup.   O However it gives the outline of how one might put a dbms and lots of additional N info into an existing filesystem. This could be done for VMS, and probably for
 other OSs.  B Seems worth mentioning in a forum like this, for what it is worth.   Glenn Everhart     The notion here is that 5    * Managing huge farms of file structures is a pain 2    * Finding things in same is even more of a pain9    * A large server is useless unless you can find things           you need A    * Getting a few orders of magnitude faster access to same than 8          EVERYONE else's servers (including microsoft's)  ? The scheme outlined below is for a layer between RMS and an XQP ; or ACP, basically requiring no mods to either, which allows B your "current directory" to mean not just somewhere in a directoryA tree, but to mean a way of selecting what files you're interested C in looking at, based on criteria of path, date, contents, keywords, A size, or most anything else you can think of. Some periodic index A pass with an Altavista type indexer (make it increasingly able to < find stuff inside funny or compressed formats too) could get# extra data to allow retrieval with.   B It should be possible to construct examples easily with this whereB VMS access with the proper default (you have some fake "directory"B names available to set up the query, e.g. setting to examine filesA containing strings X or Y and string Z, so clients of your server > need no additional work to be able to use this) finds some bit> of data 1000 times faster than a competitor, who has to search thru large numbers of files.  ? My understanding of the MS object file system is that it is not : precisely this kind of thing; however I'd like to know for sure if you know.   ? BTW I consider this a relatively modest amount of work provided A the relational dbms can be picked up from somewhere. It need only ? run in user mode...no need to build one that can run in kernel. < Since underlying filesystems would be untouched & valid,this- scheme allows sensible backup policies too...    Glenn Everhart  2 From:	NORLMN::EVERHART     10-JAN-1997 12:40:24.50 To:	STAR::Z  CC:	EVERHART= Subj:	Let's do something Microsoft will find it hard to do...    From: Glenn C. Everhart  Date: 10-Jan-1997    Folks:E There's an idea I've had for some years (actually first wrote it down B c. 1992) that might be hard for Microsoft to copy if we act on it.   The idea is the following:  H One key bottleneck in handling information is finding things when you're@ looking for them. Right now, this is dealt with with ever-longerB filenames to try to encode enough information in a name to be able$ to tell where the stuff you want is.  8 That's a crock, and is becoming ever more obviously one.  9 But Microsoft seems to still be in that mold...as is VMS.     Now consider a system like this:  C When anything tries to open a file, intercept ahead of the open and B gather the name, did, fid, etc. that are passed. Shoot the requestB off to a daemon that runs a real honest-to-God relational DBMS andA let that return you the device, did, and file ID that you want to D open. By resetting the user channel to the device (and the IRP also)> and intercepting close to put the user channel back, you get a? blindingly fast way to open a file, and have the files actually F accessed thru ONE directory, but with in fact valid file structures onH as many separate devices as you want...and need NOT touch the underlyingF file system to get it. In fact, the underlying name can even be storedD shorter if you want, and extra attributes might be able to be storedB in the database too...a structure needs to be around till close toC reset the user channel and it can have a little more stuff in it...   E I've implemented this kind of redirection ... it's blindingly fast... A and had it working by 1/1995 already on Vax or Alpha. (Yes, I can  let you have a demo.)   B On create, you pass the info to your daemon which creates the fileG on some device and fills in the DBMS; the intercept, on return, changes E the user open to open-existing-file and lets it get at the real file, B so all runs clean. I have code that tries to do this sort of thingC but uses a normal file system as the holder of the data btw, but it E lacks flexibility. However it uses a first-fill kind of scheme (which @ is good on jukeboxes and the like), not a use-emptiest-disk like- volume sets (which is terrible on jukeboxes).   H The advantages of this are that you get one directory...ONE directory...L structure for zillions of volumes, yet each volume is a valid file structureB and it's not too hard to add new disks to a master structure or toI remove them, and disks can be backed up and otherwise treated separately. @ (You'd have some, perhaps process level, control to allow directG underlying access without forcing access to use and maintain the common  directory.)   I Files in large directories get split across lots of underlying disks, and K maybe lots of underlying directories, so underlying directory perf. doesn't  get too bad.   But the REAL win is this:   B We currently have SET DEFAULT that sets a default path. Add to it.B Suppose you have SET DEFAULT "show me only files less than a monthF old", or one that says "show me files with keyword "payroll" attached"1 or "Show me files of size between X and Y" or ...   N The database can be used to hold, and efficiently store, lots more informationF about stuff stored on your disk than a filesystem would normally have.G Good databases scale well as they grow. And this would mean that a user C of OVMS would be able to access his files based on information that J was far more comprehensive than other OSs allow. Run an altavista searcherG and indexer periodically to get keywords out of the text maybe. Use the ? scheme for even files NOT on your system...and make it all look G transparent. (My stuff can inswap first easily enough, from wherever.).   H Use this to get at old data off tape or disk archives as if dealing with the current filesystem too.   G As you see it should scale exceedingly well, and represents a new twist  in OS technology.   D Then when people start wanting to access info on the net, say, or onG their own corporate databases, will they want to use some OS that gives E them remote filenames as if local, or will they want the OS that lets : them SET DEFAULT/keywordlist=(a,b,c,...)/domainlist=(...)-A /datemask=(start:date1,end:date2) ... etc. so their searches find 3 what they really want and make it local everywhere?   B BTW, when you stage a file locally, my scheme is to tag it so thatE if it's not actually used it can be cleaned up by a garbage collector  after a period of time.     G Steve Z. wanted me to talk to Drew about this & he wasn't in his office 8 so I figured I'd type it up so y'all can think about it.  D I think it'd be neat to see VMS do this sort of thing, a market win.    G OTOH, we don't want to delay long getting something going with a scheme 2 like this. Once someone else does it, game's over.   Glenn Everhart   Other notes:I 1. Let's keep this quiet if anyone will be interested in doing it. Get to 
 market first.   H 2. The notion of directory generalizes here. If the layer doing the dbmsG calls (the dbms must be ok in clusters!) "knows" some pseudodirectories D are really commands to add to any query it can strip them and returnG a DID flagged as perhaps an intermediate one. It would return directory E info possibly of the original files, use a few extra FID bits perhaps D to encode that this is an intermediate dir of a level of pseudodirs.C (I'd reuse some high seq # bits for this so's not to mess up RMS or F anything above, or better still reuse some RVN bits since you wouldn'tE use volume sets with this thing...it does all they do, better, pretty F much.) (A bit of support in mapvblk could span files across disks, butF initially I wouldn't do that...just keep them separate...and let usersC spec. how much free space must be guaranteed for a file if possible F on create to allow huge files to be created on pretty empty disks...doE this with a pseudodir too. Doing it would not be all that hard though A so long as it gets treated a lot like a window turn...send msg to @ acp interface, have the new piece accessed or created, pass back pointer info....)   E 3. The pseudo-dir scheme would allow (but not require) new queries to C maybe prune irrelevant trees at each level, but need not alter what B folks see till they list after the last part of a query mod, whichB some syntactic tag would flag. All this sugar gets stripped in the% intermediate layer betw. RMS and XQP.   E 4. A virtual device with its own FDT processing ahead of normal stuff  could be used.  @ 5. Underlying disks can have ODS-2 but still appear to have long! filenames, extra attributes, etc.   C 6. RDBMS to be used should be a somewhat generic interface.Supply a > small cheap dbms (or maybe just dir stuff in spiralog) but letC them hook in big expensive RDB if they have it. Or ingres or oracle  or sybase or whatever...  C 7. If you do queries in an rdbms, open might stall till you're done C with that. Has to happen now anyway, though, but you want to prefer - an rdbms that can have many threads active...   B 8. Backending arbitrary other storage systems is possible too with3 a little more pseudo-dir syntactic sugar thrown in.   C 9. Obviously RMS uses the read-dir primitives it needs for Spiralog A anyhow, and still needs to be able to pass longer names with more > characters in them. The intercept has to generate what readdirD would create. Also needs to be able to handle any ACP level requests5 for file attributes that cover new attributes needed.   A 10. The device must be everywhere on a cluster and must synch all A dbms access etc., though a user mode piece might do this; recall, @ we're basically dealing with open/close, not so much with r/w...? so delays are normal. I suggest queueing the server part with a ? mailbox queue or the like could be suitable...just wait & retry 8 if it hangs, or allow error return after too many tries.   ------------------------------    Date: 31 Oct 2003 13:32:52 -08001 From: byer@mail.ourservers.net (Robert Alan Byer) ! Subject: Re: SIMH: used with VMS? = Message-ID: <c4bfc78e.0310311332.184b5db2@posting.google.com>    > ; > Has anyone around here (successfully) used VMS with SIMH?   > http://simh.trailing-edge.com/ >   B As the maintainter of SIMH for OpenVMS I can say that the SIMH VAX4 emulator runs OpenVMS pretty well on a fast machine.  D In fact, just recently I ran SIMH VAX running OpenVMS, then compiled4 SIMH VAX on the SIMH VAX and ran OpenVMS under that.  F So I had SIMH VAX emulating SIMH VAX both running OpenVMS.  It was dog slow, but it worked.  E I haven't had time to test out any of the new ethernet emulation, but 6 I've heard from others in the SIMH list that it works.   ------------------------------  % Date: Fri, 31 Oct 2003 19:40:14 +0100 * From: Paul Sture <nospam@sture.homeip.net>9 Subject: Re: UK source of 800/1600 BPI SCSI reel to reel? 0 Message-ID: <3FA2BA9E.7264D84F@sture.homeip.net>   Nic Clews wrote: >  > Longshot time. > I > We're looking for what is detailed in the subject. Cipher is a possible # > make (the long flat autoloaders).  > E > 800 BPI is the real requirement, unfortunately due to the situation H > there is no way a bureau service could be used for data transfer etc.,D > the general idea is to hang the tape drive on the back of an Alpha > (PCI). > H > A less preferable alternative is to connect a tape drive to a HSC70 on > CI...  >  > Any ideas/leads? >   C Somewhat surprisingly, Google came up with several in response to a  search string of   +scsi +800 bpi +uk  A The first entry looks promising, with the web page having a "last  updated" display  of 21/01/03:  1 http://www.wpoint.co.uk/half_inch_tape_drives.htm        --  
 Paul Sture   ------------------------------    Date: 31 Oct 2003 10:57:02 -08003 From: robert_dirosario@yahoo.com (Robert DiRosario) 9 Subject: Re: UK source of 800/1600 BPI SCSI reel to reel? < Message-ID: <c83a2a1e.0310311057.b267917@posting.google.com>  Y Nic Clews <sendspamhere@[127.0.0.1]> wrote in message news:<bntv6g$8tg$1@lore.csc.com>...  > Longshot time. > I > We're looking for what is detailed in the subject. Cipher is a possible # > make (the long flat autoloaders).  > E > 800 BPI is the real requirement, unfortunately due to the situation H > there is no way a bureau service could be used for data transfer etc.,D > the general idea is to hang the tape drive on the back of an Alpha > (PCI). > H > A less preferable alternative is to connect a tape drive to a HSC70 on > CI...  >  > Any ideas/leads?   >  > TIA   L A quick google search on "scsi 9 track tape drive" returns a number of hits:  ! http://www.cpuinc.com/9track.html 0 http://www.sunstarco.com/9_track_tape_drives.htm1 http://www.electrovalueinc.com/9_track_drives.htm ! http://www.tapedrives-9track.com/   ) Including at least one company in the UK: 1 http://www.wpoint.co.uk/half_inch_tape_drives.htm    ------------------------------  % Date: Fri, 31 Oct 2003 22:58:56 +0000   From: nic <spamthis@[127.0.0.1]>9 Subject: Re: UK source of 800/1600 BPI SCSI reel to reel? 3 Message-ID: <bnupfc$23$1$8302bc10@news.demon.co.uk>    Bob Koehler wrote:V > In article <bntv6g$8tg$1@lore.csc.com>, Nic Clews <sendspamhere@[127.0.0.1]> writes: >  >>Longshot time.   > K >    If you have an HSC, you're in a cluster, or you'll get into one if you 
 >    have to?  > H >    There are SCSI tape drives which will do 800 and 1600 BPI (just didI >    a quick Google search).  There are also PCI-SCSI adapters.  Or maybe 7 >    you could cluster an older system with a SCSI bus.  > H >    I'd take a cluster solution first, if you don't have space or otherJ >    constraints.  If you go with a PCI-SCSI adapter do try to see if the J >    vendor has tried this configuration as even an 800 BPI tape can move  >    a lot of data in a hurry. > G >    In any case I would try to sell the customer on permanently moving F >    the data to another media even if they have to do it on site.  OrC >    if they have an older system still generating 800 BPI that's a  >    candidate for an upgrade.  C Well a little more background is perhaps in order. They are in the  G process of migrating to Alpha, it works better and faster. They have a  E cluster with CI, but they have a SAN and have the option to move the  I data into the SAN and off the CI, so it would be overkill to have the CI   just for the tape.  C 800 BPI is not their choice, its the way it is delivered. They use  I regular DLT for backup. I've had a few leads here, and by email, so I'll   check them out.    Thanks so far...   --- ( Regards, Nic Clews nclews at csc dot com   ------------------------------  % Date: Fri, 31 Oct 2003 19:11:12 +0100 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl> Subject: Re: used with VMS? : Message-ID: <bnu8og$160ppo$1@ID-143435.news.uni-berlin.de>  1 "Didier Morandi" <no@spam.com> schreef in bericht , news:3fa2619a$0$245$636a55ce@news.free.fr...; > Has anyone around here (successfully) used VMS with SIMH?   > http://simh.trailing-edge.com/ >  > Tx,  >  > D. > K Yes. Especially interesting on a Windows box. BTW it was possible to boot a G real VAX off a systemroot on the simh VAX system disk. Very impressive.    ------------------------------  % Date: Fri, 31 Oct 2003 19:53:40 +0100 * From: Paul Sture <nospam@sture.homeip.net>' Subject: Re: [Fwd: Re: World Wide Wake] 0 Message-ID: <3FA2BDC4.4AF25BDC@sture.homeip.net>   Greg Cagle wrote:  > 0 > FYI from our friends in the HP 3000 community. > $ > -------- Original Message -------- > Subject: Re: World Wide Wake? > Date: Fri, 31 Oct 2003 12:01:48 -0600 (Central Standard Time) . > From: John Burke <John_Burke@mindspring.com>! > Organization: e3000.org gateway  > Newsgroups: comp.sys.hp.mpe  >  > <snip> > J > I share Christian's sentiments. I will not be attending any of the WorldM > Wide Wakes because of family and professional obligations, but I will hoist L > one late this evening in honor of the HP 3000, MPE and IMAGE. I will hoistL > one in honor of the many good people who worked on and with the system forM > the last 30-some years. And, perhaps I will dream a little about what could  > have been. > L > Today is the end of an era and the beginning of another. Tomorrow we startM > to find out if HP's failure to follow through on its promise to port MPE to L > Itanium was an aberration or whether failure to follow through on promisesK > to customers when the promise does not suit it is S.O.P. at the "new" HP. J > Since 11/14/2001, HP has made a number of promises. It has also held offM > addressing a number of issues until after EOS. Frankly, I am not optimistic H > that even a majority of promises will be kept nor that any of the manyK > issues from firmware availability, to converting used HP9000s to HP3000s, K > and to support for a commercial emulator, will be addressed in a way that " > will satisfy the user community. > K > I will never forgive those people (virtually all of whom are no longer at J > HP) who by active neglect started the ball rolling downhill to the pointN > where Winston Prather, etc. believed that HP had to cancel the HP 3000 line. > K > We will probably never know the numbers and corporate politics that drove N > the decision. I do not blame Winston Prather for creating the situation; butL > I do, and will forever, blame him for the way it was communicated. For theJ > way HP executives boldly lied at HPWorld 2001 about the status of the HPK > 3000. For the way users and customers were cut out of any decisions about N > how and when the system would be phased out. For not having any kind of planM > developed for transitioning HP 3000 customers, ISVs and consultants to life K > after EOS. And, finally, for not allowing MPE/IMAGE to try to have a life 
 > outside HP.  > H > Here's hoping that character and integrity come back into style in the > corporate world, >  > John Burke > D > * To join/leave the list, search archives, change list settings, *D > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html * >   F And am article I found interesting (as someone who knows little of the 3000 or MPE) here:  : http://www.esj.com/enterprise/article.asp?EditorialsID=745   --- start quote ---   H "Migrating an MPE/iX application written in COBOL to HP-UX isntto invokeG a shopworn exampleas easy as dragging-and-dropping it from one platform G to another, even with free migration tools. For that reason, HP dangled H still another carrot to entice e3000 users to make the move: A four-foldD increase in performance. When MPE/iX is deployed on an A-class e3000C server, HP says, it exploits only 25 percent of the total processor ? capacityor 110-MHz for a 440-MHz PA-8700 processor. Performance F reduction rates vary across HPs A- and N-class lines of e3000 servers,D but amount to at least a 33 percent reduction on the largest N-class= system. Customers that made the move to HP-UX could run theireF applications at a much faster speed and also take advantage of I/O and( other performance enhancements, HP said.  G As it turns out, the company may have been understating its case. Early A tests indicated that the performance handicappingwhich some usersiG disparaged as cripplinghad a much greater effect on system performance.s@ As a result of doing MPE to HP-UX performance comparisons it hasD recently been determined that the 110MHz numbers appear to have beenH made up by HP marketing, and that these boxes actually only allow you toE use about 55MHz out of the 440MHz available, wrote one contributor to-D the HP e3000 mailing list last year. [S]o the good news is that yourB 110MHz A-class MPE system will actually become about *eight* times@ faster in CPU speed when turned into an uncrippled HP-UX system.   --- end quote ---i     -- o
 Paul Sture   ------------------------------   End of INFO-VAX 2003.605 ************************