INFO-VAX Mon, 26 May 2008 Volume 2008 : Issue 292 Contents: Re: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Re: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file RE: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Re: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file RE: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Re: DEC Document Re: EDS and LSE fibre channel tape drives accessed from multiple clusters Re: fibre channel tape drives accessed from multiple clusters Re: fibre channel tape drives accessed from multiple clusters Re: fibre channel tape drives accessed from multiple clusters Re: FTPand SSH security Re: Galaxy on ES45 Re: Galaxy on ES45 Re: Galaxy on ES45 Re: Galaxy on ES45 Re: Galaxy on ES45 Re: Galaxy on ES45 Re: Ip address blocking by country Re: VAX Media Re: VAX Media ---------------------------------------------------------------------- Date: Sun, 25 May 2008 16:59:45 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Message-ID: <4839d33d$0$90270$14726298@news.sunsite.dk> Jan-Erik Söderholm wrote: > B.t.w., the page says "(ZIP, 38 MB)" about the SDK, but I got > a 80 MB ZIP file after download... Mine is 80 MB too. Arne ------------------------------ Date: Sun, 25 May 2008 23:02:25 +0200 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne?= Subject: Re: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Message-ID: <4839d3e0$0$32745$426a74cc@news.free.fr> Richard Maher wrote: > Hi JF, > >> You have to specify Array.NUMERIC when you call the sortOn Array method. >> for example: myarray.sortOn('item', Array.NUMERIC); > > I think the problem Peter's experiencing is on the default Flex datagrid > column sort. (ie. Just clicking on the column header). I don't use the > gratuitous waste of bandwith that is XML myself and am not sure how one > would distinguish a numeric from a string (although if you look at the Adobe > Dashboard example for a while it can't be too hard to figure out as it (with > XML) certainly works there.) > [snip] The array is the one specified as the dataProvider of the datagrid. Just specified the flag and Flex do the job for you when you click on the column title. if you specified the sortOn method using Array.NUMERIC the array will be sorted (for this column) using a numeric sort instead of a string sort. My example use the AMF protocol which is native in Flex (according to the PyAMF site using AMF allow applications to load data up to 10 times faster than with text-based formats such as XML or SOAP.) JF ps. As promise a long time ago, I have set up a repository will full source of my example. I have,initially, planed to rewrite it using PureMVC but due to lack of time it's delayed, so I have decide to publish the code asis. I also expect to publish another example because 3 students are working on a T4 data browser using Flex. Send me email with a valid email and I will give you access (read only or read/write if you want to collaborate) to the repository. ------------------------------ Date: Mon, 26 May 2008 01:02:11 +0000 From: "Main, Kerry" Subject: RE: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Message-ID: > -----Original Message----- > From: Arne Vajh=F8j [mailto:arne@vajhoej.dk] > Sent: May 24, 2008 10:54 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file > > Peter Weaver wrote: > > I meant to mention in the original posting that one of the reasons I > worked > > on this was to once again demonstrate that VMS does not just mean VT > > terminals. Recently I was talking to a potential customer about > managing > > their system. When the request started going up the management chain > someone > > above said that the plan was to shutdown the VMS system because VMS > is text > > based and can not be used by a browser :(. > > VMS is an excellent web server platform. > > It is much worse if they ask to run the browser on VMS ... > > Arne Yeah, statements like "VMS is text based.." is like saying "Windows is DOS based ..". While both statements are correct, it is also true that both statements do not reflect today's reality. My standard response to naysayers questions about a shortage of Operations staff to manage OpenVMS environments is: "Do you meant to tell me that your Operations staff do not know how to use a standard mouse?" [Any OpenVMS environment today can be setup to be managed by first level Operations staff with a GUI Windows and/or Web based browser environment] Yes, Support Admins use command line interfaces, but that is also true for all other platforms as well. In fact, one of Windows 2008 selling features is a "much enhanced command line interface for enterprise operations" Hey - a good command line interface is considered a good thing these days. :-) Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sun, 25 May 2008 21:47:52 -0400 From: JF Mezei Subject: Re: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Message-ID: <483a1820$0$20592$c3e8da3@news.astraweb.com> Main, Kerry wrote: > Yeah, statements like "VMS is text based.." is like saying "Windows is > DOS based ..". > > While both statements are correct, it is also true that both statements > do not reflect today's reality. Considering that HP apologists go out of their way to justify why there is no further development of VMS gui applications, the "VMS is text based" is truer today than back in the early 1990s. ------------------------------ Date: Sun, 25 May 2008 21:55:25 -0400 From: "Peter Weaver" Subject: RE: Another Flex/VMS example - Browsing the ACCOUNTNG.DAT file Message-ID: <004301c8bed3$914e64f0$2802a8c0@CHARONLAP> >... > Yeah, statements like "VMS is text based.." is like saying "Windows is > DOS based ..". > > While both statements are correct, it is also true that both statements > do not reflect today's reality. >... You and I know that, we even know that VMS is not dead, but many, many people who have been running VMS for years do not know either of those points. I think I posted here before the story of a person who had 25 years of programming experience, most of that doing Fortran on VMS, who could not believe that my web pages were being served by VMS because the page had colour and graphics. Many people I deal with think VMS died back when Palmer told them to go to NT. Peter Weaver www.WeaverConsulting.ca www.OpenVMSvirtualization.com www.VAXvirtualization.com www.AlphaVirtualization.com ------------------------------ Date: Sun, 25 May 2008 17:34:06 -0700 (PDT) From: wayne.sewell@gmail.com Subject: Re: DEC Document Message-ID: On May 19, 5:03 pm, "Tom Linden" wrote: > On Mon, 19 May 2008 07:44:44 -0700, VAXman- <@SendSpamHere.ORG> wrote: > > I did some work for TTI. I'll fire off an email to Dan Esbensen if you'd > > like or I can forward his email to you. > > Please do. You might also suggest that maybe it would be a good idea if > they > don't want to or can't support Document that they release it as open source > like Matt did with MX > Matt isn't doing mx any more? I had noticed that the mailing list kinda went away. Where is the open source for mx kept? ------------------------------ Date: Sun, 25 May 2008 21:56:52 -0400 From: =?ISO-8859-15?Q?Arne_Vajh=F8j?= Subject: Re: EDS and LSE Message-ID: <483a18e0$0$90264$14726298@news.sunsite.dk> Tom Linden wrote: > On Fri, 16 May 2008 14:24:16 -0700, Marc Van Dyck > wrote: >> Bob Koehler brought next idea : >>> In article , Marc Van Dyck >>> writes: >>>> Well, I haven't used LSE very much lately, but last time I tried, >>>> if I remember well, it was still a pure monochrome editor. Adding >>>> colors to language sensitivity to match parenthesis, highlight syntaxes >>>> and structures, etc, would definitely be a plus. >>> >>> Colors are really handy when working with cryptic languages based on >>> C, where you never know what "}" means. >>> >>> Some of us actually prefer to work in languages that don't have that >>> problem. In such cases colors are not so helpfull. >> >> Well, it depends... I usually program in Pascal, and when you have >> a suite of heavily nested IF-THEN-ELSE statements, colors to mark >> the differents levels would be nice. Just one example... >> In anycase, if they annoy you you can always turn them off, but if they >> haven't been implemented, you can't turn them on ! > > emacs has the best language support. JEdit works on VMS. Not quite as powerful as Emacs, but a bit more mainstream. And I happen to like it. Even though on VMS I tend just to use EVE. A couple of months ago I think someone said that NEdit is also available for VMS. Arne ------------------------------ Date: Sun, 25 May 2008 13:29:06 -0700 (PDT) From: wayne.sewell@gmail.com Subject: fibre channel tape drives accessed from multiple clusters Message-ID: <82896594-7c6a-4a2e-b12a-7952e632787e@z24g2000prf.googlegroups.com> I'll have to admit that I haven't kept up with vms SAN management too much. There is no way I can afford the devices, switches, and PCI cards, and it really doesn't come up too often with tapesys, because a fibre channel tape drive looks pretty much like a hard-connected one. For the purpose of this discussion, I care nothing about fibre channel disks, but about fibre channel tape drives, especially in fibre channel jukeboxes, i.e. the juke robot is a fibre channel device too. As long as the devices are connected to only one cluster, I can basically ignore the SAN, as I mentioned earlier. Within the cluster, the device allocate takes care of all locking issues. And for the robot, the JB (Jukebox Manager) remote robot capability, together with the tapesys database, allows synchronized access even across clusters and standalone nodes, as long as all access is via tapesys/JB and nobody issues a MRU robot command directly. The problem is the tape drives. The lack of a SAN-wide locking mechanism results in crosstalk, with multiple nodes trying to access the same drives at the same time. My understanding is that most customers get around this problem by assigning specific drives to specific clusters, allowing the allocate command to work correctly. However, I currently have a customer who insists on all drives in all jukeboxes being available on all clusters. Now both JB and tapesys have central server processes that can serve an entire network, rather than just the cluster, so I could implement a lock function in one of those, and that would give me locking for the entire SAN. The problem is that it only controls tapesys/JB and nothing prevents some bozo from allocating a tape drive from the command line on a different cluster and manipulating it. Until the master lock is implemented, tapesys on another cluster can do it, which is the problem I am diagnosing now. I have always depended on the allocate system service, but in this situation it doesn't work. A node in one cluster allocates the drive then uses it for a backup. A node in another cluster allocates the same drive and also starts a backup. Both backups then get fatal drive errors and positioning errors and "volume not software enabled". I really consider this a failing of the SAN/fibrechannel protocol for not providing a locking mechanism, or of VMS for not using it if there is one. But in any case, the customer wants me to fix it. Before I go to the effort of adding my own inter-cluster tape drive lock mechanism, is there an easier way to do it, with just straight vms? ------------------------------ Date: Sun, 25 May 2008 14:08:06 -0700 (PDT) From: FrankS Subject: Re: fibre channel tape drives accessed from multiple clusters Message-ID: On May 25, 4:29=A0pm, wayne.sew...@gmail.com wrote: > I'll have to admit that I haven't kept up with vms SAN management too > much. =A0There is no way I can afford the devices, switches, and PCI > cards Then you haven't been paying very much attention to eBay. :-) > I really consider this a failing of the SAN/fibrechannel protocol for > not providing a locking mechanism, or of VMS for not using it if there > is one. =A0But in any case, the customer wants me to fix it. =A0Before I > go to the effort of adding my own inter-cluster tape drive lock > mechanism, is there an easier way to do it, with just straight vms? I won't try to point blame as long as you don't blame VMS. It's been no secret that concurrent access to any device from two or more systems doesn't work unless they are in a common cluster with a shared lock manager. Similarly, from what I know (and I don't claim it's very much) fibre has always required multiple hosts to communicate amongst themselves for sharing access to a single device (disk or tape). Maybe your client was misled about what "shared" fibre could accomplish. ------------------------------ Date: Sun, 25 May 2008 18:03:13 -0400 From: "William Webb" Subject: Re: fibre channel tape drives accessed from multiple clusters Message-ID: <8660a3a10805251503u41e94879pb286abbcdf97cf28@mail.gmail.com> On Sun, May 25, 2008 at 4:29 PM, wrote: > I'll have to admit that I haven't kept up with vms SAN management too > much. There is no way I can afford the devices, switches, and PCI > cards, and it really doesn't come up too often with tapesys, because a > fibre channel tape drive looks pretty much like a hard-connected one. > > For the purpose of this discussion, I care nothing about fibre channel > disks, but about fibre channel tape drives, especially in fibre > channel jukeboxes, i.e. the juke robot is a fibre channel device too. > > As long as the devices are connected to only one cluster, I can > basically ignore the SAN, as I mentioned earlier. Within the cluster, > the device allocate takes care of all locking issues. And for the > robot, the JB (Jukebox Manager) remote robot capability, together with > the tapesys database, allows synchronized access even across clusters > and standalone nodes, as long as all access is via tapesys/JB and > nobody issues a MRU robot command directly. > > The problem is the tape drives. The lack of a SAN-wide locking > mechanism results in crosstalk, with multiple nodes trying to access > the same drives at the same time. My understanding is that most > customers get around this problem by assigning specific drives to > specific clusters, allowing the allocate command to work correctly. > However, I currently have a customer who insists on all drives in all > jukeboxes being available on all clusters. > > Now both JB and tapesys have central server processes that can serve > an entire network, rather than just the cluster, so I could implement > a lock function in one of those, and that would give me locking for > the entire SAN. The problem is that it only controls tapesys/JB and > nothing prevents some bozo from allocating a tape drive from the > command line on a different cluster and manipulating it. Until the > master lock is implemented, tapesys on another cluster can do it, > which is the problem I am diagnosing now. I have always depended on > the allocate system service, but in this situation it doesn't work. > > A node in one cluster allocates the drive then uses it for a backup. > A node in another cluster allocates the same drive and also starts a > backup. Both backups then get fatal drive errors and positioning > errors and "volume not software enabled". > > I really consider this a failing of the SAN/fibrechannel protocol for > not providing a locking mechanism, or of VMS for not using it if there > is one. But in any case, the customer wants me to fix it. Before I > go to the effort of adding my own inter-cluster tape drive lock > mechanism, is there an easier way to do it, with just straight vms? > There used to be a device called a Modular Data Router that enabled you to make a SCSI-device SAN-aware. Don't know if HP still sells them, though. WWWebb ------------------------------ Date: Sun, 25 May 2008 15:09:20 -0700 (PDT) From: wayne.sewell@gmail.com Subject: Re: fibre channel tape drives accessed from multiple clusters Message-ID: <8dafe14f-9804-4ea4-8031-c122f1a5c189@i18g2000prn.googlegroups.com> On May 25, 5:03 pm, "William Webb" wrote: > On Sun, May 25, 2008 at 4:29 PM, wrote: > > I'll have to admit that I haven't kept up with vms SAN management too > > much. There is no way I can afford the devices, switches, and PCI > > cards, and it really doesn't come up too often with tapesys, because a > > fibre channel tape drive looks pretty much like a hard-connected one. > > > For the purpose of this discussion, I care nothing about fibre channel > > disks, but about fibre channel tape drives, especially in fibre > > channel jukeboxes, i.e. the juke robot is a fibre channel device too. > > > As long as the devices are connected to only one cluster, I can > > basically ignore the SAN, as I mentioned earlier. Within the cluster, > > the device allocate takes care of all locking issues. And for the > > robot, the JB (Jukebox Manager) remote robot capability, together with > > the tapesys database, allows synchronized access even across clusters > > and standalone nodes, as long as all access is via tapesys/JB and > > nobody issues a MRU robot command directly. > > > The problem is the tape drives. The lack of a SAN-wide locking > > mechanism results in crosstalk, with multiple nodes trying to access > > the same drives at the same time. My understanding is that most > > customers get around this problem by assigning specific drives to > > specific clusters, allowing the allocate command to work correctly. > > However, I currently have a customer who insists on all drives in all > > jukeboxes being available on all clusters. > > > Now both JB and tapesys have central server processes that can serve > > an entire network, rather than just the cluster, so I could implement > > a lock function in one of those, and that would give me locking for > > the entire SAN. The problem is that it only controls tapesys/JB and > > nothing prevents some bozo from allocating a tape drive from the > > command line on a different cluster and manipulating it. Until the > > master lock is implemented, tapesys on another cluster can do it, > > which is the problem I am diagnosing now. I have always depended on > > the allocate system service, but in this situation it doesn't work. > > > A node in one cluster allocates the drive then uses it for a backup. > > A node in another cluster allocates the same drive and also starts a > > backup. Both backups then get fatal drive errors and positioning > > errors and "volume not software enabled". > > > I really consider this a failing of the SAN/fibrechannel protocol for > > not providing a locking mechanism, or of VMS for not using it if there > > is one. But in any case, the customer wants me to fix it. Before I > > go to the effort of adding my own inter-cluster tape drive lock > > mechanism, is there an easier way to do it, with just straight vms? > > There used to be a device called a Modular Data Router that enabled > you to make a SCSI-device SAN-aware. > > Don't know if HP still sells them, though. > > WWWebb I am not trying to set up a san. I am trying to deal with a customer's existing san. ------------------------------ Date: Sun, 25 May 2008 18:18:38 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: FTPand SSH security Message-ID: <4839e5bc$0$90274$14726298@news.sunsite.dk> Bob Koehler wrote: > In article <_ZGdnZTxssXMZajVnZ2dnUVZ_qHinZ2d@posted.internode>, Gremlin writes: >> And, without wishing to start a war, it does the same about most OS - it >> is just a tool, it requires intelligent analysis, which is where COV >> comes in.... > > I take security fairly seriously. I cannot take a tool that lies to > me so much seriously. If you don't have a perfect tool, then you may need to use an imperfect tool. As long as there is an intelligent person post-processing the output, then it will not go completely wrong. That is not always the case for security evaluations. It is a business with both some very knowledgeable people and some 100% bullshitters. Arne ------------------------------ Date: Sun, 25 May 2008 15:38:22 -0400 From: JF Mezei Subject: Re: Galaxy on ES45 Message-ID: <4839c179$0$31173$c3e8da3@news.astraweb.com> Tom Linden wrote: > Is it possible? If not, why not (out of curiosity)? It is my uneducated guess that Galaxy requires certain facilities that were implented in the Wildwire class machines (followed by GS class machines). Remember that at the hardare level, those Wildifre machines allow you to boot multiple separate instances of an OS, each with their own memory and drives. Galaxy allows you to weds these separate VMS instances to allow them to share a lot, while remaining separate VMS instances. (not sure on the prenuptial crontract nor on divorce costs). A normal Alpha box doesn't have the special console firmware to boot multiple instances of a VMS machine and partition the memory and CPUs. You'll boot one VMS machine and then use VMS to allocate the CPUs etc to diffreent processes. ------------------------------ Date: Sun, 25 May 2008 17:01:12 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Galaxy on ES45 Message-ID: <4839d395$0$90270$14726298@news.sunsite.dk> JF Mezei wrote: > Tom Linden wrote: >> Is it possible? If not, why not (out of curiosity)? > > It is my uneducated guess that Galaxy requires certain facilities that > were implented in the Wildwire class machines (followed by GS class > machines). Some 4xxx/ES4x boxes do support Galaxy. I think Tom is asking why ES45 is different. Arne ------------------------------ Date: Sun, 25 May 2008 19:17:31 -0400 From: "Richard B. Gilbert" Subject: Re: Galaxy on ES45 Message-ID: Arne Vajhøj wrote: > JF Mezei wrote: >> Tom Linden wrote: >>> Is it possible? If not, why not (out of curiosity)? >> >> It is my uneducated guess that Galaxy requires certain facilities that >> were implented in the Wildwire class machines (followed by GS class >> machines). > > Some 4xxx/ES4x boxes do support Galaxy. > > I think Tom is asking why ES45 is different. > > Arne Perhaps because there wasn't much demand? Galaxy, IIRC, allowed you to run N instances of VMS on a Galaxy capable box with N CPUs. Or, you could devote two CPU's to the same O/S instance and run two instances on a four CPU box. You could cluster these instances. I never quite saw the point. From DEC/Compaq/HP's point of view, they sold a Galaxy license for each additional instance, and possibly a cluster license as well. Perhaps very few saw the point. ------------------------------ Date: Sun, 25 May 2008 20:14:13 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Galaxy on ES45 Message-ID: <483a00d1$0$90266$14726298@news.sunsite.dk> Richard B. Gilbert wrote: > Perhaps because there wasn't much demand? > > Galaxy, IIRC, allowed you to run N instances of VMS on a Galaxy capable > box with N CPUs. Or, you could devote two CPU's to the same O/S > instance and run two instances on a four CPU box. You could cluster > these instances. I never quite saw the point. > > From DEC/Compaq/HP's point of view, they sold a Galaxy license for each > additional instance, and possibly a cluster license as well. > > Perhaps very few saw the point. True. But considering how VMWare sell today, then maybe Galaxy could have sold better with the right marketing and pricing. Arne ------------------------------ Date: Sun, 25 May 2008 20:25:04 -0400 From: "Richard B. Gilbert" Subject: Re: Galaxy on ES45 Message-ID: Arne Vajhøj wrote: > Richard B. Gilbert wrote: >> Perhaps because there wasn't much demand? >> >> Galaxy, IIRC, allowed you to run N instances of VMS on a Galaxy >> capable box with N CPUs. Or, you could devote two CPU's to the same >> O/S instance and run two instances on a four CPU box. You could >> cluster these instances. I never quite saw the point. >> >> From DEC/Compaq/HP's point of view, they sold a Galaxy license for >> each additional instance, and possibly a cluster license as well. >> >> Perhaps very few saw the point. > > True. > > But considering how VMWare sell today, then maybe Galaxy > could have sold better with the right marketing and > pricing. With the "right marketing and pricing" Digital Equipment Corporation might still exist today! ------------------------------ Date: Sun, 25 May 2008 18:18:00 -0700 From: "Tom Linden" Subject: Re: Galaxy on ES45 Message-ID: On Sun, 25 May 2008 14:01:12 -0700, Arne Vajhøj wrote: > JF Mezei wrote: >> Tom Linden wrote: >>> Is it possible? If not, why not (out of curiosity)? >> It is my uneducated guess that Galaxy requires certain facilities that >> were implented in the Wildwire class machines (followed by GS class >> machines). > > Some 4xxx/ES4x boxes do support Galaxy. > > I think Tom is asking why ES45 is different. > > Arne Right. Colin's answer is likely the correct one. But is odd since the ES40 and ES47 support it but not the ES45. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sun, 25 May 2008 21:58:18 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Ip address blocking by country Message-ID: <483a1937$0$90264$14726298@news.sunsite.dk> glen herrmannsfeldt wrote: > JF Mezei wrote: >> It gets worse. At least one ISP in Australia is owned by a large telecom >> firm in the USA, and they are handing out USA IP addresses to their >> australian customers. (ozemail if I remember right). > > IP addresses don't belong to countries, but are allocated through > ISPs (usually). With multinational organizations and private > networks an IP range can easily cross countries or continents. > > A global ISP would allocate to many countries. True, but IP to country databases do exist. With a 95-99% reliability. Arne ------------------------------ Date: Sun, 25 May 2008 21:53:03 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: VAX Media Message-ID: <483a17fc$0$90264$14726298@news.sunsite.dk> JF Mezei wrote: > John Santos wrote: >> I think downloading from some cooperative fellow hobbyist is also >> okay, but I'm not certain of that. Putting up a copy of the kits >> on the Internet, publicly accessible, appears *not* to be okay, > > Making a kit available for someone to download does not imply that it > needs to be "publically accessible" on the internet. > > Since HP has abandonned new developpement of VAX, and since it no longer > sells new VAXen, making VAX kits publically available for download would > not hurt HP revenus in one bit. > > HP employees have often said that VAX customers are not interested in > upgrading. So if they haven't upgraded to 7.3 by now, they aren't going > to upgrade to 7.3 ever. Hence no loss of revenu at all. That VMS for VAX is not generating revenue for HP does not give anyone the right to distribute it to everyone. > Heck. HP could just seed some BitTorrent site with the VAX distribution. > Oh, I forgot, there is no Bittorrent client for VMS. I would expect the Java one's to run on VMS. Are you saying that they don't ? Arne ------------------------------ Date: Sun, 25 May 2008 21:59:26 -0400 From: JF Mezei Subject: Re: VAX Media Message-ID: <483a1a76$0$7280$c3e8da3@news.astraweb.com> Arne Vajhøj wrote: > That VMS for VAX is not generating revenue for HP does not give > anyone the right to distribute it to everyone. Distributing media is not the same as distributing VMS. And while we may not have the "right" to freely distribute VMS, the point is that it will not cause any financial harm to HP if it happens on a small scale between hobbysists since it does not deprive HP of any revenus. ------------------------------ End of INFO-VAX 2008.292 ************************