1 INFO-VAX	Tue, 29 Mar 2005	Volume 2005 : Issue 175       Contents: Re: /include/nocopy  Re: /include/nocopy  Re: /include/nocopy & Re: CLD symbol table object on Itanium4 HEADS UP - HP OpenVMS Announcment from Rich Marcello8 Re: HEADS UP - HP OpenVMS Announcment from Rich Marcello8 Re: HEADS UP - HP OpenVMS Announcment from Rich Marcello8 Re: HEADS UP - HP OpenVMS Announcment from Rich Marcello OpenVMS 8.2 for a hobbyist# Re: Question on DCL f<dollar>string  Re: shadow minicopy  Re: VMS Torrents Re: VMS Torrents Re: VMS Torrents Re: VMS Torrents Re: VMS Torrents Re: VMS Torrents1 Re: [OpenVMS Alpha V8.2, ORACLE Classic] Status ?   F ----------------------------------------------------------------------  % Date: Mon, 28 Mar 2005 13:41:05 -0500  From: norm.raphael@metso.com Subject: Re: /include/nocopyQ Message-ID: <OFD7487D92.E2AC4AF2-ON85256FD2.006660B6-85256FD2.00670CD6@metso.com>   ? "AEF" <spamsink2001@yahoo.com> wrote on 03/28/2005 12:48:17 AM:    > Ken Fairfield wrote: > > Ken Fairfield wrote: > > ? > > I messed up the following paragraph a bit.  It should read:  > > H > > >    NOW COMES THE PROBLEM: B boots and mounts DSA0.  If it _allows_B > > > its local member to be copied into DSA0, the more up-to-date" > > > version will be overwritten.E > >                                   However, by using /NoCopy along B > > with specifying only A's member in the MOUNT command (assuming > > A comes before B),D > >                      it will (still) have mounted an out-of-dateD > > > DSA0 (as did A), but the up-to-date data on B's member will beC > > > preserved until the system manager can decide how to procede.  >  > F > Do you mean each node will have its own DSA0? If A's DSA0 is mountedA > clusterwide, doesn't that preclude B from mounting its own DSA0 H > clusterwide, in which case you have only one disk as a memeber of only > one DSA0?  > H > I think there is a guideline that shadow unit numbers should be uniqueI > clusterwide, and that helps keep you out of trouble. I'll have to check F > the manual, but it's getting late and I've spent enough time on this
 > already! >  > ? > >     As to some other comments, yes, the /NoCopy is the most = > > important item here.  Since /NoInclude is the default, in ? > > order to get all members mounted while specifying only one,  > > you need the /Include. > > E > >     AEF implies that /NoAssist with all members specified has the D > > same effect as specifying single member with /Include.  That may? > > well be the case, but I can't couch for it since I've never  > > tested it. >  > D > No, that is not what I meant. Assume a single standalone node with > H > $ MOUNT/SYS DSA0 /SHAD=(DKA100, DKA200, DKA300) /NOASSIST volume-label > I > in the startup. Start the system. You get a shadow set with three disks D > (assume its last state prior to the previous shutdown was one withE > three disks as members). Remove one disk and reboot the system. You = > should get a re-created shadow set with all three disks. My E > understanding is that if you had /INCLUDE instead of /NOASSIST then G > upon rebooting you would only have two disks in the re-created shadow E > set -- the two that were still in the shadow set after you manually B > removed one member -- regardless of which of the three disks areG > specified in the MOUNT/INCLUDE command. I'll have to test this when I ; > get a chance, but I cannot test what happens on clusters.  > C > I mentioned /NOASSIST because Phillip was worried about the MOUNT F > command failing if not all disks specified in the MOUNT command were5 > present. But that is exactly what /NOASSIST is for!  > 0 > So in summary, my understanding is as follows: > 3 > In your startup command procedure MOUNT commands:  > F > If you don't want to risk newer data being overwritten, add /NOCOPY. >   @ ISTM that a point is being obscured (Of course, I may just be as$ confused as others admit to being.).  D If you get the scenario described earlier where one node leaves, andH writing continues to a surviving shadowset member, then the node hostingE the surviving shadowset member leaves, and the node that left earlier H comes back first, then the volume on the 1st node is written to and data: the went to the volume on the 2nd node is lost, and eitherJ a)  without /NOCOPY the data disk on the 2nd node lost during the copy, orG b)  with /NOCOPY the data disk on the 2nd node is not lost, but is also G     not present on the new single-volume shadowset member and it is far K     from apparent what the lost data is or where it is or how to recover it C     or if any damage has been done due to it not being available in  context.  H So the point about knowing it what order what happened and what to do inH each case of things happening is a particular order to recover correctly& is more important than the qualifiers.  H > If you want the MOUNT command to succeed even if some of the specified  > disks are down, add /NOASSIST. > H > If you want the shadow set to have the same disks as members as it didE > when it was last dissolved, add /INCLUDE with as many as all of the I > disks specified (I still have to test this one as for what happens with 4 > different subsets of disks specified for /SHADOW). > A > As for clusters, I think this should all work okay, but I don't & > currently have the time to check it. >    ------------------------------  % Date: Mon, 28 Mar 2005 17:05:42 -0800 , From: Ken Fairfield <my.full.name@intel.com> Subject: Re: /include/nocopy+ Message-ID: <d2a9la$ioo$1@news01.intel.com>   
 AEF wrote: > Ken Fairfield wrote: >  >>Ken Fairfield wrote: >>= >>I messed up the following paragraph a bit.  It should read:  >> >>E >>>   NOW COMES THE PROBLEM: B boots and mounts DSA0.  If it _allows_ ? >>>its local member to be copied into DSA0, the more up-to-date  >>>version will be overwritten.  >>C >>                                  However, by using /NoCopy along @ >>with specifying only A's member in the MOUNT command (assuming >>A comes before B),B >>                     it will (still) have mounted an out-of-date >>A >>>DSA0 (as did A), but the up-to-date data on B's member will be @ >>>preserved until the system manager can decide how to procede. > F > Do you mean each node will have its own DSA0? If A's DSA0 is mountedA > clusterwide, doesn't that preclude B from mounting its own DSA0 H > clusterwide, in which case you have only one disk as a memeber of only > one DSA0?   ?      No, of course not.  I may not have Phillip's configuration A exactly right, but I thinking about, and I thought he was talking @ about, clusters where there shadows to systems' locally attachedA disks.  That is, DSA0=$1$DKA100,$1$DKB100 with $1$DKA100 attached A to node A and $1$DKB100 attached to node B.  In this case, except @ for a clean cluster shutdown and reboot, one or the other member? will always need to be copied back into DSA0.  Again, depending B on a bunch of external considerations, one needs to decide whether> that copy should be started automatically on system reboot, or; require a system manager to intervene and start the copy...   H > I think there is a guideline that shadow unit numbers should be uniqueI > clusterwide, and that helps keep you out of trouble. I'll have to check F > the manual, but it's getting late and I've spent enough time on this
 > already!  ;      Yes, you can't mount a given shadow set with different = members on different nodes.  I wasn't suggesting that.  MOUNT  won't let you do it.   [...] D > No, that is not what I meant. Assume a single standalone node with > H > $ MOUNT/SYS DSA0 /SHAD=(DKA100, DKA200, DKA300) /NOASSIST volume-label > I > in the startup. Start the system. You get a shadow set with three disks D > (assume its last state prior to the previous shutdown was one withE > three disks as members). Remove one disk and reboot the system. You ; > should get a re-created shadow set with all three disks.    D      Well, I'd argue with the details  of "re-created with all threeC disks".  If one member was dismounted prior to reboot, then it will B get added to the shadow set as a *copy target*, not a full-fledgedC member.  Once you've dismounted a member, as opposed to dismounting ? the "full" shadow set, it can only become a member again with a C COPY, either the full copy we're all used, or a mini-copy if you're A running a recent enough version of VMS, if you dismounted it with C the correct incantation, and if at least one node that has a bitmap & remains up between dismount and mount.  E                                                                    My E > understanding is that if you had /INCLUDE instead of /NOASSIST then G > upon rebooting you would only have two disks in the re-created shadow E > set -- the two that were still in the shadow set after you manually B > removed one member -- regardless of which of the three disks are) > specified in the MOUNT/INCLUDE command.   >       Assume as in your example, you have three members, named@ DKA100, DKA200 and DKA300, and assume you dismount DKA300 before@ system shutdown.  On reboot, if you mount DSA0 with /Include and= /Shadow=DKA100 or /Shadow=DKA200, then both DKA100 and DKA200 > get mounted into DSA0, but DKA300 does not.  If you mount DSA0B with /Include /Shadow=DKA300, _only_ DKA300 is mounted as a member= of DSA0.  Neither DKA100 nor DKA200 are mounted because their A shadow generation number (or whatever the precise term is) is not  the same as that on DKA300.   H                                            I'll have to test this when I; > get a chance, but I cannot test what happens on clusters.   =       This is shadowing behaviour, independent of clustering.    [...]        -Ken --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Tue, 29 Mar 2005 01:48:34 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: /include/nocopyB Message-ID: <1112078908.11f332871fc2e92fd83e34734d62fe9e@teranews>  
 AEF wrote:D > Well, again, it's the competing interests. If you can't tolerate A> > getting updated when B is the more up-to-date member, but isH > unavailable due to its node being down, you have to sacrifice the back > up ASAP.      H And if you get into a 2 node situation, you need to be aware that if theD non-quorum node goes down, you are without a valid backup should the remaining node go down.   G Solution is to eother have 3 nodes with 3 disks in a shadowset, or have F the 2 drives visible to both nodes, so that if one node goes down, the. drives are still accessible to the other node.   ------------------------------  # Date: Mon, 28 Mar 2005 21:47:59 GMT & From: John Reagan <john.reagan@hp.com>/ Subject: Re: CLD symbol table object on Itanium 2 Message-ID: <jY_1e.2383$fr6.2028@news.cpqcorp.net>   JF Mezei wrote:   L > Yes, but compared to re-using the existing tools that existed on VMS ????? > I > How can there be much shared code between alpha and IA64 when the whole G > image activator is comletely different ? Does this ELF thing cater to I > all of the VMS image format needs, shareable images tec, or did the VMS ? > group have to squeeze blood out of a rock to get it running ?   > Yes the image activator is completely different on IA64 along H ANAL/OBJECT and ANAL/IMAGE (actually, now the very same image), much of I the linker, huge parts of the symbolic debugger, parts of the librarian,  @ and a smidge scattered around the system (like booting, loading  execlets, etc)  I Rewriting the image activator from Macro-32 to C for I64 was viewed as a  H good thing.  Even if we kept to the same code base, we would have still # have to do a medium amount of work.   I We certainly have some VMS-specific things inside of the ELF objects and  D images, but the format was extensible enough.  No rocks were harmed F during the port to IA64.  While switching to ELF/DWARF and basing our G calling standard on the Intel runtime environment certainly added some  I work (and time) to the schedule.  However, we feel that we are in a much    better position to move forward.   --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------    Date: 28 Mar 2005 11:06:57 -0800! From: susan_skonetski@hotmail.com = Subject: HEADS UP - HP OpenVMS Announcment from Rich Marcello C Message-ID: <1112036816.983114.134990@f14g2000cwb.googlegroups.com>     -----Original Message-----  From: 	Skonetski, Susan $ Sent:	Monday, March 28, 2005 2:06 PM To:	Skonetski, Susan= Subject:	HEADS UP - HP OpenVMS Announcment from Rich Marcello       E I'm pleased to announce that effective April 4th, Ann McQuaid will be E the new General Manager of the OpenVMS Systems Division, reporting to @ me.  Ann will be responsible for worldwide engineering, customerE satisfaction, quality, and business management of the OpenVMS Systems C product portfolio.  She brings a wealth of experience to this role, F including leading the VMS engineering team in the port to HP IntegrityB servers, serving as Operations manager and Chief of Staff for VMS,B managing the VMS/Oracle relationship, and running the VMS business> management organization. Ann has an excellent track record for delivering on schedule.   C It is with mixed emotion that I also announce, effective April 4th, D that Mark Gorham has chosen to take some well deserved personal timeA off.  Mark has been doing two jobs since last August: running the ; OpenVMS Systems Division, and working on a project in Scott A Stallard's Enterprise Storage and Software organization. Mark has G made the decision to pursue new opportunities when he returns, but will @ continue to work for me on key areas affecting BCS growth in the interim.  D This change in no way affects the OpenVMS roadmap and its associatedE deliverables.  I have complete confidence in the OpenVMS organization B to continue its excellent track record of delivering on-time, high( quality releases under Ann's management.  F I want to personally thank Mark for his dedication to the organizationF and the company over the past four years, and in particular deliveringD OpenVMS v8.2 on Integrity servers.  I wish him nothing but the best.  
 Sincerely,  
 Rich Marcello ) Senior Vice President and General Manager  Business Critical Servers  Hewlett-Packard Company    ------------------------------  % Date: Mon, 28 Mar 2005 15:25:24 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> A Subject: Re: HEADS UP - HP OpenVMS Announcment from Rich Marcello B Message-ID: <1112041534.3a0468c4759a7671ad334727c042c3a6@teranews>  " susan_skonetski@hotmail.com wrote:G > I'm pleased to announce that effective April 4th, Ann McQuaid will be G > the new General Manager of the OpenVMS Systems Division, reporting to  > me.    Congratulation to Mrs McQuaid.    G Sue, do you know if she will peek into comp.os.vms from time to time ?  E It would be nice to get to know her. (And great to see that she'll be  reporting to you !)   ' > Ann has an excellent track record for  > delivering on schedule.   F Shouldn't that be more of a case of "She has an excellent track recordA for properly estimating delivery times when making promises" ????       F > that Mark Gorham has chosen to take some well deserved personal timeC > off.  Mark has been doing two jobs since last August: running the = > OpenVMS Systems Division, and working on a project in Scott ; > Stallard's Enterprise Storage and Software organization.    A Was there a 3rd job hidden in there ? Get Gorham to try to change  Stallard's mind about VMS ?     H > I want to personally thank Mark for his dedication to the organization+ > and the company over the past four years,   A Yep. It has been a very difficult 4 years due to upper management G decisions, and despite all knive attacks, VMS is still alive. A tribute  to everyone in the VMS group.    ------------------------------    Date: 28 Mar 2005 13:22:46 -0800* From: "Alan Greig" <greigaln@netscape.net>A Subject: Re: HEADS UP - HP OpenVMS Announcment from Rich Marcello C Message-ID: <1112044966.611955.134940@o13g2000cwo.googlegroups.com>    norm.raphael@metso.com wrote:    > /<exasperated mode on> > C > Announcement from Rich Marcello, to whom Ann McQuaid will report.  > 9 > (We need no added confusion...or is " !"  an emoticon?)  >  > /<exasperated mode off>  > [snip]   Sue's not the new HP CEO then? --  
 Alan Greig   ------------------------------  % Date: Mon, 28 Mar 2005 23:26:21 +0200  From: Dirk Munk <munk@home.nl>A Subject: Re: HEADS UP - HP OpenVMS Announcment from Rich Marcello 2 Message-ID: <d29spv$7a0$1@news3.zwoll1.ov.home.nl>  8 That sounds good to me, at least she knows what VMS is !  5 Let's all wish her success (and a marketing budget) .   B And let us all wish HP a new CEO who remembers the time that this H company was renowned for its top quality high tech products, instead of , overpriced ink catridges and rebadged Ipods.   > F >I'm pleased to announce that effective April 4th, Ann McQuaid will beF >the new General Manager of the OpenVMS Systems Division, reporting toA >me.  Ann will be responsible for worldwide engineering, customer F >satisfaction, quality, and business management of the OpenVMS SystemsD >product portfolio.  She brings a wealth of experience to this role,G >including leading the VMS engineering team in the port to HP Integrity C >servers, serving as Operations manager and Chief of Staff for VMS, C >managing the VMS/Oracle relationship, and running the VMS business ? >management organization. Ann has an excellent track record for  >delivering on schedule. >  >    >    ------------------------------  % Date: Mon, 28 Mar 2005 15:29:14 -0600 3 From: Dan Holm <danholm@googlesfreemailservice.com> # Subject: OpenVMS 8.2 for a hobbyist 9 Message-ID: <4248772b$0$3714$39cecf19@news.twtelecom.net>   H After reading through the discussion of whether or not it's a good idea I to offer VMS software through some sort of P2P distribution channel, and  C that a hobbyist can use whatever means available to him to acquire  B media, I wanted to try my luck at obtaining OpenVMS 8.2 for Alpha.  G I'm affected by the Radeon 7500 hang that a few others have mentioned,  H and I've become especially anxious about upgrading once I found out one 7 other poster's problems went away after installing 8.2.   F If someone has an image that they wouldn't mind sharing that would be B great, or I live in Houston if someone locally has physical media.  B I feel a little lame begging in a newsgroup for software, but I'm ) willing to try anything at this point. =)    Thanks,    --   Dan    danholm: domain gmail.com    ------------------------------  % Date: Mon, 28 Mar 2005 23:16:49 +0200  From: Dirk Munk <munk@home.nl>, Subject: Re: Question on DCL f<dollar>string2 Message-ID: <d29s85$6nu$1@news6.zwoll1.ov.home.nl>   norm.raphael@metso.com wrote:    >  >  >  > : >Dirk Munk <munk@home.nl> wrote on 03/28/2005 04:32:51 AM: >  >    >  >>norm.raphael@metso.com wrote:  >>     >> >[snip]  >    > 	 >>>and if 
 >>>$ last = 2  >>>$ last =  F$Fao("!AS",last)> >>>%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual >>>address=000000000003 ) >>>8248, PC=0000000000110001, PS=7FFABF90  >>>$ >>> E >>>which I know is feeding it an integer and telling it to display an 	 >>>        >>>  >ASCII >    > 	 >>>string  >>>but is an ACCVIO here a bug?  >>> 	 >>>        >>> C >>Depends how you look at it. Maybe they could give a nice error if  >>you feed theA >>argument with the wrong kind of data, but that would not change  >>anything to the " >>fact that the argument is wrong. >> >>     >>J >Noted, but professionally speaking, I do not consider it good practice toI >generate ACCVIO errors at this level.  That said, I subscribe completely > >to the notion that there are more valuable things to work on. >  >    > H This lexical (and maybe others as well) will return an access violation I in other situations as well I noticed. I suppose it would be possible to  I make checks for all of these situations, but that would make the lexical  G much more complicated and slower. Since DCL is often used as a kind of  G poor man's programming language (instead of writing a 'real program'),  I speed is quite essential. And again when you look at it as a programming  I language, then you will agree with me that it is not uncommon to write a  ? 'real' program that will generate access violations because of  H programming errors. With DCL you only have activate the verification to  find the error :-) .   ------------------------------  % Date: Mon, 28 Mar 2005 18:15:59 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: shadow minicopy( Message-ID: <opsodm8x0rzgicya@hyrrokkin>  L On Mon, 28 Mar 2005 17:41:22 -0800, Ken Fairfield <my.full.name@intel.com>   wrote:   > Tom Linden wrote: @ >>  Have three shadow sets in a cluster containing nodes runningB >> 7.3, 7.3-1, 7.3-2 and 8.2 on alpha and VAX.  Had to replace theB >> CD drives in one 7.3 AXP and one 7.3-1.  The shadow sets are on? >> a shared scsi bus with those two and yet a third 7.3-2 node. G >> The shadow sets are each 74GB.  A merge operation was thus initiated E >> One of the sets hosts hosts WASD, MX HGFTP and QUEUE Manager. This K >> one took 7 days to merge!  (the sets are in a BA356 so only 40MB/sec Tx) H >> the others completed in two days.  So I thought I would implement the >> minicopy. > E >      Before we go any further, you need to understand that minicopy A > is implemented by creating a bitmap in memory on your choice of 9 > cluster (or stand-alone) nodes.  When you do a DISMOUNT D > /POLICY=MINICOPY of a shadow member, bits in that map get set whenD > a write occurs while that shadow member is dismounted.  (A certainB > efficiency is gained by having each bit map to 127 disk blocks.)  H So does that mean that I have to dismount a member from all nodes in theE cluster with the /policy=minicopy=optional qualifier, then mount them D similarly, from each node, one at a time?  Does the bitmap reside on more than one node?  > B >      In order to do a subsequent MOUNT/POLICY=MINICOPY and allow@ > the dismounted member to be "reintegrated" into the shadow set@ > with a minicopy instead of a full copy, at least one node with@ > an active bitmap for that shadow set must still be up.  If you@ > shutdown (or reboot) all nodes that had a bitmap, you can't do@ > a mini-copy.  The bitmap is not "shared" between cluster nodes@ > (although it is synchronized), so you can't, say, do a rolling? > reboot of all cluster nodes and expect to have a valid bitmap  > to support the minicopy. > 6 >      Therefore when you suggest something like this: >  > [...]  >> and for dismount / >>  $       If f$getdvi(this_disk,"shdw_member)  >> $       then @ >> $               dismount/policy=minicopy=optional 'this_disk' >> $       else ' >> $               dismount 'this_disk'  >> $       endif > = > It really makes no sense (to me) in the context of a normal = > shutdown.  If you have a stand-alone system, you'll have no ? > bitmap to support the minicopy.  If you're in cluster, simply @ > dismounting the shadow set "cleanly" in the shutdown will takeA > care of mounting it cleanly on reboot.  If the disk is a shadow @ > member but is locally attached to the node shutting down (with= > other members supplying their own locally attached disks to < > the shadow set), I also think you're out of luck because I? > doubt another node can minicopy (or full copy) an MSCP-served  > shadow set member.G OK, now I am more confused.  I have three shadow sets (with two members F each) on a shared scsi bus which can have two to four nodes (dependingI on what I decide to boot) but lets say three.  Do I successively dismount H one member from each shadow set from each node (with minicopy) and the   mount # again with minicopy from each node?    >  >      -Ken    ------------------------------  % Date: Mon, 28 Mar 2005 14:30:45 -0500 # From: "John Smith" <a@nonymous.com>  Subject: Re: VMS Torrents , Message-ID: <-cCdndUZTMDzxtXfRVn-pA@igs.net>   Larry Kilgallen wrote:@ > In article <1112017368.99485.0@despina.uk.clara.net>, issinoho > <issinoho@gmail.com> writes: > G >> Just for the record, there seems to be a certain aloofness displayed D >> on this group by some towards us mere hobbyists - can't quite see; >> why, surely we're all here for the same reason. *shrugs*  > F > While we understand the value of the hobbyist program, the post thatG > started this thread contained no hint of a design that would preclude @ > non-hobbyists from using the site, and such use seems illegal. > F > One of the reasons VMS commercial licensing is rather easy to use is? > that no unofficial infrastructure has developed to thwart VMS  > licensing.      L With the current state of VMS affairs being what they are, HP probably wouldL be glad to be able to claim 412,000 installed systems.....even if 1,000 were pirates.   --F OpenVMS - The never advertised operating system with the dwindling ISV base.    ------------------------------   Date: 28 Mar 2005 20:08:18 GMT$ From: "Doc." <doc@openvms-rocks.com> Subject: Re: VMS Torrents 7 Message-ID: <Xns9627E18F45CB9dcovmsrox@212.100.160.126>   ! %NEWS-I-NEWMSG, issinoho wrote in - news:1112017368.99485.0@despina.uk.clara.net     <snip>  H > Other hobbyists out there - what say you? Should HP give us access to A > this service or do we pursue the p2p approach and share amongst 
 > ourselves?    H There's an informal person-2-person way of getting hold of kits, either J through LUGs, or even just posting here with information on your location G (and it not look like crackbegging ;).  I had the good fortune to have  H someone provide me with kits after asking here and getting in touch off- group.  F For the record, I would prefer to go the route of asking if Hobbyists " could have access to HP's service.  F > Just for the record, there seems to be a certain aloofness displayedH > on this group by some towards us mere hobbyists - can't quite see why,5 > surely we're all here for the same reason. *shrugs*   E I think there's quite a few people in the newsgroup appreciate there  C being people who take an interest in VMS even though it may not be  F relevant to their work.  There's quite a few could say that VMS is no # longer (as) relevant to their work.      Doc. --  G OpenVMS:     Eight out of ten hackers prefer *other* operating systems. G http://www.openvms-rocks.com    Deathrow Public-Access OpenVMS Cluster.    ------------------------------    Date: 28 Mar 2005 23:31:05 +0200( From: Andreas Davour <ante@update.uu.se> Subject: Re: VMS Torrents 4 Message-ID: <cs9ll87fofa.fsf@Psilocybe.Update.UU.SE>  % issinoho <issinoho@gmail.com> writes:   G > Let me put this another way... if I set up a tracker would (a) anyone A > out there be prepared to actively participate, and (b) find the  > service useful?  > E > Lets face it we could end up with a pretty extensive archive of DEC B > software - available for instant download - now wouldn't that be
 > attractive?   H It would be useful, and attractive. At least for me. But, I'd like it toG be sanctioned by the current owners of VMS so they don't percieve it as @ a threat to their property. Then they might pull the plug on the2 hobbyist licence which I don't want to see happen.   /andreas   --  A A: Because it fouls the order in which people normally read text. ' Q: Why is top-posting such a bad thing?  A: Top-posting. ; Q: What is the most annoying thing on usenet and in e-mail?    ------------------------------  % Date: Mon, 28 Mar 2005 22:31:53 +0100 # From: issinoho <issinoho@gmail.com>  Subject: Re: VMS Torrents 5 Message-ID: <1112045488.19268.0@despina.uk.clara.net>    Doc. wrote: # > %NEWS-I-NEWMSG, issinoho wrote in / > news:1112017368.99485.0@despina.uk.clara.net   >  > <snip> > H >>Other hobbyists out there - what say you? Should HP give us access to A >>this service or do we pursue the p2p approach and share amongst 
 >>ourselves?   >  > J > There's an informal person-2-person way of getting hold of kits, either L > through LUGs, or even just posting here with information on your location I > (and it not look like crackbegging ;).  I had the good fortune to have  J > someone provide me with kits after asking here and getting in touch off- > group. >   F I appreciate that, and I have used just such an approach in the past. H This isn't however just a way of me trying to scounge the latest set of H kits; it's more about the general way in which VMS becomes available to F those who want it. I can't help feeling that we conspire to make life A harder than it ought to be. I don't think I need to spell it out.   G I used to work for a company which was 100% a VMS house - I had access  E to hardware and software as I'm sure many of this group do. I do not  H work for them anymore and now rely on the sterling work of the hobbyist I fraternity. My goal is to simply try and push that availability a little   more.   H > For the record, I would prefer to go the route of asking if Hobbyists $ > could have access to HP's service. >  > F >>Just for the record, there seems to be a certain aloofness displayedH >>on this group by some towards us mere hobbyists - can't quite see why,5 >>surely we're all here for the same reason. *shrugs*  >  > G > I think there's quite a few people in the newsgroup appreciate there  E > being people who take an interest in VMS even though it may not be  H > relevant to their work.  There's quite a few could say that VMS is no % > longer (as) relevant to their work.  >  >  > Doc.   ------------------------------  % Date: Mon, 28 Mar 2005 23:34:47 +0200 , From: "Hans Vlems" <hvlems.dotweg@zonnet.nl> Subject: Re: VMS Torrents , Message-ID: <3arbplF6bvo0dU1@individual.net>  < "Larry Kilgallen" <Kilgallen@SpamCop.net> schreef in bericht- news:nNi+OH6tQh$Q@eisner.encompasserve.org... ; > In article <3aq6agF56ekd2U1@individual.net>, "Hans Vlems" ! <hvlems.dotweg@zonnet.nl> writes:  > > @ > > "Larry Kilgallen" <Kilgallen@SpamCop.net> schreef in bericht1 > > news:mfmA+IHuZLxM@eisner.encompasserve.org...  > J > >> Or do you know of some new HP pronouncement that commercial customers > >> are allowed to copy kits ?  > > J > > Most, if not all, commercial customers own more systems than kits. And those  > > kits get > > copied.  > F > I should have been more clear, indicating that my question was about= > the legality of kit copying _between_ commercial customers.   K Which is a valid point in its own right, but licenses are tied to a system.  A PAK is indeed not L a license so even if one is allowed to copy CD's for internal use you'd need a valid license toK run the product. A hobbyist PAK is valid for a year and in this case owning  (having been granted) 6 the PAK means that you're licensed to use the product.K In the commercial world there are many PAKs in use and I doubt that they're  all covered by aI legally valid license. Even so, a VMS V5.0 PAK will let you run VMS V7.3. K Unfortunately DEC never enforced the version attribute present in LMF, that  would have made things
 a lot easier.    ------------------------------   Date: 28 Mar 2005 21:39:40 GMT$ From: "Doc." <doc@openvms-rocks.com> Subject: Re: VMS Torrents 5 Message-ID: <Xns9627F11BCABdcovmsrox@212.100.160.126>   ! %NEWS-I-NEWMSG, issinoho wrote in - news:1112045488.19268.0@despina.uk.clara.net    
 > Doc. wrote:    <snip>  C >> There's an informal person-2-person way of getting hold of kits, E >> either through LUGs, or even just posting here with information on G >> your location (and it not look like crackbegging ;).  I had the good E >> fortune to have someone provide me with kits after asking here and  >> getting in touch off- group.   H > I appreciate that, and I have used just such an approach in the past. F > This isn't however just a way of me trying to scounge the latest set? > of kits; it's more about the general way in which VMS becomes G > available to those who want it. I can't help feeling that we conspire H > to make life harder than it ought to be. I don't think I need to spell
 > it out.   G I searched the infamous http://www.piratebay.org for VMS or OpenVMS, I  F like to think it says something positive about the Hobbyist community  that I got zero results.     Doc. --  G OpenVMS:     Eight out of ten hackers prefer *other* operating systems. G http://www.openvms-rocks.com    Deathrow Public-Access OpenVMS Cluster.i   ------------------------------    Date: 23 Mar 2005 12:32:21 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER): Subject: Re: [OpenVMS Alpha V8.2, ORACLE Classic] Status ?, Message-ID: <424161d5$1@NEWS.LANGSTOEGER.AT>  j In article <newscache$sheedi$2v31$1@news.sil.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:K >As I haven't seen ORACLE Classic (vs RDB) mentioned in the Mar2005 roadmap M >am I right in assuming that there is no ORACLE RDBMS support for V8.2, yet ?r  I I just got a note from HP which told me that the Roadmap was updated (for K the 2nd time in Mar05) to include ORACLE Classic Infos (pg. 27-28) as well.e
 Thanks folks.0  O Unfortunately, the download of the PPT got me the same old version I downloadeds8 few weeks ago. But PDF and HTML does give newer infos...  I >OTOH, I saw in ORACLE SOD that 9iR2 supports OpenVMS Alpha V8.2 now, and:O >10gR1 in Q2CY05. So, is V9.2.0.5 supported on V8.2 or is there a newer versiondC >(like the still missing V9.2.0.6 for OpenVMS Alpha) in the works ?N  G As I read it now, 9.2.0.5 does run on V8.2 and a 9.2.0.6 is coming RSN.o   -- b Peter "EPLAN" LANGSTOEGERt% Network and OpenVMS system specialistb E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   End of INFO-VAX 2005.175 ************************