INFO-VAX Mon, 20 Aug 2007 Volume 2007 : Issue 455 Contents: Re: Alpha/Integrity Dead Pool RE: Alpha/Integrity Dead Pool Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? Re: Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? Re: Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? blind? Re: Deathrow cluster down? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Nasty? was: SSH login welcome message? 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 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 You know you've been around VMS too long when... ---------------------------------------------------------------------- Date: Sun, 19 Aug 2007 13:15:25 -0500 From: Ron Johnson Subject: Re: Alpha/Integrity Dead Pool Message-ID: <2N%xi.54568$GO6.24819@newsfe21.lga> On 08/19/07 07:31, Paul Raulerson wrote: > [snip] > > Mainframe (i.e. z Architecture ) != POWER. POWER technology is currently > used in the CP, > but the actual instructions that a zArch machine sees and uses are very very > much CISC. > Actual mainframes implement some of the 3500 or so instructions in hardware, > and others > in millicode (firmware). How's that different from microcode? (All VAX microcode was/could be loaded from floppy, so you could replace DEC microcode with your own, thus making certain opcodes do something completely different that what DEC had designed.) > This is a fun little issue; what the PSI firmware appears to do is use the > EPIC chips to > load additional firmware for the IA64 cores in "zArch" mode. PSI claims that > isn't emulation, > and I, like you, claim that if it quacks like a duck and it acts like a > duck... If ia64 has loadable opcodes, then, technically, it's *not* emulation. But not all CPU firmware is opcodes. For example, each Alpha has loadable firmware (but I'm not exactly sure what it does) which is different from the boot ROMs (SRM or ARC). We'd need to know what that firmware does, though, in order to assess the veracity of their statements. -- 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: Sun, 19 Aug 2007 19:25:55 -0500 From: "Paul Raulerson" Subject: RE: Alpha/Integrity Dead Pool Message-ID: <001001c7e2c0$ace25220$06a6f660$@com> > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: Sunday, August 19, 2007 1:15 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Alpha/Integrity Dead Pool > > On 08/19/07 07:31, Paul Raulerson wrote: > > > [snip] > > > > Mainframe (i.e. z Architecture ) != POWER. POWER technology is > currently > > used in the CP, > > but the actual instructions that a zArch machine sees and uses are > very very > > much CISC. > > Actual mainframes implement some of the 3500 or so instructions in > hardware, > > and others > > in millicode (firmware). > > How's that different from microcode? > Not very different at all I would think. :) > (All VAX microcode was/could be loaded from floppy, so you could > replace DEC microcode with your own, thus making certain opcodes do > something completely different that what DEC had designed.) > Wow! Now that would be cool, if you don't like the way a particular instruction works, just modify it huh? IBM code is very tightly controlled I am afraid, at least on all modern systems. -Paul > > This is a fun little issue; what the PSI firmware appears to do is > use the > > EPIC chips to > > load additional firmware for the IA64 cores in "zArch" mode. PSI > claims that > > isn't emulation, > > and I, like you, claim that if it quacks like a duck and it acts like > a > > duck... > > If ia64 has loadable opcodes, then, technically, it's *not* emulation. > > But not all CPU firmware is opcodes. For example, each Alpha has > loadable firmware (but I'm not exactly sure what it does) which is > different from the boot ROMs (SRM or ARC). > > We'd need to know what that firmware does, though, in order to > assess the veracity of their statements. > > -- > 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: Mon, 20 Aug 2007 01:44:57 -0000 From: Subject: Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? Message-ID: <13chsgptkddka8@corp.supernews.com> We are starting to migrate from VAX/VMS 5.5-2 (Ingres 6.4/06) to OpenVMS Alpha 8.3 (Ingres 9.0.4/105). The VAX disks have the ODS-2 (Files11?) file system (case insensitive, uppercase) on which Ingres 6.4 is installed and on which various report, data and log files are written. Applications are written in ABF and ESQL or EQUEL access data on these disks and might refer to the same file in uppercase, lowercase or a combination in different places in the code. We are migrating the applications and data basically as-is to an Alpha that has the OS disk formatted as ODS-2, but the other data disk on which Ingres is installed is formatted as ODS-5 (case sensitive). The Ingres 9.0.4 installation procedure only worked with the ODS-5 file system. The one other development user that has been created so far had its case lookup set to "blind" according to "show proc /full". After doing a small amount of testing on the command line, this user was able to access files similar to the VAX without regard to case. Will we run into any case sensitivity problems or other problems if we copy our files from the VAX and continue to use ODS-5 with case lookup = blind on the Alpha? Rather than go through all our code looking for potential case mismatches between variables holding filenames vs. the way the file was created on disk, we need to know if the applications will operate as they used to and be able to find files under these circumstances without any extra work on our part. Are there hidden gotchas, etc.? Anybody have any (bad) experiences they can relate while doing a similar migration? ------------------------------ Date: Sun, 19 Aug 2007 22:16:33 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? Message-ID: <07081922163361_20200296@antinode.org> From: > We are starting to migrate from VAX/VMS 5.5-2 (Ingres 6.4/06) to OpenVMS > Alpha 8.3 (Ingres 9.0.4/105). That's a jump. > The VAX disks have the ODS-2 (Files11?) > file system (case insensitive, uppercase) on which Ingres 6.4 is > installed and on which various report, data and log files are written. > Applications are written in ABF and ESQL or EQUEL access data on these > disks and might refer to the same file in uppercase, lowercase or a > combination in different places in the code. Case-blind is case-blind. ODS5 allows more and more exotic characters in file names, but old code should, in general, just work. MMS (especially the new "ODS5-compatible" MMS) can get confused in some cases which would have worked before, but most stuff just works. > We are migrating the applications and data basically as-is to an Alpha > that has the OS disk formatted as ODS-2, but the other data disk on > which Ingres is installed is formatted as ODS-5 (case sensitive). Normally, ODS5 is case-preserving, not case-sensitive. > The > Ingres 9.0.4 installation procedure only worked with the ODS-5 file > system. The one other development user that has been created so far had > its case lookup set to "blind" according to "show proc /full". "SHOW PROCESS /CASE_LOOKUP /PARSE_STYLE" may be handier, but those qualifiers seem not to appear in the help (Alpha V7.3-2, IA64 V8.3). > After > doing a small amount of testing on the command line, this user was able > to access files similar to the VAX without regard to case. > Will we run into any case sensitivity problems or other problems if we > copy our files from the VAX and continue to use ODS-5 with case lookup = > blind on the Alpha? Rather than go through all our code looking for > potential case mismatches between variables holding filenames vs. the > way the file was created on disk, we need to know if the applications > will operate as they used to and be able to find files under these > circumstances without any extra work on our part. It really depends on what your applications do with file names, which is hard to tell from a distance. RMS operations should be ok, but if your code, say, compares two file names to each other, they may look different when they refer to the same file. > Are there hidden gotchas, etc.? Anybody have any (bad) experiences they > can relate while doing a similar migration? The biggest problems I've seen are less case-related, more exotic-character-related. Methods like looking for "]" or "." to decompose a file spec are less reliable when the file spech looks like, say, "dka100:[d^.i^.r^[]a^]^.b.c". If you continue to use ODS2-compatible names, that reduces the possibilities for problems. Sadly, there's no real substitute for testing. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Mon, 20 Aug 2007 04:08:27 GMT From: "John E. Malmberg" Subject: Re: Any filename problems going from VAX/ODS-2 to Alpha/ODS-5/case blind? blind? Message-ID: <_s8yi.51122$Xa3.43000@attbi_s22> tkupp.xnox@sasktel.xspamx.net wrote: > We are starting to migrate from VAX/VMS 5.5-2 (Ingres 6.4/06) to OpenVMS > Alpha 8.3 (Ingres 9.0.4/105). The VAX disks have the ODS-2 (Files11?) > file system (case insensitive, uppercase) on which Ingres 6.4 is > installed and on which various report, data and log files are written. > Applications are written in ABF and ESQL or EQUEL access data on these > disks and might refer to the same file in uppercase, lowercase or a > combination in different places in the code. > > We are migrating the applications and data basically as-is to an Alpha > that has the OS disk formatted as ODS-2, but the other data disk on > which Ingres is installed is formatted as ODS-5 (case sensitive). ODS-5 is only case sensitive if you have set that as a process attribute. The default is for processes to be not case sensitive. ODS-5 filenames are case preserved. This only becomes a problem if something is reading a directory listing and then looking for files in a different case than what they were written in. > The > Ingres 9.0.4 installation procedure only worked with the ODS-5 file > system. The one other development user that has been created so far had > its case lookup set to "blind" according to "show proc /full". After > doing a small amount of testing on the command line, this user was able > to access files similar to the VAX without regard to case. That is the default condition. > Will we run into any case sensitivity problems or other problems if we > copy our files from the VAX and continue to use ODS-5 with case lookup = > blind on the Alpha? > > Are there hidden gotchas, etc.? Anybody have any (bad) experiences they > can relate while doing a similar migration? The only known issue with an application that I have seen is that MMS has a problem with lower case file extensions when applying default build rules to a target. There is an update scheduled, but I am not aware if it is ready yet. BACKUP/INTERCHANGE/NOCONVERT is available for 8.3 or with an ECO. The /INTERCHANGE qualifier is needed to produce a backup save set with out your local security information on it, but on ODS-5, it also converts the files to ODS-2 format. The /NOCONVERT now inhibits that conversion. I do not know if ZIP on VMS will support the extended character set and preserving case when making an archive. You will have to test your applications if to see if they are doing directory reads and expecting that files may exist with a different case than they were created on. A potential gotcha may be programs that are not aware of ODS-5, and will do internal name mangling like replacing extra dots with things like "_", so the filenames will not match what other applications are expecting. Programs that did their own filename/directory parsing or VMS to UNIX conversions tend not handle ODS-5 volumes correctly. The C library defaults to handling filenames in a ODS-2 manner, and needs to have feature settings to handle EFS characters. This can be set through logical names, or by programs written to handle this. There is also the SET PROC/PARSE=EXTENDED which allows ODS-5 extended file specifications to be used in DCL commands. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Sun, 19 Aug 2007 15:26:48 -0400 From: "John Smith" Subject: Re: Deathrow cluster down? Message-ID: <47177$46c8997a$4c0a982f$1999@TEKSAVVY.COM-Free> Michael Kraemer wrote: > Graham Burley schrieb: >> The hardware was in Florida, it's now in North Carolina. The owner >> is in Florida, with admin assists in Europe (Belgium & UK) and US. > > So, who is actually going to press the reset button ? Dialup modem connected to a relay to a motorized actuator with a Monty Python hand/finger? ;-) -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Sun, 19 Aug 2007 15:28:02 -0400 From: "John Smith" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: <2287e$46c899c4$4c0a982f$2073@TEKSAVVY.COM-Free> 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. :-) It would have been better to have ported Tru64 and not PH-UX. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Sun, 19 Aug 2007 15:30:28 -0400 From: "John Smith" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: 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. > > 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. You no doubt have seen the Sun announcement this past week of a Solaris port for Power. That makes Solaris run now on Sparc, Power, x86 -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Sun, 19 Aug 2007 16:52:13 -0700 From: AEF Subject: Re: Nasty? was: SSH login welcome message? Message-ID: <1187567533.180894.257650@d55g2000hsg.googlegroups.com> On Aug 18, 11:19 am, Malcolm Dunnett wrote: > VAXman- @SendSpamHere.ORG wrote: > > If you want to know about nasty, being that you are a relative newcomer > > to comp.os.vms, I suggest you research one Carl J. Lydick. While c.o.v. > > sometimes gets hostile and vituperations fill the threads, it is nothing > > at all like the when Carl would chime in with his castigatory vitrolic > > rhetoric! > > Carl was also a great resource and could be very helpful if you > asked what he deemed a worthy question. All things considered I > miss Carls postings. Yes, Carl would often be helpful, even if you pissed him off big time with an "inadequately put question" but followed up with a post that met his specs. OTOH, Carl sometimes didn't meet his own standards. He posted stuff he didn't check (a BIG Lydick no no), posted stuff when he didn't know what he was talking about (BACKUP/FAST for e.g.), and was informed by one respondent about the existence of the STOP command by posting the HELP STOP output when someone asked how to stop dead in the middle of a nested DCL procedure. So he really ought not have been so nasty. > Lets not forget Ehud Gavron either, there was a time when c.o.v. > flamage was rated in units called the Gavron. I remember that Carl was pissed when Ehud stopped posting (allegedly in frustration with too many bad posts) and even named a prime suspect! For the record, I've been both helped and scolded by him. AEF ------------------------------ Date: Sun, 19 Aug 2007 13:02:33 -0500 From: Ron Johnson Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: On 08/19/07 11:52, David J Dachtera wrote: > Ron Johnson wrote: >> On 08/18/07 20:48, Richard B. Gilbert wrote: >>> Ron Johnson wrote: >>>> On 08/18/07 11:55, Main, Kerry wrote: >>>> [snip] >>>> >>>>> After you do OS virtualization using solutions like VMware, Zen or >>>>> any other >>>>> solution, the next question out of the CIO's mouth will be "Great. >>>>> Now how >>>>> are you going to reduce the number of OS's, so I can cut my FTE >>>>> numbers?" >>>>> >>>>> And that is where App stacking, Workload Mgmt comes in. >>>> >>>> What exactly *is* App Stacking, other than "running multiple apps on >>>> the same machine"? >>>> >>> >>> The whole problem, as I understand it, is that Windows has traditionally >>> been not very good at protecting applications from each other! >>> >>> Windows has gotten a great deal better in the last seven years or so but >>> it would still take a brave man to run two applications simultaneously >>> on one server. >>> >>> Running multiple virtual servers on one physical server seems to solve >>> this problem; I guess VMWare provides the protection that Windows cannot! >> It *constantly* amazes me that so many IT people such sheep to be >> suck into the MSFT mindset like this. >> >> There are two reasons people in the Linux world run one app per box: >> 1. They are Windows refugees who don't know any better, or >> 2. "don't put all your eggs in one basket". >> >> Just like VMS (and BSD and Solaris, etc, etc), it's fully capable of >> running multiple apps on a single box. > > I should think one major problem is the lack of a central co-ordinating agency > for things like Registry key names. It's entirely possibly - and quite likely - > that one app.'s key path/name could duplicate that of another, with potentially > disasterous results. For a minute, I didn't realize that you had changed topic from Linux back to Windows, and was stunned that you were so ignorant of Linux. Then I realized what you did... > Another major limitation is the lack of VMS-like logical names. One way that > multiple app.'s - even multiple instances of the same app. - are separated in > VMS-land is by the use of group-level and privately-named logical name tables. > That way my "C" drive could be anything from DKB100: to DAVIDS-INSTANCE: > (DKB100:[david.]/trans=conc), while yours could be anything from DKB200: to > YOUR-INSTANCE: (DKB100:[yours.]/trans=conc) as just one example. > > There are probably some ways around this using Windows environment symbols. > However, this would be so far outside of the typical Windows programmer's > paradigm that trying to introduce it now would be tantamount to introducing a > whole new operating environment. That's true, but MS-DOS actually did come (starting with v3, probably) with a utility that allowed you to associate a drive letter with a directory on another drive. Sadly, I can't remember it's name. > Indeed, these critters have grown so accustommed to "I'll solve this problem MY > way, regardless of whether it clashes with anything else" that the probability > of changing it short of WMware or equiv. is indeed quite low. Sadly, that "I own the machine" mentality is *THE* bane of MSFT-based computing. (And thus impacts everyone...) Linux, though, is forcing a lot of PC-mindset people to realize that they don't actually own the box. -- 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: Sun, 19 Aug 2007 14:38:27 -0400 From: JF Mezei Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1f188$46c88e27$cef8887a$3013@TEKSAVVY.COM> Ron Johnson wrote: > There are two reasons people in the Linux world run one app per box: > 1. They are Windows refugees who don't know any better, or > 2. "don't put all your eggs in one basket". Setting up a system to run multiple different applications requires a certain level of skillset so that you can setup the system environment, tuning parameters etc that match what is needed instead of what is written in one book for one app. This is especially true of application installation procedures are setup to assume they are alone on the system and set the system parameters accordingly. (which you then have to go back and fix). Windows weenies don't have that level of experience. And it is also possible that it just isn't worth fighting those installation procedures (and constant patching) and just let the one app per machne be happy with its own parameters. ------------------------------ Date: Sun, 19 Aug 2007 22:23:51 +0200 From: "Martin Vorlaender" Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: Ron Johnson wrote: > That's true, but MS-DOS actually did come (starting with v3, > probably) with a utility that allowed you to associate a drive > letter with a directory on another drive. > > Sadly, I can't remember it's name. SUBST Still works in an XP DOS box... cu, Martin -- One OS to rule them all | Martin Vorlaender | OpenVMS rules! One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://www.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin.vorlaender@t-online.de ------------------------------ Date: Mon, 20 Aug 2007 00:23:17 +0200 From: "P. Sture" Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: In article <46C8755C.1527DBC0@spam.comcast.net>, David J Dachtera wrote: > I should think one major problem is the lack of a central co-ordinating > agency for things like Registry key names. It's entirely possibly - and > quite likely - that one app.'s key path/name could duplicate that of another, > with potentially disastrous results. > DLL Hell. > Another major limitation is the lack of VMS-like logical names. One way that > multiple app.'s - even multiple instances of the same app. - are separated > in VMS-land is by the use of group-level and privately-named logical name > tables. > That way my "C" drive could be anything from DKB100: to DAVIDS-INSTANCE: > (DKB100:[david.]/trans=conc), while yours could be anything from DKB200: to > YOUR-INSTANCE: (DKB100:[yours.]/trans=conc) as just one example. Not just the mapping of drives and directories, but shared images too. With VMS logical names it is possible to have different versions of software INSTALLed concurrently. > There are probably some ways around this using Windows environment symbols. > However, this would be so far outside of the typical Windows programmer's > paradigm that trying to introduce it now would be tantamount to introducing a > whole new operating environment. > > Indeed, these critters have grown so accustommed to "I'll solve this problem > MY way, regardless of whether it clashes with anything else" that the > probability of changing it short of WMware or equiv. is indeed quite low. One perfect example - apps which install their own flavour of Java. I don't know if this is still common, but during the run up to Y2K one colleague reported finding up to 6 separate instances of Java on in-house PCs. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Sun, 19 Aug 2007 17:42:47 -0500 From: Ron Johnson Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: On 08/19/07 13:38, JF Mezei wrote: > Ron Johnson wrote: >> There are two reasons people in the Linux world run one app per box: >> 1. They are Windows refugees who don't know any better, or >> 2. "don't put all your eggs in one basket". > > Setting up a system to run multiple different applications requires a > certain level of skillset so that you can setup the system environment, > tuning parameters etc that match what is needed instead of what is > written in one book for one app. This is especially true of application > installation procedures are setup to assume they are alone on the system > and set the system parameters accordingly. (which you then have to go > back and fix). > > Windows weenies don't have that level of experience. And it is also > possible that it just isn't worth fighting those installation procedures :( I must be spoiled by Debian. > (and constant patching) and just let the one app per machne be happy > with its own parameters. -- 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: Sun, 19 Aug 2007 19:57:12 +0000 From: "Main, Kerry" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: > -----Original Message----- > From: David J Dachtera [mailto:djesys.no@spam.comcast.net] > Sent: August 19, 2007 12:53 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > [snip...] > There are probably some ways around this using Windows environment > symbols. > However, this would be so far outside of the typical Windows > programmer's > paradigm that trying to introduce it now would be tantamount to > introducing a > whole new operating environment. > > Indeed, these critters have grown so accustommed to "I'll solve this > problem MY > way, regardless of whether it clashes with anything else" that the > probability > of changing it short of WMware or equiv. is indeed quite low. > > -- > David J Dachtera > dba DJE Systems > http://www.djesys.com/ Yep, and one could argue that while perhaps not to the same extent, the same is true of UNIX environments i.e. it is not technical issues, but rather culture issues which are the biggest impediment to App stacking. In some ways, OpenVMS is proprietary and has a culture associated with "this is the way you do things.." and that is a really good thing. This applies to things like app clustering and different application modules (written in diff languages) data and resource sharing rules that need to be followed in order for everyone in the sand box to play together nicely in a safe, scalable and very secure manner. Now, in the UNIX environment, in order for an App to take advantage of the local OS platform clustering technology, it needs to follow that platforms rules for clustering. Technically, its not likely an issue, but doing so would mean that application is now much less portable than if it were not written to take advantage of one OS platforms clustering. And in the UNIX world, portability is a a much bigger deal than it is on OpenVMS. With VMS, if you follow the standard rules, then your app should have no issues co-existing with other app's on the same system (assuming overall performan= ce is managed of course.) [insert discussion from those who think UNIX culture of doing their own thing is not an impediment to App stacking on centralized UNIX servers.] 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: Sun, 19 Aug 2007 19:32:38 -0500 From: "Paul Raulerson" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: <001101c7e2c1$9d14f3b0$d73edb10$@com> > -----Original Message----- > From: Main, Kerry [mailto:Kerry.Main@hp.com] > Sent: Sunday, August 19, 2007 2:57 PM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: Wonderful things happen to an OS when it has an internal > champion > > > -----Original Message----- > > From: David J Dachtera [mailto:djesys.no@spam.comcast.net] > > Sent: August 19, 2007 12:53 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: Wonderful things happen to an OS when it has an internal > > champion > > > > [snip...] > > > There are probably some ways around this using Windows environment > > symbols. > > However, this would be so far outside of the typical Windows > > programmer's > > paradigm that trying to introduce it now would be tantamount to > > introducing a > > whole new operating environment. > > > > Indeed, these critters have grown so accustommed to "I'll solve this > > problem MY > > way, regardless of whether it clashes with anything else" that the > > probability > > of changing it short of WMware or equiv. is indeed quite low. > > > > -- > > David J Dachtera > > dba DJE Systems > > http://www.djesys.com/ > > Yep, and one could argue that while perhaps not to the same extent, the > same is true of UNIX environments i.e. it is not technical issues, but > rather culture issues which are the biggest impediment to App stacking. > > In some ways, OpenVMS is proprietary and has a culture associated with > "this is the way you do things.." and that is a really good thing. This > applies to things like app clustering and different application modules > (written in diff languages) data and resource sharing rules that need > to > be followed in order for everyone in the sand box to play together > nicely > in a safe, scalable and very secure manner. > > Now, in the UNIX environment, in order for an App to take advantage of > the > local OS platform clustering technology, it needs to follow that > platforms > rules for clustering. Technically, its not likely an issue, but doing > so > would mean that application is now much less portable than if it were > not > written to take advantage of one OS platforms clustering. And in the > UNIX > world, portability is a a much bigger deal than it is on OpenVMS. With > VMS, > if you follow the standard rules, then your app should have no issues > co-existing with other app's on the same system (assuming overall > performance > is managed of course.) > > [insert discussion from those who think UNIX culture of doing their own > thing is not an impediment to App stacking on centralized UNIX > servers.] > Actually, it is very common to "app stack" under UNIX of all flavors, mostly because that is exactly what you are doing with all kinds of servers such as web servers, ftp servers, e-mail servers, etc. User applications also tend to run very well, as they are not capable of clobbering each other, memory or process wise. Windows, if you put something like Citrix on it, has no trouble at all running a few hundred copies of Word, Excel, Outlook, Access, InDesign, Terminal Emulators, etc. The culture clash you allude too seems to be dissolving in the current $$ squeeze, though Windows still lacks a decent workload manager. AIX has a very good one, and other versions of UNIX have - "sortof" halfway attempts at it. VMS has a very good workload manager of course. -Paul > 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: 19 Aug 2007 21:48:06 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: In article <46C8755C.1527DBC0@spam.comcast.net>, David J Dachtera writes: > Another major limitation is the lack of VMS-like logical names. One way that > multiple app.'s - even multiple instances of the same app. - are separated in > VMS-land is by the use of group-level and privately-named logical name tables. > That way my "C" drive could be anything from DKB100: to DAVIDS-INSTANCE: > (DKB100:[david.]/trans=conc), while yours could be anything from DKB200: to > YOUR-INSTANCE: (DKB100:[yours.]/trans=conc) as just one example. And commercial product FOO, with a registered facility name, will have logical names beginning with FOO$, avoiding name collisions with other products or site-specific logical names. ------------------------------ Date: Sun, 19 Aug 2007 20:52:29 -0700 From: "winston19842005@yahoo.com" Subject: You know you've been around VMS too long when... Message-ID: <1187581949.002440.161280@a39g2000hsc.googlegroups.com> your 6 year old son threatens to spank your 3 year old daughter, and you tell him "You aren't allowed to spank her - you don't have OPER priv." ------------------------------ End of INFO-VAX 2007.455 ************************