INFO-VAX Wed, 27 Feb 2008 Volume 2008 : Issue 115 Contents: Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: Buying disks for DS10s Re: Buying disks for DS10s Re: Buying disks for DS10s Re: Buying disks for DS10s Did I miss Infiniband clusters? Re: Did I miss Infiniband clusters? Re: Errors during shadow set merge Re: Eunice Re: Eunice (was: Wollogong TCP/IP stack) Re: Eunice (was: Wollogong TCP/IP stack) Re: Eunice (was: Wollogong TCP/IP stack) Re: Eunice (was: Wollogong TCP/IP stack) Re: Eunice (was: Wollogong TCP/IP stack) Re: Eunice (was: Wollogong TCP/IP stack) Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: newgroup decline Re: newgroup decline Re: newgroup decline Re: Strange $STATUS and messages UnZip 6.0d source kit is available. Re: Uses for a MicroServer-SP? ---------------------------------------------------------------------- Date: Tue, 26 Feb 2008 19:44:26 +0000 (UTC) From: Cydrome Leader Subject: Re: 6-core CPU on the horizon Message-ID: JKB wrote: > Le 26-02-2008, ? propos de > 6-core CPU on the horizon, > Neil Rieck ?crivait dans comp.os.vms : >> For anyone watching competing technologies, Intel has a 6-core CPU on >> the horizon. >> >> http://arstechnica.com/news.ars/post/20080226-details-slip-on-upcoming-intel-dunnington-six-core-processor.html > > Yes and ? My Sparc T1000 uses 8-cores CPU (and 4 threads by core) > for a long time... and each "thread" is about the speed of a 486. ------------------------------ Date: Tue, 26 Feb 2008 20:59:58 +0000 (UTC) From: JKB Subject: Re: 6-core CPU on the horizon Message-ID: Le 26-02-2008, à propos de Re: 6-core CPU on the horizon, Cydrome Leader écrivait dans comp.os.vms : > JKB wrote: >> Le 26-02-2008, ? propos de >> 6-core CPU on the horizon, >> Neil Rieck ?crivait dans comp.os.vms : >>> For anyone watching competing technologies, Intel has a 6-core CPU on >>> the horizon. >>> >>> http://arstechnica.com/news.ars/post/20080226-details-slip-on-upcoming-intel-dunnington-six-core-processor.html >> >> Yes and ? My Sparc T1000 uses 8-cores CPU (and 4 threads by core) >> for a long time... > > and each "thread" is about the speed of a 486. Nope. This server is a database server and runs faster than all x64 I have tried. JKB -- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. ------------------------------ Date: Tue, 26 Feb 2008 13:01:48 -0800 (PST) From: Neil Rieck Subject: Re: 6-core CPU on the horizon Message-ID: On Feb 26, 1:43=A0pm, JF Mezei wrote: > Neil Rieck wrote: > > For anyone watching competing technologies, Intel has a 6-core CPU on > > the horizon. > > Is this Moore's law that is coming to an end ? > > If increased capacity comes via more and more CPUs, it no longer makes > each CPU faster as was the case in the past. > I think Intel admitted as much when they turfed out NetBurst. If memory servces, P4-Prescott and Pentium-D 31-stage instruction pipelines (NetBurst) which was only good for running benchmarks but really bad for real world OS annoyances like interrupts. So with Core2 they dropped back to between 10-12 stages where AMD had been all along. Meanwhile, Intel also admitted that each processor improvement was an exponential effort for a linear return so it only made sense to do multiple cores. Now we all know that some Alpha engineers went to AMD while the majority ended up at Intel. So it is anyone surprised that we are seeing really cool chips come out right about now? Neil Rieck Waterloo, Ontario. ------------------------------ Date: Tue, 26 Feb 2008 21:03:57 +0000 (UTC) From: Cydrome Leader Subject: Re: 6-core CPU on the horizon Message-ID: JKB wrote: > Le 26-02-2008, ? propos de > Re: 6-core CPU on the horizon, > Cydrome Leader ?crivait dans comp.os.vms : >> JKB wrote: >>> Le 26-02-2008, ? propos de >>> 6-core CPU on the horizon, >>> Neil Rieck ?crivait dans comp.os.vms : >>>> For anyone watching competing technologies, Intel has a 6-core CPU on >>>> the horizon. >>>> >>>> http://arstechnica.com/news.ars/post/20080226-details-slip-on-upcoming-intel-dunnington-six-core-processor.html >>> >>> Yes and ? My Sparc T1000 uses 8-cores CPU (and 4 threads by core) >>> for a long time... >> >> and each "thread" is about the speed of a 486. > > Nope. This server is a database server and runs faster than all x64 > I have tried. > > JKB > Each thread is horribly slow, there's just lots of them. shut off 30 cores and see how that machine handles. ------------------------------ Date: Tue, 26 Feb 2008 21:16:50 +0000 (UTC) From: JKB Subject: Re: 6-core CPU on the horizon Message-ID: Le 26-02-2008, à propos de Re: 6-core CPU on the horizon, Cydrome Leader écrivait dans comp.os.vms : > JKB wrote: >> Le 26-02-2008, ? propos de >> Re: 6-core CPU on the horizon, >> Cydrome Leader ?crivait dans comp.os.vms : >>> JKB wrote: >>>> Le 26-02-2008, ? propos de >>>> 6-core CPU on the horizon, >>>> Neil Rieck ?crivait dans comp.os.vms : >>>>> For anyone watching competing technologies, Intel has a 6-core CPU on >>>>> the horizon. >>>>> >>>>> http://arstechnica.com/news.ars/post/20080226-details-slip-on-upcoming-intel-dunnington-six-core-processor.html >>>> >>>> Yes and ? My Sparc T1000 uses 8-cores CPU (and 4 threads by core) >>>> for a long time... >>> >>> and each "thread" is about the speed of a 486. >> >> Nope. This server is a database server and runs faster than all x64 >> I have tried. >> >> JKB >> > > Each thread is horribly slow, there's just lots of them. shut off 30 cores > and see how that machine handles. I have a lot of T1000 and I have done a lot of tests before buying this kind of material. I have made some tests to see degradation due to SMP architecture. This degradation is not important and when you know what you do with this material, you can achieve very good performances in parallel computation (or with multithreaded softwares). Each thread is not horribly slow as you say, and its performance is good even when load average is high. I think you haven't tried this material. JKB PS: [OT], thus for me, -- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. ------------------------------ Date: Tue, 26 Feb 2008 13:17:15 -0800 (PST) From: Neil Rieck Subject: Re: 6-core CPU on the horizon Message-ID: On Feb 26, 7:57=A0am, JKB wrote: [...snip...] > =A0 =A0 =A0 =A0 Yes and ? My Sparc T1000 uses 8-cores CPU (and 4 threads b= y core) > =A0 =A0 =A0 =A0 for a long time... > > =A0 =A0 =A0 =A0 JKB > That's a really nice system but how much did it cost? I just bought an HP-Pavilion with a quad-core (q6000) @ 2.4 GHz for $650 A full install of Microsoft Office only took a minute. http://www.tomshardware.com/cpu_2007.html Neil Rieck Waterloo, Ontario. ------------------------------ Date: Tue, 26 Feb 2008 22:05:33 -0000 From: "John Wallace" Subject: Re: 6-core CPU on the horizon Message-ID: <13s939u69h7ggac@corp.supernews.com> "JF Mezei" wrote in message news:47c45e32$0$30973$c3e8da3@news.astraweb.com... > Neil Rieck wrote: > > For anyone watching competing technologies, Intel has a 6-core CPU on > > the horizon. > > Is this Moore's law that is coming to an end ? > > If increased capacity comes via more and more CPUs, it no longer makes > each CPU faster as was the case in the past. > > > Seems to me that anything between now and when CSI becomes available is > just stop gap measures. Once CSI comes to the 8086, then the real future > will start to happen. Will HP start to build superdome-type systems > based on the 8086 ? > > Will Dell start to enter the real enterprise computing market by > building some large "mainframe" type servers ? > > And if so, how quickly. "Once CSI comes to the 8086, then the real future will start to happen. " So Intel have been telling us. Have HP said much on the subject so far? You might not expect to hear much about it from companies with no interest in Itanium... "Will HP start to build superdome-type systems based on the 8086 ? Will Dell start to enter the real enterprise computing market by building some large "mainframe" type servers ?" Don't know about those two questions as such, but Unisys tried "mainframe x86" a long time ago with their ES7000 family, which Compaq briefly rebadged (as the Proliant 9000?). Unisys still sell it: http://www.unisys.com/products/enterprise__servers/ and today it offers up to 32 processors (choice of Xeon or Itanium), as well as up to 512GB memory, as well as hardware partitioning and a reported 99.99% availability. Unfortunately for Unisys, it doesn't have a real enterprise-class OS to run, just Linux or Windows (and presumably lots of VMware instances). The hardware sounds interesting but an enterprise-class machine probably needs a more suitable operating system (and the things that go with it) than those two. Regards John ------------------------------ Date: Tue, 26 Feb 2008 18:29:49 -0500 From: JF Mezei Subject: Re: 6-core CPU on the horizon Message-ID: <47c4a117$0$31251$c3e8da3@news.astraweb.com> Neil Rieck wrote: > I just bought an HP-Pavilion with a quad-core (q6000) @ 2.4 GHz for > $650 Out of curiosity, does HP's wintel box offer anything that Dell or Lenovo or others don't have ? Do you feel comfortable buying from a company that is destroying VMS's chances ? > A full install of Microsoft Office only took a minute. Quick, someone call 911 to send paramedics to Mr VAXman's house, he's just had a heart attack after reading this :-) :-) :-) :-) ------------------------------ Date: Tue, 26 Feb 2008 20:18:25 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: 6-core CPU on the horizon Message-ID: <47c4ba59$0$90272$14726298@news.sunsite.dk> JF Mezei wrote: > Neil Rieck wrote: >> For anyone watching competing technologies, Intel has a 6-core CPU on >> the horizon. > > Is this Moore's law that is coming to an end ? No. But instead of increasing GHz they increase the number of cores. Arne ------------------------------ Date: Tue, 26 Feb 2008 21:07:22 -0700 From: "Michael D. Ober" Subject: Re: 6-core CPU on the horizon Message-ID: <13s9ofuiekji706@corp.supernews.com> "Arne Vajhøj" wrote in message news:47c4ba59$0$90272$14726298@news.sunsite.dk... > JF Mezei wrote: >> Neil Rieck wrote: >>> For anyone watching competing technologies, Intel has a 6-core CPU on >>> the horizon. >> >> Is this Moore's law that is coming to an end ? > > No. > > But instead of increasing GHz they increase the number of cores. > > Arne > Moore's "Law" was that the transistor count would double every 18 months or so. Not the clock speed. There are real issues of radio frequency interference when push clocks past the 3 to 3.5 GHz range. This is why newer processors keep the clock around 3 GHz and increase the number of cores. Mike. ------------------------------ Date: Tue, 26 Feb 2008 11:50:02 -0800 (PST) From: ultradwc@gmail.com Subject: Re: Buying disks for DS10s Message-ID: <66c0949f-d852-40d8-9beb-27e23883e2f1@k2g2000hse.googlegroups.com> On Feb 26, 1:47=A0pm, JF Mezei wrote: > tadamsmar wrote: > > We have DS10s with SCSI drives. > > > What is a good source for those drives? > > > Can you switch to IDE? > > DS10 and DS10L have support for IDE. YOu can put at least 2 IDE drives > in even a DS10L. > > SCSI is better performance though. > > Island Computers can probably sell yur some SCSI drives or point you to > some place that carries them. They are good folks who will ensure that > what you buy will fit into what you have. And they are loyal to the VMS > community. (*) > > (*) Disclaimer: I was so satisfied with the free DS10L I won from Island > that I bought another one from them. I thought he said he uses shadow sets and I thought volume shadowing was unsupported on vms with IDE disks ... are you saying that you can run IDE shadow sets? ------------------------------ Date: Tue, 26 Feb 2008 13:09:32 -0800 (PST) From: Rich Jordan Subject: Re: Buying disks for DS10s Message-ID: <61458adb-e66d-4166-899d-2d7528b7ce02@z17g2000hsg.googlegroups.com> On Feb 26, 1:50 pm, ultra...@gmail.com wrote: > On Feb 26, 1:47 pm, JF Mezei wrote: > > > > > tadamsmar wrote: > > > We have DS10s with SCSI drives. > > > > What is a good source for those drives? > > > > Can you switch to IDE? > > > DS10 and DS10L have support for IDE. YOu can put at least 2 IDE drives > > in even a DS10L. > > > SCSI is better performance though. > > > Island Computers can probably sell yur some SCSI drives or point you to > > some place that carries them. They are good folks who will ensure that > > what you buy will fit into what you have. And they are loyal to the VMS > > community. (*) > > > (*) Disclaimer: I was so satisfied with the free DS10L I won from Island > > that I bought another one from them. > > I thought he said he uses shadow sets and I thought > volume shadowing was unsupported on vms with IDE > disks ... > > are you saying that you can run IDE shadow sets? With the Acard SCSI-IDE bridges you can use IDE drives in shadow sets; I don't but I did test it a while ago (VMS V7.3-2 on a DS10-L). I don't know if you can use the straight IDE connected drives but it shouldn't be hard to look up. ------------------------------ Date: 26 Feb 2008 16:11:19 -0500 From: brooks@cuebid.zko.hp.nospam (Rob Brooks) Subject: Re: Buying disks for DS10s Message-ID: ultradwc@gmail.com writes: > I thought he said he uses shadow sets and I thought > volume shadowing was unsupported on vms with IDE > disks ... > > are you saying that you can run IDE shadow sets? Yes, you certainly can use HBVS with IDE drives, although it may not be supported. The issue is the (non)-support for the SCSI READL/WRITEL commands. Those are used when HBVS detects a questionable sector on a member and wants to "force the error" onto the other member(s) in the set. In the case of a device that doesn't support those SCSI commands, you'll see the NOFE bit set in the secondary device characteristics longword. In the case where shadowing can't "force the error", it'll simply drop the member with the suspect sector(s). -- Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com ------------------------------ Date: Tue, 26 Feb 2008 20:33:55 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Buying disks for DS10s Message-ID: <47c4bdfb$0$90274$14726298@news.sunsite.dk> tadamsmar wrote: > We have DS10s with SCSI drives. > > What is a good source for those drives? > > Can you switch to IDE? http://www.islandco.com/disks.html Arne ------------------------------ Date: Wed, 27 Feb 2008 06:41:06 +0800 From: "Richard Maher" Subject: Did I miss Infiniband clusters? Message-ID: Hi, IIRC there was talk a while back of HP working on Infiniband as a cluster interconnect; whatever happened to that? It's just that someone in the c.l.cobol conference posted a couple of IBM links and it jogged my memory. Maybe some kick-arse Orrible Oracle Cache-Fusion stats for VMS clusters would go someway to highlighting Rdb's unhealthy and misguided obsession with single-node configurations? HARDWARE: IBM System z10 Enterprise Class -- The forward-thinking mainframe for the twenty-first century http://www.ibm.com/vrm/newsletter_10577_2548_62970_email_DYN_1IN/WKlein12584487 OPERATING SYSTEM (preview) Preview: z/OS V1.10 -- Raising the bar and redefining scalability, performance, availability, and economics http://www.ibm.com/vrm/newsletter_10577_2548_63032_email_DYN_1IN/WKlein12584487 Cheers Richard Maher ------------------------------ Date: Tue, 26 Feb 2008 14:41:29 -0800 (PST) From: Rich Jordan Subject: Re: Did I miss Infiniband clusters? Message-ID: <6d1fa6d0-23b1-4e5c-9385-7cef9dbf35dc@f47g2000hsd.googlegroups.com> On Feb 26, 4:41 pm, "Richard Maher" wrote: > Hi, > > IIRC there was talk a while back of HP working on Infiniband as a cluster > interconnect; whatever happened to that? It's just that someone in the > c.l.cobol conference posted a couple of IBM links and it jogged my memory. > Maybe some kick-arse Orrible Oracle Cache-Fusion stats for VMS clusters > would go someway to highlighting Rdb's unhealthy and misguided obsession > with single-node configurations? > > HARDWARE: > IBM System z10 Enterprise Class -- The forward-thinking mainframe for the > twenty-first century > > http://www.ibm.com/vrm/newsletter_10577_2548_62970_email_DYN_1IN/WKle... > > OPERATING SYSTEM (preview) > Preview: z/OS V1.10 -- Raising the bar and redefining scalability, > performance, availability, and economics > > http://www.ibm.com/vrm/newsletter_10577_2548_63032_email_DYN_1IN/WKle... > > Cheers Richard Maher I think I remember a seminar some years ago down in the chi-pit here in ill annoy where Terry Shannon was present and infiniband and ZLE were discussed as up and coming. Never heard about it again though. ------------------------------ Date: Tue, 26 Feb 2008 11:45:10 -0800 (PST) From: tadamsmar Subject: Re: Errors during shadow set merge Message-ID: <88d1a249-b610-451e-8437-8a58fc9a0468@v3g2000hsc.googlegroups.com> On Feb 25, 3:32=A0pm, Pete wrote: > =A0You haven't offered much in the way of configuration around SCSI > devices. I guess I would start by verifing a valid config. IE: all > internal SCSI devices external or a mix. Where does termination happen > on the system and is it right are the devices models supported on the > same bus... It really sounds like a configuration/termination issue > may have led to some potential file system issues. > > Pete Thanks to all. I am getting 4 new disks under warranty for the two DS10s. These will either fix my hard error problem or point to something other than the disks. My swapping disk attempt was inconclusive. ------------------------------ Date: Tue, 26 Feb 2008 22:19:14 -0000 From: "John Wallace" Subject: Re: Eunice Message-ID: <13s94363o93qtb6@corp.supernews.com> "Bill Gunshannon" wrote in message news:62ikaaF23nhf1U2@mid.individual.net... > In article <47c34d44$0$8063$607ed4bc@cv.net>, > VAXman- @SendSpamHere.ORG writes: > > In article <47C2C324.7124.6DF980@infovax.stanq.com>, "Stanley F. Quayle" writes: > >>I have a client running the very-ancient Wollogong IP stack. While it works just fine, > >>they'd like to add DCPS for printing, but DCPS doesn't support that stack. > >> > >>I vaguely remember that Wollogong became TCPware. Is that correct? > > > > I would opin that that is INCORRECT. BTW, it's Wollongong. Wollongong, > > IIRC, became Attachmate. > > > > Speaking of Wollongong, I still have two tapes of Eunice for the VAX > (onre says bin the other says src. I wonder how much source is actually > there?) hanging in my tape locker. Anybody know what the status of Eunice > might be? Anybody around who might know? Eunices biggest shortcoming > was its speed (actually, its lack thereof!) and if it could be re-done > today it might not perform all that bad on an Alpha or even an Itanium > under VMS. Which then brings up the question, "Just how much of a real > Unix environment would it provide?" So many questions, so few answers!! > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > billg999@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include Set the wayback machine to 1985. A VAX 11/725 (power of a 730 in a smaller box, with 2 * 26MB disks, maybe 4MB memory?) with VMS V3.7 then V4, supporting three users. An IBM PC/XT with Venix (Unix V7-alike), again supporting three users. A nominally fast but somewhat unstable Convergent Technologies Unix/68K box (System V) with the same three users. And, on the 730, as well as VMS, Eunice (a BSD 4.1 derivative at that time). The office had three software developers working on a multiplatform project (hence the mixture). And what was the general favourite programming environment? VMS, because it was most productive. What was the least favourite? Eunice, because there were no circumstances in that setup where anything it offered was preferable to any other setup. Why anybody would be interested in Eunice today other than for historical reasons would be a mystery to me, but... regards John ------------------------------ Date: Tue, 26 Feb 2008 13:55:59 -0500 From: "Richard B. Gilbert" Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <47C460BF.2010302@comcast.net> Stanley F. Quayle wrote: > On 26 Feb 2008 at 16:05, Bill Gunshannon wrote: > >>I have not even looked at GNV for quite some time, but I don't remember it >>ever being a case of not knowing it wasn't Unix. > > > Back in 2003, I used GNV for user accounts to provide a "friendly" environment for *nix > users. If you prevent them from escaping to the VMS command line, it works pretty well. > > There are more and more things being ported from the open-source world to VMS by using > GNV. I just wish that we could the newest bash shell working there. A true "fork" > function would go a long way, too. > If you WANT Unix, why not just USE Unix????? ------------------------------ Date: 26 Feb 2008 18:58:10 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <62j5q2F23lvvgU1@mid.individual.net> In article <47C415B1.31098.5986F9D@infovax.stanq.com>, "Stanley F. Quayle" writes: > On 26 Feb 2008 at 16:05, Bill Gunshannon wrote: >> I have not even looked at GNV for quite some time, but I don't remember it >> ever being a case of not knowing it wasn't Unix. > > Back in 2003, I used GNV for user accounts to provide a "friendly" environment for *nix > users. If you prevent them from escaping to the VMS command line, it works pretty well. > > There are more and more things being ported from the open-source world to VMS by using > GNV. I just wish that we could the newest bash shell working there. A true "fork" > function would go a long way, too. > Does anyine remember if Eunice had fork()? And, once again as the original question seems to have gotten lost in the noise.... Does anyone know who is likely to be the holder of The Wollongong Group's IP? Is it at all likely that they could be asked to release Eunice to the OS world? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 26 Feb 2008 19:14:29 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <62j6olF23lvvgU3@mid.individual.net> In article <47C460BF.2010302@comcast.net>, "Richard B. Gilbert" writes: > Stanley F. Quayle wrote: >> On 26 Feb 2008 at 16:05, Bill Gunshannon wrote: >> >>>I have not even looked at GNV for quite some time, but I don't remember it >>>ever being a case of not knowing it wasn't Unix. >> >> >> Back in 2003, I used GNV for user accounts to provide a "friendly" environment for *nix >> users. If you prevent them from escaping to the VMS command line, it works pretty well. >> >> There are more and more things being ported from the open-source world to VMS by using >> GNV. I just wish that we could the newest bash shell working there. A true "fork" >> function would go a long way, too. >> > > If you WANT Unix, why not just USE Unix????? I do. I have plenty of Unix systems to work with. But, finding a way to run Unix software on VMS is a subject that comes up here frequently. Eunice went away primarily because the performance was abysmal. This was true of lots of things that have now become common because the tech- nology has caught upt and surpassed the problem. (ie. P-machines offered good performance but far enough behind native that they were abandoned. Today we have the Java Virtual Machine which is, in effect, just a P-machine.) If Eunice offers a way to port Unix software to VMS with acceptable performance, why not give it a second look and even update it to take advantage of all the stuff we have learned in the meantime. Hmmmm...... Unix with true clustering? :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 26 Feb 2008 15:00:37 -0500 From: "Richard B. Gilbert" Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <47C46FE5.6040407@comcast.net> Bill Gunshannon wrote: > In article <47C460BF.2010302@comcast.net>, > "Richard B. Gilbert" writes: > >>Stanley F. Quayle wrote: >> >>>On 26 Feb 2008 at 16:05, Bill Gunshannon wrote: >>> >>> >>>>I have not even looked at GNV for quite some time, but I don't remember it >>>>ever being a case of not knowing it wasn't Unix. >>> >>> >>>Back in 2003, I used GNV for user accounts to provide a "friendly" environment for *nix >>>users. If you prevent them from escaping to the VMS command line, it works pretty well. >>> >>>There are more and more things being ported from the open-source world to VMS by using >>>GNV. I just wish that we could the newest bash shell working there. A true "fork" >>>function would go a long way, too. >>> >> >>If you WANT Unix, why not just USE Unix????? > > > I do. I have plenty of Unix systems to work with. But, finding a way > to run Unix software on VMS is a subject that comes up here frequently. > Eunice went away primarily because the performance was abysmal. This > was true of lots of things that have now become common because the tech- > nology has caught upt and surpassed the problem. (ie. P-machines offered > good performance but far enough behind native that they were abandoned. > Today we have the Java Virtual Machine which is, in effect, just a > P-machine.) If Eunice offers a way to port Unix software to VMS with > acceptable performance, why not give it a second look and even update > it to take advantage of all the stuff we have learned in the meantime. > Hmmmm...... Unix with true clustering? :-) > > bill > > A lot of Unix software will run on VMS without too much trouble. "Hello World" will build and run on just about anything! Some depends on Unixisms like "fork" and "exec" and those can be a little more troublesome. A lot of other Unix software was written in "K&R" C and needs a bit of work before it will even compile without error. Do you have something in particular that you want to run on VMS? Are you prepared to pay to have it beaten into submission? ------------------------------ Date: Tue, 26 Feb 2008 15:58:03 -0500 From: "Stanley F. Quayle" Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <47C4370B.25200.61AB911@infovax.stanq.com> On 26 Feb 2008 at 13:55, Richard B. Gilbert wrote: > If you WANT Unix, why not just USE Unix????? It's not a question of wanting Unix -- it's a question of all those useful open-source pieces (Firefox, Apache, Samba, etc.) being able to compile natively on VMS. We need these things on VMS to be "relevant" [ie, saleable] in today's world. As for the system I set up using GNV, it was a way to get the Unix guys on VMS quickly. And there be no need for a learning curve if vi/emacs and some other tools were available. We purists, of course, would use the more-powerful DCL environment... fork -- there are like 16 requirements for fork to work like it does in *nix. Right now, VMS can do something like 5 of them. No problem, if you only need those 5. But most *nix programmers don't restrict themselves to VMS's 5, even if they could. Why would they? HP's not supporting the port of OpenOffice to VMS [darn!], but there's an "issuelist" of things that need to be in VMS to make it work. Check out http://www.oooovms.dyndns.org/ for the details... --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: 26 Feb 2008 21:06:41 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <62jdb0F236gmbU1@mid.individual.net> In article <47C46FE5.6040407@comcast.net>, "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> In article <47C460BF.2010302@comcast.net>, >> "Richard B. Gilbert" writes: >> >>>Stanley F. Quayle wrote: >>> >>>>On 26 Feb 2008 at 16:05, Bill Gunshannon wrote: >>>> >>>> >>>>>I have not even looked at GNV for quite some time, but I don't remember it >>>>>ever being a case of not knowing it wasn't Unix. >>>> >>>> >>>>Back in 2003, I used GNV for user accounts to provide a "friendly" environment for *nix >>>>users. If you prevent them from escaping to the VMS command line, it works pretty well. >>>> >>>>There are more and more things being ported from the open-source world to VMS by using >>>>GNV. I just wish that we could the newest bash shell working there. A true "fork" >>>>function would go a long way, too. >>>> >>> >>>If you WANT Unix, why not just USE Unix????? >> >> >> I do. I have plenty of Unix systems to work with. But, finding a way >> to run Unix software on VMS is a subject that comes up here frequently. >> Eunice went away primarily because the performance was abysmal. This >> was true of lots of things that have now become common because the tech- >> nology has caught upt and surpassed the problem. (ie. P-machines offered >> good performance but far enough behind native that they were abandoned. >> Today we have the Java Virtual Machine which is, in effect, just a >> P-machine.) If Eunice offers a way to port Unix software to VMS with >> acceptable performance, why not give it a second look and even update >> it to take advantage of all the stuff we have learned in the meantime. >> Hmmmm...... Unix with true clustering? :-) >> >> bill >> >> > > A lot of Unix software will run on VMS without too much trouble. "Hello > World" will build and run on just about anything! Some depends on > Unixisms like "fork" and "exec" and those can be a little more troublesome. > > A lot of other Unix software was written in "K&R" C and needs a bit of > work before it will even compile without error. > > Do you have something in particular that you want to run on VMS? Are > you prepared to pay to have it beaten into submission? It wasn't me. Others here are always clamouring for things like OpenOffice and other desktop type tools that Unix and VMS doesn't. The talk about Wolongong merely made me think of Eunice and I wondered what the chances were that it might make running some of these programs more possible, As I stated originally, there were a lot of projects that were abandoned and in many cases completely lost that probably have more utility today than they did when they were actively being developed. Just one example to consider. There used to be a project called The Software Tools Virtual Operating System. It wasn't an OS at all, it was a good job of creating a standard API (unix like) that ran on over 50 differnt systems, including VMS. Work on this stopped back in the mid to later 80's. Just think if it had been continued. We might never have had any of these discussions because we would now have a common, standard API that people were writting all these programs to. My interests are merely academic as with the exception of running hobbyist systems I expect my VMS days are all but over. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 26 Feb 2008 19:03:20 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Message-ID: <62j63oF23lvvgU2@mid.individual.net> In article , Tad Winters writes: > "tomarsin2015@comcast.net" wrote in > news:e44756bb-7ce5-4f7c-9805-25a4d04a6081@q33g2000hsh.googlegroups.com: > >> Hello >> Does anybody know how the ERASE option compares to the DOD standard? >> Does the /ERASE option meet the DOD standard?? IF the /erase option >> doesnot is there a DOD format program for VMS?? >> tks >> phil >> > > I can't exactly answer that, but let me say that a perticular piece of > software, dban, claims to offer disk erasure that meets DOD standards and > offers another erasure method that makes far more passes. I looked up > the quoted DOD standard, and it provided no details on erasing, merely > that it had to completely overwrite the data to be considered erasure. > There was no real meat to it. If you have DOD data that must be erased to their requirements, be very careful. Just because a program claims it meets that requirement doesn't make it so. When we had to wipe all the laptops we used in Germany when I was over there last year I asked about using GDISK as I had used that in my civilian job and it has an option /DODWIPE. I was quickly informed that GDISK was not considered acceptable regardless of their claims. I think other than meeting the requirement it must also be certified by someone like DISA. That would make it rather hard to do in the case of VMS. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 26 Feb 2008 13:33:16 -0600 From: Michael Austin Subject: Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Message-ID: Bill Gunshannon wrote: > In article , > Tad Winters writes: >> "tomarsin2015@comcast.net" wrote in >> news:e44756bb-7ce5-4f7c-9805-25a4d04a6081@q33g2000hsh.googlegroups.com: >> >>> Hello >>> Does anybody know how the ERASE option compares to the DOD standard? >>> Does the /ERASE option meet the DOD standard?? IF the /erase option >>> doesnot is there a DOD format program for VMS?? >>> tks >>> phil >>> >> I can't exactly answer that, but let me say that a perticular piece of >> software, dban, claims to offer disk erasure that meets DOD standards and >> offers another erasure method that makes far more passes. I looked up >> the quoted DOD standard, and it provided no details on erasing, merely >> that it had to completely overwrite the data to be considered erasure. >> There was no real meat to it. > > If you have DOD data that must be erased to their requirements, be very > careful. Just because a program claims it meets that requirement doesn't > make it so. When we had to wipe all the laptops we used in Germany when > I was over there last year I asked about using GDISK as I had used that > in my civilian job and it has an option /DODWIPE. I was quickly informed > that GDISK was not considered acceptable regardless of their claims. I > think other than meeting the requirement it must also be certified by > someone like DISA. That would make it rather hard to do in the case of > VMS. > > bill > At one time, VMS was considered C2 compliant "out of the box" and IIRC, to be compliant it had to provide a Disk eraser and the only one "out of the box" is /erase. Although I do know of sites that no matter how many times you formatted/reformatted/overwrote/erased the entire volume - the only option was to physically destroy the media by shredding it to billions of tiny little pieces. They had to purchase the HDA (head disk assembly) even though the devices were "under contract". One such environment required that NO electronic gear of any type ever "escaped" without being shredded once it was brought in - spare parts for VAX 6000/8000 for example. And the guards were armed at this particular civilian company. ------------------------------ Date: 26 Feb 2008 14:11:30 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Message-ID: In article , "tomarsin2015@comcast.net" writes: > Does anybody know how the ERASE option compares to the DOD standard? Interpretation of any DoD standards is up to your DAA. > Does the /ERASE option meet the DOD standard?? VMS provides a callout for site-specific erasure pattern code. You can tailor support to meet interpretations of your DAA, up to the point where the requirements from your DAA are "slag it", in which case you do not need to write any code. But for the code situation, certainly a better solution is for your DAA to specify a source of the callout code that is acceptable. ------------------------------ Date: 26 Feb 2008 21:11:07 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Message-ID: <62jdjaF236gmbU2@mid.individual.net> In article , Michael Austin writes: > Bill Gunshannon wrote: >> In article , >> Tad Winters writes: >>> "tomarsin2015@comcast.net" wrote in >>> news:e44756bb-7ce5-4f7c-9805-25a4d04a6081@q33g2000hsh.googlegroups.com: >>> >>>> Hello >>>> Does anybody know how the ERASE option compares to the DOD standard? >>>> Does the /ERASE option meet the DOD standard?? IF the /erase option >>>> doesnot is there a DOD format program for VMS?? >>>> tks >>>> phil >>>> >>> I can't exactly answer that, but let me say that a perticular piece of >>> software, dban, claims to offer disk erasure that meets DOD standards and >>> offers another erasure method that makes far more passes. I looked up >>> the quoted DOD standard, and it provided no details on erasing, merely >>> that it had to completely overwrite the data to be considered erasure. >>> There was no real meat to it. >> >> If you have DOD data that must be erased to their requirements, be very >> careful. Just because a program claims it meets that requirement doesn't >> make it so. When we had to wipe all the laptops we used in Germany when >> I was over there last year I asked about using GDISK as I had used that >> in my civilian job and it has an option /DODWIPE. I was quickly informed >> that GDISK was not considered acceptable regardless of their claims. I >> think other than meeting the requirement it must also be certified by >> someone like DISA. That would make it rather hard to do in the case of >> VMS. >> >> bill >> > > > At one time, VMS was considered C2 compliant "out of the box" and IIRC, > to be compliant it had to provide a Disk eraser and the only one "out of > the box" is /erase. Yeah, but how long ago was that? Requirements change. Orange Book (actually the whole rainbow) is gone. Too bad VMS never went after Common Criteria. > > Although I do know of sites that no matter how many times you > formatted/reformatted/overwrote/erased the entire volume - the only > option was to physically destroy the media by shredding it to billions > of tiny little pieces. They had to purchase the HDA (head disk assembly) > even though the devices were "under contract". One such environment > required that NO electronic gear of any type ever "escaped" without > being shredded once it was brought in - spare parts for VAX 6000/8000 > for example. And the guards were armed at this particular civilian company. I never said there weren't stricter requirements, only that claiming to meet DOD requirements is not the same as actually being so certified. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 26 Feb 2008 21:13:42 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: INIT/ERASE & DELETE/ERASE vs DOD erase/format standard Message-ID: <62jdo6F236gmbU3@mid.individual.net> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article , "tomarsin2015@comcast.net" writes: > >> Does anybody know how the ERASE option compares to the DOD standard? > > Interpretation of any DoD standards is up to your DAA. > >> Does the /ERASE option meet the DOD standard?? > > VMS provides a callout for site-specific erasure pattern code. > You can tailor support to meet interpretations of your DAA, > up to the point where the requirements from your DAA are > "slag it", in which case you do not need to write any code. > > But for the code situation, certainly a better solution is for > your DAA to specify a source of the callout code that is acceptable. The DAA doesn't get to just make it up themselves. I suppose if it's a SCSI or an IDE disk you could always move it to a PC and run an approved product there. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 26 Feb 2008 13:57:38 -0500 From: JF Mezei Subject: Long term archiving of VMS stuff Message-ID: <47c4616b$0$10255$c3e8da3@news.astraweb.com> I have some very old savesets of applications that ran a long time ago in a office far far away. (as well as some not so old ones). Since BACKUP save sets are essentially proprietary to VMS, one can't move those savesets to a platform that will outlive VMS and expect to ever be able to unpack those savesets in the future. So, I am looking at some philosophical recommendations on how to repackage those savesets for long term survival on any platform. I can think of tar/gz, or just plain old zip ? Any recommendation on which of those I should use, and whether there might be other formats I could choose ? ------------------------------ Date: Tue, 26 Feb 2008 13:09:53 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Long term archiving of VMS stuff Message-ID: <08022613095291_20667E7B@antinode.org> From: JF Mezei > I have some very old savesets of applications that ran a long time ago > in a office far far away. (as well as some not so old ones). Are these "applications" programs? > Since BACKUP save sets are essentially proprietary to VMS, one can't > move those savesets to a platform that will outlive VMS and expect to > ever be able to unpack those savesets in the future. If your "applications" are programs, how much use will they be on a non-VMS system? > So, I am looking at some philosophical recommendations on how to > repackage those savesets for long term survival on any platform. I'm looking for a rationale for this task. Actual requirements might be even more helpful. > I can think of tar/gz, or just plain old zip ? Is that a question. > Any recommendation on which of those I should use, It depends. > and whether there > might be other formats I could choose ? Yes. I'm sure that there are. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 26 Feb 2008 14:42:02 -0500 From: JF Mezei Subject: Re: Long term archiving of VMS stuff Message-ID: <47c46bd2$0$10301$c3e8da3@news.astraweb.com> Steven M. Schweda wrote: > Are these "applications" programs? Yep. Programs, source code, some data files etc. For instance, I have some COBOL programs I wrote a century ago. Should I ever need to program in COBOL again, those would be good starting point for the structure, examples etc etc, so being able to unpack those "application" would be good on whatever platform I might be at that time. (right now I am moving to Mac, but I know that stuffit is fairly proprietary to the MAC culture, so I would want a more generic packaging of files that would work 10 years from now on any platform). ------------------------------ Date: Tue, 26 Feb 2008 14:44:52 -0500 From: "Richard B. Gilbert" Subject: Re: Long term archiving of VMS stuff Message-ID: <47C46C34.8060604@comcast.net> JF Mezei wrote: > I have some very old savesets of applications that ran a long time ago > in a office far far away. (as well as some not so old ones). > > Since BACKUP save sets are essentially proprietary to VMS, one can't > move those savesets to a platform that will outlive VMS and expect to > ever be able to unpack those savesets in the future. > > So, I am looking at some philosophical recommendations on how to > repackage those savesets for long term survival on any platform. > > I can think of tar/gz, or just plain old zip ? > > Any recommendation on which of those I should use, and whether there > might be other formats I could choose ? Once upon a time, ca. 1980, I suggested to the students who used my computer system that fixed length, 80 character, records could be read by just about any computer system. I further suggested that the records could be blocked with a blocking factor of ten to fifty with only a small risk that the resulting records could not be read on some systems. How many of you can still read a nine track 1600BPI tape? Fifteen or twenty years ago, there was an archiving format known as ARC which has since been superceded by ZIP. Can anybody read ARC today? Where will ZIP be fifteen or twenty years from now? Will there be a readable copy remaining? Will there still be any old machines and operating systems that can run it? I think your philosophy should be "keep it simple" and "use a medium and format that will still be readable by surviving hardware and software". Also ask yourself, how long will these applications be of any interest to anyone? In twenty years will anyone remember the languages they were written in, how to use them, or what they were used for? ------------------------------ Date: Tue, 26 Feb 2008 14:13:38 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Long term archiving of VMS stuff Message-ID: <08022614133824_20667E7B@antinode.org> From: JF Mezei > > Are these "applications" programs? > Yep. Programs, source code, some data files etc. I'm willing to believe that "source code" involves text files. What are "data files"? > For instance, I have > some COBOL programs I wrote a century ago. Should I ever need to program > in COBOL again, those would be good starting point for the structure, > examples etc etc, so being able to unpack those "application" would be > good on whatever platform I might be at that time. Text files are relatively portable using almost any archiving program. > (right now I am > moving to Mac, but I know that stuffit is fairly proprietary to the MAC > culture, so I would want a more generic packaging of files that would > work 10 years from now on any platform). I'd tend to trust that the Info-ZIP programs will be available on a Mac (and every other useful system) long after I stop caring. For example: smacg4# zip30f/zip -v Copyright (c) 1990-2007 Info-ZIP - Type 'zip "-L"' for software license. This is Zip 3.0f BETA (September 18th 2007), by Info-ZIP. Currently maintained by E. Gordon. Please send bug reports to the authors using the web page at www.info-zip.org; see README for details. Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip, as of above date; see http://www.info-zip.org/ for other sites. Compiled with gcc 4.0.0 (Apple Computer, Inc. build 5026) for Unix (Mac OS X) on Oct 11 2007. Zip special compilation options: USE_EF_UT_TIME (store Universal Time) BZIP2_SUPPORT (bzip2 library version 1.0.2, 30-Dec-2001) bzip2 code and library copyright (c) Julian R Seward (See the bzip2 license for terms of use) LARGE_FILE_SUPPORT (can read and write large files on file system) ZIP64_SUPPORT (use Zip64 to store large files in archives) [...] ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 26 Feb 2008 21:29:55 GMT From: "Robert Jarratt" Subject: Re: Long term archiving of VMS stuff Message-ID: "JF Mezei" wrote in message news:47c4616b$0$10255$c3e8da3@news.astraweb.com... >I have some very old savesets of applications that ran a long time ago > in a office far far away. (as well as some not so old ones). > > Since BACKUP save sets are essentially proprietary to VMS, one can't > move those savesets to a platform that will outlive VMS and expect to > ever be able to unpack those savesets in the future. > > So, I am looking at some philosophical recommendations on how to > repackage those savesets for long term survival on any platform. > > I can think of tar/gz, or just plain old zip ? > > Any recommendation on which of those I should use, and whether there > might be other formats I could choose ? How about a SIMH virtual disk? Then you can always run VMS on some other platform and see your files as they were meant to be seen. That said it would also be nice to get a spec for the saveset format so that portable program could be written to extract the saveset on any future platform. Is there such a spec anywhere. Of course it would be possible to reverse engineer the spec, but that takes more time. I tried this with the TOPS-20 DUMPER format a while ago but had to give up for lack of time. ------------------------------ Date: Tue, 26 Feb 2008 22:49:53 +0100 From: Michael Kraemer Subject: Re: Long term archiving of VMS stuff Message-ID: JF Mezei schrieb: > I have some very old savesets of applications that ran a long time ago > in a office far far away. (as well as some not so old ones). > > Since BACKUP save sets are essentially proprietary to VMS, one can't > move those savesets to a platform that will outlive VMS and expect to > ever be able to unpack those savesets in the future. > > So, I am looking at some philosophical recommendations on how to > repackage those savesets for long term survival on any platform. > > I can think of tar/gz, or just plain old zip ? > > Any recommendation on which of those I should use, and whether there > might be other formats I could choose ? If you already have built those savesets, why not look for a tool to unpack VMS savesets on just about every platform ? ------------------------------ Date: Tue, 26 Feb 2008 22:15:54 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Long term archiving of VMS stuff Message-ID: In article <47c4616b$0$10255$c3e8da3@news.astraweb.com>, JF Mezei writes: > I have some very old savesets of applications that ran a long time ago > in a office far far away. (as well as some not so old ones). > > Since BACKUP save sets are essentially proprietary to VMS, one can't > move those savesets to a platform that will outlive VMS and expect to > ever be able to unpack those savesets in the future. > > So, I am looking at some philosophical recommendations on how to > repackage those savesets for long term survival on any platform. > > I can think of tar/gz, or just plain old zip ? > > Any recommendation on which of those I should use, and whether there > might be other formats I could choose ? Let me rephrase the question: plain old tar/gz, or the much better zip program, which offers many more features and has been improved quite a bit recently? With zip, you can pull individual files out of a compressed archive. With tar/gz, you have to decompress the whole archive first (same deal with a compressed save set). Zip will handle VMS attributes, and newer versions have essentially no size limits. I've been using the beta versions of zip and unzip with large-file support and I think they are pretty close to the next official releases. Contact SMS for more details. Bottom line: forget tar/gz and use zip: better and it much better meets your goal of platform independence. ------------------------------ Date: Tue, 26 Feb 2008 22:25:56 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Long term archiving of VMS stuff Message-ID: JF Mezei wrote: > For instance, I have > some COBOL programs I wrote a century ago. Should I ever need to program > in COBOL again, those would be good starting point for the structure, > examples etc etc,... Printouts on quality paper and properly stored would last *at least* 200 years, probably more then double that. :-) Jan-Erik. ------------------------------ Date: Tue, 26 Feb 2008 22:38:05 GMT From: Tad Winters Subject: Re: Long term archiving of VMS stuff Message-ID: Jan-Erik Söderholm wrote in news:Ul0xj.4220$R_4.3034@newsb.telia.net: > JF Mezei wrote: > >> For instance, I have >> some COBOL programs I wrote a century ago. Should I ever need to >> program in COBOL again, those would be good starting point for the >> structure, examples etc etc,... > > Printouts on quality paper and properly stored would > last *at least* 200 years, probably more then double that. > >:-) > > Jan-Erik. > I was just thinking about that. Scanning technology will no doubt keep improving. It would be probably end up beeing easiest to just scan the papers, OCR and compile. :-^) ------------------------------ Date: Tue, 26 Feb 2008 18:55:03 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Long term archiving of VMS stuff Message-ID: <47c4a6cf$0$90267$14726298@news.sunsite.dk> JF Mezei wrote: > I have some very old savesets of applications that ran a long time ago > in a office far far away. (as well as some not so old ones). > > Since BACKUP save sets are essentially proprietary to VMS, one can't > move those savesets to a platform that will outlive VMS and expect to > ever be able to unpack those savesets in the future. > > So, I am looking at some philosophical recommendations on how to > repackage those savesets for long term survival on any platform. > > I can think of tar/gz, or just plain old zip ? > > Any recommendation on which of those I should use, and whether there > might be other formats I could choose ? Stuff that does not make any sense outside VMS (VMS EXE, index sequential files etc.): backup save set. Pure test stuff: best: text files with CRLF delimter second best: zip Arne ------------------------------ Date: Tue, 26 Feb 2008 19:02:41 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Long term archiving of VMS stuff Message-ID: <47c4a89a$0$90272$14726298@news.sunsite.dk> Richard B. Gilbert wrote: > Fifteen or twenty years ago, there was an archiving format known as ARC > which has since been superceded by ZIP. Can anybody read ARC today? > Where will ZIP be fifteen or twenty years from now? Will there be a > readable copy remaining? Will there still be any old machines and > operating systems that can run it? ZIP can be read in 20 years. The compression algorithm (not not the file format) has been standardized. The file format is widely available. ZIP is a requirement for Java. ZIP is used in both ODF and OOXML. ZIP can be read in 20 years. I will not guarantee for 50 years. Arne ------------------------------ Date: 26 Feb 2008 20:33:40 -0500 From: Rich Alderson Subject: Re: Long term archiving of VMS stuff Message-ID: JF Mezei writes: ... > Since BACKUP save sets are essentially proprietary to VMS, one can't > move those savesets to a platform that will outlive VMS and expect to > ever be able to unpack those savesets in the future. ... > Any recommendation on which of those I should use, and whether there > might be other formats I could choose ? Let me second the recommendation of SimH virtual disk and virtual tape images. If need be, package a copy of the SimH souces with them. Use a ZIP or StuffIt! program to compress them for space savings, if you like. NB: StuffIt! provides tar, zip, and other archive formats as well as its own proprietary ones. -- Rich Alderson "You get what anybody gets. You get a lifetime." news@alderson.users.panix.com --Death, of the Endless ------------------------------ Date: Tue, 26 Feb 2008 22:08:09 -0500 From: "Stanley F. Quayle" Subject: Re: Long term archiving of VMS stuff Message-ID: <47C48DC9.12501.76D8C05@infovax.stanq.com> On 26 Feb 2008 at 20:33, Rich Alderson wrote: > Let me second the recommendation of SimH virtual disk and virtual tape images. The virtual disk files are completely compatible with LD on VMS and CHARON-VAX/CHARON- AXP, too. The SIMH virtual tapes are slightly different than the virtual tapes created by CHARON- VAX (byte ordering or some such). SRI created a small utility to convert images SIMH- >CHARON. So SIMH tape images would be good, if bootable "tapes" are necessary. --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: Tue, 26 Feb 2008 11:33:22 -0800 (PST) From: tadamsmar Subject: Re: newgroup decline Message-ID: <5409c8c8-62a0-40ab-bf17-5e8414e1eedd@z17g2000hsg.googlegroups.com> On Feb 26, 11:20=A0am, AEF wrote: > On Feb 26, 11:12 am, "Main, Kerry" wrote: > > > > > > > > -----Original Message----- > > > From: tadamsmar [mailto:tadams...@yahoo.com] > > > Sent: February 26, 2008 9:22 AM > > > To: Info-...@Mvb.Saic.Com > > > Subject: newgroup decline > > > > Looks like the peak year for posts was 2002. =A0 Declining since then.= > > > Not sure if this is a valid measurement as 2002 posts were likely 50% re= lated to Alpha cancellation and all of the stuff associated with that. > > > 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. > > Not only that, did you account for off-topic threads? One or two > really long ones could skew the data. > > AEF- Hide quoted text - > > - Show quoted text - All good points. All I did was eyeball the data here: http://groups.google.com/group/comp.os.vms/about ------------------------------ Date: Tue, 26 Feb 2008 14:44:53 -0500 From: "Ken Robinson" Subject: Re: newgroup decline Message-ID: <7dd80f60802261144q5faead63r804d4a0f72352774@mail.gmail.com> On Tue, Feb 26, 2008 at 2:33 PM, tadamsmar wrote: > All good points. All I did was eyeball the data here: > > http://groups.google.com/group/comp.os.vms/about > If anyone cares, I created an Excel chart from those numbers. You can see a PDF version here Ken ------------------------------ Date: Tue, 26 Feb 2008 17:50:05 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: newgroup decline Message-ID: <47c49795$0$90269$14726298@news.sunsite.dk> Ken Robinson wrote: > On Tue, Feb 26, 2008 at 2:33 PM, tadamsmar wrote: >> All good points. All I did was eyeball the data here: >> >> http://groups.google.com/group/comp.os.vms/about > > If anyone cares, I created an Excel chart from those numbers. You can > see a PDF version here I think the situation is much worse than the numbers indicate. The number of off topic posts has been huge in the last 5-6 years. I am pretty sure that the "content" topped in the mid 90's. Arne ------------------------------ Date: Tue, 26 Feb 2008 22:08:44 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Strange $STATUS and messages Message-ID: In article , Hein RMS van den Heuvel writes: > On Feb 23, 8:17=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- > remove CLOTHES to reply) wrote: > > $ set proc/name=3Djwefjwefiowjeiofjweiofjwefijwj > > %SET-E-NOTSET, error modifying process name > > -SYSTEM-F-IVLOGNAM, invalid logical name > > $ x=3D$status > > $ sh sym x > > =A0 X =3D "%X1077808A" > > $ write sys$output f$message(x) > > %SET-E-NOMSG, Message number 1077808A > > > > Why does f$message show something different than the messages above? > > Because the message comes from a dedicated message file which the > program had open but the process now does not. In this specific case > the file is CLIUTLMSG I suspected something similar, but not in a bread-and-butter DCL command. > $ set mess sys$message:CLIUTLMSG.EXE > $ write sys$output f$message(x) > %SET-E-NOTSET, error modifying !AS > > So even if you knew that, then message is not very usefull as it needs > additional params. Can one somehow have multiple message files active? > The 'somewhat' high bit in the status tells the system NOT to try to > output an error message > 1) because it already has bee processed > 2) DCL would not have all data needed to do a proper job. > > $ X =3D "%X1077808A" > $ exit 'x > $ X =3D "%X0077808A" > $ exit 'x > %SET-E-NOTSET, error modifying !AS Two points. One: Why expand the symbol? (Peeve: if you expanded, use a trailing apostrophe!) Two: Can you turn off the quoted-printable encoding? ------------------------------ Date: Tue, 26 Feb 2008 14:52:38 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: UnZip 6.0d source kit is available. Message-ID: <08022614523880_20667E7B@antinode.org> A source kit for UnZip 6.0d (pre-release, "BETA") should be available at the usual places: ftp://ftp.info-zip.org/pub/infozip/beta/unzip60d.zip http://downloads.sourceforge.net/infozip/unzip60d.zip It should be pretty close to the real UnZip 6.0, particularly on VMS. This kit should cure the long-standing spurious "76 bytes" warning messages (6.0c), and should solve all known problems, while adding support for large files, ODS5 extended file specs, bzip2 compression, symbolic links, and a typical set of bug fixes. Problems which are reported promptly may get fixed in the real release. Zip 3.0g (also pre-release, "BETA") source kits should be available nearby. Complaints are always welcome. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 26 Feb 2008 23:55:47 GMT From: Antonio Carlini Subject: Re: Uses for a MicroServer-SP? Message-ID: "Bob Blum" wrote in news:SaBwj.20$Ee6.16@newsfe05.lga: > I've supported the DEMSA as a DECnet-to-SNA gateway. If I recall, > there are two models, a four-port unit and a single-port one. Both > use the MOP protocol to boot from a load host on the local LAN. I > think they can be used for connecting between either SNA (IBM > mainframe) or X.25 networks, depending on the load image and/or > configuration file settings. All correct. All the code was based on LES (as was DECnis). There was also a ChannelServer product (which I didn't see much of). That was basically a MicroVAX 3 in a BA213 (or similar) chassis and with channel cards so it could go talk to those big IBM mainframes. > The DEC networking products were bought up (by Cabletron, I think) Yes > then later split off into their own company, Digital Network Products > Group. I tried going to their web site ( www.dnpg.com, NOT > www.digitalnetworks.com ) but got the following message: > "As of January 1, 2008, Digital Networks now operates under the name > Vnetek Communications, LLC. The merger between Vnetek Communications > and Digital Networks brings together Vnetek's world class sales and > distribution with Digital Networks top quality networking products > which includes the world renowned DECserver product line. For product > information and online ordering please visit www.vnetek.com". The terminal servers and DEChub stuff went that way (iirc). DECnis support stayed with Riverstone for a while and then vanished when Riverstone vanished. The last backup tapes for MARVIN (the DECnis/DEMSA build cluster) were cut at Riverstone as MARVIN was decommissioned. AFAIK, no copy ever went anywhere else, and certainly the only engineers who knew how DECnis and DEMSA worked were at Riverstone (if they hadn't found an exit path elsewhere by then). > Trying to go there and search for DEMSA or SNA Gateway didn't come up > with anything. I did a quick Google search for DEMSA SNA X.25 and > found many links, here's one you might be interested in, it mentions > manuals on the hardware: > http://classiccmp.org/pipermail/cctech/2006-February/057563.html . > There's always eBay, of course! I tried searching for DEMSA, and > found people selling them for anywhere from $90 to $650. "Selling" or "trying to sell" :-) > Good luck with it, whatever you decide to do. Well if the OP wants to write code for a uVAX-II with a limited view of the world, the maintenance manuals are on the web and I can probably help with "how do I MOP load it" and maybe even "how can I drive the LED". Otherwise it makes an adequate DECnet router (don't push it too hard ..!) or X.25 Gateway. Antonio ------------------------------ End of INFO-VAX 2008.115 ************************