INFO-VAX Sat, 26 May 2007 Volume 2007 : Issue 288 Contents: Re: Anyone know why the Alpha market is so so quiet? RE: Anyone know why the Alpha market is so so quiet? Re: Is VMS losing the Financial Sector, also? Kits available Re: OM Group acquired by Nasdaq - VMS probably out Re: OM Group acquired by Nasdaq - VMS probably out Re: OM Group acquired by Nasdaq - VMS probably out Re: SYSMAN: No SYS$SCRATCH/SYS$LOGIN ? Re: TCPIP Services SMTP, RBLs blocking all inbound email VMS job in Germany RE: VMS job in Germany ---------------------------------------------------------------------- Date: Sat, 26 May 2007 06:51:51 -0500 From: pechter@i4get.(none) (William Pechter) Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: In article <1179847916.555477.223420@z24g2000prd.googlegroups.com>, Andrew wrote: >On 20 May, 15:43, Chip Coldwell wrote: >> On Fri, 18 May 2007, ChrisQuayle wrote: >> >> > Why would anyone in their right mind want to run Linux for mission critical >> > stuff when Solaris is now free, industrial strength, has decades of >> > professional development effort and runs on Sparc or X86 ? >> >> Because they are pessimistic about the long-term prospects for Sun as a >> company. Linux has the property that it is owned by nobody, so there is >> nobody to go broke and strand the customer. For example, you can now buy >> support for the Red Hat Enterprise Linux distro from either Red Hat or >> Oracle. If one of those two goes broke, switch to the other one. >> > >Ahh but this is Linux's great strength while at the same time being >its greatest weakness as well. > >>From a hobbyist perspective the bazaar approach to developing an OS >platform is very attractive, it bodes well for longevity and the rapid >inclusion of new features. That is if you do not care too much about >compatibility and stability. > >>From an enterprise perspective the bazaar approach causes huge >problems of ownership. The code maintainers and developers who will be >responsible for fixing XYZ issue almost certainly do not work for >Oracle or RedHat instead they may work in academia etc, so while >RedHat or Oracle may be able to manage your support problem ultimately >they may be powerless to effect a change that resolves your problem. > >Buying AIX/HP-UX/Solaris/Windows or VMS gives any enterprise customer >a degree of certainty that their problem will be rectified and in a >way that does not break random other bits of their OS, this certainty >simply isn't there in the Linux world. > Not true that the enterprise customer would get the support they pay for. In the mid 80's I worked for a Concurrent Computer in their IT dept. We noticed cron jobs were not getting run and cron was dying on their Xelos System V operating system. I reported the problem to support (I was internal to the company but used the normal support chanels.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. th.) The bug was kicked up to AT&T. The cron was malloc'ing memory and never releasing it so it used up all the memory available and then core dumped. The answer from the OS develeoper/vendor is "Get a machine with demand paged virtual memory, we never see the problem on those boxes." Thank you #@$ much AT&T. Having source code to the OS allows you to fix your own problmes. Counting on a vendor to do what they should do is leaving your fate in others hands. I've taken software issues to DEC, Sun, IBM etc. Sometimes the response is excellent... sometimes the response is dependant on the financial state and staff load at the company. At least Open Source (and Solaris is getting there) gives you the option to do it yourself. > >Regards >Andrew Harrison > Bill -- -- "When I think back on all the crap I learned in Vax school It's a wonder I fixed anything at all." (to the tune of Kodachrome) pechter-at-gmail.com ------------------------------ Date: Sat, 26 May 2007 12:55:07 -0400 From: "Main, Kerry" Subject: RE: Anyone know why the Alpha market is so so quiet? Message-ID: > -----Original Message----- > From: William Pechter [mailto:pechter@i4get.tay.hp.com (none)] > Sent: May 26, 2007 7:52 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Anyone know why the Alpha market is so so quiet? >=20 [snip...] > Having source code to the OS allows you to fix your own problmes. > Counting on a vendor to do what they should do is leaving your fate in > others hands. I've taken software issues to DEC, Sun, IBM etc. > Sometimes the response is excellent... sometimes the response is > dependant on the financial state and staff load at the company. >=20 > At least Open Source (and Solaris is getting there) gives you the > option > to do it yourself. >=20 > > > >Regards > >Andrew Harrison > > >=20 >=20 > Bill > -- > -- Yep, of course that assumes that you know and understand advanced kernel resource scheduling, SMP synchronization techniques, cluster co-ordination logic, IO driver debugging, thread synchronization in SMP, clustered environments etc etc.=20 And yes, you can throw your problem out on some list server or newsgroup or web forum and hope that someone who really does understand these issues has the time and energy to not only understand the issue, but also develop a patch for the problem. And of course, once you customize your environment, then you have to ensure that all future security patches, OS upgrades etc do not break because of the Custom code you installed. Open source was the hot topic for awhile, and will certainly have a place in some areas. However, a trend I see emerging right now is that many med-large Cust's do not want their IT staff playing in the OS weeds. They would much rather their senior IT folks engaging with the Business Units to better understand their issues and working with them to understand how IT can add value to their bottom lines. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sat, 26 May 2007 10:52:15 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Is VMS losing the Financial Sector, also? Message-ID: In article , "Richard Maher" writes: > When OM Gruppen failed in its bid for the London Stock Exchange (Is "LSE" > the London School of Economics?) I thought someone may try to turn the > hunter into the hunted, but that was a few years ago now. Where exactly are > these rumours abounding? All over the place. I'm not on the lookout for such rumours, so if I've heard them, they must be quite common. > > Note that Deutsche Börse (sp ?) Spelling is correct. > bought into the International Securities > > Exchange (ISE) in New York. But this is neutral to VMS since both are > > VMS shops. Indeed. ------------------------------ Date: Sat, 26 May 2007 10:10:10 -0700 From: "Tom Linden" Subject: Kits available Message-ID: Have a number of VMS kits VAX, Alpha I64 eval, Tru64, SPL's Doc's for all going back to 1999, If you want something send me mail and I will see if I have it, these are otherwise heading for the recycle bin. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Sat, 26 May 2007 10:57:23 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: OM Group acquired by Nasdaq - VMS probably out Message-ID: In article , clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes: > > According to what I hear this morning, VMS will be phased out. > > > > I don't suppose anyone from HP can go and have a chat ? > > [Or can I assume that things are too far along for this to do any good ? :-(] > > It's not nice been forced onto other platforms because VMS doesn't offer > a competitive application portfolio anymore. :-( Decisions to move away from VMS are not based on merit. There are extremely profitable stock exchanges running VMS. If OMX is bought and drops VMS, then not because VMS can't compete. > If we are to lose VMS, I don't suppose there's any chance that VMS technology > could be contributed to other operating systems rather than seeing it be > lost ? I would rather have no VMS at all (or move into a non-computing job) than have some watered-down VMS. ------------------------------ Date: Sat, 26 May 2007 14:58:40 +0200 From: "P. Sture" Subject: Re: OM Group acquired by Nasdaq - VMS probably out Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote: > I would rather have no VMS at all (or move into a non-computing job) > than have some watered-down VMS. Something about that statement reminds me of NT... :-( -- Paul Sture ------------------------------ Date: Sat, 26 May 2007 13:46:30 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: OM Group acquired by Nasdaq - VMS probably out Message-ID: <00A68303.33AAAAC4@SendSpamHere.ORG> In article , "P. Sture" writes: > > >In article , > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to > reply) wrote: > >> I would rather have no VMS at all (or move into a non-computing job) >> than have some watered-down VMS. > >Something about that statement reminds me of NT... :-( NT is completely submerged, not just watered-down. It's inundated in the mirk and mire that is the WEENDOZE mentality. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Sat, 26 May 2007 11:02:19 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: SYSMAN: No SYS$SCRATCH/SYS$LOGIN ? Message-ID: In article <7b251$4657378a$cef8887a$16480@TEKSAVVY.COM>, JF Mezei writes: > $ mc sysman > SYSMAN> set env/node=velo > %SYSMAN-I-ENV, current command environment: > Individual nodes: VELO > Username JFMEZEI will be used on nonlocal nodes > > SYSMAN> do show log sys$scratch > %SYSMAN-I-OUTPUT, command execution on node VELO > %SHOW-S-NOTRAN, no translation for logical name SYS$SCRATCH > SYSMAN> > > There is also no SYS$LOGIN defined. Of course, you can (and should) define SYS$SCRATCH yourself, and if you want, it would also be available with SYSMAN (F$MODEE() .EQS. "OTHER"). From SYS$SYLOGIN: $ Set NoOn $ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY")) $! we need this later on $! $ USERNAME = F$EDIT(F$GETJPI("","USERNAME"),"TRIM") $! $! $ Goto MODE_'F$MODE()' $! $! $MODE_INTERACTIVE: $! Fall through... $! $MODE_BATCH: $! Fall through... $ $MODE_NETWORK: $ $! Place those commands that should be available to interactive users, $! to batch jobs, and to network jobs, below. (Few commands should be $! placed here, as network tasks do not normally need symbols nor $! logical names defined in SYLOGIN.) $ $ $! Fall through... $ $MODE_OTHER: $ $! Place those commands that should be available to interactive users, $! to batch jobs, and to network jobs, below. (Very few commands should $! be placed here, as detached processes do not normally need symbols nor $! logical names defined in SYLOGIN.) $! $! $! SYSMAN is mode OTHER, so stuff needed by SYSMAN should go in here $! $! $ @ SYS$MANAGER:TCPIP$DEFINE_COMMANDS $! $! $! SYS$SCRATCH etc $! $ IF F$GETDVI("DISK$SCRATCH","EXISTS") $ THEN $ IF F$GETDVI("DISK$SCRATCH","AVL") .AND. F$GETDVI("DISK$SCRATCH","MNT") $ THEN $ DEFINE/JOB SYS$SCRATCH DISK$SCRATCH:['USERNAME'] $ ELSE $ DEFINE/JOB SYS$SCRATCH DISK$USER:[SCRATCH.'USERNAME'] $ ENDIF $ ELSE $ DEFINE/JOB SYS$SCRATCH DISK$USER:[SCRATCH.'USERNAME'] $ ENDIF $! $! $ Exit 1 > What is the reason behind the lack of those logicals ? There's probably a historical reason. ------------------------------ Date: Sat, 26 May 2007 10:46:40 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TCPIP Services SMTP, RBLs blocking all inbound email Message-ID: In article <34aef$4655f5fd$cef8887a$29388@TEKSAVVY.COM>, JF Mezei writes: > You can also configure your DNS resolvers to NOT try your local domain > if the request initially fails. > > (I think it is TCPIP SET NAME/NODOMAIN/SYSTEM and/or SET NAME/NOPATH ) > > This however will prevent you from doing a > $TELNET PASTRY > > and you will have to do a TELNET PASTRY.CHOCOLATE.COM Unless you have PASTRY in your local hosts database. ------------------------------ Date: Sat, 26 May 2007 11:04:32 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: VMS job in Germany Message-ID: I know someone offering a permanent VMS position in Germany. Contact me via email if you are interested. ------------------------------ Date: Sat, 26 May 2007 12:56:24 -0400 From: "Main, Kerry" Subject: RE: VMS job in Germany Message-ID: Developer or Sys Manager? Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. > -----Original Message----- > From: Phillip Helbig---remove CLOTHES to reply > [mailto:helbig@astro.multiCLOTHESvax.de] > Sent: May 26, 2007 7:05 AM > To: Info-VAX@Mvb.Saic.Com > Subject: VMS job in Germany >=20 > I know someone offering a permanent VMS position in Germany. Contact > me > via email if you are interested. ------------------------------ End of INFO-VAX 2007.288 ************************