INFO-VAX Tue, 30 Oct 2007 Volume 2007 : Issue 594 Contents: 9-Track tapes on integrity Re: BUG in SEARCH /NUMBERS Encrypt data with LTO-4 drive Re: Re: Englanders fleeing socialized healthcare in record numbers! Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young HP *is* celebrating 30 years of OpenVMS Re: HP *is* celebrating 30 years of OpenVMS Re: Newbie directory protection question Re: Newbie directory protection question Re: Pathworks vs CIFS performance Re: Pathworks vs CIFS performance Re: Pathworks vs CIFS performance Remote NFS Mounts on OpenVMS ---------------------------------------------------------------------- Date: Tue, 30 Oct 2007 08:47:36 -0400 From: "Ebinger . Eric" Subject: 9-Track tapes on integrity Message-ID: =20 Is it possible (I know it's not supported) to use a SCSI 9-track tape = drive (TSZ07) on a VMS Integrity server (RX26660) by way of an Ultra320 = scsi adapter? We would also need to use a 4mm DDS-3 drive but I can't = imagine that would be a problem if the 9-track would work. =20 =20 I think I have a handle on the issues involved except for the archaic = data input requirements. (No, it isn't feasible to eliminate the 9-track = input requirement.) Is anyone using 9-track on Itanium? =20 =20 Eric Ebinger ------------------------------ Date: Tue, 30 Oct 2007 13:30:25 -0000 From: Hein RMS van den Heuvel Subject: Re: BUG in SEARCH /NUMBERS Message-ID: <1193751025.606451.191190@57g2000hsv.googlegroups.com> On Oct 29, 3:13 pm, JF Mezei wrote: > Alpha VMS 8.3 > > >$ search/num $disk2:[000000]indexf.sys mozilla.com;5 > >3= >> Something else must be going on. Maybe a visual effect with rub-outs? Send that output to a file an try again? Below is a sample session with record 40,000 in an indexf.sys suggesting all works fine in at least 1 case. Regards, Hein. $ dump/bloc=3D(start=3D40000,count=3D1) sys$disk:[000000]indexf.sys : Virtual block number 40000 (00009C40), 512 (0200) bytes : 00000000 00509A15 02010000 FFFF6428 (d........P..... 000000 : 00000014 00000000 00000139 0DB3FFCC =EF=BF=BD.=EF=BF=BD.9........... 000040 30303039 35444345 30364124 4C49414D MAIL$A60ECD59000 000050 $ searc/number/form=3Dnonull sys$disk:[000000]indexf.sys MAIL $A60ECD59000 40000 (dP.=EF=BF=BD=EF=BF=BD9MAIL$A60ECD590005009 ------------------------------ Date: Tue, 30 Oct 2007 15:26:45 +0400 From: Valentin Likoum Subject: Encrypt data with LTO-4 drive Message-ID: <437673269.20071030152645@ncc.volga.ru> Hello, The questions below was already asked on ITRC forum, but may be someone who don't visit it will answer here. According to external requirements we have to implement tape encryption. I like the idea to put this task to HP 1840 LTO-4 drive to offload our already overloaded CPUs. We are running v7.3-2 on ES40 which is not supported with 1840 drive but may work (scsi is scsi). But what to do with encryption keys loading? AFAIK, it's not exist even on 8.3. The idea is to buy FC-interfaced library (MSL2024) with 1840 drive, load keys there from Windows or Linux host with LTO4-encryption aware software (say, HP Data Protector Express which is included with any 1840 drive) and use plain BACKUP to feed the drive and data on the tape should be encrypted (?). So the question are: 1. Did anybody try 1840 drive with 7.3-2 and which were results? 2. Is it possible to load encryption keys from one host and feed data from the other host? I know that the keys are kept in drive until power off or another keys loading, but will they applied to the data if no specific commands will be issued (7.3-2 BACKUP)? 2.5 (non-VMS) Does Data Protector Express allow to load keys only, without writing any real data? I can't realize this from the it's manual. 3. Our FC infrastructure is 2Gb. MSL2024 library has 4Gb interface. I afraid we'll be unable to feed this beast even with compression disabled and it'll die very fast due to shoeshining. Thank you. -- Best regards, Valentin valentin.likoum at ncc dot volga dot ru ------------------------------ Date: Tue, 30 Oct 2007 09:45:56 -0400 From: "David Turner, Island Computers" Subject: Re: Re: Englanders fleeing socialized healthcare in record numbers! Message-ID: <13iedge8cl0r50d@news.supernews.com> And primarily sex-change clinics (so "they" tell me) "Dr. Dweeb" wrote in message news:472530e0$0$21928$157c6196@dreader1.cybercity.dk... > ultradwc@gmail.com wrote: >> looks like India is becoming popular for not only vms support but >> surgery for Britans people as well ... this is the same socialized >> healthcare system Hillary wants to give you ... read and learn ... >> >> http://www.worldnetdaily.com/news/article.asp?ARTICLE_ID=58379 > > Actually, "medical tourism" is big business in Asia. There are regular > articles in major publications, mostly about *Americans* going to Thailand > (or wherever) for procedures. There have been articles in Newsweek and I > think Time. > > http://www.bumrungrad.com/Overseas-Medical-Care/Bumrungrad-International.aspx > > This is the major 5-star hospital in Bangkok. > > And to bring it on topic, they are an MS and SQLServer shop. > > Dr. Dweeb > ------------------------------ Date: Tue, 30 Oct 2007 05:40:58 -0700 From: "Tom Linden" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck wrote: > We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but > never thought we'd see anything better until we experienced OpenVMS on > Alpha. Let's not revise history, VMS on Alpha was never quite the same as on VAX, a lot was lost in the gratuitous migration -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 30 Oct 2007 13:45:51 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: In article , "Tom Linden" writes: >On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >wrote: > >> We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >> never thought we'd see anything better until we experienced OpenVMS on >> Alpha. > >Let's not revise history, VMS on Alpha was never quite the same as on VAX, >a lot was lost in the gratuitous migration > A lot of software was lost (and was made worse by DEC then selling of lots of software which was ported) but the transition to Alpha wasn't gratuitous. VAX performance even with the best efforts of the Digital engineers just couldn't keep up with the competition. David Webb Security team leader CCSS Middlesex University >-- >PL/I for OpenVMS >www.kednos.com ------------------------------ Date: 30 Oct 2007 13:58:12 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <5oorjkFns754U1@mid.individual.net> In article , david20@alpha2.mdx.ac.uk writes: > In article , "Tom Linden" writes: >>On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >>wrote: >> >>> We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>> never thought we'd see anything better until we experienced OpenVMS on >>> Alpha. >> >>Let's not revise history, VMS on Alpha was never quite the same as on VAX, >>a lot was lost in the gratuitous migration >> > A lot of software was lost (and was made worse by DEC then selling of lots of > software which was ported) but the transition to Alpha wasn't gratuitous. > VAX performance even with the best efforts of the Digital engineers just > couldn't keep up with the competition. Sadly, we will never know, but I would be most interested in what the performance of a VAX (or a PDP-11, for that matter) made with today's technology (process size, speed-ups, etc.) would be. 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, 30 Oct 2007 10:45:18 -0400 From: "Richard B. Gilbert" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <4727437E.7060900@comcast.net> Bill Gunshannon wrote: > In article , > david20@alpha2.mdx.ac.uk writes: > >>In article , "Tom Linden" writes: >> >>>On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >>>wrote: >>> >>> >>>>We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>>>never thought we'd see anything better until we experienced OpenVMS on >>>>Alpha. >>> >>>Let's not revise history, VMS on Alpha was never quite the same as on VAX, >>>a lot was lost in the gratuitous migration >>> >> >>A lot of software was lost (and was made worse by DEC then selling of lots of >>software which was ported) but the transition to Alpha wasn't gratuitous. >>VAX performance even with the best efforts of the Digital engineers just >>couldn't keep up with the competition. > > > Sadly, we will never know, but I would be most interested in what the > performance of a VAX (or a PDP-11, for that matter) made with today's > technology (process size, speed-ups, etc.) would be. > > bill > That's one of those things that we will probably never know. Do consider, however, the fact that RISC architectures are generally faster than CISC. ------------------------------ Date: Tue, 30 Oct 2007 15:10:29 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: Richard B. Gilbert wrote: > Bill Gunshannon wrote: >> In article , >> david20@alpha2.mdx.ac.uk writes: >> >>> In article , "Tom Linden" >>> writes: >>> >>>> On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >>>> wrote: >>>> >>>> >>>>> We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>>>> never thought we'd see anything better until we experienced OpenVMS on >>>>> Alpha. >>>> >>>> Let's not revise history, VMS on Alpha was never quite the same as >>>> on VAX, >>>> a lot was lost in the gratuitous migration >>>> >>> >>> A lot of software was lost (and was made worse by DEC then selling of >>> lots of software which was ported) but the transition to Alpha wasn't >>> gratuitous. VAX performance even with the best efforts of the Digital >>> engineers just couldn't keep up with the competition. >> >> >> Sadly, we will never know, but I would be most interested in what the >> performance of a VAX (or a PDP-11, for that matter) made with today's >> technology (process size, speed-ups, etc.) would be. >> bill >> > > That's one of those things that we will probably never know. > > Do consider, however, the fact that RISC architectures are generally > faster than CISC. > And the the current VAX *emulators* runs faster then any VAX *hardware* ever did. If I understand correctly... ------------------------------ Date: 30 Oct 2007 15:12:19 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <5oovujFnvtu4U3@mid.individual.net> In article <4727437E.7060900@comcast.net>, "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> In article , >> david20@alpha2.mdx.ac.uk writes: >> >>>In article , "Tom Linden" writes: >>> >>>>On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >>>>wrote: >>>> >>>> >>>>>We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>>>>never thought we'd see anything better until we experienced OpenVMS on >>>>>Alpha. >>>> >>>>Let's not revise history, VMS on Alpha was never quite the same as on VAX, >>>>a lot was lost in the gratuitous migration >>>> >>> >>>A lot of software was lost (and was made worse by DEC then selling of lots of >>>software which was ported) but the transition to Alpha wasn't gratuitous. >>>VAX performance even with the best efforts of the Digital engineers just >>>couldn't keep up with the competition. >> >> >> Sadly, we will never know, but I would be most interested in what the >> performance of a VAX (or a PDP-11, for that matter) made with today's >> technology (process size, speed-ups, etc.) would be. >> > > That's one of those things that we will probably never know. > > Do consider, however, the fact that RISC architectures are generally > faster than CISC. Yes, they are. But, what of EPIC? The target is no longer Alpha. 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: 30 Oct 2007 15:15:34 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <5op04lFnvtu4U4@mid.individual.net> In article , Jan-Erik Söderholm writes: > Richard B. Gilbert wrote: >> Bill Gunshannon wrote: >>> In article , >>> david20@alpha2.mdx.ac.uk writes: >>> >>>> In article , "Tom Linden" >>>> writes: >>>> >>>>> On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >>>>> wrote: >>>>> >>>>> >>>>>> We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>>>>> never thought we'd see anything better until we experienced OpenVMS on >>>>>> Alpha. >>>>> >>>>> Let's not revise history, VMS on Alpha was never quite the same as >>>>> on VAX, >>>>> a lot was lost in the gratuitous migration >>>>> >>>> >>>> A lot of software was lost (and was made worse by DEC then selling of >>>> lots of software which was ported) but the transition to Alpha wasn't >>>> gratuitous. VAX performance even with the best efforts of the Digital >>>> engineers just couldn't keep up with the competition. >>> >>> >>> Sadly, we will never know, but I would be most interested in what the >>> performance of a VAX (or a PDP-11, for that matter) made with today's >>> technology (process size, speed-ups, etc.) would be. >>> bill >>> >> >> That's one of those things that we will probably never know. >> >> Do consider, however, the fact that RISC architectures are generally >> faster than CISC. >> > > And the the current VAX *emulators* runs faster then any > VAX *hardware* ever did. If I understand correctly... But the question is would that hold true if the VAX were being manufactured in today'sa technology? The very existence of VAX emulators (the commercial ones) proves that after all this time there is still a need and a desire to have the VAX architecture around. And we need not even go into how many PDP-11 systems both real and emulated are still in operation as well. 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, 30 Oct 2007 08:28:25 -0700 From: "Tom Linden" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: On Tue, 30 Oct 2007 06:45:51 -0700, wrote: > A lot of software was lost (and was made worse by DEC then selling of > lots of > software which was ported) but the transition to Alpha wasn't gratuitous. > VAX performance even with the best efforts of the Digital engineers just > couldn't keep up with the competition. Rubbish, they didn't try. Notice the clock speed on z hardware or x86? Yes, I have read Hennessy's paper on the VAX, and I don't agree, based on a number of assumptions, likely to justify the mips approach, and don't forget they sold a piece to DEC, after that paper. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 30 Oct 2007 08:30:06 -0700 From: "Tom Linden" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: On Tue, 30 Oct 2007 07:45:18 -0700, Richard B. Gilbert wrote: > Do consider, however, the fact that RISC architectures are generally > faster than CISC. > Not completely true. For simple things yes. Alpha had a 3:1 bloat factor over VAX -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 30 Oct 2007 11:02:11 -0500 From: Ron Johnson Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <8AIVi.613$3X.476@newsfe19.lga> On 10/30/07 08:45, david20@alpha2.mdx.ac.uk wrote: > In article , "Tom Linden" writes: >> On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >> wrote: >> >>> We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>> never thought we'd see anything better until we experienced OpenVMS on >>> Alpha. >> Let's not revise history, VMS on Alpha was never quite the same as on VAX, >> a lot was lost in the gratuitous migration >> > A lot of software was lost (and was made worse by DEC then selling of lots of > software which was ported) but the transition to Alpha wasn't gratuitous. > VAX performance even with the best efforts of the Digital engineers just > couldn't keep up with the competition. Too bad that CISC-over-RISC came after the Alpha was designed... -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Tue, 30 Oct 2007 12:04:18 -0400 From: "Richard B. Gilbert" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <47275602.8030809@comcast.net> Tom Linden wrote: > On Tue, 30 Oct 2007 07:45:18 -0700, Richard B. Gilbert > wrote: > >> Do consider, however, the fact that RISC architectures are generally >> faster than CISC. >> > Not completely true. For simple things yes. Alpha had a 3:1 bloat > factor over VAX > > Alpha's generally needed at least three times as much RAM as a VAX to run the same software. That was because the executables contained more instructions. We still got a VERY nice speed up! The VAX architecture was very programmer friendly. The Alpha is less so if you program in machine language. That's not that big a disadvantage because very few of us get down to the bare metal or want to. Most of us just want to get our prompts back in seconds instead of minutes! I have a VAXstation 4000/VLC and a MicroVAX 3100. I haven't booted either one in years because I also have an Alphastation 200 and an Alphastation 600. I use one of the Alphas when I want a VMS prompt! ------------------------------ Date: Tue, 30 Oct 2007 17:34:05 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: In article <5op04lFnvtu4U4@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >In article , > Jan-Erik Söderholm writes: >> Richard B. Gilbert wrote: >>> Bill Gunshannon wrote: >>>> In article , >>>> david20@alpha2.mdx.ac.uk writes: >>>> >>>>> In article , "Tom Linden" >>>>> writes: >>>>> >>>>>> On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >>>>>> wrote: >>>>>> >>>>>> >>>>>>> We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>>>>>> never thought we'd see anything better until we experienced OpenVMS on >>>>>>> Alpha. >>>>>> >>>>>> Let's not revise history, VMS on Alpha was never quite the same as >>>>>> on VAX, >>>>>> a lot was lost in the gratuitous migration >>>>>> >>>>> >>>>> A lot of software was lost (and was made worse by DEC then selling of >>>>> lots of software which was ported) but the transition to Alpha wasn't >>>>> gratuitous. VAX performance even with the best efforts of the Digital >>>>> engineers just couldn't keep up with the competition. >>>> >>>> >>>> Sadly, we will never know, but I would be most interested in what the >>>> performance of a VAX (or a PDP-11, for that matter) made with today's >>>> technology (process size, speed-ups, etc.) would be. >>>> bill >>>> >>> >>> That's one of those things that we will probably never know. >>> >>> Do consider, however, the fact that RISC architectures are generally >>> faster than CISC. >>> >> >> And the the current VAX *emulators* runs faster then any >> VAX *hardware* ever did. If I understand correctly... > >But the question is would that hold true if the VAX were being >manufactured in today'sa technology? You would need to find someway to produce RISC like instructions from the VAX instructions and pass them to a RISC core (as modern x86 processors do) only then can you start looking at optimisations such as out of order execution. As I recall discussions on this subject in comp.arch concluded that this would be more difficult for the VAX instruction set than for the x86 instruction set. Yes with modern chip manufacturing you would get a faster VAX than any which was ever manufactured but Power and other RISC architectures would still be much faster. David Webb Security team leader CCSS Middlesex University >The very existence of VAX >emulators (the commercial ones) proves that after all this time >there is still a need and a desire to have the VAX architecture >around. And we need not even go into how many PDP-11 systems >both real and emulated are still in operation as well. > >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: 30 Oct 2007 17:41:58 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <5op8n6Fnkn47U1@mid.individual.net> In article , david20@alpha2.mdx.ac.uk writes: > In article <5op04lFnvtu4U4@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>In article , >> Jan-Erik Söderholm writes: >>> Richard B. Gilbert wrote: >>>> Bill Gunshannon wrote: >>>>> In article , >>>>> david20@alpha2.mdx.ac.uk writes: >>>>> >>>>>> In article , "Tom Linden" >>>>>> writes: >>>>>> >>>>>>> On Mon, 29 Oct 2007 19:35:30 -0700, Neil Rieck >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> We welcomed the move from RSX-11M on PDP-11/44 to go to VMS on VAX but >>>>>>>> never thought we'd see anything better until we experienced OpenVMS on >>>>>>>> Alpha. >>>>>>> >>>>>>> Let's not revise history, VMS on Alpha was never quite the same as >>>>>>> on VAX, >>>>>>> a lot was lost in the gratuitous migration >>>>>>> >>>>>> >>>>>> A lot of software was lost (and was made worse by DEC then selling of >>>>>> lots of software which was ported) but the transition to Alpha wasn't >>>>>> gratuitous. VAX performance even with the best efforts of the Digital >>>>>> engineers just couldn't keep up with the competition. >>>>> >>>>> >>>>> Sadly, we will never know, but I would be most interested in what the >>>>> performance of a VAX (or a PDP-11, for that matter) made with today's >>>>> technology (process size, speed-ups, etc.) would be. >>>>> bill >>>>> >>>> >>>> That's one of those things that we will probably never know. >>>> >>>> Do consider, however, the fact that RISC architectures are generally >>>> faster than CISC. >>>> >>> >>> And the the current VAX *emulators* runs faster then any >>> VAX *hardware* ever did. If I understand correctly... >> > >>But the question is would that hold true if the VAX were being >>manufactured in today'sa technology? > > You would need to find someway to produce RISC like instructions from the VAX > instructions and pass them to a RISC core (as modern x86 processors do) > only then can you start looking at optimisations such as out of order execution. > As I recall discussions on this subject in comp.arch concluded that this would > be more difficult for the VAX instruction set than for the x86 instruction > set. > > Yes with modern chip manufacturing you would get a faster VAX than any which > was ever manufactured but Power and other RISC architectures would still be > much faster. Which, of course, does not mean not commercially viable. "Power and other RISC architectures" are all faster than Itanium and yet........ 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, 30 Oct 2007 09:22:32 -0400 From: "Syltrem" Subject: HP *is* celebrating 30 years of OpenVMS Message-ID: <13iec0pecdbckab@corp.supernews.com> I want to thank HP for putting the "Celebrating 30 years of OpenVMS" on their main page. That's great ! And of course I thank everyone that worked on making this 30-years site. Now that it's more properly advertised, I hope the number of visits will raise. I know, some here will not be so happy and find ways to complain, but I think this is the best thing that happened to VMS for a very long time, advertisement-wise. Not only preaching to the choir this time. Happy anniversary VMS ! -- Syltrem http://pages.infinit.net/syltrem (OpenVMS information and help, en français) ------------------------------ Date: Tue, 30 Oct 2007 08:59:43 -0700 From: AEF Subject: Re: HP *is* celebrating 30 years of OpenVMS Message-ID: <1193759983.932237.325750@o3g2000hsb.googlegroups.com> On Oct 30, 9:22 am, "Syltrem" wrote: > I want to thank HP for putting the "Celebrating 30 years of OpenVMS" on > their main page. > > That's great ! > > And of course I thank everyone that worked on making this 30-years site. > Now that it's more properly advertised, I hope the number of visits will > raise. > > I know, some here will not be so happy and find ways to complain, but I > think this is the best thing that happened to VMS for a very long time, > advertisement-wise. Not only preaching to the choir this time. > > Happy anniversary VMS ! > > -- > Syltremhttp://pages.infinit.net/syltrem(OpenVMS information and help, en = fran=E7ais) Happy Anniversary VMS!!! Yep, I just checked: It's still there on the front f------ page! Hooray again! AEF ------------------------------ Date: Tue, 30 Oct 2007 15:17:51 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Newbie directory protection question Message-ID: JF Mezei writes: >VMS is Virus Free wrote: >> Normal protection on the MFD would be (RWE,RWE,RE,E). >Interesting. All my MFDs are at RWED RWED RE E, with owner 1,1. Something added 'delete' permission to the MFD. Owner [1,1] is normal for a disk initialized /SYSTEM. >>>What protection should $disk2:[000000]users.dir have ? >> Same as the just suggested: S:RWE, O:RWE, G:RE, W:E And this is the MFD protection when the disks are initialized. >> Minimal access to USERS.DIR is Execute: you can see the contents of >> this file IF you already know the filename. Sometimes, it makes sense >Thanks. It had been such a long time since I had to dab in directory >security that I wasn't too sure anymore what was needed. For directory files, E allows you to access a file if you know its name, but not do a DIR or wildcard search. R allows a directory/wildcard access as well. W allows you to create files in the directory. D allows the directory itself to be deleted (it must be empty) Personally I find the fact that VMS goes out of its way to remove O:D permission on a directory to be unnecessary (although a MFD should never have delete permission). It makes an additional step necessary to delete a directory/directory tree and is unnecessary (VMS disallows deleting any directory with any contents regarless of protection). It just adds fuel to Unix weenies' gripe that there you need multiple steps to do the equivalent of "rm -rf". ------------------------------ Date: 30 Oct 2007 12:04:09 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Newbie directory protection question Message-ID: In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes: > Personally I find the fact that VMS goes out of its way to remove O:D > permission on a directory to be unnecessary As I understand it, the reason for this is backward compatibility of customer programs. Delete permission was withheld on VMS V1, where such a protection was actually necessary. Since deleting non-empty directories is no longer possible, the protection is not important, but theoretically some existing customer program could go bonkers if it encountered a directory not created with the traditional protection. > (although a MFD should never have delete permission). I don't see why not. It will never be empty (since it always contains itself at the very least), so granting delete permission should not matter. > It just adds fuel to > Unix weenies' gripe that there you need multiple steps to do the > equivalent of "rm -rf". Just tell them that backward compatibility is a prime goal of VMS. The most drastic change I was remember was altering the Backup default to /NOREWIND, because the prior default caused careless users to destroy data. ------------------------------ Date: 30 Oct 2007 09:08:50 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Pathworks vs CIFS performance Message-ID: <4726f4a2$1@news.langstoeger.at> In article , Malcolm Dunnett writes: >VMS is Virus Free wrote: >> Do you know if you can run both Pathworks and CIFS at the same time? >> If so, this might allow a second path to VMS files from Windows, >> effectly doubling the bandwidth since both Pathworks and CIFS are tied >> to the max performance of a single CPU. > >I don't think there's any reasonable way to run SMB on a non-standard >port - so I'd say the answer is no, only one server could listen on that >port at a time. It *may* work if you find a way to use different IP addresses (but the same TCP port) for the different packages on the same node. But as long as every one of the 2 packages binds to all addresses (0.0.0.0) you're SOL... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Tue, 30 Oct 2007 07:41:41 -0400 From: "PEN" Subject: Re: Pathworks vs CIFS performance Message-ID: Hi, "VMS is Virus Free" wrote in message news:e552i3h4s9v5v3nlqc254c3gljlncdl1ro@4ax.com... > On Thu, 25 Oct 2007 03:55:47 GMT, "John E. Malmberg" > wrote: > >> >>Pathworks is not single threaded, Pathworks is multi-threaded in a >>single process per cluster. It is far more efficient on CPU resources >>and context switching than the current V3 generation of SAMBA. If you >>are having problems with performance with Pathworks, SAMBA will probably >>not be much better, and possibly will be worse. > > We currently see Pathworks use 100% of one CPU. My guess is that it > was designed before Kernel threads were available. When threading > became available, it was too late or not enough energy left at Digital > to optimize the product to take full advantage of threading. > Otherwise, Pathworks would be able to use more than one CPU. > >>There may be tuning or other issues like disk / file fragmentation that >>are causing the slowdowns you are seeing. > > There are always tuning, umm, "opportunities". AUTOGEN doesn't find > anything. There is ample memory, multiple CPUs. Everything else runs > well, only Pathworks gets bogged down. > > The problems we see stems from Windows desktops accessing files on VMS > when > > (a) the directory being accessed has lots of files (lots = 10K to 100K > files). Many .DIR files are in the 5K to 10K blocks size. DFU on a > directory compress helps but does not offer much relief. > > (b) large files (500 GB to 1 TB) being read/written > > (c) lots of file transfers (both directions) > > Typical scenario is that access is relatively robust then one or more > users start doing some of these activities and slows Pathworks file > access down for everyone. > > The large directory sizes are the results of program design that did > not think through design decisions when decade's worth of file > activity would need to be available online. We cannot change this > behavior. Reason: works okay, bigger fish to fry, no time to go back > and fix an old app. > >>> Any experiences and comments relative to the merits of Pathworks >>> versus CIFS (aka Samba in VMS clothes) would be most appreciated. >> >>I left the SAMBA / VMS project before the various planed performance >>enhancements could be implemented and tested, so I do not know the >>specifics. >> >>The SAMBA V4 design allows a single process similar to Pathworks / >>Advanced Server to be used. I have no idea if it will be more efficient. > > We currently see Pathworks use 100% of one CPU. What we were looking > (hoping) for with CIFS is that the design would make better use of the > available CPU resources in a multi-CPU environment. > > What is sounds like is that CIFS still has a ways to go to catch up to > Pathworks (performance-wise). > >>The SAMBA V1 through V3 model of separate processes has a much higher >>overhead than threads, but provides the appearance of higher reliability >>as a failed process only briefly affects one client until it is >>restarted, where a single process model would affect all clients. >> >>-John >>wb8tyw@qsl.network >>Personal Opinion Only If you're truly running PATHWORKS for OpenVMS and not Advanced Server for OpenVMS then, yes you'll see problems you describe - until you get some patches from HP. If you have Advanced Server for OpenVMS (and to a lesser extent PATHWORKS for OpenVMS) you may benefit from: http://h10025.www1.hp.com/ewfrf/wc/genericDocument?docname=c00596671&cc=us&dlc=en&lc=en&jumpid=reg_R1002_USEN Regards, Paul ------------------------------ Date: Tue, 30 Oct 2007 07:53:34 -0400 From: "PEN" Subject: Re: Pathworks vs CIFS performance Message-ID: Hi, "VMS is Virus Free" wrote in message news:2tabi3hf7escaeptgbn4cd0aj8r7csjtei@4ax.com... > Do you know if you can run both Pathworks and CIFS at the same time? > If so, this might allow a second path to VMS files from Windows, > effectly doubling the bandwidth since both Pathworks and CIFS are tied > to the max performance of a single CPU. Yes, it is possible. PATHWORKS will allocated TCP port 139 and UDP ports 137 and 138 - nothing you can do to "control" that - and PATHWORKS binds to all interfaces - again, nothing you can do about that. But, CIFS supports TCP port 445 too. So if you configure CIFS to use TCP port 445 ONLY (by setting the tcpip smbd service accordingly) and do NOT start the NMBD process you can map drives to both CIFS (over TCP port 445) and PATHWORKS (over TCP port 139). Of course, they cannot share the same file simulataneously - the first to open it wins and the other is going to get a file currently is use error. HTH, Paul ------------------------------ Date: Tue, 30 Oct 2007 08:11:10 -0700 From: mmbrightman@gmail.com Subject: Remote NFS Mounts on OpenVMS Message-ID: <1193757070.450863.232320@t8g2000prg.googlegroups.com> Does anyone know if OpenVMS uses a range of ports when trying to do remote NFS mounts? We're running DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A - ECO 3 on OpenVMS 7.2-1. We're trying to do a remote NFS mount over our WAN and it's passing through a firewall which we are currently changing each time we need to remount these drives, because it continually picks a different port to use. This is the command we are using for the NFS mounts: UCX MOUNT DNFS25:[000000] /HOST="PRODNFS.ARGUS.DSTSYS.COM" - /PATH="/oti_nfs/reports" Any suggestions would be appreciated. ------------------------------ End of INFO-VAX 2007.594 ************************