INFO-VAX Tue, 08 Jan 2008 Volume 2008 : Issue 16 Contents: Re: Anyone interested in building a vms-like OS? Re: Anyone interested in building a vms-like OS? Re: Anyone interested in building a vms-like OS? Re: Anyone interested in building a vms-like OS? Re: Anyone interested in building a vms-like OS? Re: Anyone interested in building a vms-like OS? Re: Anyone interested in building a vms-like OS? Re: Anyone interested in building a vms-like OS? Baltimore Social Media Optimization Re: Building libxml2 on OpenVMS/VAX Re: Carl J. Lydick Re: dial up modem Re: dial up modem Re: gnutar was (Re: Porting Subversion to VMS) Re: gnutar was (Re: Porting Subversion to VMS) Re: gnutar was (Re: Porting Subversion to VMS) Re: gnutar was (Re: Porting Subversion to VMS) Re: OT: sound minds, and the benefit of hindsight Re: Porting Subversion to VMS Re: Porting Subversion to VMS Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: SOT: (somewhat off topic) driver for LK250 keyboard Re: SOT: (somewhat off topic) driver for LK250 keyboard Re: Tivoli Storage Manager (TSM) on OVMS Re: VMS 7.3 and a RD54 ---------------------------------------------------------------------- Date: Tue, 8 Jan 2008 11:38:10 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Anyone interested in building a vms-like OS? Message-ID: In article <47828bb8$0$4342$c3e8da3@news.astraweb.com>, JF Mezei writes: >> On Jan 6, 12:19 pm, gaoshan.w...@gmail.com wrote: >> >> I am in china right now, and have been talking with venture capitals >> recently, probably can get 100m us$ to start up provided we have the >> ability. There is a big OS market developing in china right now, > >You might as well buy VMS from HP. Then you can move the support from >India to China and re-hire the lost VMS engineers and get development >going again. > >In terms of platforms, you are better off making VMS run on "generic " >industry standard hardware that adheres to certain standards. This way >VMS could run from laptop to data centre again. > >If HP won't sell VMS, then you hire all the ex VMS engineers and poach a >few key ones still working for HP, and you also get some of the compiler >people now at Intel. > And then get sued by HP if any of the code looks anything like that in VMS since the Engineers you poached had access to the VMS sources. David Webb Security team leader CCSS Middlesex University ------------------------------ Date: Tue, 8 Jan 2008 08:32:38 -0800 (PST) From: yyyc186 Subject: Re: Anyone interested in building a vms-like OS? Message-ID: <841c744b-5f3a-48b6-9c08-9dfc589948ef@e10g2000prf.googlegroups.com> On Jan 8, 5:38 am, davi...@alpha2.mdx.ac.uk wrote: > > And then get sued by HP if any of the code looks anything like that in VMS > since the Engineers you poached had access to the VMS sources. > That would be a court case the underdog would win. HP has both demonstrated and allowed documentation to be created stating they have abandoned the OpenVMS platform. Suing a company who ported it to a completely different platform AMD rather than Titanic with no HP or Intel components anywhere in the developed system would win the day in court. You forget that OpenVMS is used heavily by military and military contractors. In the past it was under a Strategic Supplier contract, breach of which is an act of treason and all acts of treason are eligible for the death penalty. We've just tended to hand life in prison out lately. Porting OpenVMS to a non-Intel non-HP platform would give the DOD a second source and a real hardware vendor. ------------------------------ Date: Tue, 8 Jan 2008 18:05:22 +0100 From: "Michel HERRSCHER" Subject: Re: Anyone interested in building a vms-like OS? Message-ID: Dans un message yyyc186 disait : > On Jan 8, 5:38 am, davi...@alpha2.mdx.ac.uk wrote: >> >> And then get sued by HP if any of the code looks anything like that in >> VMS since the Engineers you poached had access to the VMS sources. >> > > That would be a court case the underdog would win. HP has both > demonstrated and allowed documentation to be created stating they have > abandoned the OpenVMS platform. Suing a company who ported it to a > completely different platform AMD rather than Titanic with no HP or > Intel components anywhere in the developed system would win the day in > court. You forget that OpenVMS is used heavily by military and > military contractors. In the past it was under a Strategic Supplier > contract, breach of which is an act of treason and all acts of treason > are eligible for the death penalty. We've just tended to hand life in > prison out lately. > > Porting OpenVMS to a non-Intel non-HP platform would give the DOD a > second source and a real hardware vendor. There is a project running on that matter (X86 platform): http://www.freevms.org/ I know the team is looking for developpers ;-)) -- Michel HERRSCHER Consultant tel : +33450870912 ------------------------------ Date: 8 Jan 2008 17:11:19 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Anyone interested in building a vms-like OS? Message-ID: <5uhp5nF1i07l1U1@mid.individual.net> In article <841c744b-5f3a-48b6-9c08-9dfc589948ef@e10g2000prf.googlegroups.com>, yyyc186 writes: > On Jan 8, 5:38 am, davi...@alpha2.mdx.ac.uk wrote: >> >> And then get sued by HP if any of the code looks anything like that in VMS >> since the Engineers you poached had access to the VMS sources. >> > > That would be a court case the underdog would win. HP has both > demonstrated and allowed documentation to be created stating they have > abandoned the OpenVMS platform. Suing a company who ported it to a > completely different platform AMD rather than Titanic with no HP or > Intel components anywhere in the developed system would win the day in > court. You have a very strange understanding of the law. Need I point to the Unix court case. Neither AT&T nor the CSRG did Unix for the Intel architecture. But they still owned Unix and they won the case against BSDI. And that only involved a dozen or so lines of code that could be traced back to AT&T. People here are talking about using the original engineers who can't become un-poluted. > You forget that OpenVMS is used heavily by military and > military contractors. You guys need to give this one a rest. It isn't true and there is much more evidence to supoport the lack of VMS in DOD then there is to try and support its presence. > In the past it was under a Strategic Supplier > contract, breach of which is an act of treason and all acts of treason > are eligible for the death penalty. We've just tended to hand life in > prison out lately. Boy, you do live in a strange reality. > > Porting OpenVMS to a non-Intel non-HP platform would give the DOD a > second source and a real hardware vendor. They aren't interested. If they were, HP would be doing to get all that money. Or, a major contractor, like LMCO, would be doing it with HP's blessing. You guys really need to wake up and smell the coffee. The VMS constant is probably rapidly approaching 50,000 and shrinking fast. (Unless they're counting hobbyist machines which may already outnumber production machines. I know they do around here. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 8 Jan 2008 09:32:08 -0800 (PST) From: John Subject: Re: Anyone interested in building a vms-like OS? Message-ID: <1bbbe70a-876e-400b-bd39-4d20c2ede506@l1g2000hsa.googlegroups.com> On Jan 8, 8:32 am, yyyc186 wrote: >You forget that OpenVMS is used heavily by military and > military contractors. In the past it was under a Strategic Supplier > contract, breach of which is an act of treason and all acts of treason > are eligible for the death penalty. We've just tended to hand life in > prison out lately. > > Porting OpenVMS to a non-Intel non-HP platform would give the DOD a > second source and a real hardware vendor. So the Department of Defense is going to buy a Chinese-written operating system? Correct me if I'm wrong but that seems unlikely to me. ------------------------------ Date: Tue, 08 Jan 2008 12:37:54 -0500 From: "Richard B. Gilbert" Subject: Re: Anyone interested in building a vms-like OS? Message-ID: <4783B4F2.3070807@comcast.net> Michel HERRSCHER wrote: > Dans un message yyyc186 disait : > > >>On Jan 8, 5:38 am, davi...@alpha2.mdx.ac.uk wrote: >> >>>And then get sued by HP if any of the code looks anything like that in >>>VMS since the Engineers you poached had access to the VMS sources. >>> >> >>That would be a court case the underdog would win. HP has both >>demonstrated and allowed documentation to be created stating they have >>abandoned the OpenVMS platform. Suing a company who ported it to a >>completely different platform AMD rather than Titanic with no HP or >>Intel components anywhere in the developed system would win the day in >>court. You forget that OpenVMS is used heavily by military and >>military contractors. In the past it was under a Strategic Supplier >>contract, breach of which is an act of treason and all acts of treason >>are eligible for the death penalty. We've just tended to hand life in >>prison out lately. >> >>Porting OpenVMS to a non-Intel non-HP platform would give the DOD a >>second source and a real hardware vendor. > > > There is a project running on that matter (X86 platform): > http://www.freevms.org/ > > I know the team is looking for developpers ;-)) > > It's been done already. It was called PCVMS. It gave you a DCL shell and, IIRC, some VMS-like APIs. A toy, really. This was twelve or fifteen years ago. . . . ------------------------------ Date: Tue, 8 Jan 2008 17:59:45 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Anyone interested in building a vms-like OS? Message-ID: In article <841c744b-5f3a-48b6-9c08-9dfc589948ef@e10g2000prf.googlegroups.com>, yyyc186 writes: >On Jan 8, 5:38 am, davi...@alpha2.mdx.ac.uk wrote: >> >> And then get sued by HP if any of the code looks anything like that in VMS >> since the Engineers you poached had access to the VMS sources. >> > >That would be a court case the underdog would win. HP has both >demonstrated and allowed documentation to be created stating they have >abandoned the OpenVMS platform. Please provide links to that HP documentation. In any case they definitely have not placed OpenVMS into the public-domain ie open-sourced it. Hence they could and would sue. If it was someone big and powerful like Microsoft doing the port then HP would probably be bought off for a pittance but if it was anyone smaller then the porters would probably either lose the case very quickly or be held up in court for long enough for them to go bankrupt. Even the suspicion of not using clean-room reverse engineering in porting could cause problems as in the allegation of 17th January 2006 that the Free ReactOS contained code obtained by disassembling Microsoft Windows see http://en.wikipedia.org/wiki/ReactOS >Suing a company who ported it to a >completely different platform AMD rather than Titanic with no HP or >Intel components anywhere in the developed system would win the day in >court. The problem isn't with hardware components it is with software components ie the code which belongs to HP as the successor to Compaq and Digital. You can't just pinch someone's proprietary code and port it to another platform. You can though reverse-engineer that code and port it. But you need to be able to show that you have done the latter not the former otherwise you will face the full force of the law. > You forget that OpenVMS is used heavily by military and >military contractors. In the past it was under a Strategic Supplier >contract, breach of which is an act of treason and all acts of treason >are eligible for the death penalty. We've just tended to hand life in >prison out lately. > >Porting OpenVMS to a non-Intel non-HP platform would give the DOD a >second source and a real hardware vendor. Until the DOD came out and publicly asked HP to either release VMS into the public-domain or port it to x86-64 I'd tend to disregard any thought of them riding to the rescue. David Webb Security team leader CCSS Middlesex University ------------------------------ Date: Tue, 08 Jan 2008 18:18:12 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Anyone interested in building a vms-like OS? Message-ID: In article <4783B4F2.3070807@comcast.net>, "Richard B. Gilbert" writes: >{...snip...} > >It's been done already. It was called PCVMS. It gave you a DCL shell >and, IIRC, some VMS-like APIs. A toy, really. This was twelve or >fifteen years ago. . . . Try 20! Wendin Associates in Wash. state. The biggest issue, IMO, for PC-VMS at that time was the lack of a more robust and sophisticated processor to run on. That was the era of the 80286 and, toward the end of the 80s, the 80386. I'd had a copy of it back when I worked at Lakehurst NAEC. It was, like you've said, a toy but fun to play with. CP/M ran on the box when there was something to do beside see what would fail in PC-VMS DCL when you typed in a certain command. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Tue, 8 Jan 2008 02:37:06 -0800 (PST) From: aaflsahc Subject: Baltimore Social Media Optimization Message-ID: <0592c6ec-480d-4f70-b530-4b5d35d520ea@u10g2000prn.googlegroups.com> This is for the benefit of everyone who wants to benefit from really good organic search engine optimization. http://socialmediaoptimization.tv/social-media-optimization/ that link has plenty of helpful videos and if you want it done right then there is only one company that i can rely on, atleast in orange country california. http://www.atomicseo.net these guys are so cocky but they now their stuff and I actually had results within a week because they did a lot of social marketing and that works better than google in my opinion adwords is the biggest joke the amount of money you waste, it must be nice to have cash like that... ------------------------------ Date: 8 Jan 08 13:22:03 EST From: cook@wvnvms.wvnet.edu (George Cook) Subject: Re: Building libxml2 on OpenVMS/VAX Message-ID: In article <4782e516$0$90274$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > George Cook wrote: >> Just recently I finished getting libxml2-2_4_27 to build on VAX with >> both DEC C and VAX C for use with VMS Mosaic. The main issue I ran >> into was the need for IEEE floating point; several functions depend >> on IEEE behaviors which are not available on VAX. Fortunately, I do >> not think Mosiac's usage of libxml2 will be affected by the lack of >> these behaviors. I can zip up what I have and put it out for FTP. >> >> If your application depends on the unavailable IEEE behaviors, then >> you could be in for major problems. I'm not sure how much (or when) >> libxml2 actually makes use of these behaviors. >> >> As far as D_FLOAT vs. G_FLOAT, I used G_FLOAT because it is the closest >> match for libxml2's use of IEEE floating point. > > I know I could look in the code myself, but WTF does a XML parser > need floating point for ? > > xsd:double in schema's ? I am far from being an expert on XML or libxml2, but some XML does use floating point. An SVG image is an XML file which can contain a lot of floating point values. Mosaic will use libxml2 for SVG images and style sheets, and I did just enough investigation to be reasonably sure that using G_FLOAT instead of IEEE will not cause significant problems. That, however, may not be the case for other applications. George Cook WVNET ------------------------------ Date: Tue, 8 Jan 2008 01:00:24 -0800 (PST) From: "Andreas W. Wylach" Subject: Re: Carl J. Lydick Message-ID: On 8 Jan., 05:15, "Richard B. Gilbert" wrote: > yyyc186 wrote: > > None of you can give me the answer I was looking for from him. > > > I'm in the process of finishing the last few chapters of "The Minimum > > You Need to Know About SOA" and wanted to include his > > GENTMPFILENAME.COM in the chapter where a DCL port service will be > > receiving XML messages it dumps to files so they can be queued to ACMS > > tasks. > > > Since it was posted publicly, I will add an author tag in the comments > > and attribute it to him. It was a nice little piece of code and I > > don't believe in re-inventing the wheel. > > I don't think Carl would mind as long as you give him proper credit and > don't publish anything you haven't tested!! Carl was ok. Had lots of good conversations and he helped out a lot. All one had to do is explaining the problem/questions as best as possible along providing details. I liked his disclaimer: This is comp.os.vms , not alt.read.my.mind. ;-))) Andreas W Wylach ------------------------------ Date: Tue, 08 Jan 2008 10:02:28 +0100 From: "P. Sture" Subject: Re: dial up modem Message-ID: In article <4780C0D5.4609.E452051@infovax.stanq.com>, "Stanley F. Quayle" wrote: > Hyperterminal. It's a really lousy implementation, though. Last time I looked, Hilgraeve do a Personal Edition which is far superior to the version which comes with Windows. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Tue, 8 Jan 2008 01:38:54 -0800 (PST) From: "winston19842005@yahoo.com" Subject: Re: dial up modem Message-ID: <4ef6029b-f799-4a05-a7ac-f5cc88098557@t1g2000pra.googlegroups.com> On Jan 8, 4:02 am, "P. Sture" wrote: > In article <4780C0D5.4609.E452...@infovax.stanq.com>, > "Stanley F. Quayle" wrote: > > > Hyperterminal. It's a really lousy implementation, though. > > Last time I looked, Hilgraeve do a Personal Edition which is far > superior to the version which comes with Windows. > And wasn't that free at one time? I remember upgrading the one that came with Windows. After reloading Windows recently, and realizing how crappy the default Hyperterm is, I went to their website. They want $$$ now... I found my version of Reflections. One thing I like about that software (at least the version I have) is that it can reinstall itself from a copy of the original folder. Doesn't do me much good though, as I don't have access to Alpha/Vax here, only AS/400... (talk about crap, that "Personal Communications" that IBM supplies is crap - craps out with memory violations ALL the time on XP...) ------------------------------ Date: Tue, 08 Jan 2008 08:13:50 +0100 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne?= Subject: Re: gnutar was (Re: Porting Subversion to VMS) Message-ID: <478322ac$0$14505$426a34cc@news.free.fr> Steven M. Schweda wrote: > From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne? > [snip] > > Interesting test philosophy you have there. Some people would wait > until _after_ they've tried it before becoming "definitively sure" about > it. Compiling with _LARGEFILE defined does not ensure the use of 64-bit I know that Python on VMS correctly handle large file because it pass all the tests provide to check that large file support is present. I don't remember having mentionned that "compiling with _LARGEFILE" is what I have test. FYI, a test doesn't prove the correctness of a program, it can prove that there is a problem or just that the program pass this test when you run it. So until you provide an example showing it doesn't work it is suppose to work. > integers for a file size/offset. There's also a "tar" format limit at > 8GB (an 11-digit octal size field, as I recall). But if you're _that_ > sure, well, that's good enough for me. > So if it is a tar format limitation it is not a Python (or any program) limitation. JFP ------------------------------ Date: Tue, 8 Jan 2008 05:17:28 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: gnutar was (Re: Porting Subversion to VMS) Message-ID: <08010805172871_206002CA@antinode.org> From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne? > > Interesting test philosophy you have there. Some people would wait > > until _after_ they've tried it before becoming "definitively sure" about > > it. Compiling with _LARGEFILE defined does not ensure the use of 64-bit > > I know that Python on VMS correctly handle large file because it pass > all the tests provide to check that large file support is present. Do any of those tests involve a file bigger than 2GB? 8GB? As I said, "interesting". > I don't remember having mentionned that "compiling with _LARGEFILE" is > what I have test. True. You didn't actually provide much of a description of your tests. What you did say was, "[...] Python is compile using 64 bits file routines [...]", which, on VMS, means "[c]ompiling with _LARGEFILE defined", which is what I said. As I also said, doing this is not a guarantee of proper program operation on large files. If it were, one could, for example, rebuild Zip 2.32 and UnZip 5.52 with that level of large-file support, and save all the years of (part-time) work which have gone into developing Zip 3.0 and UnZip 6.0. In the real world, however, most people would prefer programs which actually work to programs which someone believes are supposed to work. > FYI, a test doesn't prove the correctness of a program, it can prove > that there is a problem or just that the program pass this test when you > run it. So until you provide an example showing it doesn't work it is > suppose to work. But _not_ running a test does let you _suppose_ that the program works? Interesting (as before). > > integers for a file size/offset. There's also a "tar" format limit at > > 8GB (an 11-digit octal size field, as I recall). But if you're _that_ > > sure, well, that's good enough for me. > > So if it is a tar format limitation it is not a Python (or any program) > limitation. GNU "tar" uses a "tar" format extension to work around that limit. It involves storing a binary value in what had been an 11-digit (ASCII) octal size field. But don't worry about these details. I'm sure that you can _suppose_ that everything works perfectly. I prefer to test features like this before making such a claim. Call me old-fashioned. SMS. ------------------------------ Date: Tue, 08 Jan 2008 17:00:24 +0100 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne?= Subject: Re: gnutar was (Re: Porting Subversion to VMS) Message-ID: <47839e16$0$17618$426a74cc@news.free.fr> Steven M. Schweda a écrit : > From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne? > >>> Interesting test philosophy you have there. Some people would wait >>> until _after_ they've tried it before becoming "definitively sure" about >>> it. Compiling with _LARGEFILE defined does not ensure the use of 64-bit >> I know that Python on VMS correctly handle large file because it pass >> all the tests provide to check that large file support is present. > > Do any of those tests involve a file bigger than 2GB? 8GB? As I > said, "interesting". > >> I don't remember having mentionned that "compiling with _LARGEFILE" is >> what I have test. > > True. You didn't actually provide much of a description of your > tests. So as I don't provide a description you assume I haven't done any test, interesting. What you did say was, "[...] Python is compile using 64 bits > file routines [...]", which, on VMS, means "[c]ompiling with _LARGEFILE > defined", which is what I said. As I also said, doing this is not a > guarantee of proper program operation on large files. If it were, one > could, for example, rebuild Zip 2.32 and UnZip 5.52 with that level of > large-file support, and save all the years of (part-time) work which > have gone into developing Zip 3.0 and UnZip 6.0. In the real world, > however, most people would prefer programs which actually work to > programs which someone believes are supposed to work. > believe or not believe that is the question... As you are the only guy on earth able to prove that a program is correct (except very simple program), you will win a lot of money because nobody is able to do this :-)) >> FYI, a test doesn't prove the correctness of a program, it can prove >> that there is a problem or just that the program pass this test when you >> run it. So until you provide an example showing it doesn't work it is >> suppose to work. > > But _not_ running a test does let you _suppose_ that the program > works? Interesting (as before). > For the third time, I *have* run all the tests to check that the 64 bits support is correct. So until you prove the opposite it work. Y have done a assumption about something I haven't written, so read carefully: All the 64 bits file support tests without any problem. >>> integers for a file size/offset. There's also a "tar" format limit at >>> 8GB (an 11-digit octal size field, as I recall). But if you're _that_ >>> sure, well, that's good enough for me. >> So if it is a tar format limitation it is not a Python (or any program) >> limitation. > > GNU "tar" uses a "tar" format extension to work around that limit. > It involves storing a binary value in what had been an 11-digit (ASCII) > octal size field. But don't worry about these details. I'm sure that > you can _suppose_ that everything works perfectly. I prefer to test > features like this before making such a claim. Call me old-fashioned. > I didn't do any claim about gnutar extension (I do claim about 64 file support by Python) but I tend to trust the documentation (http://docs.python.org/lib/module-tarfile.html) and the tests passed instead someone which claim that he trust nobody and that nothing work until *he* have prove it work, LOL. > SMS. JFP ps. As this thread seem, now, sterile, this is my last post. ------------------------------ Date: Tue, 8 Jan 2008 11:13:07 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: gnutar was (Re: Porting Subversion to VMS) Message-ID: <08010811130697_206002CA@antinode.org> From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne? > >>> Interesting test philosophy you have there. Some people would wait > >>> until _after_ they've tried it before becoming "definitively sure" about > >>> it. Compiling with _LARGEFILE defined does not ensure the use of 64-bit > >> I know that Python on VMS correctly handle large file because it pass > >> all the tests provide to check that large file support is present. > > > > Do any of those tests involve a file bigger than 2GB? 8GB? As I > > said, "interesting". > > > >> I don't remember having mentionned that "compiling with _LARGEFILE" is > >> what I have test. > > [Explanation of the equivalence of the this with what you did claim > > omitted here.] > > True. You didn't actually provide much of a description of your > > tests. > > So as I don't provide a description you assume I haven't done any test, > interesting. No, what I assume is that you've run some simple-minded test which ensures that file-size/offset variables are 8 bytes, not four. What I assume that you haven't run is a useful, more realistic test which involves actual large files in a large "tar" archive. But feel free to tell me that you really _did_ run some serious "tar" tests. > For the third time, I *have* run all the tests to check that the 64 bits > support is correct. So until you prove the opposite it work. > Y have done a assumption about something I haven't written, so read > carefully: > All the 64 bits file support tests without any problem. And, for the Nth time (where I've lost track of N), that is not certain to be a useful test of "tar" capability on large files, which is what I thought that we were discussing, any more than it would have been a useful test of UnZip+Zip capability on large files, because there's more involved in such support than use of large file size/offset variables. > As this thread seem, now, sterile, this is my last post. Well, that's a mercy. SMS. ------------------------------ Date: 8 Jan 2008 13:12:08 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: OT: sound minds, and the benefit of hindsight Message-ID: <5uhb58F1huvnkU1@mid.individual.net> In article <47826745.1080403@comcast.net>, "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> In article <47824491.3020702@comcast.net>, >> "Richard B. Gilbert" writes: >> >>>Bill Gunshannon wrote: >>> >>>>In article <47803A43.6020501@comcast.net>, >>>> "Richard B. Gilbert" writes: >>>> >>>> >>>>>Bill Gunshannon wrote: >>>>> >>>>> >>>>>>In article <13nunthlrf2ie49@corp.supernews.com>, >>>>>> "John Wallace" writes: >>>>>> >>>>>> >>>>>> >>>>>>>"ChrisQuayle" wrote in message >>>>>>>news:Dzzej.25815$KC3.11290@newsfe6-gui.ntli.net... >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Bill Gunshannon wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>The whole company has no problem noticing Microsoft Windows. And the >>>>>>>>>money from that just goes into someone else's coffers. Great way to >>>>>>>>>run a business. >>>>>>>>> >>>>>>>>>bill >>>>>>>>> >>>>>>>> >>>>>>>>The amazing thing to me, even years after the event, was the way that HP >>>>>>>>took an industry leading architecture and tossed it away as though it >>>>>>>>were worthless. Even now, such a decision doesn't look like the product >>>>>>>>of sound minds - irrational from any view. How can anyone take such a >>>>>>>>company seriously after such a fiasco and all the politics and other >>>>>>>>crap that's gone down since ?. >>>>>>>> >>>>>>>>At least Sun is still flying the flag of innovation - have you looked at >>>>>>>>Solaris 10 yet ? - Everything Tru64 would have grown into and a company >>>>>>>>that looks like it understands the meaning of the phrases 'business >>>>>>>>ethics' and 'pursuit of excellence'. >>>>>>>> >>>>>>>>Remember, it took Intel 10 years to catch up with Alpha - that's how far >>>>>>>>ahead it was. Rest in Peace perhaps, but not forgotten :-)... >>>>>>>> >>>>>>> >>>>>>>I don't know much about Sun, and whether their current situation is the >>>>>>>result of good judgement or good luck. Where's Andrew these days (oh, I >>>>>>>forgot, he had so much faith in Sun's future that he went to the Dark Side, >>>>>>>iirc. Or perhaps Sun had so much faith in his future :)). >>>>>> >>>>>> >>>>>>In this business changing employers at intervals is the norm rather >>>>>>than the exception. It probably means nothing. I have been with >>>>>>the same employer for 18 years. All it appears to have done is make >>>>>>it harder to find a new position now that I feel it is becoming >>>>>>necessary. >>>>>> >>>>>>bill >>>>>> >>>>> >>>>>Look at it in a positive way. If you've been there eighteen years, you >>>>>have almost certainly held three or four positions increasingly more >>>>>responsible and better paid than the one you started with! >>>> >>>> >>>>Wanna bet? >>>> >>>> >>>> >>>>>Wise employers try to retain good people! Hiring and training new >>>>>people from outside is a high expense, high risk, activity. >>>> >>>> >>>>You have never worked here. They frequently drive out qualified people >>>>only to replace them with unqualified people. I started here as the >>>>networking guru before moving out of production and into the academic >>>>side of the house after building the first network and making this >>>>University the first one on the INTERNET in NEPA. There have been three >>>>people in that position since. The first two had less than a year of >>>>networking experience and left for better jobs as sson as they had enough >>>>experience to actually put it on their resumes. The current came here >>>>from a position as a medical electronics equipment repairman. >>>> >>>> >>>> >>>>>I spent twenty-four years working for Princeton University. My long >>>>>tenure there did not seem to negatively impact my subsequent career. I >>>>>got at least five jobs worth of varied experience out of the deal. >>>> >>>> >>>>I have added lots of experience, but about the only places that seem >>>>to see value in it are other schools, who pay equally poorly. I do >>>>have to admit, I had one decent offer but we failed to agree on thngs >>>>outside of salary so I declined the position. And, contrary to what >>>>a lot of people may believe, I am certain my age is always considered >>>>when I apply and it isn't considered a plus. (They may not be allowed >>>>to ask your age, but when your job experience goes back to 1968 they >>>>can pretty well figure it out!!) >>> >>>Hey junior, you think you got problems? My first job was the summer of >>>1957. My first full time job came somewhat later. . . . >> >> >> I don't put the jobs I held before leaving school on my resume. Doesn't >> go back to '57, but come pretty close. >> >> >>>The market for VMS people is somewhere between small and nonexistent. >>>What else do you know? >> >> >> Not looking for VMS work at all as my experience is not strong enough >> that I would even warrant consideration. Doesn't mean I can't do it, >> just that I don't consider myself qualified enough to warrant the salary >> I would require. I do, however, have 27 years of Unix experience going >> back as far as Version7 and including not only your typical SAing but >> also things like patching kernels with adb because, unlike today, we >> didn't used to have all the sources. >> >> bill >> > > Well, there's plenty of Unix/Linux stuff around but there's no shortage > of people who know it. True, but I'll bet not many with my level of experience. Unfortunately, it seems today that age trumps experience everytime. (Yes, I have even had one job offered to me by the US Army that was stopped by someone higher up the food chain who had no problem with the fact that it was my date of birth that was the disqualifying factor!! Apparently, while I am not too old to go to Iraq or Afghanistan I am too old to go to GA.) > > Is retirement an option for you? Sadly, mostly due to the many years I spent in the real Army followed by an even greater number in academia, that is not an option. At least not for maybe another 10 years. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 08 Jan 2008 09:41:43 +0100 From: "P. Sture" Subject: Re: Porting Subversion to VMS Message-ID: In article <4iUfj.22893$Ux2.3521@attbi_s22>, "John E. Malmberg" wrote: > Only the client code will compile, the server code requires the Berkely > DB. (The last time I looked) > > If you only compile the client, you will have to host the repository on > another system. > > The SleepyCat source, which seems to be what LINUX uses for the Berkely > DB, also seems to have VMS specific code in it, but I am not sure how > well it works, if at all. I'm not up to date with version numbers or anything, but the VMS port of htdig contains Berekeley DB. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Tue, 08 Jan 2008 17:54:33 +0100 From: "Martin Vorlaender" Subject: Re: Porting Subversion to VMS Message-ID: P. Sture wrote: > "John E. Malmberg" wrote: >> Only the client code will compile, the server code requires the Berkely >> DB. (The last time I looked) >> >> If you only compile the client, you will have to host the repository on >> another system. >> >> The SleepyCat source, which seems to be what LINUX uses for the Berkely >> DB, also seems to have VMS specific code in it, but I am not sure how >> well it works, if at all. > > I'm not up to date with version numbers or anything Neither am I... > but the VMS port of htdig contains Berekeley DB. Indeed. In order to independent of version incompatibilities, the htdig maintainers packaged a Berkeley DB v2.6.4 with ht://Dig 3.1.6 (which is the version I ported to VMS a few years ago). Couldn't run the tests, though, as I didn't have a TCL installation on VMS. It seems to work quite well. But it's probably way out of date. cu, Martin -- One OS to rule them all | Martin Vorlaender | OpenVMS rules! One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://vms.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin.vorlaender@t-online.de ------------------------------ Date: Tue, 08 Jan 2008 11:07:24 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Security level of SET PASS /GENERATE ? Message-ID: In many places in the VMS docs one is recomended to use the /GENERATE option of SET PASS (or the correspending flag in SYSUAF). What is the current view of these generated passwords ? How safe are they against hacking/probing/directory-attacs ? Jan-Erik. ------------------------------ Date: 8 Jan 2008 06:11:36 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <$y79yGDMKbgk@eisner.encompasserve.org> In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > In many places in the VMS docs one is recomended > to use the /GENERATE option of SET PASS (or the > correspending flag in SYSUAF). What is the current > view of these generated passwords ? How safe are they > against hacking/probing/directory-attacs ? Certainly generated passwords are better than human-chosen passwords. But for the highest security one must abandon reusable passwords and switch to one-time authentication. Typically this is done with a hardware token, but there is one implementation that uses a list of successive passwords printed on a piece of paper. I don't know exactly what you mean by directory attacks, but for both "dictionary" attacks and "probing", VMS breakin evasion is the most powerful defense. The attacker is locked out but is not informed of that by the system. Those with TCP/IP connections need to be sure to set LGI_BRK_TERM to 0. Reusable passwords are the wave of the past, and have been for 20 years. Just now the US government is putting rules in place forbidding their use on government systems. ------------------------------ Date: Tue, 08 Jan 2008 13:49:30 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: Larry Kilgallen wrote: > In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > >> In many places in the VMS docs one is recomended >> to use the /GENERATE option of SET PASS (or the >> correspending flag in SYSUAF). What is the current >> view of these generated passwords ? How safe are they >> against hacking/probing/directory-attacs ? > > Certainly generated passwords are better than human-chosen passwords. Yes, that's what I was thinking about. I showed some of the generated passwords (with /gen=10) and they said they didn't looked "safe" at all... :-) Some wanted mixed-case to have "safe" passwords... And yes, I know about the anti-breakin tools. But I was mainly interested inte level of security in the generated passwords as such. One thing one asks is how many of them are there ? That is, if one know how the "generation" is done, what is the chance/risk to be able to generate a matching password ? Jan-Erik. ------------------------------ Date: 8 Jan 2008 07:59:29 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > Larry Kilgallen wrote: >> In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: >> >>> In many places in the VMS docs one is recomended >>> to use the /GENERATE option of SET PASS (or the >>> correspending flag in SYSUAF). What is the current >>> view of these generated passwords ? How safe are they >>> against hacking/probing/directory-attacs ? >> >> Certainly generated passwords are better than human-chosen passwords. > > Yes, that's what I was thinking about. I showed some of the > generated passwords (with /gen=10) and they said they didn't > looked "safe" at all... :-) > > Some wanted mixed-case to have "safe" passwords... That might be appropriate for systems that allow unlimited guessing, but VMS is rather guesser-unfriendly. For an attack that involves reading a cleartext password off the wire, case variations do not help at all. > And yes, I know about the anti-breakin tools. But I was > mainly interested inte level of security in the generated > passwords as such. One thing one asks is how many of them > are there ? That is, if one know how the "generation" is > done, what is the chance/risk to be able to generate a > matching password ? The chance is "very small". Over 15 (at least) years of use there have not been public reports of such happening. ------------------------------ Date: Tue, 08 Jan 2008 09:12:54 -0500 From: "Richard B. Gilbert" Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <478384E6.90203@comcast.net> Jan-Erik Söderholm wrote: > In many places in the VMS docs one is recomended > to use the /GENERATE option of SET PASS (or the > correspending flag in SYSUAF). What is the current > view of these generated passwords ? How safe are they > against hacking/probing/directory-attacs ? > > Jan-Erik. The generated passwords are as safe and secure as any other passwords. Passwords are not the problem! Users are the problem!! If you get too anal retentive about passwords such as requiring weekly changes or generated passwords, the users will write their password on a Post-It and stick it to the bottom of their keyboard!!!!! If not Post-Its, you will find yourself doing a lot of password resets. I'd advise a 90 day lifetime and eight character minimum. Train the users! They should not use theirs pet's name, husband's name, name of the street they live on, etc! Suggest that they invent a new word or miss spell a word creatively. Strings like "knobnoxious" or "snickels" are quite secure and quite memorable if the user invents his/her own. Inspect the bottoms of keyoards occasionally. If you find password that works, fire the owner. ------------------------------ Date: Tue, 08 Jan 2008 14:24:38 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: Richard B. Gilbert wrote: > Jan-Erik Söderholm wrote: >> In many places in the VMS docs one is recomended >> to use the /GENERATE option of SET PASS (or the >> correspending flag in SYSUAF). What is the current >> view of these generated passwords ? How safe are they >> against hacking/probing/directory-attacs ? >> >> Jan-Erik. > > The generated passwords are as safe and secure as any other passwords. > > Passwords are not the problem! Users are the problem!! Hold it ! I know everything about all that. I was *specificaly* asking about the builtin security of the *generated* passwords. Nothing else... :-) Jan-Erik. If you get too > anal retentive about passwords such as requiring weekly changes or > generated passwords, the users will write their password on a Post-It > and stick it to the bottom of their keyboard!!!!! If not Post-Its, you > will find yourself doing a lot of password resets. > > I'd advise a 90 day lifetime and eight character minimum. Train the > users! They should not use theirs pet's name, husband's name, name of > the street they live on, etc! Suggest that they invent a new word or > miss spell a word creatively. Strings like "knobnoxious" or "snickels" > are quite secure and quite memorable if the user invents his/her own. > > Inspect the bottoms of keyoards occasionally. If you find password that > works, fire the owner. > ------------------------------ Date: Tue, 8 Jan 2008 06:38:51 -0800 (PST) From: AEF Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <7e686001-d849-4c98-a94f-36bcaf04ccc0@41g2000hsy.googlegroups.com> On Jan 8, 10:24 am, Jan-Erik S=F6derholm wrote: > Richard B. Gilbert wrote: > > Jan-Erik S=F6derholm wrote: > >> In many places in the VMS docs one is recomended > >> to use the /GENERATE option of SET PASS (or the > >> correspending flag in SYSUAF). What is the current > >> view of these generated passwords ? How safe are they > >> against hacking/probing/directory-attacs ? > > >> Jan-Erik. > > > The generated passwords are as safe and secure as any other passwords. > > > Passwords are not the problem! Users are the problem!! Exactly! > > Hold it ! > I know everything about all that. I was *specificaly* asking > about the builtin security of the *generated* passwords. > Nothing else... :-) Longer is stronger. Contrary to CW, forcing users to use complex passwords is more pain than gain. You gain A LOT MORE SECURITY by making passwords longer vs. making them complex. See my other posts on this and there's a reference I'll dig up later on this (from InfoWorld, I think). > > Jan-Erik. > > If you get too > > > anal retentive about passwords such as requiring weekly changes or > > generated passwords, the users will write their password on a Post-It > > and stick it to the bottom of their keyboard!!!!! If not Post-Its, you > > will find yourself doing a lot of password resets. Exactly. This is yet another reason why increasing length is much better than increasing "complexity". The only complexity checks should be for stupid passwords like AAAAAAAAA or 12345678 and the like. Things like using O's for zeros are not going to help much at all and just make the system admin's job harder than it has to be. > > > I'd advise a 90 day lifetime and eight character minimum. Train the > > users! They should not use theirs pet's name, husband's name, name of > > the street they live on, etc! Suggest that they invent a new word or > > miss spell a word creatively. Strings like "knobnoxious" or "snickels" > > are quite secure and quite memorable if the user invents his/her own. > > > Inspect the bottoms of keyoards occasionally. If you find password that= > > works, fire the owner. AEF ------------------------------ Date: Tue, 08 Jan 2008 10:22:31 -0500 From: "Richard B. Gilbert" Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <47839537.3050300@comcast.net> Jan-Erik Söderholm wrote: > Richard B. Gilbert wrote: > >> Jan-Erik Söderholm wrote: >> >>> In many places in the VMS docs one is recomended >>> to use the /GENERATE option of SET PASS (or the >>> correspending flag in SYSUAF). What is the current >>> view of these generated passwords ? How safe are they >>> against hacking/probing/directory-attacs ? >>> >>> Jan-Erik. >> >> >> The generated passwords are as safe and secure as any other passwords. >> >> Passwords are not the problem! Users are the problem!! > > > Hold it ! > I know everything about all that. I was *specificaly* asking > about the builtin security of the *generated* passwords. > Nothing else... :-) > My point is that generated passwords are little or no better than any other sort! A password has little or no inherent security! If handled and used properly it's reasonably secure and if not, not! ------------------------------ Date: 8 Jan 2008 10:42:05 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: In article <47839537.3050300@comcast.net>, "Richard B. Gilbert" writes: > My point is that generated passwords are little or no better than any > other sort! A password has little or no inherent security! If handled > and used properly it's reasonably secure and if not, not! Generated passwords are _guaranteed_ by the system to be hard to guess. They are also _guaranteed_ by the system to not be the same password that user has chosen on multiple other systems. If one can trust a user to come up with a unique hard-to-guess password, there would be no benefit to using a generated password. But in many situations the users cannot be trusted to follow security rules. On VMS, the guessability of a password is less important than on other systems due to breakin evasion. But VMS is still vulnerable to threats of a password that is chosen to be the same on multiple systems, since if one system is compromised they all go down. ------------------------------ Date: Tue, 08 Jan 2008 12:33:04 -0500 From: "Richard B. Gilbert" Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <4783B3D0.4010500@comcast.net> Larry Kilgallen wrote: > In article <47839537.3050300@comcast.net>, "Richard B. Gilbert" writes: > > >>My point is that generated passwords are little or no better than any >>other sort! A password has little or no inherent security! If handled >>and used properly it's reasonably secure and if not, not! > > > Generated passwords are _guaranteed_ by the system to be hard to guess. > They are also _guaranteed_ by the system to not be the same password > that user has chosen on multiple other systems. > It seems impossible to guarantee that the password is not identical to one used elsewhere without the system having prior knowledge of the passwords in use on other systems. Yes, the probability of duplication is low but a low probability is not quite the same a guarantee. Generated passwords do provide some protection against a dictionary attack but the system protects itself against such attacks by locking the user out after some small number of failures (break-in evasion). The system also protects itself by disallowing some of the worst choices; e.g. the entire Robert Morris list! It's very easy for the system manager to spot attempts at password guessing or dictionary attacks. The system gives you plenty of notice if you are paying any attention at all. I used to see such things two or three times a week. People had changed their passwords and forgotten the new one. Eventually, they had to come to me or the help desk to get the password reset before they could log in! ------------------------------ Date: Tue, 8 Jan 2008 12:21:22 -0500 From: norm.raphael@metso.com Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: This is a multipart message in MIME format. --=_alternative 005F510F852573CA_= Content-Type: text/plain; charset="US-ASCII" Kilgallen@SpamCop.net (Larry Kilgallen) wrote on 01/08/2008 11:42:05 AM: > In article <47839537.3050300@comcast.net>, "Richard B. Gilbert" > writes: > > > My point is that generated passwords are little or no better than any > > other sort! A password has little or no inherent security! If handled > > and used properly it's reasonably secure and if not, not! > > Generated passwords are _guaranteed_ by the system to be hard to guess. > They are also _guaranteed_ by the system to not be the same password > that user has chosen on multiple other systems. > > If one can trust a user to come up with a unique hard-to-guess password, > there would be no benefit to using a generated password. But in many > situations the users cannot be trusted to follow security rules. > > On VMS, the guessability of a password is less important than on other > systems due to breakin evasion. But VMS is still vulnerable to threats > of a password that is chosen to be the same on multiple systems, since > if one system is compromised they all go down. As I read it, Jan-Erik was asking about the vulnerablity of the generating algorthm - how likely is it the password generation could be turned into a tool to crack generated passwords. ISTM that given all the previous discussion, this is not a concern, but that is what concerns him. He groks security. His question is about any vulnerability of this algorthm and its implementation. (I find generated passworks harder, not easier, to remember.) --=_alternative 005F510F852573CA_= Content-Type: text/html; charset="US-ASCII"



Kilgallen@SpamCop.net (Larry Kilgallen) wrote on 01/08/2008 11:42:05 AM:

> In article <47839537.3050300@comcast.net>, "Richard B. Gilbert"
> <rgilbert88@comcast.net> writes:
>
> > My point is that generated passwords are little or no better than any
> > other sort!  A password has little or no inherent security!  If handled
> > and used properly it's reasonably secure and if not, not!
>
> Generated passwords are _guaranteed_ by the system to be hard to guess.
> They are also _guaranteed_ by the system to not be the same password
> that user has chosen on multiple other systems.
>
> If one can trust a user to come up with a unique hard-to-guess password,
> there would be no benefit to using a generated password.  But in many
> situations the users cannot be trusted to follow security rules.
>
> On VMS, the guessability of a password is less important than on other
> systems due to breakin evasion.  But VMS is still vulnerable to threats
> of a password that is chosen to be the same on multiple systems, since
> if one system is compromised they all go down.

As I read it, Jan-Erik was asking about the vulnerablity of the generating
algorthm - how likely is it the password generation could be turned into
a tool to crack generated passwords.

ISTM that given all the previous discussion, this is not a concern, but that
is what concerns him.  He groks security.  His question is about any
vulnerability of this algorthm and its implementation.

(I find generated passworks harder, not easier, to remember.)
--=_alternative 005F510F852573CA_=-- ------------------------------ Date: Tue, 08 Jan 2008 10:18:18 +0100 From: "P. Sture" Subject: Re: SOT: (somewhat off topic) driver for LK250 keyboard Message-ID: In article <97ogj.6$7b2.0@newsfe12.lga>, VAXman- @SendSpamHere.ORG wrote: > have a Powerbook and I purchased an Apple bluetooth wireless keyboard > to use with it. It has a layout akin to the LK keyboards. I have not > had a problem with the alternate keypads in EDT. The [PF1] (gold) key > outputs the proper OP for me. This is one of the major reasons I > purchased the keyboard. I do not like to use the "embedded" alternate > keypad in the laptop keyboard. It requires toggling the F6 (num lock) > on and off to use and, invariably, I'd forget to toggle it off before > typing some other character. When that would happen, my session seems > to get horked. FWIW I was looking at the new slimline Mac keyboards this weekend and they appear to have a few extra function keys - up to F19 IIRC. These are nearly twice the price of the older white ones (looking at the USB models here), but the white ones are not very tolerant of general dust and liquids, so the extra cost could be worth it in the long run. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Tue, 08 Jan 2008 12:13:00 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SOT: (somewhat off topic) driver for LK250 keyboard Message-ID: In article , "P. Sture" writes: >{...snip...} >FWIW I was looking at the new slimline Mac keyboards this weekend and >they appear to have a few extra function keys - up to F19 IIRC. These >are nearly twice the price of the older white ones (looking at the USB >models here), but the white ones are not very tolerant of general dust >and liquids, so the extra cost could be worth it in the long run. Mine has F1-F16... F17 through F20 are decrease volume, increase volume, mute and eject. I suppose Apple decided the volume controls could go. Nope, I just looked at the Apple site for a picture of the new keyboard. Several of the function keys are labeled with an icon and F##. It's not clear how to get the F## feature over the icon feature. I'd imagine the shift and [Option/Alt] key in conjunction with the F## key. I like the idea of the new keyboard because it is much lighter than the current keyboard. I was dismayed when the wireless version was released without the alternate keypads though. I'm looking for ways to NOT have to travel with excess cables in the travel case and a wireless keyboard is less cable. The USB (Use System Battery) keyboard will also require power from the Powerbook meaning less working time on battery. At least most of the new jet liners have power in the seats and I have a special power adapter for use in the car. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Tue, 8 Jan 2008 06:23:31 -0800 (PST) From: cycle4fun@excite.com Subject: Re: Tivoli Storage Manager (TSM) on OVMS Message-ID: <3471d7d9-113e-4945-bac2-8806069ee5dd@d70g2000hsb.googlegroups.com> Been using the Tivoli client ABC from Storserver for many years to backup my VMS systems. It works very well. The only catch is you need to have the software loaded on a system to be able to restore your system disk. You also need to be aware of your file retentiion on the Tivoli server. With VMS's file versions you can take up a lot of extra space on Tivoli. http://www.storsol.com/main.cfm?menu=2&submenu=abc&detail=include/abcoverview.cfm ------------------------------ Date: Tue, 08 Jan 2008 09:44:58 +0100 From: "P. Sture" Subject: Re: VMS 7.3 and a RD54 Message-ID: In article , "tomarsin2015@comcast.net" wrote: > Hello > I picked up a VAXstation/server 2000 with a RD54. After loading 7.3/ > DECwindows/UCX 4.2 I am down to less then 80000 blocks free. I never > used VMStailor to free up space on a system disk, so is there a guide > on how to use VMStailor? I dont really know what is safe to remove or > keep. > Also if anybody wants to take this bad boy off my hands, make me a > offer. > tks > phillip When I had one I took DECwindows off it to free up space. I did this manually as doing so freed up an appreciable amount more space than VMStailor did. WIth the amount of RAM my beasty had, there was not much left to run apps once DECwindows was loaded. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ End of INFO-VAX 2008.016 ************************