INFO-VAX Wed, 15 Aug 2007 Volume 2007 : Issue 445 Contents: Re: Backup save set compression Re: Backup save set compression Re: Backup save set compression RE: Computerworld article Re: Free to good home. Microvaxes, Vaxstations, Alphas Re: How to detect duplicate auto-resubmiting batch job Re: How to detect duplicate auto-resubmiting batch job Re: How to detect duplicate auto-resubmiting batch job Re: How to detect duplicate auto-resubmiting batch job Re: How to detect duplicate auto-resubmiting batch job Re: How to detect duplicate auto-resubmiting batch job Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? RE: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Is this Address really Illegal? Re: Node & Port allocation classes on a new cluster Re: Node & Port allocation classes on a new cluster Re: Node & Port allocation classes on a new cluster Re: Node & Port allocation classes on a new cluster Re: Node & Port allocation classes on a new cluster Re: Oldest Alpha for upgrade to Integrity Re: Oldest Alpha for upgrade to Integrity Re: Oldest Alpha for upgrade to Integrity SSSU - Version 6 - script error Update going out on Thursday Re: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion ---------------------------------------------------------------------- Date: Tue, 14 Aug 2007 11:03:51 -0700 From: AEF Subject: Re: Backup save set compression Message-ID: <1187114631.185768.195520@22g2000hsm.googlegroups.com> On Aug 14, 1:35 pm, Jur van der Burg <"lddriver at digiater dot nl"> wrote: > > What's wrong here? > > There's probably a record of less than 14 bytes in lenght in the file, > and the VMS i/o subsystems rejects that for tapes. And yes, that's > documented. > > Talking about data compression, there's a big gotcha when you use it. > > If you create a compressed saveset on disk, and copy it to another system > with ftp (binary copy), and copy it back you can't restore it. The records > for a compressed saveset are now variable length, Really? 8-0 (!) Do you get the same number of records with and without compress? > and ftp has a problem with > that in binary mode. I'd bet! > And if you use text mode you will get a problem for > sure. Also, after restoring, backup/repair does not know how to handle > compressed savesets. What about RESET_BACKUP_SAVESET_ATTRIBUTES.COM? Did you try that? > I ended up doing a 'set file/attr=(rfm=fix,rat=none,mrs=512,lrl=512)' on > the saveset before copying, and a 'set file/attr=(rfm=var,rat=none,mrs=32256,lrl=32256)' > when I want to restore it. With TCPWARE FTP you can do SET DEFAULT/IMAGE=32256 ! Preserve default BACKUP save-set record size. to preserve the record length. But I don't think it will help with your variable-record-length compressed save sets. > I found this out when testing backup procedures. You see, anyone can create a > backup, but restoring is another art. Testing if you can reaaly restore it > may pay off! Yep! You have to test your restore procedures! AEF [...] ------------------------------ Date: Tue, 14 Aug 2007 19:54:29 -0400 From: "Carl Friedberg" Subject: Re: Backup save set compression Message-ID: <890539d90708141654s71083565y9e65206bd1a238e7@mail.gmail.com> >My question -...how reliable is the output save set? Using the 8.3 Distribution media with standalone backup, you cannot restore an image backup if you created the saveset in compressed format. Be sure to build a suitable bootable disk on another volume to avoid this issue.I have been playing with this, and so far, it appears to work as not documented :-) Carl ------------------------------ Date: Wed, 15 Aug 2007 02:22:52 +0300 From: "Guy Peleg" Subject: Re: Backup save set compression Message-ID: <46c22d35$0$16397$88260bb3@free.teranews.com> "Jur van der Burg" <"lddriver at digiater dot nl"> wrote in message news:46c1e7ff$0$241$e4fe514c@news.xs4all.nl... > > What's wrong here? > > There's probably a record of less than 14 bytes in lenght in the file, > and the VMS i/o subsystems rejects that for tapes. And yes, that's > documented. > > Talking about data compression, there's a big gotcha when you use it. > > If you create a compressed saveset on disk, and copy it to another system > with ftp (binary copy), and copy it back you can't restore it. The records > for a compressed saveset are now variable length, and ftp has a problem > with > that in binary mode. And if you use text mode you will get a problem for > sure. Also, after restoring, backup/repair does not know how to handle > compressed savesets. > > I ended up doing a 'set file/attr=(rfm=fix,rat=none,mrs=512,lrl=512)' on > the saveset before copying, and a 'set > file/attr=(rfm=var,rat=none,mrs=32256,lrl=32256)' > when I want to restore it. Jur - That's documented in my utilities presentation. > > I found this out when testing backup procedures. You see, anyone can > create a > backup, but restoring is another art. Testing if you can reaaly restore it > may pay off! > > Jur. > > > Scott Greig wrote: >> "Guy Peleg" wrote in message >> news:46c17fb5$0$16340$88260bb3@free.teranews.com... >>> "Scott Greig" wrote in message >>> news:f9pru1$2gei$1@sxnews1.qg.com... >>>> Hello all: >>>> >>>> The Alpha 8.3 patch site lists a new Backup patch >>>> (VMS83A_BACKUP-V0300) that describes a fix >>>> for a problem concerning the use of the /Journal >>>> switch and the /Data_Format=Compressed switch. >>>> >>>> The /Data_Format switch???!!!??? >>> This is a mistake. /DATA_FORMAT=COMPRESS should not have been >>> documented. It is very reliable, and as mentioned by Ian, it uses >>> ZLIB as the compression engine. It has one major limitation, it can >>> only compress savesets when writing to disks. Writing compressed >>> savesets >>> to Tapes is not supported. >> >> Further to this - it seems that I cannot even $ COPY the saveset >> to a tape - I get >> >> $ dir/fu sys$sysdevice:[000000]qq.bck >> Directory SYS$SYSDEVICE:[000000] >> QQ.BCK;1 File ID: (6180,230,0) >> Size: 8364/8365 Owner: [1,1] >> Created: 14-AUG-2007 11:18:28.79 >> Revised: 14-AUG-2007 11:18:37.99 (1) >> Expires: >> Backup: >> Effective: >> Recording: >> Accessed: >> Attributes: >> Modified: >> Linkcount: 1 >> File organization: Sequential >> Shelved state: Online >> Caching attribute: No_caching >> File attributes: Allocation: 8365, Extend: 0, Global buffer count: 0 >> No version limit >> Record format: Variable length, maximum 32256 bytes, longest 32256 bytes >> Record attributes: None >> RMS attributes: None >> Journaling enabled: None >> File protection: System:RWED, Owner:RWED, Group:, World: >> Access Cntrl List: None >> Client attributes: None >> Total of 1 file, 8364/8365 blocks. >> $ init mka600: save/media=compact >> $ mount mka600: save/media=compact >> %MOUNT-I-MOUNTED, SAVE mounted on _GEMAXP$MKA600: >> $ copy sys$sysdevice:[000000]qq.bck mka600:/log >> %COPY-E-OPENOUT, error opening MKA600:[SCOTT.CLIENTS.DND]QQ.BCK;1 as >> output >> -RMS-E-CRE, ACP file create failed >> -SYSTEM-F-BADATTRIB, bad attribute control list >> %COPY-W-NOTCOPIED, SYS$SYSDEVICE:[000000]QQ.BCK;1 not copied >> >> What's wrong here? >> >> Scott >> >>> .... and AFAIK, VMS engineering use it. >>>> So, I tried it out - and achieved a 67% compression >>>> rate for the output save set (138087 blocks with >>>> compression, 412461 blocks without.) >>>> >>>> HELP BACKUP does not mention this switch. >>>> >>>> My question - when was this implemented, and >>>> how reliable is the output save set? >>> Introduced with OpenVMS V8.3. It's an undocumented >>> feature....use it at your own risk. >>> >>>> Cheers, >>>> Scott >>>> >>>> >>>> >>> >>> >>> -- >>> Posted via a free Usenet account from http://www.teranews.com >>> >> -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Tue, 14 Aug 2007 22:50:20 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: RE: Computerworld article Message-ID: > Extract - "As OpenVMS nears 30, users dredge up videos from DEC's heyday > Old clips get posted online to mark operating system's upcoming anniversary= > " I guess one would play them in the tape DEC. :-| ------------------------------ Date: 14 Aug 2007 19:37:52 -0400 From: Rich Alderson Subject: Re: Free to good home. Microvaxes, Vaxstations, Alphas Message-ID: Robert Deininger writes: > In article <130820072054094448%nospam@yrl.co.uk>, > Elliott Roper wrote: >> Everyone who covets a free Vax heap can speak that much teco, or at any >> rate fake it. > Eh? I've been on VMS for 21 years, and I've NEVER used TECO. It's never too late. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ Date: Tue, 14 Aug 2007 17:13:35 -0400 From: "Richard B. Gilbert" Subject: Re: How to detect duplicate auto-resubmiting batch job Message-ID: <46C21AFF.8020203@comcast.net> vancouvercancun@yahoo.ca wrote: > Hi everybody > I have a auto-resubmiting daily disk cleaning job. It is submitted at > startup and should be resubmitting itself after running every day at > 8h00. Yesterday, I noticed I now have 3 entries for the same job, all > waiting to execute at the same time. Notwithstanding the fact that > some startup job is submitting the batch more than once(I will need to > find it!), I need to add code to my DCL procedure to verify that only > one job is present. > > What is the usual way to detect that there is only one instance/job/ > batch of the procedure running daily ? What code can I use in DCL to > verify that I have only one version of the batch job present in the > queue ? Can you provide examples ? > > Here is a part of my cleaning.com procedure: > > $ datelog = f$cvtime("tomorrow","comparison","date") > $ submit /queue=sys$batch /noprinter /nonotify /restart /log=my > $log:cleaning-'datelog'.log - > /after="tomorrow+08:" cleaning.com > $ delete my$log:*.log;*/cre/before=today-30-0 > $ ... > > Yesterday, I had 3 entries waiting to execute at 8h00. I would like > entries 2 and 3 to kill themselves if there is already a same job > present in the queue. Notice all 3 will be begin executing in the same > split second. > Suggestions ? Examples ? Links to code ? > TIA > Van > $ HELP SET PROCESS /NAME No two processes can have the same name so when the second process executes SET PROCESS /NAME, it will fail. ------------------------------ Date: Tue, 14 Aug 2007 14:52:50 -0700 From: Doug Phillips Subject: Re: How to detect duplicate auto-resubmiting batch job Message-ID: <1187128370.029258.92120@x40g2000prg.googlegroups.com> On Aug 14, 3:15 pm, vancouvercan...@yahoo.ca wrote: > Hi everybody > I have a auto-resubmiting daily disk cleaning job. It is submitted at > startup and should be resubmitting itself after running every day at > 8h00. Yesterday, I noticed I now have 3 entries for the same job, all > waiting to execute at the same time. Notwithstanding the fact that > some startup job is submitting the batch more than once(I will need to > find it!), I need to add code to my DCL procedure to verify that only > one job is present. > > What is the usual way to detect that there is only one instance/job/ > batch of the procedure running daily ? What code can I use in DCL to > verify that I have only one version of the batch job present in the > queue ? Can you provide examples ? > > Here is a part of my cleaning.com procedure: > > $ datelog = f$cvtime("tomorrow","comparison","date") > $ submit /queue=sys$batch /noprinter /nonotify /restart /log=my > $log:cleaning-'datelog'.log - > /after="tomorrow+08:" cleaning.com > $ delete my$log:*.log;*/cre/before=today-30-0 > $ ... > > Yesterday, I had 3 entries waiting to execute at 8h00. I would like > entries 2 and 3 to kill themselves if there is already a same job > present in the queue. Notice all 3 will be begin executing in the same > split second. > Suggestions ? Examples ? Links to code ? > TIA > Van To me, this looks like a problem I'd want to know about. Something is not working. You can use the F$GETQUI lexical to get information about jobs in the queue, or you can do something like the following (which predates the pipe command as well as f$getqui, but like they say, if it ain't broke...): $ $ SHOW QUE /ALL /OUT=SYS$SCRATCH:a_b_temp.tmp SYS$BATCH $ SEARCH /NOOUTP /NOWARN SYS$SCRATCH:a_b_temp.tmp IMPORTANT_JOB $ save_status = $STATUS $ DELETE SYS$SCRATCH:a_b_temp.tmp;* $ if save_status .eqs. "%X00000001" $ then $ WRITE SYS$OUTPUT "IMPORTANT_JOB is already submitted." $ goto QUIT $ endif It would be easy to change this to use pipe, or you could learn about the strange-workings of F$GETQUI. Building a unique .tmp file name has also been left as an exercise. You can put your similar logic in the com file's scheduler, or in the com file itself to keep it from submitting/starting a duplicate job and to tell you there's a problem. ------------------------------ Date: Tue, 14 Aug 2007 22:55:11 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: How to detect duplicate auto-resubmiting batch job Message-ID: In article <1187122509.791422.293350@l22g2000prc.googlegroups.com>, vancouvercancun@yahoo.ca writes: > What is the usual way to detect that there is only one instance/job/ > batch of the procedure running daily ? What code can I use in DCL to > verify that I have only one version of the batch job present in the > queue ? Can you provide examples ? Before the job resubmits itself, it should check whether a job of the same name is already submitted and on hold, i.e. a job of the same name other than itself. Also, it might be a good idea to have a very basic batch job which essentially just resubmits itself and calls the main procedure. That way, if you change the main procedure, you don't have to resubmit the batch job. ------------------------------ Date: Tue, 14 Aug 2007 22:56:56 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: How to detect duplicate auto-resubmiting batch job Message-ID: In article <46C21AFF.8020203@comcast.net>, "Richard B. Gilbert" writes: > $ HELP SET PROCESS /NAME > > No two processes can have the same name so when the second process > executes SET PROCESS /NAME, it will fail. On the same node. If he submits to a generic queue, with execution queues on different nodes, then he could have as many processes as nodes. If the entry is retained on error, he still has to do manual cleanup. If not, he might miss real errors. ------------------------------ Date: Tue, 14 Aug 2007 19:59:33 -0500 From: David J Dachtera Subject: Re: How to detect duplicate auto-resubmiting batch job Message-ID: <46C24FF5.C9D3458B@spam.comcast.net> vancouvercancun@yahoo.ca wrote: > > Hi everybody > I have a auto-resubmiting daily disk cleaning job. It is submitted at > startup and should be resubmitting itself after running every day at > 8h00. Yesterday, I noticed I now have 3 entries for the same job, [snip] DCSC$STARTUP has the same problem... :-( -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 14 Aug 2007 21:33:54 -0500 From: Ron Johnson Subject: Re: How to detect duplicate auto-resubmiting batch job Message-ID: On 08/14/07 15:15, vancouvercancun@yahoo.ca wrote: > Hi everybody > I have a auto-resubmiting daily disk cleaning job. It is submitted at > startup and should be resubmitting itself after running every day at > 8h00. Yesterday, I noticed I now have 3 entries for the same job, all > waiting to execute at the same time. Notwithstanding the fact that > some startup job is submitting the batch more than once(I will need to > find it!), I need to add code to my DCL procedure to verify that only > one job is present. > > What is the usual way to detect that there is only one instance/job/ > batch of the procedure running daily ? What code can I use in DCL to > verify that I have only one version of the batch job present in the > queue ? Can you provide examples ? > > Here is a part of my cleaning.com procedure: > > $ datelog = f$cvtime("tomorrow","comparison","date") > $ submit /queue=sys$batch /noprinter /nonotify /restart /log=my > $log:cleaning-'datelog'.log - > /after="tomorrow+08:" cleaning.com > $ delete my$log:*.log;*/cre/before=today-30-0 > $ ... > > Yesterday, I had 3 entries waiting to execute at 8h00. I would like > entries 2 and 3 to kill themselves if there is already a same job > present in the queue. Notice all 3 will be begin executing in the same > split second. > Suggestions ? Examples ? Links to code ? Pony up for CA-SCHEDULER (or whatever it's called now). -- 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, 14 Aug 2007 12:15:56 -0700 From: "Tom Linden" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On Tue, 14 Aug 2007 10:33:17 -0700, FredK wrote: > Golly. OK. So should it be POWER? Or SPARC? That HP-UX ports to? I was only thinking about the technical aspect, having myself ported similar styled Unix (BSD4.x) a couple of times before. But you are quite right they really don't have any options. It would appear HP really did bet the farm on IA64. X86 doesn't have support beyond the byte swap instructions? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 14 Aug 2007 15:38:59 -0400 From: "FredK" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: "Tom Linden" wrote in message news:op.tw2c4utdhv4qyg@murphus.linden... > On Tue, 14 Aug 2007 10:33:17 -0700, FredK wrote: > >> Golly. OK. So should it be POWER? Or SPARC? That HP-UX ports to? > > I was only thinking about the technical aspect, having myself ported > similar styled Unix (BSD4.x) a couple of times before. > > But you are quite right they really don't have any options. It would > appear HP really did bet the farm on IA64. X86 doesn't have support > beyond the > byte swap instructions? > Yup. That is my point. Without reviving Alpha or PA RISC and going back into the FAB business to stay competetive - HP-UX needs to use Itanium *or* one of HPs competetors chips. SPARC which is well on its way to the grave. Or POWER - noticed how IBM appears to be hiding how much they make/lose on the chip business? It is very, very expensive to maintain the ability to design and FAB your own chips with cutting edge processes. For various degrees of difficulty and performance - VMS "could" run on any of the 64-bit chips out there... at a considerable expense and time cost. ------------------------------ Date: Tue, 14 Aug 2007 20:25:57 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: Keith Parris writes: >David J Dachtera wrote: >> It now appears there never was an intent to continue VMS past Itanic. >I've seen public statements that the work done for the Itanium port >makes future ports easier, and even that HP _expects_ to port to other >architectures in the future -- that's just the way things go: whole new >sets of CPU architectures/technology arise in the industry every decade >or so. In the process of porting from VAX to Alpha, they designed Alpha VMS to be very easy to port to something else. It worked, too. Alpha and Itanium VMS are built from a common source with relatively few architecture specific modules/pieces of code. It's not unreasonable to port VMS to something else in the future - IF HP actually wanted to. IF. ------------------------------ Date: Tue, 14 Aug 2007 13:27:48 -0700 From: "Tom Linden" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On Tue, 14 Aug 2007 12:38:59 -0700, FredK wrote: > > "Tom Linden" wrote in message > news:op.tw2c4utdhv4qyg@murphus.linden... >> On Tue, 14 Aug 2007 10:33:17 -0700, FredK wrote: >> >>> Golly. OK. So should it be POWER? Or SPARC? That HP-UX ports to? >> >> I was only thinking about the technical aspect, having myself ported >> similar styled Unix (BSD4.x) a couple of times before. >> >> But you are quite right they really don't have any options. It would >> appear HP really did bet the farm on IA64. X86 doesn't have support >> beyond the >> byte swap instructions? >> > > Yup. That is my point. Without reviving Alpha or PA RISC and going back > into the FAB business to stay competetive - HP-UX needs to use Itanium > *or* > one of HPs competetors chips. SPARC which is well on its way to the > grave. > Or POWER - noticed how IBM appears to be hiding how much they make/lose > on > the chip business? It is very, very expensive to maintain the ability to > design and FAB your own chips with cutting edge processes. The economy of scale is better for IBM than it would have been with Alpha. The i- and p- series both enjoy the same chip, and the core is shared with z-series, I believe. Just out of curiosity when the pitch was being made to go with Alpha I am sure that these people were smart enough to be able to project the future costs of maintaining a competitive architecture, and as I recall, NT was the convincing factor. It would seem to me that any kind of seasoned management would see how risky that was particularly since, I am sure they were likewise able to estimate the reduction to the customer base would ensue. I met some of those folks years ago, and they certainly weren't Rubes. Not sure how the economics would have shaken out, had DEC gone fabless. Of course, you know my viewpoint, whatever was built should have been backward compatible with 32bit VAX just as IBM has done with z > > For various degrees of difficulty and performance - VMS "could" run on > any > of the 64-bit chips out there... at a considerable expense and time cost. > > > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 14 Aug 2007 20:55:42 +0000 From: "Main, Kerry" Subject: RE: Intel marginalizing Itanium even faster than expected? Message-ID: > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: August 14, 2007 1:15 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Intel marginalizing Itanium even faster than expected? > > On 08/14/07 09:39, Tom Linden wrote: > > On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris > > wrote: > > > >> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so > >> eliminating Itanium would eliminate the HP-UX platform too. Better > >> find a better hypothesis. > > > > I imagine that it would not be too difficult to port HP-UX to another > > platform > > I think it would be simpler to harden & add features to Linux (both > kernel and userland). > > -- And how would you propose that HP do this when it does not own or control t= he kernel? Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: 14 Aug 2007 22:03:04 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: <5ien4oF3nt1rmU1@mid.individual.net> In article , "Main, Kerry" writes: >> -----Original Message----- >> From: Ron Johnson [mailto:ron.l.johnson@cox.net] >> Sent: August 14, 2007 1:15 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: Intel marginalizing Itanium even faster than expected? >> >> On 08/14/07 09:39, Tom Linden wrote: >> > On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris >> > wrote: >> > >> >> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so >> >> eliminating Itanium would eliminate the HP-UX platform too. Better >> >> find a better hypothesis. >> > >> > I imagine that it would not be too difficult to port HP-UX to another >> > platform >> >> I think it would be simpler to harden & add features to Linux (both >> kernel and userland). >> >> -- > > And how would you propose that HP do this when it does not own or control t= > he kernel? One needn't own the kernel to make their own release. HP-UX is not Linux compatable now so why would it matter if the replacement flavor of Linux was not compatable with others? Of course, they could always forget about Linux and go with BSD where they are truly free to do whatever they wish. And they can even keep their significant additons proprietary if they want. Just like HP-UX. :-) 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, 14 Aug 2007 15:14:10 -0700 From: Doug Phillips Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: <1187129650.698308.294740@m37g2000prh.googlegroups.com> On Aug 14, 3:25 pm, moro...@world.std.spaamtrap.com (Michael Moroney) wrote: > Keith Parris writes: > >David J Dachtera wrote: > >> It now appears there never was an intent to continue VMS past Itanic. > >I've seen public statements that the work done for the Itanium port > >makes future ports easier, and even that HP _expects_ to port to other > >architectures in the future -- that's just the way things go: whole new > >sets of CPU architectures/technology arise in the industry every decade > >or so. > > In the process of porting from VAX to Alpha, they designed Alpha VMS to be > very easy to port to something else. It worked, too. Alpha and Itanium > VMS are built from a common source with relatively few architecture > specific modules/pieces of code. It's not unreasonable to port VMS to > something else in the future - IF HP actually wanted to. IF. I think this Technical Journal article should be required reading for anyone discussing the Alpha->Itanium port: if above wraps, use: "Overview This article describes the 3.5 years of work that went into porting OpenVMS to Integrity Servers. A little history, the rationale behind the major decisions, and some technical details are combined to present the engineering that resulted in OpenVMS I64 V8.2. First there is a chronology of the major events and decisions of the project. The concluding sections provide details of some of the technology that we found the most interesting and challenging and how they came together to produce the preliminary and final releases. ..." You'll notice that lots of time went into tool-building, and the fact that *nix was already ported to IA was more than a little helpful. ------------------------------ Date: Tue, 14 Aug 2007 19:49:28 -0500 From: David J Dachtera Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: <46C24D98.84FDC435@spam.comcast.net> Keith Parris wrote: > > David J Dachtera wrote: > > It now appears there never was an intent to continue VMS past Itanic. > > I've seen public statements that the work done for the Itanium port > makes future ports easier, and even that HP _expects_ to port to other > architectures in the future -- that's just the way things go: whole new > sets of CPU architectures/technology arise in the industry every decade > or so. > > > HP's > > intent was to supplant VMS with UX and the only way to do that was to eliminate > > VMS's operating platforms: first Alpha as a condition of the Compaq merger, now > > Itanic, apparently the hidden part of agenda. > > There's a fatal flaw in this logic: HP-UX runs on Itanium too, so > eliminating Itanium would eliminate the HP-UX platform too. Better find > a better hypothesis. :-) Try again. See the "binary Compatibility" page: http://www.intel.com/cd/ids/developer/asmo-na/eng/technologies/64bit/170114.htm?page=4 (URL is likely to have wrapped) "Interestingly, binaries for Hewlett-Packard's PA-RISC architecture can also be run without modification. To run these binaries, sites must use Aries* software that HP will bundle with all its systems. Aries performs two primary functions: it performs dynamic translation of PA-RISC binaries into native 64-bit processor instructions for immediate execution, and it performs interpretation of other, lesser- used PA-RISC commands" ..., ostensibly a form of "PEST" (PA-RISC Executable (S?) Translation) for PA-RISC executables. So, porting to EM64T is likely to not be a huge issue for UX, except perhaps where "endianness" is concerned. That could pose a challenge, I suppose, unless the difference can be made up in software without a significant performance hit (remember MicroVAXes and VAX floating point?). Since HP does not properly understand "business needs", however, the probability of a VMS port to EM64T is effectively nil. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 14 Aug 2007 21:42:48 -0500 From: Ron Johnson Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On 08/14/07 15:55, Main, Kerry wrote: >> -----Original Message----- From: Ron Johnson >> [mailto:ron.l.johnson@cox.net] Sent: August 14, 2007 1:15 PM >> To: Info-VAX@Mvb.Saic.Com Subject: Re: Intel marginalizing >> Itanium even faster than expected? >> >> On 08/14/07 09:39, Tom Linden wrote: >>> On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris >>> wrote: >>> >>>> There's a fatal flaw in this logic: HP-UX runs on Itanium >>>> too, so eliminating Itanium would eliminate the HP-UX >>>> platform too. Better find a better hypothesis. >>> I imagine that it would not be too difficult to port HP-UX to >>> another platform >> I think it would be simpler to harden & add features to Linux >> (both kernel and userland). >> >> -- > > And how would you propose that HP do this when it does not own or > control the kernel? Regarding the kernel, they'd do it the same way that IBM, Oracle, Intel, Red Hat, etc, etc, ad nauseum do: release the code under the GPL2 and get it into the mainline. Regarding userland code: there's no law that says that userland must be open source. (After all, Oracle makes a pretty penny selling licenses for RDBMSs that run on Linux.) -- 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, 14 Aug 2007 23:08:29 -0400 From: "Peter Weaver" Subject: Re: Is this Address really Illegal? Message-ID: <061101c7dee9$8edccdd0$2802a8c0@CHARONLAP> >... > I have never had a positive response. In most cases, I received not > so much as an acknowledgement and, as I said, int he worst case the > attacks increased, probably because they then knew they had a live one!! I usually have 10 or so SSH attacks a week, once every month or two I get positive feedback. > >> Sending an abuse report only takes seconds and it >> feels good when you get a reply that some Unix box was hacked into. > > It takes longer than seconds just to look it up and frequently they are > buried so deep in holding companies it take considerably longer. And, I just sent a complaint, it took 39 seconds from start to finish. To me that is just seconds. > especially in the case of Pacific Rim sites, it isn't a hacked box, > (unix or VMS :-) it is a deliberate and fully supported attack. Feel > free to advertise your machines to the enemy, I feel much better not I went through two months of reports and the only repeat offender was 125.76.230.10. That machine attacked me on August 10th (5 login attempts to admin and root) and on August 12th (9 attempts on the non-exisitant root account). In April of 2006 I also had two attacks from 62.197.179.152, I do not have the original complaints saved but I did get a reponse from a person saying that the machine was broken into over the weekend and fixed on the Monday. I do not recall any other time when a single machine came back for more attacks after the first one was reported. > acknowledging them and when necessary, blocking them completely. It's > just like SPAM. It needs to be treated the same. >... It does need to be treated like Spam, report the abuse, try to stop it rather than ignore it. Ignoring it is only helping the attackers. Peter Weaver www.weaverconsulting.ca CHARON-VAX CHARON-AXP DataStream Reflection PreciseMail HP Commercial Hardware ------------------------------ Date: Tue, 14 Aug 2007 11:10:39 -0700 From: sean@obanion.us Subject: Re: Node & Port allocation classes on a new cluster Message-ID: <1187115039.202649.44860@l22g2000prc.googlegroups.com> I think the crux of this is: What are you going to MSCP serve these disks to? Keeping in mind that MSCP serving will take place over the Ethernet and not the SAN, since both nodes are connected to the same SAN, and in this case the same storage controler, there is no need to MSCP serve from one node to the other. Supporting failover if SAN connectivity is lost is often not usefull because the bandwidth of Ethernet is not large engouh. Sean On Aug 14, 6:34 am, issinoho wrote: > On Aug 14, 2:12 pm, "Jilly" wrote: > > > > > "issinoho" wrote in message > > >news:1187083999.469368.171760@l70g2000hse.googlegroups.com... > > > > Chaps, can I borrow your intellect for a few moments please. > > > I have been through the Clustering manuals and various posts here but > > > am still not 100% sure how this all works. > > > > I currently have 2 rx2660 unclustered both connected multi-path to a > > > dual controller MSA1000 rack. I have one LUN which will contain shared > > > data, another to become a quorum disk. > > > > Both servers have the same disk profile as follows, > > > > Device Device Error Volume Free > > > Trans Mnt > > > > Name Status Count Label Blocks > > > Count Cnt > > > > NODE1$DKA800: Mounted 0 I64_V83 > > > 53579760 604 1 > > > > NODE1$DNA0: Online wrtlck 0 > > > > $1$DGA1501: (NODE1) Mounted 0 DATADISK > > > 273834144 11 1 > > > > $1$DGA1502: (NODE1) Mounted 0 QUORUMDISK > > > 142254000 1 1 > > > > I am planning the clustering of these servers using the quorum disk > > > and would like clarification of the following. > > > > As the servers have the same system disk name (DKA800) do they need a > > > different node allocation class to uniquely serve them up using MSCP; > > > or if I don't use node allocation will the current NODE$DISK notation > > > be sufficient to achieve this. > > > > Should I avoid the allocation class of '1' since this is already > > > assigned to the FC disks? > > > > In this instance do I need to use port allocation classes? > > > > The CLUSTER_CONFIG routine seems a lot 'scarier' since I last used it > > > (about V6.2) and I don't want to get this wrong. > > > > Many thanks. > > > For this cluster you will only need a non-zero system allocation class if > > you wish to use host based volume shadowing. If you do wish to use > > shadowing then yes each system will need to have an allocation class. When > > I set up clusters I always use the following rules > > > 1) If Port Allocation Class (PAC) is needed then it should be used on all > > nodes > > 2) HSx widgets should start at allocation class 255 and work down > > 3) System allocation class should start at 10 and work up as a multiple of > > 10 UNLESS overridden by MSCP requirements for HSx served devices > > 4) Shared SCSI ports should have PAC = 2 thru 7 as needed > > 5) System controllers should have the system allocation class plus a number > > ie node A = 10 then DQA = 11 DQB = 12 PKA = 13 > > > So for your cluster, node A would have ALLOCLASS = 10 & node B would be 20 > > under my guidelines. Your cluster would work fine if A = 216 & B = 44 or > > even if A=1 & B=2. What you cannot have is A=B=n since that would create > > multiple $n$DKA800 pointing to different devices (with MSCP serving > > enabled). > > So, just to be clear... > I am not using Volume Shadowing so I can use a non-zero host > allocation and I don't require port allocation? > Correct? ------------------------------ Date: Tue, 14 Aug 2007 14:52:39 -0400 From: "Jilly" Subject: Re: Node & Port allocation classes on a new cluster Message-ID: <46c1f9ce$0$7526$ec3e2dad@news.usenetmonster.com> "issinoho" wrote in message news:1187098486.363677.205130@g4g2000hsf.googlegroups.com... > On Aug 14, 2:12 pm, "Jilly" wrote: >> "issinoho" wrote in message >> >> news:1187083999.469368.171760@l70g2000hse.googlegroups.com... >> >> >> >> > Chaps, can I borrow your intellect for a few moments please. >> > I have been through the Clustering manuals and various posts here but >> > am still not 100% sure how this all works. >> >> > I currently have 2 rx2660 unclustered both connected multi-path to a >> > dual controller MSA1000 rack. I have one LUN which will contain shared >> > data, another to become a quorum disk. >> >> > Both servers have the same disk profile as follows, >> >> > Device Device Error Volume Free >> > Trans Mnt >> >> > Name Status Count Label Blocks >> > Count Cnt >> >> > NODE1$DKA800: Mounted 0 I64_V83 >> > 53579760 604 1 >> >> > NODE1$DNA0: Online wrtlck 0 >> >> > $1$DGA1501: (NODE1) Mounted 0 DATADISK >> > 273834144 11 1 >> >> > $1$DGA1502: (NODE1) Mounted 0 QUORUMDISK >> > 142254000 1 1 >> >> > I am planning the clustering of these servers using the quorum disk >> > and would like clarification of the following. >> >> > As the servers have the same system disk name (DKA800) do they need a >> > different node allocation class to uniquely serve them up using MSCP; >> > or if I don't use node allocation will the current NODE$DISK notation >> > be sufficient to achieve this. >> >> > Should I avoid the allocation class of '1' since this is already >> > assigned to the FC disks? >> >> > In this instance do I need to use port allocation classes? >> >> > The CLUSTER_CONFIG routine seems a lot 'scarier' since I last used it >> > (about V6.2) and I don't want to get this wrong. >> >> > Many thanks. >> >> For this cluster you will only need a non-zero system allocation class if >> you wish to use host based volume shadowing. If you do wish to use >> shadowing then yes each system will need to have an allocation class. >> When >> I set up clusters I always use the following rules >> >> 1) If Port Allocation Class (PAC) is needed then it should be used on all >> nodes >> 2) HSx widgets should start at allocation class 255 and work down >> 3) System allocation class should start at 10 and work up as a multiple >> of >> 10 UNLESS overridden by MSCP requirements for HSx served devices >> 4) Shared SCSI ports should have PAC = 2 thru 7 as needed >> 5) System controllers should have the system allocation class plus a >> number >> ie node A = 10 then DQA = 11 DQB = 12 PKA = 13 >> >> So for your cluster, node A would have ALLOCLASS = 10 & node B would be >> 20 >> under my guidelines. Your cluster would work fine if A = 216 & B = 44 or >> even if A=1 & B=2. What you cannot have is A=B=n since that would create >> multiple $n$DKA800 pointing to different devices (with MSCP serving >> enabled). > > So, just to be clear... > I am not using Volume Shadowing so I can use a non-zero host > allocation and I don't require port allocation? > Correct? > If this isn't a typo 'non-zero' then the answer is Yes and Yes. If it was a typo and you meant zero for allocation class the answer is still Yes. ------------------------------ Date: Tue, 14 Aug 2007 14:55:12 -0400 From: "Jilly" Subject: Re: Node & Port allocation classes on a new cluster Message-ID: <46c1fa67$0$7507$ec3e2dad@news.usenetmonster.com> "Michael Moroney" wrote in message news:f9sivd$asi$1@pcls6.std.com... > issinoho writes: > >>On Aug 14, 2:12 pm, "Jilly" wrote: > >>> 4) Shared SCSI ports should have PAC = 2 thru 7 as needed > > You may want to skip 2 if you ever wish to use fibrechannel magtapes. > Yep, I had forgotten about SAN based tapes and I missed saying that I like to start my shared busses at 7 and work down so this statement should be 4) Shared SCSI ports should have PAC = 7 thru 3 as needed ------------------------------ Date: Tue, 14 Aug 2007 19:50:09 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Node & Port allocation classes on a new cluster Message-ID: sean@obanion.us writes: >I think the crux of this is: >What are you going to MSCP serve these disks to? >Keeping in mind that MSCP serving will take place over the Ethernet >and not the SAN, since both nodes are connected to the same SAN, and >in this case the same storage controler, there is no need to MSCP >serve from one node to the other. Supporting failover if SAN >connectivity is lost is often not usefull because the bandwidth of >Ethernet is not large engouh. VMS always uses the direct path if both direct and MSCP paths are available. Lower bandwidth MSCP serving will only happen if the direct path is somehow lost. Also, if he wants to make the system disks (and any other local disks such as CDROMs) available to each other, he'll want the MSCP server. ------------------------------ Date: Tue, 14 Aug 2007 23:45:59 GMT From: John Santos Subject: Re: Node & Port allocation classes on a new cluster Message-ID: Michael Moroney wrote: > sean@obanion.us writes: > > >>I think the crux of this is: >>What are you going to MSCP serve these disks to? > > >>Keeping in mind that MSCP serving will take place over the Ethernet >>and not the SAN, since both nodes are connected to the same SAN, and >>in this case the same storage controler, there is no need to MSCP >>serve from one node to the other. Supporting failover if SAN >>connectivity is lost is often not usefull because the bandwidth of >>Ethernet is not large engouh. > > > VMS always uses the direct path if both direct and MSCP paths are > available. Lower bandwidth MSCP serving will only happen if the > direct path is somehow lost. Also, if he wants to make the system > disks (and any other local disks such as CDROMs) available to each other, > he'll want the MSCP server. > It sounds like you won't be having a shared common system disk, but separate local system disks for each rx2660. Since the system disks are not shared (DKA disks), but are on local SCSI buses, MSCP serving them would be very convenient for system management tasks. Direct access instead of using DECnet remote access or FTP, etc. You'll want to put all the common files on one of the shared MSA disks, but you'll still have a few things on the local disks, such as systartup_vms.com, modparams.dat, etc., and if you discover you need to bump the default for some system parameter, you will probably want to do it on both systems, and it will be a lot easier with direct access to both system disks from a single login. The Ethernet ports on the RX2660 are Gigabit-capable, so they won't be all that slow (says someone who's been running a cluster on 10Mb half-duplex Ethernet for many years!) My rx2620 has two ethernet ports; if the rx2660 is the same, you could directly connect one pair of them with a cross-over cable (unless they autosense, in which case a straight-through patch cable would also work), and put all your SCS traffic on the private "LAN". Or get a GB switch ($20-$40 for a cheap one at MicroCenter), and use it just for cluster traffic. MSCP would be even faster that way. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Tue, 14 Aug 2007 16:51:54 -0500 From: Chris Scheers Subject: Re: Oldest Alpha for upgrade to Integrity Message-ID: <5iemfnF3p6gngU2@mid.individual.net> FredK wrote: > "tadamsmar" wrote in message > news:1187019709.710397.207640@w3g2000hsg.googlegroups.com... >> On Aug 10, 3:06 pm, bro...@cuebid.zko.hp.nospam (Rob Brooks) wrote: >>> tadamsmar writes: >>>> Does the AlphaStation 400, AlphaServer 800 and the DS10 support VMS >>>> 8.3 or some version that Integrity also supports? >>> Yes >>> >>>> I was wondering if I can upgrade my older Alphas to a common version >>>> with Integrity. >>>> Is there a web page that shows what hardware will run what versions of >>>> VMS? >>> While there have been a few VAX models that have been dropped along the >>> way, >>> no Alpha hardware has been dropped from support. In this context, I'm >>> talking >>> about models that were properly sold with VMS, not oddball things like >>> the >>> multia, or the early EV3-based systems. >> I know you are wrong about this from my direct experience. The first >> Alpha we bought was an AXP 150 sold with VMS from DEC. I ended up >> surplussing it since it was dropped by 7.3.2. >> >> I think it may have been delivered with NT on it, but DEC sold us the >> system and the media. >> > > The limitations in support in general have had to do mostly with memory > constraints. VMS on Alpha initially ran with 16mb, but today we require > 64mb IIRC. You can tweak things in SYSGEN and what software you load to > make it run with small memories - but we don't support it. > > The AXP150 (aka AlphaPC, aka Jensen) was an attempt to create a system out > of standard PC giblets. EISA bus. Junk IO. Small memory. VMS was > initially split on if or how to support it (it was designed for NT). > Eventually we decided to support it as a server, and then at the last minute > decided to support it as a workstation as well. > > Given the ability to pick up DS10's on the used market cheap - I can't > imagine wanting to continue to use one. One reason to use an AXP150 is that it will run VMS 6.1. (Actually it will run 1.5. I'm not sure about 1.0). .EXEs built on an AXP150 running VMS 6.1 should be able to run on most any Alpha out there. A DS10 isn't as flexible. (But it is a heck of a lot faster.) -- ----------------------------------------------------------------------- Chris Scheers, Applied Synergy, Inc. Voice: 817-237-3360 Internet: chris@applied-synergy.com Fax: 817-237-3074 ------------------------------ Date: Tue, 14 Aug 2007 18:21:37 -0400 From: "FredK" Subject: Re: Oldest Alpha for upgrade to Integrity Message-ID: "Chris Scheers" wrote in message news:5iemfnF3p6gngU2@mid.individual.net... > FredK wrote: >> "tadamsmar" wrote in message >> news:1187019709.710397.207640@w3g2000hsg.googlegroups.com... >>> On Aug 10, 3:06 pm, bro...@cuebid.zko.hp.nospam (Rob Brooks) wrote: >>>> tadamsmar writes: >>>>> Does the AlphaStation 400, AlphaServer 800 and the DS10 support VMS >>>>> 8.3 or some version that Integrity also supports? >>>> Yes >>>> >>>>> I was wondering if I can upgrade my older Alphas to a common version >>>>> with Integrity. >>>>> Is there a web page that shows what hardware will run what versions of >>>>> VMS? >>>> While there have been a few VAX models that have been dropped along the >>>> way, >>>> no Alpha hardware has been dropped from support. In this context, I'm >>>> talking >>>> about models that were properly sold with VMS, not oddball things like >>>> the >>>> multia, or the early EV3-based systems. >>> I know you are wrong about this from my direct experience. The first >>> Alpha we bought was an AXP 150 sold with VMS from DEC. I ended up >>> surplussing it since it was dropped by 7.3.2. >>> >>> I think it may have been delivered with NT on it, but DEC sold us the >>> system and the media. >>> >> >> The limitations in support in general have had to do mostly with memory >> constraints. VMS on Alpha initially ran with 16mb, but today we require >> 64mb IIRC. You can tweak things in SYSGEN and what software you load to >> make it run with small memories - but we don't support it. >> >> The AXP150 (aka AlphaPC, aka Jensen) was an attempt to create a system >> out of standard PC giblets. EISA bus. Junk IO. Small memory. VMS was >> initially split on if or how to support it (it was designed for NT). >> Eventually we decided to support it as a server, and then at the last >> minute decided to support it as a workstation as well. >> >> Given the ability to pick up DS10's on the used market cheap - I can't >> imagine wanting to continue to use one. > > One reason to use an AXP150 is that it will run VMS 6.1. (Actually it > will run 1.5. I'm not sure about 1.0). > > .EXEs built on an AXP150 running VMS 6.1 should be able to run on most any > Alpha out there. > > A DS10 isn't as flexible. (But it is a heck of a lot faster.) > Yeah, and those images built on V6.1 will also not take advantage of many new features and compiler advances. But you are correct. But there are other old systems out there that probably also meet that test with a little better performance. Heck - probably even an emulated Alpha will ;-) ------------------------------ Date: 14 Aug 2007 23:03:34 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Oldest Alpha for upgrade to Integrity Message-ID: <32tiqpCrPboX@eisner.encompasserve.org> In article <5iemfnF3p6gngU2@mid.individual.net>, Chris Scheers writes: > One reason to use an AXP150 is that it will run VMS 6.1. (Actually it > will run 1.5. I'm not sure about 1.0). The low end Alpha VMS V1.0 machines are Flamingo (3000-500?) and Sandpiper (3000-400), the latter being about one half of the former. ------------------------------ Date: Tue, 14 Aug 2007 12:07:52 -0700 From: phoenix Subject: SSSU - Version 6 - script error Message-ID: <1187118472.212175.320050@i38g2000prf.googlegroups.com> Upgraded my command view and had to install a new version of SSSU on OpneVMS. Installed SSSU - version 6 and can't get my scripts to run from the back-end. Below is my testing script with errror. $ sssu :==$DSA99:[SSSU]SSSU_ALPHA.EXE;1 $! $ sssu sel manager XX.XX.XXX user=administrator pass=administrator sel cell EVA11 exit i get this.. SSSU for HP StorageWorks Command View EVA Version: 6.0.2 Build: 5 Manager: Username:er 10.64.2.154 user= administratorass=administrator Password:ll EVA02 Error opening https connection Press return to exit ------------------------------ Date: Tue, 14 Aug 2007 18:25:10 -0700 From: Sue Subject: Update going out on Thursday Message-ID: <1187141110.113276.71130@x35g2000prf.googlegroups.com> Dear Newsgroup, I will be sending out an update on Thursday, if you have anything you need me to include please send it to my by the close of business Wednesday. Warm Regards, Sue ------------------------------ Date: Tue, 14 Aug 2007 16:39:55 -0500 From: Ron Johnson Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: On 08/14/07 12:24, Bob Koehler wrote: > In article <004a01c7de81$27d4bf70$777e3e50$@com>, "Paul Raulerson" writes: > >> That which is not well documented is either >> >> used by a small portion of the community (who don't feel the need for more >> documentation) or is just not popular or used enough to worry about. > > That which is not documented is not documented. It doesn't matter to > me how few people wanted to use it, it only mattered that I needed > information to use the product as described and it wasn't there. > >> This is not something that can be used a relative scale to say VMS (or z/OS) >> is BETTER than Linux - it is much more a difference of kind. > > Useable is always better than not useable. Apparently, lots of people seem to think that Linux is usable. >> If VMS was popular enough to have as many people developing for it as say, >> Linux, then you would see the same problem. > > Back when VMS was exceedingly popular it didn't have that problem. > There's no reason why the Linux kernel, which is stable and > controlled by Linus, the gnu utilities that run on top of it, which > are fairly stable and well controlled by gnu, or any commercial UNIX > can't be well documented; they just aren't. Because it costs *money* to create (and keep current) extensive *good* documentation with lots of examples. While I remember DOS/VSE having lots of documentation, I remember it being relatively poor quality. -- 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: Wed, 15 Aug 2007 00:11:09 +0000 From: "Main, Kerry" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: August 14, 2007 5:40 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > > On 08/14/07 12:24, Bob Koehler wrote: > > In article <004a01c7de81$27d4bf70$777e3e50$@com>, "Paul Raulerson" > writes: > > > >> That which is not well documented is either > >> > >> used by a small portion of the community (who don't feel the need > for more > >> documentation) or is just not popular or used enough to worry about. > > > > That which is not documented is not documented. It doesn't matter > to > > me how few people wanted to use it, it only mattered that I needed > > information to use the product as described and it wasn't there. > > > >> This is not something that can be used a relative scale to say VMS > (or z/OS) > >> is BETTER than Linux - it is much more a difference of kind. > > > > Useable is always better than not useable. > > Apparently, lots of people seem to think that Linux is usable. > And there is an old saying from somewhere that states something like - "If the whole world thinks something is true, then it likely is not." History is full of examples where technologies become white hot for short periods Of time, but then for numerous reasons, fall by the wayside. DCE, NAS (early versions of SOA), AI (artificial Intelligence) etc are All examples of technologies that were seen to be "the next big thing", but then fell by the wayside. Fwiw, Gartner likes to call it the hype curve. A technology becomes white hot, then crashes as people find out it does not do everything it was expected to, then arises again at a much lower level more in line with reasonable expectations of what that technology is best suited for. [snip] Pure personal opinion, but based on various discussions with senior IT managers, there appears to be another emerging trend that may run counter to the Linux type movement. Senior IT managers want their senior IT folks interacting more with the lines of business to better educate the business types on how IT can help solve their business problems. They do not want their senior IT folks playi= ng in the OS weeds dealing with the patch of the day support, compatibility an= d other low level OS issues. For this low level OS support stuff, they would rather pay some other vendo= r To provide Support - especially since this is only a small part of the over= all IT budget (IT staffing is 60-70% of IT budget). Interesting times ahead. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Tue, 14 Aug 2007 21:58:04 -0500 From: Ron Johnson Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1Ztwi.217701$LE1.188973@newsfe13.lga> On 08/14/07 19:11, Main, Kerry wrote: >> -----Original Message----- >> From: Ron Johnson [mailto:ron.l.johnson@cox.net] >> Sent: August 14, 2007 5:40 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: Wonderful things happen to an OS when it has an internal >> champion >> >> On 08/14/07 12:24, Bob Koehler wrote: >>> In article <004a01c7de81$27d4bf70$777e3e50$@com>, "Paul Raulerson" >> writes: >>>> That which is not well documented is either >>>> >>>> used by a small portion of the community (who don't feel the need >> for more >>>> documentation) or is just not popular or used enough to worry about. >>> That which is not documented is not documented. It doesn't matter >> to >>> me how few people wanted to use it, it only mattered that I needed >>> information to use the product as described and it wasn't there. >>> >>>> This is not something that can be used a relative scale to say VMS >> (or z/OS) >>>> is BETTER than Linux - it is much more a difference of kind. >>> Useable is always better than not useable. >> Apparently, lots of people seem to think that Linux is usable. >> > > And there is an old saying from somewhere that states something like - > > "If the whole world thinks something is true, then it likely is not." > > History is full of examples where technologies become white hot for short > periods Of time, but then for numerous reasons, fall by the wayside. > > DCE, NAS (early versions of SOA), AI (artificial Intelligence) etc are > All examples of technologies that were seen to be "the next big thing", > but then fell by the wayside. > > Fwiw, Gartner likes to call it the hype curve. A technology becomes white > hot, then crashes as people find out it does not do everything it was > expected to, then arises again at a much lower level more in line with > reasonable expectations of what that technology is best suited for. Like Windows isn't as stable and secure as my grandmother's broken hip, so people are flocking away from it back on to OpenVMS? Puh-leeze. > [snip] > > Pure personal opinion, but based on various discussions with senior IT > managers, there appears to be another emerging trend that may run counter > to the Linux type movement. > > Senior IT managers want their senior IT folks interacting more with the > lines of business to better educate the business types on how IT can help > solve their business problems. They do not want their senior IT folks playing > in the OS weeds dealing with the patch of the day support, compatibility and > other low level OS issues. Puh-leeze again. When was the last time that a senior IT person played in the OS weeds? That's correct: back when he was a mid-layer IT person. > For this low level OS support stuff, they would rather pay some other vendor > To provide Support - especially since this is only a small part of the overall > IT budget (IT staffing is 60-70% of IT budget). > > Interesting times ahead. Outsource OS support like they outsource programming and the hell desk? -- 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, 14 Aug 2007 11:03:32 -0700 From: Doug Phillips Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1187114612.315272.78820@g12g2000prg.googlegroups.com> On Aug 14, 2:14 am, Michael Kraemer wrote: > Richard B. Gilbert schrieb: > > > Doug Phillips wrote: > > >> Yep. DEC let Sun become what it is today by not closing that door. The > >> VAXstation CAD/CAM systems my customers had back then were *all* > >> replaced with cheaper and faster Sun's. And from there Sun grew. > > > Yup! Faster and cheaper beats better every time!!! > > Define "better". The RISC boxes in question here were at least as capable > as the VAXen to do the job. The ones I saw were *more* capable in that their rendering was much faster (actually, they seemed to be faster at everything) and the cost was significantly lower. So: higher speed + lower cost = higher productivity + less overhead = higher return on investment. They were also quite reliable (from what I saw) and there was more software. By the time Alpha workstations came along, Sun was fully entrenched. ------------------------------ Date: Tue, 14 Aug 2007 22:09:09 GMT From: John Santos Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <9Kpwi.684$5Q5.92@trnddc05> Doug Phillips wrote: > On Aug 14, 6:18 am, "Main, Kerry" wrote: > >>>-----Original Message----- >>>From: Doug Phillips [mailto:dphil...@netscape.net] >>>Sent: August 13, 2007 4:24 PM >>>To: Info-...@Mvb.Saic.Com >>>Subject: Re: Wonderful things happen to an OS when it has an internal >>>champion >> >>>On Aug 13, 2:58 pm, "Main, Kerry" wrote: >>> >>>> -----Original Message----- >>>> >>>>>From: Doug Phillips [mailto:dphil...@netscape.net] >>>>>Sent: August 13, 2007 3:40 PM >>>>>To: Info-...@Mvb.Saic.Com >>>>>Subject: Re: Wonderful things happen to an OS when it has an >>> >>>internal >>> >>>>>champion >> >>>>[snip] >> >>>>>>Here are just a few recent examples of OpenVMS clustering by what >>>>> >>>>>would be >>>>> >>>>>>considered SMB companies: >> >>>>>>http://h71028.www7.hp.com/ERC/downloads/4AA0- >> >>>7388EEE.pdf(full)http://h71028.www7.hp.com/erc/library/GetPage.aspx?pag >>> >>>>>eid=496911(condensed) >> >>>>>>http://h71028.www7.hp.com/ERC/downloads/5983-2346EN.pdf >> >>>>>>http://h71028.www7.hp.com/ERC/downloads/4AA0-3672ENE.pdf >> >>>>>>http://h71028.www7.hp.com/ERC/Downloads/4AA0-8708EEW.pdf >> >>>>>>Imagine a company wanting rock solid, very high stable >>> >>>applications >>> >>>>>with ultra-high security that does not require 5-20 security >>> >>>patches >>> >>>>>per month - what a novel idea! >> >>>>>>:-) >> >>>>>Without seeing the financials (which are usually not easy to find >>> >>>for >>> >>>>>private companies), those don't look like "$2 mil.revenue/year" >>>>>operations. That's what we were discussing. >> >>>>>AFA clustering, I don't think anyone is arguing the benefits; just >>> >>>the >>> >>>>>cost. >> >>>>A few of the examples provided were clustered rx2620's .. >> >>>>Low end servers with clustering which to me says SMB type >>> >>>environment. >> >>>As it does to me. But SMB covers a wide revenue range and I guess >>>you'll just have to read the discussion to understand why the examples >>>you gave probably don't apply. >> >>In your view ... >> > > > > Darn, Kerry. It's real hard to reply to this if you aren't going read > the thread and stay in the context of the discussion, so I'll try to > repeat some of it so you don't have to go back and find it. > > Here's a bit from the post that started this branch of the thread: > ### > >>>[attribution removed] >>> >>>>I've spent 20 years in this field on OpenVMS and other platforms. >>>>I've never been to an OpenVMS shop for any company grossing >$2mil in >>>>sales which wasn't fully using a cluster. > > ### > > In my reply to that statement I said I've seen *lots more* OpenVMS > shops in the $2mil/year range that were *not* clustered than ones that > were, and you posted examples of clustered SMB companies that I > suspect fall considerably above the $2mil/year we were discussing. > > My point is not about the benefits or value of clustering. It's about > affordability. I think clustering is *good* and I think VMS does it > right. > > An Alpha clustering license costs close to $20,000/per on the *low* > end. I'm not that familiar yet with Itanium pricing, but the last I > looked you needed the MCOE license, and from what I recall that is > also quite expensive (and is per processor.) > I recently received a quote for some Itanium systems from a reseller with both MCOE and FOE+SHADOWING+CLUSTER licenses. (We didn't need any of the other stuff in MCOE or EOE.) The F+S+C licenses were somewhat cheaper. The systems were rx3600 w/2 dual-core 1.6GHz processors. This required 4 FOE LTU (License to use?) @~$1K plus 4 volume shadowing licenses @~$1600. There seemed to be two cluster licenses involved, a Cluster Client PCL LTU @$1250 and a Cluster for VMS PCL LTU @$5K, or $25K for clusters, for a grand total of $35,400 for licensing (per rx3600 system). MCOE on the same system was $10,400 per core, or $41,600. So it was about $11K/system cheaper to go a la carte. The quotes also included 3 years of 24*7 support which totaled up (over 3 years) to about the same as the license prices. (8*5 maint would have been much cheaper, but if you're clustering for availability, do you really want to scrimp here?) We ultimately decided though the clustering would be nice to have, we didn't really need it, and so kept the FOE plus shadowing for about $10,500 per system, saving 60% of the license costs and about the same percentage of the software maintenance costs. The total system price per system with memory, MSA1000 disk array, backup, software (O/S, compilers, shadowing) was about $110K, adding clustering would have added another 25K to that ($135K). (Not including maintenance.) MCOE would have added $41.6K to the base, minus shadowing ($6.4K), for a total of about $145K/system. I don't know how these prices scale with system size. I hope these numbers help with the discussion. > So, a $2mil/year company with a high profit margin and whose business > depends on 24/7 operation will find the cost of VMS clustering > justifiable. The majority of businesses that size will not. > > If you disagree with that, please explain your reasons. > > 88 > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Tue, 14 Aug 2007 21:24:34 +0000 From: "Main, Kerry" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: > -----Original Message----- > From: Doug Phillips [mailto:dphill46@netscape.net] > Sent: August 14, 2007 1:48 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > [snip] > > > Darn, Kerry. It's real hard to reply to this if you aren't going read > the thread and stay in the context of the discussion, so I'll try to > repeat some of it so you don't have to go back and find it. > > Here's a bit from the post that started this branch of the thread: > ### > > >[attribution removed] > > > > I've spent 20 years in this field on OpenVMS and other platforms. > > > > I've never been to an OpenVMS shop for any company grossing > >$2mil in > > > > sales which wasn't fully using a cluster. > ### > > In my reply to that statement I said I've seen *lots more* OpenVMS > shops in the $2mil/year range that were *not* clustered than ones that > were, and you posted examples of clustered SMB companies that I > suspect fall considerably above the $2mil/year we were discussing. > > My point is not about the benefits or value of clustering. It's about > affordability. I think clustering is *good* and I think VMS does it > right. > > An Alpha clustering license costs close to $20,000/per on the *low* > end. I'm not that familiar yet with Itanium pricing, but the last I > looked you needed the MCOE license, and from what I recall that is > also quite expensive (and is per processor.) > Your pricing estimates are outdated. In addition, you do not need MCOE Licenses for Integrity clustering. You can buy the entry level and simply add the cluster license on its own. > So, a $2mil/year company with a high profit margin and whose business > depends on 24/7 operation will find the cost of VMS clustering > justifiable. The majority of businesses that size will not. > > If you disagree with that, please explain your reasons. > > 88 A $2M company falls into the range of SMB. You can quibble about what the r= ange, but it basically all falls into SMB. Given that even small companies like t= his use Oracle Enterprise either directly or via a packaged solution, the cost associated with OpenVMS pales in comparison to those costs. I am sure you k= now that Oracle Enterprise lists for USD $40K / CPU + an additional 50% per CPU= if RAC is used. (and that is the same for all platforms - even X86...) So, yes, clustering is a cost-benefit decision. I am not saying that all sm= all Companies should use it, but if they are offering a service over the Intern= et or round the clock, then in today's world, they need to consider it. It is not just about the $'s, but also their reputations. If these small Companies are to be successful, they need to offer online services that mak= e them appear to be in the big leagues. Fwiw, one of the challenges of selling additional availability features on OpenVMS is that on its own, OpenVMS is extremely stable and reliable. Hence= , The decision to not cluster small OpenVMS systems is often based on "Why? T= he current system never goes down..." Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ End of INFO-VAX 2007.445 ************************