1 INFO-VAX	Mon, 10 May 2004	Volume 2004 : Issue 258       Contents: Re: another DFO question Re: another DFO question& AUTOGEN and swap and page file (names)N Re: DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...]8 Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time Re: DEC C fsync and fflush environmental consoles...  Re: environmental consoles... < HBVS, shutdown procedures, dismounting disks, SHADOW_MBR_TMOJ Re: HP World Magazine: For Business Continuity...the answer may be OpenVMSJ Re: HP World Magazine: For Business Continuity...the answer may be OpenVMSP Re: HP World Magazine: For Business Continuity...the answer may be OpenVMS OpenVP Re: HP World Magazine: For Business Continuity...the answer may be OpenVMS OpenV4 Re: Linux on its way out - unless you are a geek ...< Re: looking for suggestions for new $GETDVI item codes . . . Re: more DFO questions Re: more DFO questions( Newbie Queue Manager in cluster question, Re: Newbie Queue Manager in cluster question Re: OT: McDonald's coffee again ( Re: Queuing a file to print from FORTRAN	 Re: RWINS 	 Re: RWINS  Re: VMS news on news.com) Re: You'll never guess what HP advertised ) Re: You'll never guess what HP advertised ) Re: You'll never guess what HP advertised ) Re: You'll never guess what HP advertised " [OT] Offshore outsourcing....again  F ----------------------------------------------------------------------  * Date: Sun, 9 May 2004 17:44:47 +0000 (UTC)6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)! Subject: Re: another DFO question 0 Message-ID: <newscache$stjgxh$00s$1@news.sil.at>  w In article <c7lj93$55m$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:   >Two questions, perhaps related. > J >Is there a way, with DEFRAGMENT MONITOR, for example, to estimate when a ' >defragmentation process will complete?    I never succeeded.  A >What is the Countdown parameter displayed by DEFRAGMENT MONITOR?    At free space defragmentation ? B If it is zero, then it is finished (or it starts again sometimes),E since freespace defragmentation is the last before EPILOGUE starts...   H >Another question: Presumably, there is no danger in aborting a running J >script.  If it is then restarted, will the time to completion be more or J >less the time which the script had remaining before being aborted, or is I >there a significant overhead in restarting, meaning that the total time   >would be greater?  O No, it would start from the beginning. Means Scanning all files for candidates. H It will be faster than the first run (because some work is already done)J but together with the first run it is definitely slower than the first run4 alone if this would have had a chance to complete...   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  * Date: Sun, 9 May 2004 18:16:49 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)! Subject: Re: another DFO question $ Message-ID: <c7lsih$qem$2@online.de>  E In article <newscache$stjgxh$00s$1@news.sil.at>, peter@langstoeger.at $ (Peter 'EPLAN' LANGSTOEGER) writes:   y > In article <c7lj93$55m$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: " > >Two questions, perhaps related. > > L > >Is there a way, with DEFRAGMENT MONITOR, for example, to estimate when a ) > >defragmentation process will complete?  >  > I never succeeded. > C > >What is the Countdown parameter displayed by DEFRAGMENT MONITOR?  > ! > At free space defragmentation ?    Yes.  D > If it is zero, then it is finished (or it starts again sometimes),G > since freespace defragmentation is the last before EPILOGUE starts...   H OK, so one can roughly estimate completion time by seeing how fast this - number decreases---if it doesn't start again.    ------------------------------  * Date: Sun, 9 May 2004 22:04:14 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)/ Subject: AUTOGEN and swap and page file (names) $ Message-ID: <c7m9su$3dp$1@online.de>  F I know that I can tell AUTOGEN not to mess with page files, and in my G case, since the values for the sizes are either hard-coded or set to a  E minimum value which is more than large enough, it doesn't, no matter  I what arguments I execute it with.  Rather, I'm trying to understand what   is going on.  H Due to reasons I can no longer figure out, AUTOGEN has the names of two  page files reversed.  ; In MODPARAMS.DAT, I specify PAGEFILE1_NAME, PAGEFILE2_NAME, G SWAPFILE1_NAME and SWAPFILE2_NAME.  I have two page and two swap files, F with the primary ones being on the system disk.  The primary files areE "1", the others are "2".  I have run AUTOGEN several times, more than D enough to "clean things out", but have not rebooted several times if& that is needed to "clean things out".   C AUTOGEN complains that there are duplicate values for both pagefile B names and one of the swap file names.  In the case of the pagefileG names, they are reversed, as indicated (as seen in AGEN$PARAMS.REPORT)  F but they are not reversed in the case of the swapfile names.  It says E that the values in MODPARAMS.DAT will override those in PARAMS.DAT.   F However, they don't----the wrong name is used in the calculation, and G even after a reboot things don't change.  (In the case of the swapfile  G names, in one case there is a ";" at the end, in the other there isn't. E Perhaps that is why it is complaining about duplicate names (though,  H strangely, it only does so for one, not for both) even though the names  appear to be correct.)  F I've even---shudder---tried editing PARAMS.DAT and AGEN$FEEDBACK.DAT, # but even that doesn't seem to work!   I Is there any way I can get AUTOGEN to make a completely fresh start with  + respect to the pagefile and swapfile names?   G Since the pagefile and swapfile names are not system parameters in the  I narrow sense, it is difficult to see what a running system really thinks  	 they are.   C Where does AUTOGEN get its information as to what the pagefile and  F swapfile names are on the running system?  If MODPARAMS.DAT specifies I the correct values, and (after editing) PARAMS.DAT and AGEN$FEEDBACK.DAT  < do so as well, why is it still picking up the "wrong" value?   ------------------------------   Date: 9 May 2004 21:39:24 -0700 . From: spamsink2001@yahoo.com (Alan E. Feldman)W Subject: Re: DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...] = Message-ID: <b096a4ee.0405092039.2d4dc16b@posting.google.com>   \ Paul Sture <nospam@sture.homeip.net> wrote in message news:<2g5uibF4o8fkU1@uni-berlin.de>... > Alan E. Feldman wrote:G > > How about directory listings sorted by date-time? Yes, you'd either H > > have to list a single directory or suppress the headers and trailersH > > for multi-directory listings, and you'd have to wait to see even the? > > first file listed. But so what -- it would still be useful.  > @ > Peter Weaver posted this neat trick with dates on 30-Apr-2004: > @ > Make sure you run it with SET TERM/WIDTH=132 to avoid wrapping >  > J > $ ! Needs @SYS$STARTUP:LIB$DT_STARTUP executing by privileged user first  > $ ASSIGN LIB$DATE_FORMAT_037,- >     LIB$TIME_FORMAT_001 -  >     LIB$DT_FORMAT/USER_MODE ' > $ directx -  ! Ignore any DIR symbols  >     /date=modified- # >     /width=(file:80,display:132)-  >     /out=out.txt > $ sort out.txt - >      /key=(pos:83,siz:22) tt:     C But I'd like to do it without messing with system logical names and $ within the directory command itself.   ------------------------------   Date: 9 May 2004 21:51:33 -0700 . From: spamsink2001@yahoo.com (Alan E. Feldman)A Subject: Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time = Message-ID: <b096a4ee.0405092051.296cddea@posting.google.com>   \ Paul Sture <nospam@sture.homeip.net> wrote in message news:<2g5u52F4orm9U1@uni-berlin.de>... > Alan E. Feldman wrote:F > > Any chance of having a time option added to SET PROMPT? Perhaps itJ > > could be added F$FAO style. Note: The time would be static -- it would< > > just be the time that the prompt appeared on the screen. > J > It's already there. It can be very useful for batch jobs in conjunction  > with verification. >  > & > $ SET PROMPT="''F$fao("!5%T",0)' $ "	 > 07:30 > 	 > 07:31 > - > 07:31 > SET PROMPT="''F$fao("!17%D",0)' $ "  >   9-MAY-2004 07:31 > >   9-MAY-2004 07:31 >  E Yes, I tried this. But it didn't work. I got the time alright. But it D was "frozen". That is, the time didn't advance with repeated pressesF of the Return key. And I don't see how your example could have worked.C The rules of DCL would evaluate the lexical function before the SET C PROMPT command would be executed, resulting in a fixed-time string,  which is NOT what I want.   C I tried it on VMS 6.2. What is your VMS? How could it have possibly @ worked given the symbol substituion rules of apostrophes in DCL?   ------------------------------  % Date: Sun, 09 May 2004 16:50:28 -0500 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler># Subject: Re: DEC C fsync and fflush E Message-ID: <craigberry-657429.16502809052004@chi.news.speakeasy.net>   @ In article <5b0ebda81d7392d6715102712227278e@news.teranews.com>,/  JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:    > M > In my notes, I had written that fsync was an undocumented function that did O > what fflush was supposed to do. Haven't revisited the issue since (many years  > ago) because the code works.  ? fflush() is in the C standard, which says it causes data to be  C "delivered to the host environment to be written to the file."  It  H seems to be carefully worded to allow for buffering and synchronization 8 activities that may complete after the function returns.  G fsync() is not specified in the C standard but is in POSIX, which says  H fsync() causes data to be "transferred to the storage device associated H with the file" and does not return until the transfer is complete.  The A rationale section goes on to elaborate, "The fsync() function is  F intended to force a physical write of data from the buffer cache, and F to assure that after a system crash or other failure that all data up 9 to the time of the fsync() call is recorded on the disk."   @ These well-documented behaviors are consistent with the HP CRTL D documentation, and as far as I know with the actual behavior of the  CRTL functions.   F I would guess that fsync() includes an implicit fflush(), but I don't F know for sure.  It would be nice to have this point clarified, but it 7 seems safest to do the fflush() first and then fsync().    ------------------------------  # Date: Sun, 09 May 2004 21:54:58 GMT % From: "Mike Naime" <mnaime@kc.rr.com> " Subject: environmental consoles...8 Message-ID: <SMxnc.28304$ee7.3126@twister.rdc-kc.rr.com>  G Ok, I was replacing a failed power supply and the environmental console K question came up this morning.  The FE and I came up with this list for the  Alphaservers that I have.   = These are all accessed by the "OPA0" port on the Alphaserver. + 4000   ^]^]RCM  (control-], control-], rcm)  DS10L esc-esc-rmc  DS10 esc-esc-rmc, DS20E   ^]^]RCM  (control-], control-], rcm) DS25    esc-esc-rmc  ES40.  esc-esc-rmc ES45.  esc-esc-rmc GS160/320 esc-esc-scm   G Marvel line.  Here is where they re-designed and split up the consoles. G ES47/GS1280  "Connect" to get to the Alphaserver console port(s) if not @ already actively monitored or connected.  esc-esc-MBM to return.J Note: All consoles for the Marvel line are Telnet sessions through the SMCJ router.  MBM console on port 23.  Alphaserver consoles for the SBB's start! at port 323 and go up from there.    ------------------------------  $ Date: Sun, 9 May 2004 23:11:23 +0100< From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>& Subject: Re: environmental consoles...) Message-ID: <c7ma9n$npn$1@news.wplus.net>   0 "Mike Naime" <mnaime@kc.rr.com> wrote in message2 news:SMxnc.28304$ee7.3126@twister.rdc-kc.rr.com...I > Ok, I was replacing a failed power supply and the environmental console I > question came up this morning.  The FE and I came up with this list for  the  > Alphaservers that I have.  > ? > These are all accessed by the "OPA0" port on the Alphaserver. - > 4000   ^]^]RCM  (control-], control-], rcm)  > DS10L esc-esc-rmc  > DS10 esc-esc-rmc. > DS20E   ^]^]RCM  (control-], control-], rcm) > DS25    esc-esc-rmc  > ES40.  esc-esc-rmc > ES45.  esc-esc-rmc > GS160/320 esc-esc-scm  > I > Marvel line.  Here is where they re-designed and split up the consoles. I > ES47/GS1280  "Connect" to get to the Alphaserver console port(s) if not B > already actively monitored or connected.  esc-esc-MBM to return.L > Note: All consoles for the Marvel line are Telnet sessions through the SMCL > router.  MBM console on port 23.  Alphaserver consoles for the SBB's start# > at port 323 and go up from there.  >    That is wrong.  G While it is not documented anywhere I have seen, you can plug a console J directly into the first 2P unit in each RAD (into the 9pin Serial) and useE this as a serial console. I have done this on both ES80's and ES47's.   H You do not have to use the NAT box to get a console. Although you shouldJ still run a cable up to the NAT box, or you can get some errors on bootingL from MBM to SRM. You can then use your incumbant Console Monitoring software% via a terminal server if you so wish.    Alex   ------------------------------  * Date: Sun, 9 May 2004 20:05:12 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)E Subject: HBVS, shutdown procedures, dismounting disks, SHADOW_MBR_TMO $ Message-ID: <c7m2to$b91$1@online.de>  H Hobbyist cluster, all disks are physical SCSI disks (or, in one case, an< RF disk on a DSSI bus) MSCP served to all nodes.  No SAN, noG controller-based RAID etc.  Most of the disks are in shadow sets which, F unless it is the system disk, has members on more than one node.   AllH disks, whether shadowed or not, are mounted by all nodes in the cluster.  I Occasionally, I want to reboot just one node in the cluster.  I'm trying  G to figure out what disks to dismount before doing a reboot.  There are  " the following categories of disks:  3    A. non-shadowed disks on the node to be rebooted   '    B. non-shadowed disks on other nodes   =    C. shadow sets with all members on the node to be rebooted   1    D. shadow sets with all members on other nodes   K    E. shadow sets with some members on the node to be rebooted and some on          other nodes  H There is also the question whether the dismount needs to be done on the ) node shutting down or on the other nodes.   E I've had a look at SYS$SYSTEM:SHUTDOWN.COM, but the code is not very   easy to follow.  :-|  I Here is my gut feeling: B is not necessary, in E: I need to dismount the  B members with a direct connection to the node to be rebooted, A is # probably necessary, as are C and D.   F SHUTDOWN.COM does dismount some disks, of course.  As the code is not F very easy to follow, does anyone know which of the A--E above it does?  ; How is any of this related to the value of SHADOW_MBR_TMO?  I SHADOW_MBR_TMO is probably more relevant to an unexpected reboot without  H a clean shutdown caused by a power outage, crash of a machine etc.  The B default is 120 seconds.  What, if any, disadvantages are there in   setting it to a very high value?  I It seems that SHUTDOWN.COM invokes the site-specific shutdown procedure,  B where my own dismount commands would logically be located, before D stopping the audit server and the smi server.  This is unfortunate, F since if the corresponding files are not on the system disk (as in my I case, so that they can be common throughout the cluster and available to  I all members which are up), this disk cannot be dismounted.  A workaround  H would be to shut down the audit server etc in my site-specific shutdown B procedure before dismounting the disk, but that seems rather ugly.   ------------------------------  $ Date: Sun, 9 May 2004 19:16:53 -0400* From: "Bill Todd" <billtodd@metrocast.net>S Subject: Re: HP World Magazine: For Business Continuity...the answer may be OpenVMS 2 Message-ID: <gpidnSCcstxYJgPdRVn-gQ@metrocast.net>  B "Robert Deininger" <rdeininger@mindspringdot.com> wrote in messageF news:rdeininger-0905041254060001@user-uinj4h4.dialup.mindspring.com...   ...   C > Intel seems to be launching improved Itanium CPUs every couple of  > quarters.   2 For unusually large values of a 'couple', perhaps.  F Merced was launched in May, 2001 (just in time to have a working - oneK hesitates to say 'running' - Itanic on the market before Alpha was killed).   K I don't recall any Itanic 'improvements' between then and early July, 2002, F when McKinley was launched (at least nominally - availability prior toJ latish September of that year seemed to be somewhat questionable).  That'sA over 4 quarters (accepting the July launch date), not a 'couple'.   L Then it took almost exactly another full year (again, with no 'improvements'B that I can remember) until Madison was launched, on June 30, 2003.  I And here we are nearly a full year later, and AFAIK that mid-2003 1.5 GHz I Madison is still the fastest Itanic on the block, though a few additional K *lower*-performance variants have appeared in the interim.  Some marginally E faster (1.7 GHz or so) clock rates are rumored to be imminent, and/or I expansion of the on-chip cache to 9 MB (whether both will be available in L the same chip is not clear), but even if these relatively minor advances (atF least compared with the progress from Merced to McKinley, or even withD McKinley to Madison) appear immediately that still makes the averageL interval between Itanic 'improvements' a full year, rather than a 'couple of
 quarters'.  D And Montecito (the next projected significant Itanic revision) isn'tL scheduled to appear before some time in 2005, with Tukwila (the first *real*K redesign since McKinley, since McKinley, Madison, Madison II, and Montecito F all share the same basic core) reportedly planned for 2006 (or perhapsJ 2007), both of which appear to project that same schedule into the future.G So where you got your 'couple of quarters' figure for the rate at which ? Itanic 'improves' is, to say the least, something of a mystery.   A   Of course HP expects that they will be faster in 2005 than they 
 > are now.  D This is hardly surprising:  HP (and Compaq before it) have had greatE expectations for Itanic right along, despite rather clearly troubling D suggestions to the contrary.  In the case of the move to 90 nm. withL Montecito, those suggestions are found in the facts that Intel has had greatI difficulty making its new 90 nm. x86 Prescott chips run *any* faster than J its previous 130 nm. P4s, nor do the Prescotts use any less power, meaningL that if Montecito experiences anything like similar problems they'll have toF disable one of its two cores just to allow the chip to *match* today's2 Madison clock rate within the same power envelope.  I No wonder Dubya chose Carly as an advisor:  they both have that same "Can K do!" attitude that blithely and utterly ignores any annoying expert opinion D (and even clear evidence) that might tend to get in the way of their rose-colored predictions.    ...     VMS on low-end (can IK > say entry-level?) Itaniums like rx1600 will probably be cheap compared to ! > low-end AlphaServers like DS15.   G That's pretty much a matter of how HP chooses to price and position the F various products, I suspect.  IIRC you could buy a DS10 VMS system forH around $6K a few years ago, and hardware component prices have certainly! dropped significantly since then.    - bill   ------------------------------   Date: 10 May 2004 05:20:16 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>S Subject: Re: HP World Magazine: For Business Continuity...the answer may be OpenVMS ? Message-ID: <DTiotGxQ0bj6-pn2-1Qg0tHo0Jgd7@dave2_os2.home.ours>   * On Sat, 8 May 2004 21:44:11 UTC, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:   " > Peter 'EPLAN' LANGSTOEGER wrote:N > > My prediction: VMS will die with/cause-of ITANIC and earlier than we fear. > M > I hope that in this probably long process, HP stops developping VMS on IA64 L > and continues a few versions on Alpha since that is where the demand wouldR > still be. That would send such a strong message to the likes of Curly and Carly.  E Despite the schadenfeude that this would generate and the deep sense  F of unwanted(?) satisfaction about having a better idea of how to run aD business than the current and previous incumbents of VMS ownership, F that would probably be the nail in VMS and HP's (OS) coffin. There areF people who believed the IA64/Alpha hype, companies who have committed F cash to IA64 ports (VMS and Unix variants). If it stops then VMS does  too.   Broken Commitments ?!?!    --   Cheers - Dave.   ------------------------------  # Date: Sun, 09 May 2004 18:18:56 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> Y Subject: Re: HP World Magazine: For Business Continuity...the answer may be OpenVMS OpenV @ Message-ID: <e1f46fccade0fa9fdf8e2ad9d86a80d9@news.teranews.com>   Robert Deininger wrote: I > low-end AlphaServers like DS15.  As long as both platforms have VMS and J > "mainstream" IO support like SCSI, LAN, and FibreChannel, most customersG > won't care about the HW details.  But they will care about the price.   K You are probably blinded by the large fence which surrounds VMS engineering * from the real world. (sorry to be blunt).   K There are two major issues that you have forgotten to mention which are far  more important to customers:   -cost of migration  I if you have in-house apps, they need to be ported. Even if the porting is C simple, it requires building a test environment, and rebuilding the N applications from scratch and testing it. Then you can think about a migration plan to put it into production.   I It is also a question of rebuilding all your environment (all those small , utilities you have gathered over the years).    5 -whether 3rd part apps are will be available on IA64.   K Remember that even many DEC products won't make it to IA64 because they got L the axe after they were ported to Alpha. So a customer who runs one of thoseN apps simply cannot migrate to IA64 and chances are that if he can wein himselfR from that app, he will do so by migrating to a mainstream platform (unix/windows).    M From the engineer's point of view, their responsability is to make recompiles I simples. And I am confident that you will have done an outstanding job of L this. However, that is a small part of any port of a commercial application.   ------------------------------  % Date: Mon, 10 May 2004 03:15:35 +0800 , From: Paul Repacholi <prep@prep.synonet.com>Y Subject: Re: HP World Magazine: For Business Continuity...the answer may be OpenVMS OpenV - Message-ID: <87vfj5pg2w.fsf@prep.synonet.com>   / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   E > One article I read had one HP rep state that VMS on IA64 might come > > (commercially) in 2005 rather than late 2004.  This opens up. > interesting possibilities for speculation...  = If we assume that this is totally true etc (silly perhaps...)   @ It is most likley that the `release' will be with some new modelE of the chipheater, so if the intanicIII needs extra swimming lessions + then VMS will be draged downstream with it.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 10 May 2004 03:41:18 +0800 , From: Paul Repacholi <prep@prep.synonet.com>= Subject: Re: Linux on its way out - unless you are a geek ... - Message-ID: <87n04hpew1.fsf@prep.synonet.com>   ; Andrew Harrison <andrew_._remove_harrison@su_n.com> writes:   # > Can you still buy a StarCoupler ?   @ Yes, but why would you when you can be almost paid to carry them" away? Idiots do have their uses :)   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 10 May 2004 03:08:42 +0800 , From: Paul Repacholi <prep@prep.synonet.com>E Subject: Re: looking for suggestions for new $GETDVI item codes . . . - Message-ID: <87zn8hpged.fsf@prep.synonet.com>   R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  C > How about the possibility to get ALL terminal attributes with one F > call, and a way to set them ALL back, instead of one line of DCL for > each TT thingy.   F At the program level, RSX could do that, and I would be amaised if VMS/ can't. Time for Kermit to be borged with DCL :)      --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  * Date: Sun, 9 May 2004 18:15:30 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: more DFO questions $ Message-ID: <c7lsg1$qem$1@online.de>  E In article <newscache$1ajgxh$wyr$1@news.sil.at>, peter@langstoeger.at $ (Peter 'EPLAN' LANGSTOEGER) writes:   H > >> >I have DF0 2.6 on all nodes (2 VAX and 1 ALPHA).  Soon, I plan to  > >> >install 2.7.   > >>   > >> V2.8 is current.  > >  > >When did it come out? > ? > About Oct/Nov 2003. After being in fieldtest for some months.   H OK, I have the VAX LP distribution from SEP03.  I have a somewhat newer B ALPHA distribution.  IIRC, for DFO the kit includes VAX and ALPHA I software and the proper stuff is selected at installation time.  Maybe I   have 2.8 on the VAX CDs.  / > It is said to be required for OpenVMS V7.3-2.   D I guess you mean that 7.3-2 is required for DFO 2.8.  Or is DFO 2.8 % required if one runs DFO under 7.3-2?   E > >OK, this seems to work---almost.  SYS$STARTUP:DFG$STARTUP defines  F > >logicals and starts the scheduler.  There seems to be no supported L > >mechanism for defining these logicals to something else.  If one defines G > >them after the startup, then one has to manually stop and start the  ) > >scheduler.  Or am I missing something?  >  > No, you're right. I > Change SYS$STARTUP:DFG$STARTUP.COM or some kind of force DEC/CPQ/HPQ to J > honor previous logical definitions (in SYLOGICALS.COM) with DFG$STARTUP.  G I guess the proper way to do this would have DFG$STARTUP to define the  * logical only if it is not already defined.   ------------------------------  $ Date: Sun, 9 May 2004 19:34:58 +0100< From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk> Subject: Re: more DFO questions * Message-ID: <c7ltng$1q8a$1@news.wplus.net>  L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>/ wrote in message news:c7lsg1$qem$1@online.de... G > In article <newscache$1ajgxh$wyr$1@news.sil.at>, peter@langstoeger.at % > (Peter 'EPLAN' LANGSTOEGER) writes:  > I > > >> >I have DF0 2.6 on all nodes (2 VAX and 1 ALPHA).  Soon, I plan to  > > >> >install 2.7. > > >> > > >> V2.8 is current.  > > >  > > >When did it come out? > > A > > About Oct/Nov 2003. After being in fieldtest for some months.  > I > OK, I have the VAX LP distribution from SEP03.  I have a somewhat newer C > ALPHA distribution.  IIRC, for DFO the kit includes VAX and ALPHA J > software and the proper stuff is selected at installation time.  Maybe I > have 2.8 on the VAX CDs. > 1 > > It is said to be required for OpenVMS V7.3-2.  > E > I guess you mean that 7.3-2 is required for DFO 2.8.  Or is DFO 2.8 ' > required if one runs DFO under 7.3-2?  > <SNIP>   2.8 on Alpha...   J Disk File Optimizer  2.8     6.1   7.3-2    Mar 04     55.85 2GNAA X  X  X  
 2.8 on VAX  K Disk File Optimizer    2.8   6.0    7.3      Mar 04     55.85 GJ8AA X  X  X   L Ok, from the support chart it seems 2.8 runs on 6.0 VAX 6.1 Alpha through to 7.3-2.K I am running 2.8 successfully on 7.3-2, upgraded it at the same time as the  OS.    And here's the 2.7 details...   E Disk File Optimizer       VA  2.7ECO  N  6.2   7.3-2  55.85 2GNAA NOW    Alex   ------------------------------  # Date: Sun, 09 May 2004 19:29:10 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Newbie Queue Manager in cluster question @ Message-ID: <9f1e5f60a7a38f726e430b9b8f549857@news.teranews.com>  N I have 2 nodes with separate system disks (node1 started off as stand-alone in the 4.7 time frame)   . On node1, I had START/QUEUE/MANAGER/ON=(NODE1)  O on node2, I had DEFINE/SYSTEM QMAN$MASTER  directory spec of node1's sys$system  			START/QUEUE/MANAGER 			ENABLE AUTOSTART   L Node1 failed and rebooted. However, in the process, the TCPIP$SMTP queues onJ node2 stopped and didn't restart. Wishing to investigate, I noticed in the0 help that using /ON disables autostart features.  J Should I just have a START/QUEUE/MANAGER without any added options on both nodes ? E I can't remember why I added the /ON=(NODE1) only to node1's startup.    ------------------------------  * Date: Sun, 9 May 2004 19:49:27 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)5 Subject: Re: Newbie Queue Manager in cluster question $ Message-ID: <c7m207$4qa$1@online.de>  C In article <9f1e5f60a7a38f726e430b9b8f549857@news.teranews.com>, JF - Mezei <jfmezei.spamnot@teksavvy.com> writes:    P > I have 2 nodes with separate system disks (node1 started off as stand-alone in > the 4.7 time frame)  > 0 > On node1, I had START/QUEUE/MANAGER/ON=(NODE1) > Q > on node2, I had DEFINE/SYSTEM QMAN$MASTER  directory spec of node1's sys$system  > 			START/QUEUE/MANAGER > 			ENABLE AUTOSTART   8 Won't this prevent failover to node2 when node1 is down?  N > Node1 failed and rebooted. However, in the process, the TCPIP$SMTP queues onL > node2 stopped and didn't restart. Wishing to investigate, I noticed in the2 > help that using /ON disables autostart features.  & Where exactly in HELP do you see this?  L > Should I just have a START/QUEUE/MANAGER without any added options on both
 > nodes ?   H In that case, it's like /ON=*.  The difference between * and explicitly I listing all nodes is that in the latter case you can specify an order of   preference.   G > I can't remember why I added the /ON=(NODE1) only to node1's startup.    ------------------------------  % Date: Mon, 10 May 2004 03:36:36 +0800 , From: Paul Repacholi <prep@prep.synonet.com>( Subject: Re: OT: McDonald's coffee again- Message-ID: <87r7ttpf3v.fsf@prep.synonet.com>   4 williamwebb@openvms-rocks.com (William Webb) writes:  F > Contingent liability is becoming a forgotten concept, in other words= > taking into consideration how much each party was at fault.   < Contingent liability is alive and very well, even in the US.  F In the McCoffee case, almost all of the award was for special punitiveC damages. They had been warned about the danger, they wanted to save E less than 1c per cup, so the award gave the total for the US for that 	 year, x3.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Mon, 10 May 2004 01:16:33 GMT % From: "John Vottero" <John@mvpsi.com> 1 Subject: Re: Queuing a file to print from FORTRAN ? Message-ID: <RJAnc.5429$eH1.2785445@newssvr28.news.prodigy.com>   B "Bradford J. Hamilton" <brad@rabbit.dnsalias.org> wrote in message& news:onWmc.1136$xw3.97613@attbi_s04...G > In article <TzUmc.4370$eH1.2297743@newssvr28.news.prodigy.com>, "Johne! Vottero" <John@mvpsi.com> writes:  > !snip! > !s  > !Don't change the application! > !aI > !Just create some fake LTA devices and set them spooled pointing to theF new.K > !TCPIP queues.  The LTA devices don't have to point to an actual terminal ( > !server because they'll never be used. > !i > !An example: > ! ! > !$ MCR LATCP CREATE PORT LTA888n3 > !$ SET DEVICE/SPOOLED=(ANY_QUEUE_YOU_WANT) LTA888r > !$ COPY SOMEFILE.TXT LTA888: > !  >OE > I don't have access to a cluster (and generic print queues).  Is it  possible toe, > point a spooled device at a generic queue? >e  9 I just tried it and it worked.  This was with VMS V7.3-2.n   ------------------------------  # Date: Sun, 09 May 2004 23:49:45 GMTt( From: "konabear" <maurert@ameritech.net> Subject: Re: RWINS: Message-ID: <tsznc.576$Tg1.435@newssvr16.news.prodigy.com>  J There are a few ways to get an AMDS or AM (Availabilty Manager) session toI your desktop for monitoring and fixing.  If the box (Windows are OpenVMS) K running AMDS or AM is physically at your desk, then you'll need to have the < AMDS protocal bridged to the Ethernet segment for your cube.  I Another is to have the box physically located in the data center with the'I OpenVMS systems that are to managed.  You can run AMDS or AM (on Java) on-E OpenVMS, then DECwindows is used and simply needs to be pointed to an I Xserver on your PC as your desk.  OR you can use a Windows box running AMeK (agian on Java) and use some mechanism to serve the Windows desktop back toc you cube's PC.  K Now one might be tempted to say, "I already have OpenVMS in the datacenter.SK I'll just run the user GUI (data collector) for AMDS or AM on my productioneL system(s)."  However if you want to use the quorum or forces crash fixes, or@ if you want to monitor a hung node, this strategy will backfire.  L If all you hagve the $ for is to run AM or AMDS on your production box, thisL is better than nothing.  But IMHO to do it right requires that AM or AMDS beD run on a system separate from the production system or cluster.  OneL candidate is a ConsoleWorks system.  That is an OpenVMS box that is not partK of the cluster. (I hope!) However if no Consolework, then an OpenVMS systemiB to simply host AM or AMDS is not usually cost effective.  Here the2 AM/Windows/Desktop sharing often makes more sense.   Todd  K This assumes that network can't allow bridging of the AMDS protocol to your  cube's  ? AMDS on OpenVMS using DECwindoes and an Xwindows server on your F  0esktop is one way to get AMDS or AM (Availabitility Manager) on your desktop at your cube.h  K "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in messagee0 news:409ADA99.FE181D08@NeOaSrPtAhMlNiOnWk.net... > Keith Parris wrote:  > >pG > > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote inS: message news:<4088799B.9162BDA4@NeOaSrPtAhMlNiOnWk.net>...I > > > There is a problem with some versions of WEBES on GS1280s where therJ > > > DESTA Director process leaks BIOLM and gets wedged into RWAST with a* > > > BIOCNT (remaining BIOLM) of zero(0). > > ...cL > > > You can clear that by using STOP/ID, then go into SDA, find the "Busy"L > > > mailbox channels, and COPY NLA0: to those devices one-by-one until theG > > > process dies - it causes I/Os to complete which will release somem BIOLMTL > > > and allow the process to continue long enough to acknowledge and honor > > > the $DELPRC request. > >oJ > > Another way to deal with hangs due to quota exhaustion is to raise the8 > > process quota using Availability Manager or DECamds. >t > True.y >bF > Problem with them has always been the non-routable protocol. AMDS isI > VMS-based, but AM is WhineBloze which means your PC must be on the sameiH > VLAN or LAN segment as the VMS machine, and cluster comm. traffic must > traverse the ethernet. > B > Problem children like DESTA are best killed anyway. Since it's aH > resource leakage problem, upping the quota just delays the inevitable. >0 > -- : > David J. Dachtera  > dba DJE SystemsL > http://www.djesys.com/ >-* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/s   ------------------------------  # Date: Sun, 09 May 2004 23:49:54 GMT ( From: "konabear" <maurert@ameritech.net> Subject: Re: RWINS: Message-ID: <Csznc.577$Vc1.262@newssvr16.news.prodigy.com>  J There are a few ways to get an AMDS or AM (Availabilty Manager) session toI your desktop for monitoring and fixing.  If the box (Windows are OpenVMS) K running AMDS or AM is physically at your desk, then you'll need to have thel< AMDS protocal bridged to the Ethernet segment for your cube.  I Another is to have the box physically located in the data center with thewI OpenVMS systems that are to managed.  You can run AMDS or AM (on Java) onlE OpenVMS, then DECwindows is used and simply needs to be pointed to aneI Xserver on your PC as your desk.  OR you can use a Windows box running AMfK (agian on Java) and use some mechanism to serve the Windows desktop back tod you cube's PC.  K Now one might be tempted to say, "I already have OpenVMS in the datacenter.aK I'll just run the user GUI (data collector) for AMDS or AM on my production)L system(s)."  However if you want to use the quorum or forces crash fixes, or@ if you want to monitor a hung node, this strategy will backfire.  L If all you hagve the $ for is to run AM or AMDS on your production box, thisL is better than nothing.  But IMHO to do it right requires that AM or AMDS beD run on a system separate from the production system or cluster.  OneL candidate is a ConsoleWorks system.  That is an OpenVMS box that is not partK of the cluster. (I hope!) However if no Consolework, then an OpenVMS systemcB to simply host AM or AMDS is not usually cost effective.  Here the2 AM/Windows/Desktop sharing often makes more sense.   Todd  K This assumes that network can't allow bridging of the AMDS protocol to your  cube's  ? AMDS on OpenVMS using DECwindoes and an Xwindows server on youreF  0esktop is one way to get AMDS or AM (Availabitility Manager) on your desktop at your cube.m  K "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in messagea0 news:409ADA99.FE181D08@NeOaSrPtAhMlNiOnWk.net... > Keith Parris wrote:R > >AG > > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in$: message news:<4088799B.9162BDA4@NeOaSrPtAhMlNiOnWk.net>...I > > > There is a problem with some versions of WEBES on GS1280s where the9J > > > DESTA Director process leaks BIOLM and gets wedged into RWAST with a* > > > BIOCNT (remaining BIOLM) of zero(0). > > ...AL > > > You can clear that by using STOP/ID, then go into SDA, find the "Busy"L > > > mailbox channels, and COPY NLA0: to those devices one-by-one until theG > > > process dies - it causes I/Os to complete which will release some  BIOLMsL > > > and allow the process to continue long enough to acknowledge and honor > > > the $DELPRC request. > >eJ > > Another way to deal with hangs due to quota exhaustion is to raise the8 > > process quota using Availability Manager or DECamds. >f > True.  >eF > Problem with them has always been the non-routable protocol. AMDS isI > VMS-based, but AM is WhineBloze which means your PC must be on the sameeH > VLAN or LAN segment as the VMS machine, and cluster comm. traffic must > traverse the ethernet. > B > Problem children like DESTA are best killed anyway. Since it's aH > resource leakage problem, upping the quota just delays the inevitable. >8 > -- a > David J. Dachterao > dba DJE Systemst > http://www.djesys.com/ >i* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/    ------------------------------   Date: 10 May 2004 05:20:14 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>! Subject: Re: VMS news on news.comd? Message-ID: <DTiotGxQ0bj6-pn2-PqpPdd2Jz2Nf@dave2_os2.home.ours>:  8 On Sat, 8 May 2004 17:42:30 UTC, "Roert G. Schaffrath"  <rschaffrath@yahoo.com> wrote:   > Dave Gudewicz wrote: > > ! > > Thought this was interesting:. > > = > > http://news.com.com/2100-1016_3-5208195.html?tag=nefd.hedi > E > "When Compaq launched the first 64-bit Alpha processor in the earlyh5 > 1990s, it was, at 200MHz, significantly faster thaneH > Intel's then top-of-the-range 66MHz Pentium. Intel's introduction of a9 > successive product lines, starting with the Pentium andf@ > now the Itanium 2, has steadily eroded that performance lead." > : > Huh?  That was Digital Equipment Corporation not Compaq!  C Yeah but I like the admission that Itanium 2 has only _eroded_ the t lead, not eliminated it :-)m   -- h Cheers - Dave.   ------------------------------  $ Date: Sun, 9 May 2004 14:52:21 -0400# From: "John Smith" <a@nonymous.com>x2 Subject: Re: You'll never guess what HP advertised, Message-ID: <WIGdnXkJXMV64APd4p2dnA@igs.net>  L >"David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message0 news:409E5264.46D08E3E@NeOaSrPtAhMlNiOnWk.net...- >> Alan Winston - SSRL Admin Cmptg Mgr wrote:v   >eI > Then, again, look at what the market is buying, and what they're paying-G > for it. All we have to do is illustrate how value is derived not from<J > cost-to-acquire but from, as hp continually touts but consistently fails > to demonstrate, TCO. >5C > Getting the bean-counters over the sticker shock of VMS's cost to1% > acquire will always be a challenge.  >e> > To quote Tom Hanks's character from "A League of Their Own": >dI > "It's supposed to be hard. Otherwise, everyone would do it. The hard isa > what makes it great."     L No, I beg to disagree. It shouldn't be hard. 'Hard' is what makes acceptance5 difficult.  There is no reason why it should be hard.   0 'In the case of VMS, 'hard' takes on many forms:4 1. Lack of desire by HP to make the product visible.I 2. Obfuscation and 'bait-n'switch' ordering & configuration tactics by HPt7 (either through deliberate actions or sheer stupidity). F 3. The perception that OpenVMS is different enough that it isn't worthD writing/port software , or doesn't offer enough differentiation from= unix/linux/windows functionality to justify have VMS instead.   K As to these forms of 'hard', we as a group can only address some aspects ofwL each of these. Some of you know of tactics that I, and others, have proposedI to deal with the first issue - but until there is substantial movement byrH those still using VMS to join in on this, there never will be sufficientH critical mass to get things moving (HP must be rubbing its hands in gleeL knowing that we are the gang that couldn't get our collective act together).  C The second issue is, in the absence of efforts by HP to improve theoK situation, in the hands of VARS, re-sellers, and the like who still want to) be in the VMS marketplace.  K Finally as to issue #3, there's enough talent in c.o.v., experienced enough.L on VMS, unix, linux, and Windows, to be able to whip together a 4 volume setD of books/on-line guides to help make the case that VMS isn't 'hard'.  J Vol. 1 - OpenVMS for Executives - why purchasing anything else is a career
 limiting moves! Vol 2. - OpenVMS for Unix Weenies   Vol. 3 - OpenVMS for Billy-goatsL Vol. 4 - OpenVMS for Serious Production Environments - The How-To Book Based9 on Real-World Implementations of All Sizes and ComplexityC  ' Time to belly-up to the bar, gentlemen.-      / > > HP has to make it orderable, or advertising/ > > campaigns are for naught.. >eC > It is orderable. We just gotta open ourselves up to some creative B > approaches to exploiting the existing ordering channels (channel > partners, OEMs, VARs, etc.). > L > > I wasn't proposing that we continue to watch the erosion and do nothing, I wasrB > > proposing a PR campaign to surface the issue in the media that decisionmakersF > > read, and thus attempt to encourage/shame HP upper management into	 promoting ) > > what could be their flagship product.  >i; > ...but that's still trying to change the leopard's spots.v >nG > There is one place - and place only - we are assured of being able toa6 > have influence and make changes. Look in the mirror. >eH > If we can cause the existing partners to be placing more orders (stuffJ > we're selling through them), it may re-inforce to the brain-damaged thatI > advertising is not needed since hp is not advertising VMS yet sales are C > rising suddenly. Sad and pitiable as it may be, that's just their0( > reality - we cannot change it or them. > F > The end result - proliferation of VMS sites, however, would still be > achieved none the less.s >sD > I may sound a bit Machiavellian saying this, but the "how" matters( > little - it's the "what" that matters. >y > -- > David J. Dachterah > dba DJE Systems7 > http://www.djesys.com/ >t* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Mon, 10 May 2004 03:01:05 +0800l, From: Paul Repacholi <prep@prep.synonet.com>2 Subject: Re: You'll never guess what HP advertised- Message-ID: <874qqpqvbi.fsf@prep.synonet.com>   % "John Smith" <a@nonymous.com> writes:o  F > In HP's case the harm perceived by carly(tm) et al. will be that youD > are promoting a product they are trying to kill, thereby extending> > the time it takes to kill it and making them commit funds to+ > continue manufacturing and supporting it.s  E Well, it will be a fun day when the blonde has to lodge that with the  court!   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 10 May 2004 00:51:43 +0100t< From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>2 Subject: Re: You'll never guess what HP advertised* Message-ID: <c7mg5l$1jf2$1@news.wplus.net>  K "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message 0 news:409EC14F.9C02D0B5@NeOaSrPtAhMlNiOnWk.net... > John Smith wrote:e
 > > [snip]H > > Finally as to issue #3, there's enough talent in c.o.v., experienced enoughL > > on VMS, unix, linux, and Windows, to be able to whip together a 4 volume setaH > > of books/on-line guides to help make the case that VMS isn't 'hard'. > >eG > > Vol. 1 - OpenVMS for Executives - why purchasing anything else is ad career > > limiting move  > H > Plenty of ammunition available in today's trade media. Viruses, worms,I > trojans, all proliferating at corporate America's expense. That doesn't + > begin to mention blue screens and such...  >s% > > Vol 2. - OpenVMS for Unix Weenieso >o$ > Religious war, but worth fighting. >r$ > > Vol. 3 - OpenVMS for Billy-goats >:A > Same deal, but also worth fighting. Reminders that DEC inventedeC > clustering long before Bill Gates even heard the word might provee > convincing - dunno...  >nJ > > Vol. 4 - OpenVMS for Serious Production Environments - The How-To Book BasedH= > > on Real-World Implementations of All Sizes and Complexity  > I > I'm sure almost everyone here could contribute some anecdotal evidence. H > "Sanitizing" it for publication will be the challenge. Experience withG > this group has shown that no matter how "sanitary" the text may seem,hH > someone will always claim that conclusions can be drawn that lead backF > to the obfuscated source. We'll just have to get over that, I guess. >e+ > > Time to belly-up to the bar, gentlemen.i >kJ > If no else does it first, the format of the documentation I produce willE > become the standard. If you don't like that, get there before I do.m > <SNIP>  # Is it going to be in RUNOFF format?r   ------------------------------  % Date: Sun, 09 May 2004 18:39:59 -0500c@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>2 Subject: Re: You'll never guess what HP advertised6 Message-ID: <409EC14F.9C02D0B5@NeOaSrPtAhMlNiOnWk.net>   John Smith wrote:s > [snip]M > Finally as to issue #3, there's enough talent in c.o.v., experienced enough-N > on VMS, unix, linux, and Windows, to be able to whip together a 4 volume setF > of books/on-line guides to help make the case that VMS isn't 'hard'. > L > Vol. 1 - OpenVMS for Executives - why purchasing anything else is a career > limiting mover  F Plenty of ammunition available in today's trade media. Viruses, worms,G trojans, all proliferating at corporate America's expense. That doesn'tn) begin to mention blue screens and such...C  # > Vol 2. - OpenVMS for Unix Weenieso  " Religious war, but worth fighting.  " > Vol. 3 - OpenVMS for Billy-goats  ? Same deal, but also worth fighting. Reminders that DEC inventeduA clustering long before Bill Gates even heard the word might prove  convincing - dunno...o  N > Vol. 4 - OpenVMS for Serious Production Environments - The How-To Book Based; > on Real-World Implementations of All Sizes and Complexityy  G I'm sure almost everyone here could contribute some anecdotal evidence.gF "Sanitizing" it for publication will be the challenge. Experience withE this group has shown that no matter how "sanitary" the text may seem,uF someone will always claim that conclusions can be drawn that lead backD to the obfuscated source. We'll just have to get over that, I guess.  ) > Time to belly-up to the bar, gentlemen.a  H If no else does it first, the format of the documentation I produce willC become the standard. If you don't like that, get there before I do.m   -- a David J. Dachteraf dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------  $ Date: Sun, 9 May 2004 15:12:41 -0400# From: "John Smith" <a@nonymous.com>o+ Subject: [OT] Offshore outsourcing....againe, Message-ID: <R-WdnbSFDP62GAPdRVn-gw@igs.net>  J I have not yet seen an off-shored project in the financial services sectorH come in on-time and on-budget, not even if it was the 3rd or 4th projectL between the same pair of customer-supplier companies. For most projects I'veI seen the final all-in cost is about what it realistically would have costr done domestically.    @ http://www.nytimes.com/2004/05/09/business/yourmoney/09indi.html   May 9, 2004o; As a Center for Outsourcing, India Could Be Losing Its Edger By NOAM SCHEIBER  G In early April, Infosys Technologies, an Indian outsourcing firm, had a L party to celebrate reaching $1 billion in annual revenue. It gathered nearlyI 10,000 employees under a tent on its Bangalore campus and plied them withx food and entertainment.h  L The company also distributed some $23 million in bonuses. "And we're doing aF lot of other things to retain employees," said Stephen R. Pratt, chief= executive of the Infosys consulting arm in the United States.e  L Infosys is hardly the only Indian company making a serious effort to attractD and keep employees. Over all, according to a recent survey by HewittJ Associates, the consulting group, wages in the country's major outsourcing7 sectors have been rising by close to 15 percent a year.o  F The reason is increased competition for labor, thanks in large part toA American companies' rush to outsource work offshore. In fact, thetK competition has become so fierce that typical Indian operations in businessvL processing - including call centers and offices handling payroll, accountingL and human-resources functions - can expect to lose 15 to 20 percent of theirH work forces each year, versus single-digit percentage losses in the late 1990's.e  I The surge in offshore outsourcing has attracted the attention of AmericancF politicians worried about the loss of jobs at home. In late April, theK presidential campaign of Senator John Kerry announced its "Jobs First" tournK and said, "While the president and his economic advisers have insisted that2G outsourcing benefits America, a record number of U.S. workers have lostj" their jobs to countries overseas."  K But the data from India show that, to some extent, the offshore outsourcing0F phenomenon may be self-correcting. Though outsourcing shows no sign ofE fading, rising wages and rapid turnover in Indian hubs may reduce theE; savings American companies reap when they send work abroad.N  E The stiffest competition for offshore labor tends to occur in India'scK so-called first-tier cities: Bangalore, Mumbai, New Delhi and Hyderabad. InhL some sectors of the outsourcing market, attrition rates are 50 to 75 percentL a year, according to Sunil Mehta, vice president of the National AssociationI of Software and Service Companies, or Nasscom, an industry trade group in  India.  L Managers in the business-processing sector, in particular, have difficultiesL keeping workers. A typical outsourcing contract sends workers from an IndianF company "onshore" - to the American company's headquarters - while theK outsourcing project is starting. The problem is that the onshore experienceSF becomes a valuable credential in the American or Indian labor markets.  F "Many don't want to go back offshore," said William S. McCarter, chiefF operating officer and executive vice president of ePolicy Solutions, aG company based in Torrance, Calif., that focuses on Web-based technology J services. "Or if they do go back offshore, they have a marketable skill to churn in the Indian market."  G The situation became so dire last spring that, according to a report inrE India in The Business Standard, the top outsourcing firms in businesstH processing reached an informal agreement not to poach employees from oneJ another. Other retention measures included clauses in employment contractsL to require each new worker to observe a three-month cooling-off period after3 the hiring date before accepting another job offer.m  D Not surprisingly, wage increases have been the most common method ofK attracting and retaining employees. For example, Wipro, the big outsourcingmJ company, gave its 24,000 employees in India an average raise of 10 percentJ last October; the increases were as high as 15 percent for managers. TheseF costs have largely come out of its bottom line - denting its operatingH margin by 1 percentage point to 1.5 percentage points a quarter - ratherK than showing up as higher prices. (The leading Indian outsourcing companiest4 have operating margins of 20 percent to 25 percent.)  K But part of Wipro's higher costs have been passed along. "Certain customerstE got a price increase" last quarter, said Sridhar Ramasubbu, a companyi
 spokesman.  L Indian executives like Jaithirth Rao, the chief executive of the MphasiS, anH outsourcing company, and the current chairman of Nasscom, argue that theH labor shortage, especially for middle managers, will be temporary. LocalD universities have already begun expanding the enrollment in two- andI four-year business programs, according to outsourcing company executives.a  J There are, to be sure, pockets of the country where less-skilled technicalK workers have difficulty finding jobs. But there are reasons to believe thatsL India's shortage of highly skilled labor could be stubborn. A recent NasscomL report projected that if India continued to produce college graduates at theB current rate, demand would exceed supply by 20 percent in the main outsourcing markets by 2008.  J "Candidly, we see a labor problem in India right now," said Dan Zadorozny,L the vice president for applications delivery at Electronic Data Systems, theJ big seller of computer services that is based in the United States but has operations in India.  L Even with wages rising 15 percent a year, the cost for a computer programmerK or a middle manager in India remains a small fraction of that for a similar E employee in the United States. A programmer with three to five years'eG experience makes about $25,000 in India but about $65,000 in the UnitedhL States. But the wage savings from offshore outsourcing have never translatedL directly into overall savings; typically, an outsourcing contract between anI American company and an Indian vendor saves less than half as much as thea wage differences would imply.p  D Praba Manivasager, the chief executive of Renodis Global OutsourcingA Solutions, a company based in Minneapolis that advises clients onbG outsourcing projects, sees two reasons for that. The first involves thedH costs of the transition from doing work in-house to offshore - usually aK one- to two-year process. During the transition, employees of vendors based H in India must work in the United States. The second involves the cost ofI maintaining the relationship. Employees of the American company must makeaE frequent trips to India, and the vendor needs some continued Americanl	 presence.-  K "The vendor says, 'We'll save 40 to 60 percent; we'll give you such a greatlL rate - $22 or whatever,' '' Mr. Manivasager said, referring to hourly wages.D "But if the onshore rate is $50 to $55, and you have half the people= onshore, the savings aren't going to be what are advertised."o  F IT is not as if offshore outsourcing is going away. Indian outsourcingK companies may simply shift operations to cities like Nasik and Ponticherry,fK where wage inflation is relatively mild. Others may outsource work offshoreoL themselves, to China, Southeast Asia and Eastern Europe. Still, most expertsI say India is years ahead of countries like China in its workers' facility H with English, its telecommunications and the sophistication of its legal system  G Another possibility is that American companies may turn increasingly touB global companies based in the United States - like I.B.M. BusinessI Consulting Services, E.D.S. and Hewlett-Packard. These companies have the-J advantage of locations in dozens of countries around the world - E.D.S. isL in 57 - so they can constantly shift work to the most efficient destination.  I That trend may bring a measure of relief to American workers. Of E.D.S.'saL 135,000 global employees, nearly half are based in the United States. Wipro,I by contrast, bases more than 80 percent of its 28,000 employees in India.1D (The difference is that E.D.S. uses American workers for the onshoreK component of its American contracts; Wipro uses Indian workers, dispatchinge* them to the United States when necessary.)  F If the increasing competitiveness of the Indian labor market begins toK benefit companies like E.D.S. and I.B.M., outsourcing may one day no longere+ be a dirty word in a presidential election.e   (c) 2004, New York Times.    ------------------------------   End of INFO-VAX 2004.258 ************************