1 INFO-VAX	Sun, 19 May 2002	Volume 2002 : Issue 275       Contents: !d!i!g!i!t!a!l! India?2 Re: "Best" programming language on VMS for newbie?2 Re: "Best" programming language on VMS for newbie?3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix * Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long) Re: DECUS Lyon: some pictures * Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside???* Re: DHCP and ADSL: no view from outside??? Re: HP commits to VMS again ...  Re: HP commits to VMS again ...  Re: HP commits to VMS again ...  Re: ISE just spammed me... RE: ISE just spammed me... Re: ISE just spammed me... print queue name RE: Stallards smoking gun! RE: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Stallards smoking gun! Re: Tivoli ABC for VMS RE: Tivoli ABC for VMS Re: Tivoli ABC for VMS Re: Tivoli ABC for VMS Re: Tivoli ABC for VMS* [Fwd: RE: Comments on HP officers' remarks  F ----------------------------------------------------------------------  % Date: Sat, 18 May 2002 20:01:41 +0200 - From: Didier Morandi <Didier.Morandi@Free.fr>  Subject: !d!i!g!i!t!a!l! India? ' Message-ID: <3CE69705.14397C54@Free.fr>   G http://www.digitalindiasw.com/financials/downloads/Digital-Q4FY2002.doc   
 Just curious.    D. --  2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans1 Visit: http://www.softresint.com/AlphaMigrate.htm 2 --------------------------------------------------   ------------------------------    Date: 18 May 2002 12:16:38 -0700( From: bob@instantwhip.com (Bob Ceculski); Subject: Re: "Best" programming language on VMS for newbie? = Message-ID: <d7791aa1.0205181116.444c9cd6@posting.google.com>   l sdk_joseph@msn.com (Shawn Joseph) wrote in message news:<f897700f.0205172334.2bdead20@posting.google.com>...H > I have been working with VMS 7.2-1 for just over a year now and wantedE > to start getting into some entry level programming.  I have written H > many simply DCL procedures and I am currently reading/applying WritingF > Real Programs in DCL, 2nd edition.  I have no programming experienceH > but was looking to start out to help improve my skills and net worth.  > I have a few questions.  > G > What is the best programming language for a newbie on VMS and why?  I H > know each language has it's own highlights, but I don't know what theyC > are.  Since I don't know a lot about these languages I guess I am G > looking for pro's and con's on each, what people would recommend as a F > best return on investment in time and money and what is likely to beG > in demand/supported for the forseeable future.  I will most likely be B > learning it all through self study as I'm sure many others have. > E > It sounds like there are several languages supported on VMS.  Would H > anyone care to rank the top 5 in order of your own opinion and why you > feel that way? > E > How would you rank the languages in order of difficulty to learn?    > F > Is there one language that can do "most" or everything one needs?  I3 > know I am setting myself up with this question :)  > F > If not, is there a logical order the languages should be studied and
 > applied? > H > What is the difference between C, C++ and Compaq C and Compaq C++, and > C/C++ for that matter? > G > Most of the references I have seen thus far for C have been for Unix, < > are there resources out there for programming in C on VMS? > F > I am told that Java runs on VMS and is even more portable than C butE > requires additional overhead as it requires a runtime environment.   > Any thoughts on this?  > H > I am looking for something long range I can pick up and something thatE > is going to be portable to other Operating systems.  I think DCL is E > pretty slick but is limited to VMS and from what I am told has many ; > limitations when compared to other programming languages.  > A > I was considering C as I'm told it can be run on many operating  > systems and is very powerful.  > F > Any comments in this area would be greatly appreciated.  I have beenH > to Compaq's website, but all the different choices kind of overwhelmedH > me.  I was hoping to get a "best in class" to narrow it down so that IE > can do some more research and start learning a language in the near 	 > future.  > 
 > Regards,, > Shawn Joseph, up and coming System Manager  F the best by far is DIBOL, now on Alpha and soon to be itanium known asG Synergy DBL.  It has GUI, dreamweaver support for web apps, an ODBC for E access from other other platforms, as well as oracle/rdb support, and B it can call "c" routines from within itself.  Also, it also can beF easily ported to unix/linux/windoze/OS400 if need be.  It also has itsG own database that mimics RMS so migrations to other platforms are easy!    ------------------------------    Date: 18 May 2002 15:53:02 -0700" From: cstranslations@msn.com (Joe); Subject: Re: "Best" programming language on VMS for newbie? = Message-ID: <d56d1c2d.0205181453.280728e5@posting.google.com>   h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<9QQnwOj$7bwR@eisner.encompasserve.org>...i > In article <f897700f.0205172334.2bdead20@posting.google.com>, sdk_joseph@msn.com (Shawn Joseph) writes:  > I > > What is the best programming language for a newbie on VMS and why?  I J > > know each language has it's own highlights, but I don't know what theyE > > are.  Since I don't know a lot about these languages I guess I am I > > looking for pro's and con's on each, what people would recommend as a H > > best return on investment in time and money and what is likely to beI > > in demand/supported for the forseeable future.  I will most likely be D > > learning it all through self study as I'm sure many others have. > G > If you know a language well, it is easier to learn a second language.  > C > I would recommend Ada because it is best at detecting programming E > errors at compile time and getting you on your way for the learning 
 > process. > D > You may find demand for programming other languages in the future,< > but if you have learned one language you can learn others. > + > If you have bias against Ada, try Pascal.  > D > If you don't care about learning to program rigorously, try Basic.  D Although I don't post any where near as much as I use to I have beenF following the NG for almost 6 years now (so I know, Larry, that you'reC a big fan/user of Ada) - I do feel a compulsion to say something in  response to that one...   F I've been programming on OpenVMS/VMS for almost 10 years at this pointD (70-75% BASIC and 25-30% C). People (do) have a tendency to, shall ID say, "roll their eyes" on hearing BASIC. Never-the-less I have foundE BASIC on OpenVMS to be a very robust language. Back on the east coast D I spent 6 years supporting BASIC code in a hospital environment thatD was originally written in '78 and '79 (when I was in the 7th and 8th@ grade). For the last 2-3 years I've been working with BASIC codeD written in the early '80s (insurance related). When it comes down toC it - if there was some sort of dereference/pointer mechanism in the 5 language (but then I guess we can't have everything).   B Some languages may make it easier to do so than others but writing% cr*p code is possible in any of them.   A The fact that there's code written 20-25 years ago that I can run D (essentially unmodified) through the current compiler is a statement+ to something that M$ will never understand.    Joe    ------------------------------    Date: 19 May 2002 00:50:35 +0800, From: Paul Repacholi <prep@prep.synonet.com>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix0 Message-ID: <87bsbdpfhg.fsf@k9.prep.synonet.com>  , "Bill Todd" <billtodd@metrocast.net> writes:  ; > "Paul Repacholi" <prep@prep.synonet.com> wrote in message , > news:877km2sgjc.fsf@k9.prep.synonet.com..., > > Ken Green <Ken.Green@kgcc.co.uk> writes:  E > > > copies exist in the memory of the members of the cluster how do = > > > you ensure if one member modifies all the other members ) > > > invalidate their copies atomically.   E > > Step one, take the unix buffer cache out and destroy that part of  > > the brain...  A Oh yes, with VMS, it is normal for a file to be open for write by A multiple processes, and on multiple nodes. SYSUAF.DAT, the passwd E `equivalent' is updated on every login, and is help open on all nodes C all the time by the job-controller. Mail can be delivered while you E are reading it. All `just works'. (Thank Bill for a good bit of that! + He was one of the original RMS developers.)   B > Sorry, Paul, but the lack of a Unix-style buffer cache is more a! > detriment than an asset to VMS.   ? Yes, but until recently, on unix systems all disk IO was to the F kernel, never to userland. (for a large enought value of recently, andA a small value of all :) The key factor is the buffer *may* exist, D rather than *must*. So you can not use it as a sync point, as it mayF not be there at all. or it may be there in SOME nodes, but not others.  A > VIOC is a step toward a VMS system-level cache, and XFC another B > bigger one, but for most typical use the Unix approach is likely> > better still - and really doesn't introduce any more sharingE > problems than current VMS distributed caching/buffering mechanisms.    C > >  VMS uses direct to the process IO, not IO to the kernel with a > > > copy to the process, so there can well be NO cache at all.   F > Depends on how you look at it.  Only application-specified block I/OD > (or 'locate-mode' access, if that still exists) avoids a bufferingB > layer - just because it happens to be in P1 space rather than SxD > space doesn't really make much difference (except that other local > processes can't share it).   D One thing VMS has done, is that buffer update go via the disk, neverE memory to memory although the SCS ports could do it no problem. I was D told that failure modes where too horrid to handle with out a stableB copy in the middle, so onto and off the disk... This may have been	 improved.   6 > >  RMS Global buffers are the common exception here.   A > Another not-so-great excuse for Unix-style system caching.  RMS C > *could* have chosen to create a Unix-like system cache instead of E > implementing 'global buffers' way back when, but that didn't fit as B > well with RMS's layering model (and real-time advocates may haveD > preferred to have somewhat tighter control over system memory use,E > though it's not clear that equivalent controls couldn't be obtained @ > by establishing quotas and/or priorities on system cache use).  F I was always amused that RMS lived in system space, and the XQP was in
 user space...     > ...    B > > > Truncating doesn't affect this, it can be considered as justD > > > like any other write.  On Unix, files can be sparse, I seem toB > > > remember that VMS' view of files is somewhat different, so IB > > > have no idea whether it supports sparse files, if not Then I. > > > guess truncates are a different problem.   > > Considered commenting on this before, but got lazy.  I'm notC > familiar with the details of Unix-style byte-range locks, so it's E > possible that a truncate can just take out a write-style range lock C > on the section truncated and have it 'just work' (though since it E > would have to wait for *every* conflicting read or write lock to be E > released, it could take a while).  VMS locks are slightly different E > in that they operate on names and hence don't accommodate amorphous @ > (and potentially overlapping) entities like byte (or truncate)A > ranges easily.  I don't know exactly how VMS handles byte-range A > locks themselves let alone truncate ranges, but I suspect it is ( > indeed (as Paul suggests) a bit messy.  D Remember, we are allowed to lose blocks to n-space on crash etc, butE we must be able to recover totally normally. Even if we have multiple E extents, and cross bit-map blocks, and volumes, and another node does C a BIG extend of another file and runs out of space and all the XQPs @ have to dump their free space cache etc... Plus some interesting$ corner cases in timing and the like.  E > > ODS files are extent based. Any file is a ordered list of extents F > > of blocks. (A block btw, is *defined* to be 512 bytes. It is up toF > > the driver to do the various fudging to make this so.) So the fileD > > system is VERY different to any of the unix systems. It does notD > > have to provide anything other than block access to the process.F > > Although truncation is simple in principle, doing it so it is safeF > > and completable is a far trickier matter! It is also why you get a< > > big performance hit cf unix file systms for some things.   B > Not sure that the use of extents makes any real difference here:E > after all, several Unix file systems are extent-based (XFS, VxFS, I 
 > think JFS).   C > > The nice thing about VMS, is that the tools are good enough for C > > you to pick up a lot of the stuff on a running system. With the C > > VMS FAQ in one hand, and SDA in the other you are set. To begin 
 > > anyway :)   C > > Getting a copy of the ODS-2 specs from the SIG tapes from years @ > > ago is a very good start. Once you have a handle on the file- > > system, then you can move out from there.    E > As I said, I'm not sure that the actual on-disk structure makes too D > much difference.  Inodes correspond at least moderately closely toB > index-file entries, etc.  The use of careful-update sequences inE > ODS-2 in contrast to many Unix file systems (which range from using B > prayer plus fsck to using transaction logs to protect integrity)? > *is* a significant difference, however, especially in how the  > clustered file system works.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Sat, 18 May 2002 20:20:05 GMT * From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' UnixB Message-ID: <VHyF8.175541$M7.18025753@bin7.nnrp.aus1.giganews.com>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in message * news:87bsbdpfhg.fsf@k9.prep.synonet.com...   ...   7 > All `just works'. (Thank Bill for a good bit of that! - > He was one of the original RMS developers.)   9 But only on the 11, not in the clustered VMS environment.    > D > > Sorry, Paul, but the lack of a Unix-style buffer cache is more a# > > detriment than an asset to VMS.  > A > Yes, but until recently, on unix systems all disk IO was to the H > kernel, never to userland. (for a large enought value of recently, andC > a small value of all :) The key factor is the buffer *may* exist, F > rather than *must*. So you can not use it as a sync point, as it mayH > not be there at all. or it may be there in SOME nodes, but not others.  L I'm not sure that's a significant distinction (any more, now that Unixes canK perform direct I/O).  After all, the local system cache isn't a distributed K synchronization point in clustered Unix environments either, and even local K Unix environments may (I don't know, but they could) coordinate cached data J with directly-accessed data (just as VMS could - and again I don't know if' it does) using lock-manager mechanisms.   I Using global buffers you can make local RMS access work similarly to Unix I cached access in this regard.  Using Unix direct I/O mechanisms you could H make local Unix access work similarly to RMS access in this regard.  TheL *big* differences between the two systems are the default behaviors (sharingL via caching using RMS global buffers is a bit of a pain, and duplicating theI caching instead using lower-level VIOC or XFC caches is wasteful) and the 7 flexible use of system memory that Unix caching allows.U   ...   F > One thing VMS has done, is that buffer update go via the disk, neverG > memory to memory although the SCS ports could do it no problem. I was F > told that failure modes where too horrid to handle with out a stableD > copy in the middle, so onto and off the disk... This may have been > improved.i  J I think XFC was doing something in that area (but not in 7.3).  It is hardG to get right in many of the cases (e.g., distributed write after write: D what happens when the original owner issues a Flush in the middle ofI things?).  There is, however, no need for the new owner to go to disk for F the data after it has been written:  it can just be forwarded from the original owner.    > 8 > > >  RMS Global buffers are the common exception here. > C > > Another not-so-great excuse for Unix-style system caching.  RMS E > > *could* have chosen to create a Unix-like system cache instead ofeG > > implementing 'global buffers' way back when, but that didn't fit as D > > well with RMS's layering model (and real-time advocates may haveF > > preferred to have somewhat tighter control over system memory use,G > > though it's not clear that equivalent controls couldn't be obtained2B > > by establishing quotas and/or priorities on system cache use). >:H > I was always amused that RMS lived in system space, and the XQP was in > user space...i  J Evolution doesn't always proceed in straight lines.  One of the reasons it> sometimes makes sense to start over using what you've learned.   - bill   ------------------------------  % Date: Sat, 18 May 2002 15:27:17 -0400F- From: JF Mezei <jfmezei.spamnot@videotron.ca>53 Subject: Re: DECUS Lyon: Another VMS summary (long)i, Message-ID: <3CE6AB13.C4C2D6EF@videotron.ca>   Carl Perkins wrote:-* > The question is "why would you need it"?  " Is there actually a problem here ?  H If Intel's crap uses some proprietary protocol instead of BootP or TFTP,C couldn't VAX-VMS or ALPHA-VMS be updtated to serve requests in thatDM proprietary protocol ?  By the time a VMS box is ready to serve boot requestswK from another host, isn't VMS well past the ROM of the hardware it runs on ?c  J Similarly, couldn't VMS on IA64 be designed to support MOP requests ? ThisH way, if you have a fully booted IA64 VMS host, when a VAX workstation isE turned on and its ROM sends out a MOP request, VMS on IA64 could theni4 understand this and serve the request, couldn't it ?  I Consider that VAX-VMS has the ability to serve boot requests in differentsJ protocols (MOP, BOOTP, TFTP), adding Intels uselessly proprietary protocolJ shoudln't be impossible, unless Intel really insists on it being extremely> proprietary and forbits non-Intel hardware from supporting it.    L While I realise that HP thinks only in terms of wildfire class systems whereK such cross-boots are probably not expected, there may still be a lot of VMSmB workstations out there that do want to boot from some boot server.  I Since it seems that IA64 will arrive first in the big boxes as opposed touH workstations, it would be logical to see the boot server in a cluster beL replaced before the workstations, and hence, that boot server should supportL MOP requests (even though its own ROM would be unable to make such requests,D it doesn't preclude the software in VMS from serving such requests).   ------------------------------  # Date: Sat, 18 May 2002 20:23:20 GMT . From: peter@langstoeger.at (Peter LANGSTOEGER)3 Subject: Re: DECUS Lyon: Another VMS summary (long)i3 Message-ID: <YKyF8.47339$oG6.450898@news.chello.at>e  \ In article <3CE6AB13.C4C2D6EF@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:K >Similarly, couldn't VMS on IA64 be designed to support MOP requests ? This I >way, if you have a fully booted IA64 VMS host, when a VAX workstation isnF >turned on and its ROM sends out a MOP request, VMS on IA64 could then5 >understand this and serve the request, couldn't it ?h  K AS I UNDERSTAND IT, then OpenVMS IPF does support MOP server functions justh7 like OpenVMS Alpha does it. Remember: same code stream. N It is the MOP client functionality which we won't see in the IA64 boxes f/w !!  I And therefore BOOTP/TFTP will be supported soon for booting VMS as client I from a server. I don't think this is much of a problem technically, it is + only the problem of becoming "supported"...   M And I also expect to boot then my VAX from an IPF bootserver without problemsaL though it will never be (as a cross architecture boot) officially supported.   Did I understood wrong ?   -- h Peter "EPLAN" LANGSTOEGERs% Network and OpenVMS system specialistt E-mail  peter@langstoeger.atP A-1030 VIENNA  AUSTRIA              I'm looking for (a) Network _and_ VMS Job(s)   ------------------------------  % Date: Sat, 18 May 2002 15:52:16 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>e& Subject: Re: DECUS Lyon: some pictures, Message-ID: <3CE6B0ED.A01CE975@videotron.ca>   Didier Morandi wrote:. > " > http://213.36.104.34/decus_lyon/  L I liked the "VMS boots on Macintosh" picture... You forgot to mention a "VMS7 Boots on a macintosh running Windows" ..... Sacrilege !-   ------------------------------  % Date: Sat, 18 May 2002 11:09:30 -0700l" From: GreyCloud <cumulus@mist.com>3 Subject: Re: DHCP and ADSL: no view from outside???g( Message-ID: <3CE698DA.EF7B55E4@mist.com>   Jerry Leslie wrote:l > 0 > Didier Morandi (Didier.Morandi@Free.fr) wrote: > : Its an Eicon DIVA 2430 SEs > : microcode 1.2.9 LSFe > :7$ > : When reaching 192.168.1.1 I get: > :> > : Address IP  213.36.104.34e > : Subnet mask 255.255.255.0h > : DNS  213.36.80.1 > : local IP 192.168.1.1 > : Subnet mask 255.255.255.0g	 > : VPI 8'
 > : VCI 35 > : encapsulation LLCw > : MTU 1460 > : N > : If I access 213.36.104.34 I reach the maintenance leg of the modem, not my7 > : system. (maybe I can pool 213.36.104.* to find it?)  > :e > : I'll check with the vendor.n > :e > : D. > :  > I found its technical specs: > / >    http://www.eicon.com/diva2430se/techsp.htmb7 >    DIVA 2430 SE ADSL Modem - Technical Specificationsn > G > It doesn't seem to support port forwarding, but the 2440 ADSL router:c > > >    http://www.eicon.com/worldwide/products/DSL/Diva_2440.htm* >    Eicon Networks Diva 2440 ADSL Router:< >    Connect and Surf, secure, multi-user broadband solution > 6 > does support port forwarding by NAT static mappings: > 2 >    http://www.eicon.com/pubs/diva_2440/index.htm4 >    usertoc.htm: Diva 2440 ADSL Router User's Guide >  >   "NAT static mappings > H >    With NAT enabled, computers outside of the internal LAN do not haveF >    access to any computers on the internal LAN. The computers on theJ >    internal LAN are effectively invisible to the outside network. If youF >    need a computer on the internal LAN to be visible to the externalF >    network (such as a web server), the Diva 2440 provides a solution$ >    through NAT static mappings..." > G > You may need to exchange the modem for the router, or add a cable/DSLNG > router, like a Linksys, that goes between the ADSL modem and the LAN..  < I find the wording on my Linksys sort of funny in that to be7 visible to the outside world, Linksys calls it the DMZ.    ------------------------------  % Date: Sat, 18 May 2002 15:33:57 -0400I- From: JF Mezei <jfmezei.spamnot@videotron.ca>e3 Subject: Re: DHCP and ADSL: no view from outside???o, Message-ID: <3CE6ACA3.C2C86216@videotron.ca>   "Doc.Cypher" wrote: J > Also, there is no mention of how incoming requests are handled. This mayM > give you problems if you want to run a web server and connect more than oneyF > device to the ADSL modem - i.e. which machine will get the requests?  K If the service is PPPoE, this presents a second problem since it emulates a I dial-up connection when you have to sign in with username and password to-H establish the line, after which connection requests can come in or out.   J I am not familiar how the the line is "broken" (logoff) however. I suspectJ that if the line is not "logged in", inbound requests would not reach yourJ modem/host. Perhaps your modem is smart enough to constantly keep the line "logged in".   ------------------------------  % Date: Sat, 18 May 2002 17:42:32 -0400.1 From: Michael Austin <maustin@firstdbasource.com>o3 Subject: Re: DHCP and ADSL: no view from outside???e2 Message-ID: <3CE6CAC8.F38FEEF2@firstdbasource.com>   Didier Morandi wrote:  > 2 > on which account should I send my shareware fee? > :-)d >  > merci. >  > D. >  > Michael Austin wrote:i > >S > (VMS/DHCP for Dummies) > --8<--   Well -- he did ask :)p  + http://www.firstdbasource.com/donation.htmle   --   Regards,  7 Michael Austin            Registered Linux User #261163e7 First DBA Source, Inc.    http://www.firstdbasource.come Sr. Consultant 704-947-1089 (Office)s 704-236-4377 (Mobile)o   ------------------------------  % Date: Sat, 18 May 2002 17:55:24 -0400o1 From: Michael Austin <maustin@firstdbasource.com>e3 Subject: Re: DHCP and ADSL: no view from outside???,2 Message-ID: <3CE6CDCC.7E42C647@firstdbasource.com>   JF Mezei wrote:e >  > "Doc.Cypher" wrote:gL > > Also, there is no mention of how incoming requests are handled. This mayO > > give you problems if you want to run a web server and connect more than one,H > > device to the ADSL modem - i.e. which machine will get the requests? > M > If the service is PPPoE, this presents a second problem since it emulates aiK > dial-up connection when you have to sign in with username and password tolI > establish the line, after which connection requests can come in or out.M > L > I am not familiar how the the line is "broken" (logoff) however. I suspectL > that if the line is not "logged in", inbound requests would not reach yourL > modem/host. Perhaps your modem is smart enough to constantly keep the line > "logged in".   JF.  o  E With DSL EXTERNAL ethernet modem/router configuration it is literally D always on.  Occasionally there it will disconnect - such as when anyH change is made to the router configuration etc.. and the IP address doesG change.  I have very old 133 and 166Mhz PC's running Caldera Linux thattA executes a PERL script every 5 minutes which logs into my Linksys F BEFSR41 router/hub and check to see if the IP address has changed.  IfH so, then it updates my dynamic DNS provider with the latest IP address. C And since I have 2 of them, they are actually executing this scriptpC every 2.5 minutes.  I have not yet configured this script on my VMSa; system to run in "daemon" mode. Still working on it though.t  D Again, a word of caution, most cable providers and a number of otherD ISP's do not allow web/ftp servers running on a residential account.E doesn't matter if it is "hobbyist" or not. It is strictly foridden --y@ but as always YMMV. Just make sure you read the T&C/AUP for your	 provider.e  4 Acutally the real problem is that ADSL is "normally"G 1.5Mb-down/256Kb-upstream and having a busy server running over a 256Kbe@ uplink, can get really slow.  But it is very good for testing :) -- d Regards,  7 Michael Austin            Registered Linux User #261163r7 First DBA Source, Inc.    http://www.firstdbasource.come Sr. Consultant 704-947-1089 (Office)h 704-236-4377 (Mobile)    ------------------------------  % Date: Sat, 18 May 2002 18:49:27 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>d3 Subject: Re: DHCP and ADSL: no view from outside???t, Message-ID: <3CE6DA69.4FC2D5E4@videotron.ca>   Michael Austin wrote: G > With DSL EXTERNAL ethernet modem/router configuration it is literally  > always on.   With PPPoE service:'  J What happens if your line has not "logged in" to the PPP server at the ISP* side ? Will inbound requests get refused ?  M Since the physical line is always on, how does the customer equipment know ife5 a login with username and password is needed or not ?i  F How does a line get logged out ? If the modem detects there is nothingS physocal on the other side of the ethernet ? (eg: single PC on ethernet turned off)a   ------------------------------  % Date: Sun, 19 May 2002 00:41:17 +0200e- From: Didier Morandi <Didier.Morandi@Free.fr>o3 Subject: Re: DHCP and ADSL: no view from outside???n' Message-ID: <3CE6D88D.3FB8A180@Free.fr>t  O It should as many (more than 300) folks did access my mac since this morning...n) successfully (according to the HTTP log).e   D.   JF Mezei wrote:r >  > "Doc.Cypher" wrote:uL > > Also, there is no mention of how incoming requests are handled. This mayO > > give you problems if you want to run a web server and connect more than one,H > > device to the ADSL modem - i.e. which machine will get the requests? > M > If the service is PPPoE, this presents a second problem since it emulates aeK > dial-up connection when you have to sign in with username and password toeI > establish the line, after which connection requests can come in or out.t > L > I am not familiar how the the line is "broken" (logoff) however. I suspectL > that if the line is not "logged in", inbound requests would not reach yourL > modem/host. Perhaps your modem is smart enough to constantly keep the line > "logged in".   -- a2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans1 Visit: http://www.softresint.com/AlphaMigrate.htm 2 --------------------------------------------------   ------------------------------  % Date: Sat, 18 May 2002 20:59:48 -0400n1 From: Michael Austin <maustin@firstdbasource.com>r3 Subject: Re: DHCP and ADSL: no view from outside???h2 Message-ID: <3CE6F904.2973A4D7@firstdbasource.com>   JF Mezei wrote:- >  > Michael Austin wrote:fI > > With DSL EXTERNAL ethernet modem/router configuration it is literally  > > always on. >  > With PPPoE service:k > L > What happens if your line has not "logged in" to the PPP server at the ISP, > side ? Will inbound requests get refused ?  G If you are using a USB- or PCI-based DSL modem then this is correct. IfCE you are using a router/external ethernet modem, then the router keeps D the connection alive and logged in all of the time - ie "Always on".   > O > Since the physical line is always on, how does the customer equipment know ifs7 > a login with username and password is needed or not ?-  H If using a router, the router is always connected and will re-connect if# it gets disconnected using the u/p.n   > H > How does a line get logged out ? If the modem detects there is nothingU > physocal on the other side of the ethernet ? (eg: single PC on ethernet turned off)e  G obviously if you are using a PC runnning Wxx and you have it turned offaC then there is no connection.  There are several PPPoE programs likevE Enternet300 and RASPPPOE that will make the  connection - and take up E lots of overhead in the PC doing so, which is why I prefer to use theoE external ethernet/router-hub combination.  My VMS and Linux boxes runlG 24x7 - and because only the  VMS system is actually exposed to the net,(. my ftp/web servers are unlikely to get hacked.   -- a Regards,  7 Michael Austin            Registered Linux User #261163a7 First DBA Source, Inc.    http://www.firstdbasource.comy Sr. Consultant 704-947-1089 (Office)h 704-236-4377 (Mobile)n   ------------------------------  % Date: Sat, 18 May 2002 22:10:24 -0400t1 From: Michael Austin <maustin@firstdbasource.com>e3 Subject: Re: DHCP and ADSL: no view from outside???t2 Message-ID: <3CE70990.F7D96BB6@firstdbasource.com>   GreyCloud wrote: >  > Jerry Leslie wrote:o > >t2 > > Didier Morandi (Didier.Morandi@Free.fr) wrote: > > : Its an Eicon DIVA 2430 SE- > > : microcode 1.2.9 LSF  > > :)& > > : When reaching 192.168.1.1 I get: > > :l > > : Address IP  213.36.104.34c > > : Subnet mask 255.255.255.0h > > : DNS  213.36.80.1 > > : local IP 192.168.1.1 > > : Subnet mask 255.255.255.0i > > : VPI 8  > > : VCI 35 > > : encapsulation LLC  > > : MTU 1460 > > : P > > : If I access 213.36.104.34 I reach the maintenance leg of the modem, not my9 > > : system. (maybe I can pool 213.36.104.* to find it?)h > > :t! > > : I'll check with the vendor.a > > :  > > : D. > > :   > > I found its technical specs: > >i1 > >    http://www.eicon.com/diva2430se/techsp.htmo9 > >    DIVA 2430 SE ADSL Modem - Technical Specificationst > >oI > > It doesn't seem to support port forwarding, but the 2440 ADSL router:r > >e@ > >    http://www.eicon.com/worldwide/products/DSL/Diva_2440.htm, > >    Eicon Networks Diva 2440 ADSL Router:> > >    Connect and Surf, secure, multi-user broadband solution > >u8 > > does support port forwarding by NAT static mappings: > >e4 > >    http://www.eicon.com/pubs/diva_2440/index.htm6 > >    usertoc.htm: Diva 2440 ADSL Router User's Guide > >) > >   "NAT static mappings > > J > >    With NAT enabled, computers outside of the internal LAN do not haveH > >    access to any computers on the internal LAN. The computers on theL > >    internal LAN are effectively invisible to the outside network. If youH > >    need a computer on the internal LAN to be visible to the externalH > >    network (such as a web server), the Diva 2440 provides a solution& > >    through NAT static mappings..." > > I > > You may need to exchange the modem for the router, or add a cable/DSLvI > > router, like a Linksys, that goes between the ADSL modem and the LAN.a > > > I find the wording on my Linksys sort of funny in that to be9 > visible to the outside world, Linksys calls it the DMZ.a  E There are 2 different types of allowing access to your system. One isr5 very controlled access, the other is full, wide open.g  E DMZ allows all port inquiries to the WAN IP address to be directed ton/ this machine uncheck, with all ports available.-  A PortForwarding allows you to control which ports are forwarded toMG individual machines.  I could have port 80 and 443 forwarded to a LinuxSF box while I can have SMTP and POP (25 and 110) forwarded to a VMS box.G Although you cannot forward say port 23 (telnet) to 2 different boxes. tC You only have one IP address for inbound traffic any way -- the WANcH address assigned to the Router via Bridged DHCP (generally cable modems)F or PPPoE/A DHCP (generally ADSL).  For business customers, you can getF more than one STATIC IP address and can assign those to your "servers"E and set up your router to pass the traffic correctly. - But that is a6 whole new subject.   -- P Regards,  7 Michael Austin            Registered Linux User #261163 7 First DBA Source, Inc.    http://www.firstdbasource.comO Sr. Consultant 704-947-1089 (Office)e 704-236-4377 (Mobile)h   ------------------------------  % Date: Sat, 18 May 2002 20:11:07 -0700b" From: GreyCloud <cumulus@mist.com>3 Subject: Re: DHCP and ADSL: no view from outside???t( Message-ID: <3CE717CB.6E5A8453@mist.com>   Michael Austin wrote:o >  > GreyCloud wrote: > >t > > Jerry Leslie wrote:  > > >e4 > > > Didier Morandi (Didier.Morandi@Free.fr) wrote:! > > > : Its an Eicon DIVA 2430 SEs > > > : microcode 1.2.9 LSFs > > > :a( > > > : When reaching 192.168.1.1 I get: > > > : ! > > > : Address IP  213.36.104.34 ! > > > : Subnet mask 255.255.255.0i > > > : DNS  213.36.80.1 > > > : local IP 192.168.1.1! > > > : Subnet mask 255.255.255.0w
 > > > : VPI 8  > > > : VCI 35 > > > : encapsulation LLCl > > > : MTU 1460 > > > :sR > > > : If I access 213.36.104.34 I reach the maintenance leg of the modem, not my; > > > : system. (maybe I can pool 213.36.104.* to find it?)h > > > :e# > > > : I'll check with the vendor.  > > > :-
 > > > : D. > > > :-" > > > I found its technical specs: > > >r3 > > >    http://www.eicon.com/diva2430se/techsp.htm:; > > >    DIVA 2430 SE ADSL Modem - Technical Specificationsy > > >9K > > > It doesn't seem to support port forwarding, but the 2440 ADSL router:J > > > B > > >    http://www.eicon.com/worldwide/products/DSL/Diva_2440.htm. > > >    Eicon Networks Diva 2440 ADSL Router:@ > > >    Connect and Surf, secure, multi-user broadband solution > > >i: > > > does support port forwarding by NAT static mappings: > > >l6 > > >    http://www.eicon.com/pubs/diva_2440/index.htm8 > > >    usertoc.htm: Diva 2440 ADSL Router User's Guide > > >e > > >   "NAT static mappings > > >pL > > >    With NAT enabled, computers outside of the internal LAN do not haveJ > > >    access to any computers on the internal LAN. The computers on theN > > >    internal LAN are effectively invisible to the outside network. If youJ > > >    need a computer on the internal LAN to be visible to the externalJ > > >    network (such as a web server), the Diva 2440 provides a solution( > > >    through NAT static mappings..." > > >rK > > > You may need to exchange the modem for the router, or add a cable/DSL-K > > > router, like a Linksys, that goes between the ADSL modem and the LAN.l > >e@ > > I find the wording on my Linksys sort of funny in that to be; > > visible to the outside world, Linksys calls it the DMZ.- > G > There are 2 different types of allowing access to your system. One iso7 > very controlled access, the other is full, wide open.  > G > DMZ allows all port inquiries to the WAN IP address to be directed to 1 > this machine uncheck, with all ports available.S > C > PortForwarding allows you to control which ports are forwarded tomI > individual machines.  I could have port 80 and 443 forwarded to a Linux-H > box while I can have SMTP and POP (25 and 110) forwarded to a VMS box.H > Although you cannot forward say port 23 (telnet) to 2 different boxes.E > You only have one IP address for inbound traffic any way -- the WANnJ > address assigned to the Router via Bridged DHCP (generally cable modems)H > or PPPoE/A DHCP (generally ADSL).  For business customers, you can getH > more than one STATIC IP address and can assign those to your "servers"G > and set up your router to pass the traffic correctly. - But that is a' > whole new subject. >   ; Hi Michael... seen you around in another newsgroup.  Thanks ; for the extra info that Linksys didn't explain well.  Everym bit helps. :-)   ------------------------------  # Date: Sat, 18 May 2002 19:54:34 GMT ( From: spam@devnull.com (Russell Wallace)( Subject: Re: HP commits to VMS again ...0 Message-ID: <3ce6b163.100117819@news.eircom.net>  , On Fri, 17 May 2002 22:37:06 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:A  O >In other words, so far, all HP has been able to say is that they will continue / >the very same Compaq policies of ignoring VMS.n  C Was there ever any doubt about this? It's been clear all along thatt) Fiorina agrees with Capellas on strategy.    -- h3 "Mercy to the guilty is treachery to the innocent."e! http://www.esatclear.ie/~rwallacer mail:rw(at)eircom(dot)neti   ------------------------------  % Date: Sat, 18 May 2002 21:04:20 -0400N- From: JF Mezei <jfmezei.spamnot@videotron.ca>h( Subject: Re: HP commits to VMS again ..., Message-ID: <3CE6FA13.E9369D64@videotron.ca>   David Mathog wrote:u6 > taken over by a competitor. Shouldn't his strategies6 > be just a little bit suspect, at least, if HPQ wants > to remain in business?  K Carly has repeated many times that ever since she first laid eyes on Curly,eN she knew that they shared computing philosophies and were made for each other.  L Lets not forget that HP wasn't doing too well before Carly was put in chargeL and she wasn't able to turn things around very well, and the Compaq takeoverL was a good distraction to remove the focus on her inability to make HP work.  K Remember that Carly's idea of enterprise computing is printers, imaging andvM wintel stuff. What I found interesting is that during her presentation of theeL product roadmap, there was a greater focus on HP-UX than before. I wonder ifL Mr Hewlett has at least succeeded in making Carly realise that there is more to computing than wintel.    ------------------------------  % Date: Sat, 18 May 2002 17:44:26 -0700 ' From: David Mathog <mathog@caltech.edu>c( Subject: Re: HP commits to VMS again ...+ Message-ID: <3CE6F56A.54E738FB@caltech.edu>d   Russell Wallace wrote:  E > Was there ever any doubt about this? It's been clear all along that + > Fiorina agrees with Capellas on strategy..  5 Yes, but what was never clear, and still isn't clear,r4 is _why_ she agrees with him.  After all, he's fresh1 from doing such a great job at Compaq that it was 4 taken over by a competitor. Shouldn't his strategies4 be just a little bit suspect, at least, if HPQ wants to remain in business?   Regards,   David Mathog mathog@caltech.edu   ------------------------------  % Date: Sat, 18 May 2002 20:07:44 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca> # Subject: Re: ISE just spammed me... , Message-ID: <3CE6ECBD.EBB980E5@videotron.ca>  N I have been getting something called "ISE newsletter" for quite some time now.L Since it is in HTML, I always delete it before allowing Netscape to open it.J Didn't even know it was VMS related. Maybe I should open it. Is there some "unsubscribe" button in it ?  M I have been getting a LOT of spam lately, including some outfit in china that-+ sends me about 20 "test" messages each day.o   ------------------------------    Date: 18 May 2002 18:54:13 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)D# Subject: RE: ISE just spammed me...o3 Message-ID: <cUXZAKaclX$t@eisner.encompasserve.org>   ~ In article <BE56C50EA024184DAF48F0B9A47F5CF4026606E2@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> writes: > Bill,c > , >>>> There is NO justification for SPAM. <<< > F > While I am certainly not promoting SPAM, my $.02 is that a very goodI > OpenVMS partner tries to promote their OpenVMS based products on a very I > occasional basis to the OpenVMS newsgroup, it is certainly not a reasonf > to jump all over them.  B As I understand it, this was not a newsgroup post but a email spamC sent to names possibly harvested from the newsgroup.  That is spam,e5 out and out.  The definition of spam email is either:o   	Unsolicited Commercial Emailn    or  	Unsolicited Bulk Email   C If I ask in the newsgroup when V7.3-1 will be release, you can mailfE me the answer since it is not Unsolicited and is not Bulk even thougho, it is Commercial coming from an HP employee.  F > What do you call the hard copy marketing material that goes out on a > regular basis?=20C  @ I call it something paid for by the sender rather than the emailB recipient.  It is quite wrong to attempt to apply paper mail rulesC to email spam issues.  The economic basis of the two mechanisms areS totally unrelated.  J > Is that SPAM as well? Do I take it you don't want to receive anything at0 > all from anyone who you don't personally know?  5 No, that is not it at all.  See the definition above.    -- tN ==============================================================================I The Boulder Pledge: "Under no circumstances will I ever purchase anythingtJ      offered to me as the result of an unsolicited email message. Nor willI      I forward chain letters, petitions, mass mailings, or virus warnings H      to large numbers of others. This is my contribution to the survival      of the online community."N ==============================================================================   ------------------------------    Date: 18 May 2002 19:26:17 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)n# Subject: Re: ISE just spammed me... 3 Message-ID: <dyaRBsowwAmZ@eisner.encompasserve.org>(  \ In article <3CE6ECBD.EBB980E5@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:P > I have been getting something called "ISE newsletter" for quite some time now.N > Since it is in HTML, I always delete it before allowing Netscape to open it.L > Didn't even know it was VMS related. Maybe I should open it. Is there some > "unsubscribe" button in it ?  D You are free to do what you want, but nobody should ever be requiredB to "unsubscribe" from something to which they did not "subscribe".@ Some spammers try to claim that the presence of an "unsubscribe"$ address means something is not spam.  ? It is also quite possible for one person to receive as spam the @ same message that another person receives because they asked for' it, or in extreme case paid to receive.f   -- -N ==============================================================================I The Boulder Pledge: "Under no circumstances will I ever purchase anything J      offered to me as the result of an unsolicited email message. Nor willI      I forward chain letters, petitions, mass mailings, or virus warningsfH      to large numbers of others. This is my contribution to the survival      of the online community."N ==============================================================================   ------------------------------  % Date: Sun, 19 May 2002 14:29:22 +0900t& From: "David Lee" <phongle@kornet.net> Subject: print queue name + Message-ID: <ac7cgn$dgj$1@news1.kornet.net>n  I How/Where do I set and assign a queue name to SYS$PRINT so I can print it 7 without specifying a queue name everytime when I print?e	 Thank youn   ------------------------------  % Date: Sat, 18 May 2002 14:48:49 -0400i' From: "Main, Kerry" <Kerry.Main@hp.com>t# Subject: RE: Stallards smoking gun!nT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4023D904A@kaoexc01.americas.cpqcorp.net>   Andrew,s  : >>> Urban myth along with the hairy handed hitch hiker.<<<  A Ooo... Andrew is getting sensitive ..doing the fud thing again ..r   :-)i  A While I did not see the hairy handed hitch hiker at the last CETS B (Compaq symposium), I did see one of the folks from Irish NationalH Railway stand up and tell those in the audience about their world record? - at least I have heard no other application being continuously-2 available for 17 years - VMS V3.2 was the version.   :-)0  
 Kerry Main Senior Consultanti Hewlett-Packard Canada! Consulting & Integration Services  Voice: 613-592-4660s Fax  :  819-772-7036 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancyt7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20l Sent: May 14, 2002 1:09 PM To: Info-VAX@Mvb.Saic.Coms# Subject: Re: Stallards smoking gun!t    3 Urban myth along with the hairy handed hitch hiker.g   Regards? Andrew Harrisoni   Main, Kerry wrote:  @ >>>>>Neither have I. Only started using VMS 20 years ago. ;-}<<< >>>>>n >=20I > Well, having spent time in a prior lifetime doing CS support, I have=20iG > seen lots of crash dumps, but the point is that there are numerous=20o5 > examples of extra ordinary uptimes for VMS systems.n >=20? > Case in point - the Irish National Railway application ran=20sD > CONTINUOUSLY (no scheduled or unscheduled system downtime which=20E > impacted the application availability) for 17 years before being=20  > retired some time last year. >=20	 > Regards  >=20 > Kerry Main > Senior Consultant  > HP Global Services > HP Canada Ltd. > Voice: 613-592-4660d > Fax  :  819-772-7036 > Email: Kerry.Main@hp.com >=20 >=20 > -----Original Message-----8 > From: Terry C. Shannon [mailto:terryshannon@attbi.com] > Sent: May 10, 2002 8:09 AM > To: Info-VAX@Mvb.Saic.Comi% > Subject: Re: Stallards smoking gun!h >=20 >=20 >=201 > "Roy Omond" <Roy@Omond.net> wrote in message=20d% > news:3CDB8BE8.FE82DBDF@Omond.net...l >=20 >>Carl Karcher wrote:p >> >>C >>>In a previous article, bob@instantwhip.com (Bob Ceculski) wrote:  >>> F >>>->I could care less about anyone else ... as long as I have vms and >>>->I >>>c > have >=20C >>>->support, let everyone else get shut down ... I will be up, the- >>>->company >>>- > Ia >=20G >>>->work for will be up 99.9999, and I will be just fine ... for thoser >>>m >=20 >>>->who >>>  > fail >=20 >>>->... >>>eE >>>Come on Bob, while I have a similar mantra, that's six nines or 31rF >>>seconds of downtime a year if I did the math correctly. Even VMS=20, >>>would be hard pressed to accomplish that. >>>-@ >>Come on Carl, you haven't been reading Good Old Bob Ceculski'sC >>postings. He's never seen a VMS crash in the last 32,767 *years*.s >> >=20: > Neither have I. Only started using VMS 20 years ago. ;-} >=20 >=20 >=20 >=20   ------------------------------  % Date: Sat, 18 May 2002 15:04:57 -04004' From: "Main, Kerry" <Kerry.Main@hp.com>3# Subject: RE: Stallards smoking gun!mT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026606E6@kaoexc01.americas.cpqcorp.net>   Andrew,k  H >>> The harder bit is getting access to the resources to convice, cajoleA and bully your ISV's to port to IA64 at the same time. HP need to ? educate their existing sales force on OpenVMS and their partnert channels.<<<  H Yep, and here is a pointer to just a few of the Cust's and ISV's jumping on the IPF bandwagon:/  
 Customers:= http://www.compaq.com/hps/ipf-enterprise/customer_quotes.html   
 ISV Partners:r< http://www.compaq.com/hps/ipf-enterprise/partner_quotes.html= http://www.compaq.com/hps/ipf-enterprise/partner_quotes2.html/= http://www.compaq.com/hps/ipf-enterprise/partner_quotes3.htmla   RegardsR  
 Kerry Main Senior ConsultantN Hewlett-Packard Canada! Consulting & Integration Servicess Voice: 613-592-4660n Fax  :  819-772-7036 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancye7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20n Sent: May 14, 2002 12:22 PMl To: Info-VAX@Mvb.Saic.Comx# Subject: Re: Stallards smoking gun!          Bob Ceculski wrote:e  = > JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message=20o* > news:<3CDC9976.DA0D77D1@videotron.ca>... >=20 >>"Terry C. Shannon" wrote:r >>D >>>Some might argue that the only replacement product (in the HPQ=20' >>>portfolio) is NSK. Just a thought...n >>> I >>I brought that up a long time ago. A certain percentage of VMS sites=20hH >>will be forced to go to NSK because Unix won't have the reliability=20& >>needed, while the rest will go Unix. >>H >>VMS didn't fill a gap between two product lines, it sat on their laps. >>J >>From the "accountant" point of view, eliminating VMS makes sense. But=20G >>from the visionary point of view, eliminating a product with great=20oG >>profit potential and great market differentiator and great quality=20  >>doesn't make sense.r >> >=20H > they are not going to eliminate vms!  the commitment has been made!=20I > this was all about waking up Scott Stallard so he understands us vms=20 G > customers, and that we will not be porting to unix.  The statement=20dH > could have been made because a few holdover morons want to port, but I  G > believe he has gotton the message from the others ... he did from me!   G > The merger is iver, the letter was true, the support and port will=20l- > continue.  Get a grip man and face reality!t >=20    @ But people already are porting to UNIX. Didier in another threadH reported on a number of OpenVMS customers who are already in the process' of moving with others planning to move.-  8 You may not have any intentions of doing so, but you are" not the OpenVMS market as a whole.  ; The holdover morons you refered to seemed from his posts to1$ be in the majority not the minority.  : You don't seem to understand how dangerous the complacency% you appear to advocate is to OpenVMS.i  E Doing the port of OpenVMS to IA64 is the easy bit you just stick someiF engineers in a cage with workstations and throw them red meat and Jolt Cola.   H The harder bit is getting access to the resources to convice, cajole andE bully your ISV's to port to IA64 at the same time. HP need to educatesA their existing sales force on OpenVMS and their partner channels.t  6 Remember the whole rational behind the deal is to take7 2 2and-3rd=3D4th tier companies in each market, combineo5 them lose ~5% revenues and save more in efficiencies.   G The efficiencies will be HQ, R&D, Manufacturing, Sales, Channels etc So E you will end up with people who were pushing HP's products nowpushingt1 OpenVMS as well. These people need to be trained.D  E The theory at the end of the day is that the combination of a 2nd-3rdnF place company or 3rd-4th place company in each market will result in aD corporation that has moved up the market share ladder in each marketD that it plays in. Histories of technolgy company mergers should make; anyone expecting this very nervous but thats another story.s  7 Bottom line is that if HP just do the port and then say F all done on the OpenVMS front then OpenVMS is dead, they actually haveB to boost spending on OpenVMS in order to pay for all of the issues; surrounding the Alpha->IA64 transition not just to OS port.o   Regardsn Andrew Harrisone   ------------------------------    Date: 18 May 2002 12:10:30 -0700( From: bob@instantwhip.com (Bob Ceculski)# Subject: Re: Stallards smoking gun! = Message-ID: <d7791aa1.0205181110.779be7bd@posting.google.com>b  \ Daniel Clar <Daniel.Clar@supelec.fr> wrote in message news:<3CE6574A.7E627D75@supelec.fr>...0 > Did you take a look at the "updated version" : >  > ( > Q: For OpenVMS customers who have made+ > a firm decision to move to UNIX, will youe" > offer a migration path to HP-UX? > 3 > A: Yes. For our OpenVMS customers who have made ay4 > decision to move to UNIX, we believe that HP-UX is6 > an excellent choice, and we will work with them on a4 > migration plan and provide tools and services that& > can help ensure a smooth transition. > Q > Yes the first version was ugly. But it seems that they want lead people leavings6 > OpenVMS to their Unix instead of other vendors ones.  : are you kidding?  VMS users would move to freevms or OS400" before they would move to unix ...   ------------------------------  % Date: Sat, 18 May 2002 15:44:39 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>a# Subject: Re: Stallards smoking gun!n, Message-ID: <3CE6AF25.7150EA92@videotron.ca>   Daniel Clar wrote:Q > Yes the first version was ugly. But it seems that they want lead people leavingh6 > OpenVMS to their Unix instead of other vendors ones.   Dah !D  N For years, the biggest problems Digital, Compaq and now HP have had is to findG a way to get folks off VMS and migrate to their own replacement system.tL Digital failed royally and customers went to competitors. Compaq realised itN could not pitch NT as a replacement for VMS, so it had no replacement it could present to VMS customers.a  M HP is different since it has "a" leading Unix solution with one of the better1% inventory of available applications. v  I While it was easy to ditch Digital in favour of HP IBM or Sun, it becomes-K harder to ditch HP in favour if Sun or IBM since the choices have narrowed,00 especially if you already have HP gear in house.  L This may be why HP will be more agressive in trying to migrate VMS customersM off VMS.  The fact that the question was just "toned down" instead of removeduL alltogether in the volatile VMS roadmap document is an indication to me that the policy hasn't changed. t  K If they really didn't intend to hope VMS customers will get off VMS to gotor@ Unix, they would have replaced the question with something like:  J Q: What VMS development strategies can customers expect in the long term ?H A: The first step will be declaring VAX-VMS mature, with only updates toK ensure interoperability with new versions of VMS on Alpha and IA64.  With a I shared code-base, we can expect Alpha and IA64 version of VMS to match atwJ least until 2006. Once demand for Alpha-VMS drops, it too will be delcaredK mature with only updates to ensure operability, after which, development ofs/ VMS will continue with no end in sight on IA64.f   ------------------------------  % Date: Sat, 18 May 2002 16:16:02 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>d# Subject: Re: Stallards smoking gun!r, Message-ID: <3CE6B67E.A7BDFB77@videotron.ca>   Glenn Everhart wrote:r > G > It seems likely to me that the HP folks knew almost nothing about VMSsF > and considered it to be another flavor of Unix early on. Being a CEO@ > does not confer Deific (nor even angelic) intellectual powers.  K I have to disagree with this.  Carly didn't make all the decisions. That iseJ why there was an integration team formed initially of about 400 people andM supposedly raised to about 1000 later on, according to what Carly said on TV.   K Considering that True64 and Alpha were one of of the "problem child" of thehM integration, and that they were part of the same group that also handles VMS, H I find it very hard to believe that the integration team would have beenM allowed to overlook VMS, unless whomever was being consulted for the businessi0 critical Compaq stuff had an agenda against VMS.  G Similarly, when Carly got access to Compaq's real books, she would have L required to see revenus/profits breakdowns on a product line by product lineK basis in order to make the product roadmap decisions. Again, she would have-" seen the profits generated by VMS.  K Consider that Carly made sure to say many times during and after the mergerRN process that Tandem stuff was safe and that it serves stock exchanges etc etc.M This means that someone did their job of educating Carly on the impossibilityc? of cancelling Tandem. Who was in charge of doing this for VMS ?p? Would it have been Marcello or his boss ? (was it Blackmore ?).i    B > In short I think a lot of hoo-raw about foolish statements about2 > conversion of VMS to phux\\\\HP-UX is premature.  L You can ignore those signs if you wish. But to me, this was a tell tale sign of what is to come.2  J > As for how VMS is marketed, actions speak louder than words. I hope they4 > do better as part of HP than they did with Compaq.  M You can wish all you want. But the only way to try to predict what HP will do2L with VMS in the future is to look at their statements of directions. The oneD constant theme is "we will continue Compaq's roadmap to maintain our@ commitment to existing customers" (or something to that effect).M This means no changes to marketing, reduced niche markets etc etc, as well asaE a focus on not breaking commitments to existing customers. This shows @ absolutely no intentions of changing the way Compaq handled VMS.    K Some time ago, there were many calls for Compaq to start to take enterprise H systems seriously. Marcello then let it be known to some of us to expectM Compaq to change significantly and start to take enterprise systems seriously N and that there would be a advertising campaign on TV to try to change Compaq'sM image from a PC manufacturer to an enterprise company. Our hopes were all waya& up. Imagine seing a VMS ad on TV !!!!!  N Unfortunatly, Compaq's idea of enterprise computing was some .com company thatN makes kites setting up their main data centre in a VW minivan and fill it with
 wintel boxes.m  L Right now, Intel maintains it monopoly on advertising by heavily subsidisingN any advertising that ends with the damned intel logo and tune. This means thatK it is far cheaper for Compaq/HP to advertise some wintel crap than it is tol advertise a real system.  L It won't be until VMS is commercially viable on IA64 that we can see whetherH HP will ever have any intentions of leveraging VMS's full potential. TheM problem is that 4-5 years from now, without any advertising, with the loomingeL death of Alpha, and a focus to send all new customers to PA-RISC, VMS may beN terminally injured and we may never know if HP would have marketed VMS once it
 was on Intel.i  L In hindsight, I am starting to agree with Mr Dachtera,s calls for VMS on theJ 8086. Not for VMS to run on affordable boxes, but rather so that VMS couldM have been marketed with funds partly paid by Intel. Imagine, you make VMS runLM on 8086. Yo get "free" marketing paid by Intel, but when a customer walks in,mI you convince him Alpha is much better. Ahhh ! That would have been great.,   ------------------------------  % Date: Sat, 18 May 2002 17:33:37 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>m# Subject: Re: Stallards smoking gun!y, Message-ID: <3CE6C8A8.D88E9885@videotron.ca>   "Main, Kerry" wrote:J > Yep, and here is a pointer to just a few of the Cust's and ISV's jumping > on the IPF bandwagon:r    L Mr Main, I do not know about the rest of customers, but to me, those attempsM from Compaq to show customers who supported the murder of Alpha actually hurthL Compaq more than it helped. It was very obvious spin control, and one has toJ wonder what Compaq had to do for those customers to agree to be associated$ with the Compaq prepared statements.  J Secondly, as far as ISVs are concerned, I think that HP will have to startN from scratch following the HP announcements of product roadmaps.  Will HP workL to get Oracle to port its applications, or will HP be happy with Oracle just porting the database back end ?e  K The danger is that ISVs will wait to see what their customers indend to do, N and customers waiting to see what ISVs intend to do. With nobody making formalL decisions, the end result is that customers will not see ISV commitments andP will decide to migrate off VMS, at which point the signal to ISVs will be clear.   ------------------------------    Date: 18 May 2002 18:09:33 -0700( From: bob@instantwhip.com (Bob Ceculski)# Subject: Re: Stallards smoking gun!n= Message-ID: <d7791aa1.0205181709.76c2e734@posting.google.com>    "Main, Kerry" <Kerry.Main@hp.com> wrote in message news:<BE56C50EA024184DAF48F0B9A47F5CF4023D904A@kaoexc01.americas.cpqcorp.net>...,	 > Andrew,2 > < > >>> Urban myth along with the hairy handed hitch hiker.<<< > C > Ooo... Andrew is getting sensitive ..doing the fud thing again ..5 >  > :-)@ > C > While I did not see the hairy handed hitch hiker at the last CETShD > (Compaq symposium), I did see one of the folks from Irish NationalJ > Railway stand up and tell those in the audience about their world recordA > - at least I have heard no other application being continuously 4 > available for 17 years - VMS V3.2 was the version. >  > :-)  >  > Kerry Main > Senior Consultantd > Hewlett-Packard Canada# > Consulting & Integration Servicesl > Voice: 613-592-4660a > Fax  :  819-772-7036 > Email: Kerry.Main@hp.com >   C mine have ... I have been on VAX/VMS and then ALPHA/VMS for over 17i6 years now w/o an OS crash ... still waiting Andrew ...   ------------------------------  # Date: Sun, 19 May 2002 01:35:44 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>r# Subject: Re: Stallards smoking gun!4' Message-ID: <3CE704B4.95465127@fsi.net>s   Bob Ceculski wrote:s >  > "Main, Kerry" <Kerry.Main@hp.com> wrote in message news:<BE56C50EA024184DAF48F0B9A47F5CF4023D904A@kaoexc01.americas.cpqcorp.net>...r > > Andrew,  > >e> > > >>> Urban myth along with the hairy handed hitch hiker.<<< > >tE > > Ooo... Andrew is getting sensitive ..doing the fud thing again ..a > >m > > :-)h > >nE > > While I did not see the hairy handed hitch hiker at the last CETSfF > > (Compaq symposium), I did see one of the folks from Irish NationalL > > Railway stand up and tell those in the audience about their world recordC > > - at least I have heard no other application being continuouslye6 > > available for 17 years - VMS V3.2 was the version. > >  > > :-)e > >a > > Kerry Main > > Senior Consultante > > Hewlett-Packard Canada% > > Consulting & Integration Services- > > Voice: 613-592-4660@ > > Fax  :  819-772-7036 > > Email: Kerry.Main@hp.com > >r > E > mine have ... I have been on VAX/VMS and then ALPHA/VMS for over 17 8 > years now w/o an OS crash ... still waiting Andrew ...  F I dunno, Bob. To have never had to deal with a crash or analyze a dump% might not be something to brag about.n   --   David J. Dachterar dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------  # Date: Sat, 18 May 2002 18:29:23 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: Tivoli ABC for VMS>% Message-ID: <3CE6A0C5.8FDFCA@fsi.net>p   "Main, Kerry" wrote: >  > David, > J > >>> True, with the advent of SAN technology, the hardware is available -H > but is the available telecomm. infrastructure ready and is it equal to" > the demands of such in scale?>>> > E > While it obviously depends of what part of the globe you are in, in F > general, the telecom folks have huge amounts of speeds and bandwidthJ > available at costs that are a small fraction of what they used to be. InJ > addition, due to the current depressed telecom market, I suspect you canJ > negotiate some very attractive deals that would not have been possible a > year ago.M > " > Reference: [noted, then snipped]  F That still begs the question: if all of the Comdisco/Sungard customersG suddenly elected to change from 'hot site' to (the equivalent of) "longbE distance clustering", would sufficient bandwidth be available at thatr/ scale for costs which would not be prohibitive?t  F ...and if so, is this possible in the immediate term, near term, short term, mid term or long term?   -- r David J. Dachterah dba DJE Systemss http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  % Date: Sat, 18 May 2002 14:39:34 -0400r' From: "Main, Kerry" <Kerry.Main@hp.com>p Subject: RE: Tivoli ABC for VMS/T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026606E5@kaoexc01.americas.cpqcorp.net>   David,  @ >>> That still begs the question: if all of the Comdisco/SungardG customers suddenly elected to change from 'hot site' to (the equivalentcG of) "long distance clustering", would sufficient bandwidth be availablec: at that scale for costs which would not be prohibitive?<<<  ! Well, cost is a relative term.=20n  D Hot backup sites for a med-large config typically start at $250K perF year (every year) with the actual daily rates (if implemented) runningF around $10-$15K/day. Think about the total costs if the company had to2 run its business for 3+ months in the backup site.  @ Imho, the decision is not unlike spending lots of $'s to rent anH apartment vs. wanting to see the $'s better invested and deciding to buy a home.V  E P.s. not sure if you knew this, but Comdisco no longer exists. It hadeG financial problems and Sungard bought their Business Continuity assets.l  
 Reference: www.comdisco.com   Regards,  
 Kerry Main Senior Consultanto Hewlett-Packard Canada! Consulting & Integration Services  Voice: 613-592-4660p Fax  :  819-772-7036 Email: Kerry.Main@hp.com     -----Original Message-----9 From: David J. Dachtera [mailto:djesys.nospam@fsi.net]=20e Sent: May 18, 2002 2:29 PM To: Info-VAX@Mvb.Saic.Comm Subject: Re: Tivoli ABC for VMS=     "Main, Kerry" wrote: >=20 > David, >=20H > >>> True, with the advent of SAN technology, the hardware is available   > >>> - H > but is the available telecomm. infrastructure ready and is it equal to  " > the demands of such in scale?>>> >=20H > While it obviously depends of what part of the globe you are in, in=20I > general, the telecom folks have huge amounts of speeds and bandwidth=20iJ > available at costs that are a small fraction of what they used to be.=20H > In addition, due to the current depressed telecom market, I suspect=20J > you can negotiate some very attractive deals that would not have been=20 > possible a year ago. >=20" > Reference: [noted, then snipped]  F That still begs the question: if all of the Comdisco/Sungard customersG suddenly elected to change from 'hot site' to (the equivalent of) "longeE distance clustering", would sufficient bandwidth be available at thatV/ scale for costs which would not be prohibitive?e  E ..and if so, is this possible in the immediate term, near term, shorth term, mid term or long term?   --=20h David J. Dachterat dba DJE Systems  http://www.djesys.com/  H Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   ------------------------------  # Date: Sat, 18 May 2002 18:50:22 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Tivoli ABC for VMSeB Message-ID: <OnxF8.174704$M7.17940383@bin7.nnrp.aus1.giganews.com>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3CE68865.BF6624E3@fsi.net...  > Bill Todd wrote: > >o@ > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message% > > news:3CE5C78D.1C1A2BF6@fsi.net...    ...a  L > > > Who doesn't? How many "enterprises" can afford disaster "tolerance" of ahK > > > scale that would have survived 9/11? Sorry, Disaster Recovery is here  to > > > stay!l > > E > > Maybe not.  As usual, software is years behind making good use ofs	 availableeJ > > hardware:  with the right software, you could have a disaster-tolerantK > > solution (for something like the 9/11 situation - requires only several - > > hundred feet of separation between sites)o >sH > I suppose so - I saw a picture in Thursday's Chicago Sun Times showingG > the "crater" of "ground zero". The caption was talking about the lasteG > loads of debris being removed from the site (even the most gargantuanrF > task eventually reaches a conclusion). The buildings quite literallyH > "across" the street appear to have sustained some minor damage (mostlyJ > from the collapse, and not the impact itself). They might have made good' > candidates for "nearby" backup sites.t >"H > The next question in my mind, however, would be: "Will the next attackI > (or its after effects) be so devastating that such proximity would be a?" > liability rather than an asset?"  F Well, my response was to the specific challenge you raised - where theK required separation distance falls within the scope where running dedicatedaL private lines to the 'remote' site is feasible (and inexpensive).  But I didE later describe use of an SSP (i.e., spreading both storage and remoteoK redundancy costs across multiple companies to achieve scaling efficiencies)o5 where the separation could easily approach 100 miles.e   >t# > > using today's (high-quality but-L > > commodity) hardware for less than the cost of existing disaster-recoveryJ > > configurations (even assuming that those existing configurations don't use-F > > redundant storage but depend on recovery to solve *all* problems). > E > In our shop (total storage 5+TB and rising), I dunno if that's evenpH > within the realm of possibility, given the sheer volume of storage andJ > the fact we are FDA certified and required to maintain certain standards& > so as to maintain our certification.  G Three complete copies of 5 TB cost under $25K for the raw (IDE) storagem' these days - hardly a major impediment.i   >TF > > Given the convenience and other value of essentially uninterruptedF > > operation, and the fairly rapid progress that is being made towardD > > commodity-hardware-based disaster tolerance, I wouldn't count on disasterD > > recovery being the solution of choice for too many years longer. >tH > Given that so few companies actually choose it now - or can afford to,C > is it really the "solution of choice"? Has it ever been? Dunno...l  F Well, reasonably complete remotely-stored backups sort of qualify as aK disaster recovery solution (though it would be nice to have already on handtF the systems to recover them to as well), so anything less is really no solution at all.  G But offloading storage chores to a competent party is quite attractive,gL especially given the rate at which storage use expands these days.  Once youB do that, achieving disaster tolerance is a logical (and relatively straight-forward) next step.   >r > >  EspeciallyeE > > given the potential synergy between disaster-tolerant storage andSI > > locally-outsourced storage:  if you're going to run a couple of lines4 anywayH > > for disaster tolerance, why not instead run them to an SSP which can then dolK > > that for you - at even lower cost and even greater separation distance,vG > > possibly with temporary emergency server facilities near the remote- site?- >-G > Is that possible given current telecomm. technology? (For "possible",eJ > read "cost effective as compared to maintaining a 'hot site' contract").I > (Yes, I am requesting the benefit of your insight, as opposed to my owns > knowledge/experience.)  K Unless you're planning on getting the data to your hot site using a stationoB wagon full of tapes (in which case I'm not sure 'hot' is the rightF adjective), you need the connectivity anyway.  Though if you only sendJ updates over the lines (rather than read over them as well, as occurs whenI you out-source storage) the bandwidth (and possibly latency) requirementsnF may be looser (it's not inconceivable that you could use redundant ISP
 connections).   G But dedicated bandwidth is pretty cheap these days and continues to get H cheaper rapidly, and there's a *lot* of 'dark fibre' still available forL rent.  No technology problem, more a question of whether a line already runsJ where you want it - and an SSP is in a position to set up both ends of itsH disaster-tolerant shop to take advantage of what connectivity is alreadyF available if it doesn't want to run its own (that still requires localD client connections to the SSP, but that didn't seem to present major5 obstacles during the initial flurry a year-plus ago).b   - bill   ------------------------------  # Date: Sun, 19 May 2002 01:28:39 GMTe1 From: "David J. Dachtera" <djesys.nospam@fsi.net>s Subject: Re: Tivoli ABC for VMSh' Message-ID: <3CE70307.7FA21F66@fsi.net>u   "Main, Kerry" wrote: >  > David, > B > >>> That still begs the question: if all of the Comdisco/SungardI > customers suddenly elected to change from 'hot site' to (the equivalenttI > of) "long distance clustering", would sufficient bandwidth be availableo< > at that scale for costs which would not be prohibitive?<<< >   > Well, cost is a relative term. > F > Hot backup sites for a med-large config typically start at $250K perH > year (every year) with the actual daily rates (if implemented) runningH > around $10-$15K/day. Think about the total costs if the company had to4 > run its business for 3+ months in the backup site.  D Of course, the idea is to use the hot site for business continuationG only for as long as it takes to either restore the existing facility ore to secure another.  B > Imho, the decision is not unlike spending lots of $'s to rent anJ > apartment vs. wanting to see the $'s better invested and deciding to buy	 > a home.i  F Well, I think I know what youre trying to say, but the comparison is aG bit rough. The reasons for owning a home vs. renting are (at least) twotB fold: tax advantages and build up of equity. Then again, a company@ tyoically does not "own" telecomm. facilities outside of its ownF premises, withthepossible expection of those few who can afford to own their own satellites.a  G > P.s. not sure if you knew this, but Comdisco no longer exists. It hadpI > financial problems and Sungard bought their Business Continuity assets.o >  > Reference: > www.comdisco.com  ? Yes. I have local contacts inside of the former Comdisco. To mynH knowledge, they are continuing to use the Comdisco name, but my info. onA that is a bit stale. Then again, Comdisco's business continuationeF services were to Comdisco corporate rather like VMS is to HPQ: a money> maker amid marginal or money-losing other businesses. BusinessF continuation has always made them money (AFAIK), unlike other areas ofC the company which foundered and led Comdisco's bottom line down the  drain.   -- e David J. Dachtera  dba DJE Systemsr http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------    Date: 18 May 2002 23:47:29 -0600+ From: young_r@encompasserve.org (Rob Young)k Subject: Re: Tivoli ABC for VMS 3 Message-ID: <QUd+wXAzlgz9@eisner.encompasserve.org>r  [ In article <3CE5C78D.1C1A2BF6@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:c > Rob Young wrote: >> w^ >> In article <3CE3177B.37171E2A@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: >> > Rob Young wrote:c >> >> a >> >> In article <3CE1D600.7C786560@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:- >> >> > jp wrote:- >> >> >>M >> >> >> Can anyone here give any feedback, positive or negative, on Tivoli'sm> >> >> >> ABC with OpenVMS? Does it use the VMS Backup utility? >> >> >dL >> >> > I cannot recommend any backup "solution" for OpenVMS that avoids VMSK >> >> > BACKUP or tries to send multiple terabytes of data over an Ethernet  >> >> > link, gigabit or no. >> >> >u1 >> >> > The "solution" to ABC is VMS BACKUP, IMO.r >> >> >p >> >>hL >> >>         I can recommend any backup solution that does what is supposedG >> >>         to do.  Restore files when you need them.  ABC does that.c >> >>sK >> >>         Secondly, many shops have Enterprise backup solutions... i.e. J >> >>         tape robots, multiple tape drives and dozens of Terabytes of >> >>         tape storage.e >> >H >> > No - not terabytes of tape storge, terabytes of *DISK* storage that) >> > *MUST* be backed up *EVERY* *NIGHT*.n >> >M >> > NFW you're gonna transfer all that over Ethernet every night, gigabit ort >> > no. >> > >>  J >>         Well... perhaps you tend to believe people with that much stuff' >>         back it all up every night. t > G > Nope - I don't "believe it" - I *LIVE* it! ...every workday, *AND* oni > the weekends!a >  >> That mostly isn't the case. - > . > You've never worked in healthcare, have you? >   B 	Yes.  But that is your case.  When I say "mostly" , to have above/ 	2 Terabytes of active data puts in a minority.e   >> With TSM, youI >>         typically perform INCREMENTAL backups, only that which changed2 >>         is saved. 3 > I > Rather useless when the entire database table space (every file! 2.7TB)g > get updated *EVERY DAY*! >   B 	It would still get backed up as it is changing.  How long does itB 	take to do your backups?  How many active tape drives?  DLT 7000?  : >> Customers keep 20-30 days , that is where the Terabytes >>         come from.  > H > Not in healthcare, it doesn't. That's barely a week's worth of imagery > and patient history! >   C 	You are using Cerner.  I have been onsite at a Cerner site before,y, 	they don't have nearly the totals you have.   >> eJ >>         The situation you describe, Terabytes of storage of course will* >>         require several tape libraries, > > > ...or many tape drives running in parallel simultaneously... > # >> a large setup indeed.  But for a/H >>         more typical mid-size setup (200-400 GBytes of daily changing: >>         data) the backup over the net goes like this... >  > (you hope) >   7 	It works and works well as that other poster mentions.a   >> servers back upR >>         to TSM server, the TSM server itself has a very large DiskPool > [snip]2 >> >> You can't justify separate solutions in manyD >> >>         cases.  That is why there is 3rd party clients for VMS, >> >>         for Enterprise backup vendors. >> >+ >> > For *VERY* small VMS systems, perhaps.. >> > >> s >>         Eh?  Define small.f > H > 100GB or less doing incrementals six days a week and taking a full dayI > of downtime on the weekend so the backups can saturate the network intof' > uselessness for a weekly full backup.a >   E 	You don't understand how the product works.  Incrementals are alwaysl@ 	performed.  TSM is a database behind the scenes.  A very robustE 	database.  The only copy of autorize.exe was backed up in September:   0 <NODE>$ abc show backup sys$system:authorize.exe; Archive Backup Client for ADSM on OpenVMS, Version V3.1.0.1o8 Copyright 1996-2001, Storage Solutions Specialists, Inc.P DISK$ALPHASYS:[SYS0.SYSCOMMON.SYSEXE]AUTHORIZE.EXE;1 (A) 0  20-SEP-2001 10:12:58  D  	For DR the entire library is offsite and tapes to keep it in-synch< 	go offsite everyday.  (Many others need DR, dozens of other 	platforms, various OSes).  @ 	Secondly and just as important, you don't saturate the network.B 	The network is designed to handle it.  Switched.  Each server has? 	multiple cards if necessary.  100 MBit is typical and they are- 	very cheap.  I > Ain't gonna happen, but won't stop folks from insisting on trying to doi > it.   C 	I'll wager you could speed your backups considerably if interestedp 	and not by going to SuperDLT.   > E >> > Good luck come disaster recovery time, that's all I gotta say...a >> eD >>         Diasaster Recovery is for those that can't.  I believe in( >>         Disaster Tolerant solutions.  > J > Who doesn't? How many "enterprises" can afford disaster "tolerance" of aJ > scale that would have survived 9/11? Sorry, Disaster Recovery is here to > stay!c >    	For those that can't.  $ >> >> TSM, Legato and surely one forG >> >>         Veritas but don't know the name.  And a quick google doesi8 >> >>         show VMS is there for Veritas as a client: >> >M >> > ...but if you've ever inquired of Veritas support, you'll find their VMS G >> > support is shaky, at best, and they outright admit that VMS systemhJ >> > (bootable) disks are not supported, according my partner's experienceE >> > (though he does tend to "embellish" the truth, shall we say...).o >> > >> pF >>         Ah, a problem.  My solution is to backup the system disk toJ >>         a local disk, in case of major corruption of course.  CertainlyQ >>         wouldn't be losing it as it is shadowed mirrorsets across datacenters.  > H > Come disaster recovery time - then what? Hope the backup disk survivedE > the disaster and the hot site will accept a hot/warm-pluggable SBB?p >   % 	You are talking about me having lostDE 	both sites.  If that is the case, yes there are problems, VERY largeeD 	problems, me losing a system disk are small in comparison.  I would@ 	also say if you lose your datacenter and your disaster recovery# 	site, you have large problems too.e  L >> > Sorry - I cannot recommend any "solution" that requires another machine> >> > to be recovered before the VMS system can even be booted. >> 24 >>         A nit that is easily overcome, see above. >  > ...and see my response above.r >   G 	Tangential response.  Come disaster recovery time?  What does disasteriA 	recovery have to do if disaster tolerant?  Want a laugh?  I knowrD 	several large customers using a large DR specialist and they aren't  	separated by more than 5 miles.   >> >3 >> > VMS systems are BACKUP *SERVERS*, not clients!  >> > >> o$ >>         No, they can be clients.  >  > Read my lips:g > 0 > VMS systems are BACKUP *SERVERS*, not clients! >   @ 	Not in my case , nor the fellow that responded.  Here is a veryD 	good example of why it is better.  After midnight, and I am looking( 	to restore a file backed up in October:  , ABC> show backup diskname:[user.username]m.mE DISKNAME:[USER.USERNAME]M.M;1 (A)            14  14-OCT-2001 04:16:44   / ABC> restore diskname:[user.username]m.m []/log0L %ABC-I-QRYPASS, 00:20:47.27 Scanning catalog for restore/retrieve candidatesJ %ABC-I-RSTPASS, 00:20:47.30 Restoring/retrieving file data from the server5 %ABC-S-RESTOK, restored DISKNAME:[USER.USERNAME]M.M;1 	 ABC> EXITa   > Are there any questions?    @ 	Yes.  If faster, and backed up by a rock solid database that in= 	turn creates a DR export (for those that need it), and everya3 	file is literally "right there", why not recommenda? 	it?  What is the downsides?  Network?   Can't help if 10 Mbit, 2 	but many of us are 100 MBit (or higher) switched.   > * >> Just like all the large Unix boxes thatM >>         fall into the same category.   Did you know they backup mainframes  >>         with TSM? e > 1 > How many "wrongs" does it take to make a right?  >   = 	My... that's a great technical rejoinder.  Care to shed somee 	light as to the "wrongness?"f   >> Server or client: >  > Who gives a shit?t >   = 	Those that may be interested in Enterprise backup and seeingc# 	if there is native client support.i   				Rob    ------------------------------  % Date: Fri, 17 May 2002 22:29:26 -0400m0 From: Glenn and Mary Everhart <Everhart@gce.com>3 Subject: [Fwd: RE: Comments on HP officers' remarksf' Message-ID: <3CE5BC86.B50E1897@gce.com>:  - Re the statements about initial HP VMS plans:-  @ It could be so, but given that evidently many of the HP'ers wereJ uninformed enough about what VMS is to think it was another kind of unix, E I think it plausible that they have been educated a bit to understandeE that those kinds of things can be said only in very circumscribed andiC legalistic ways when speaking of certain POSIX operations, and thusoB the customers of VMS would not be generic Unix customers, and haveF needs for functions perhaps not to be found in someone's generic unix.  C You can't expect HP'ers to have seen the Life of a Project documentyI (the VMS development method Bible) nor to have been informed of what thatuC culture achieves, and if they thought VMS was a kind of unix, it isdC unlikely they would have any idea about its reliability, security,   scalability, or much else.  H What all the hoo-raw says to me is that HP and Compaq management thoughtH there were much more difficult issues to merging than VMS (and in this IH think they were right) and did not devote much bandwidth to it. That theI CEO made statements about how fully they had gone over product lines says 5 only that she also didn't realize what was going on. u  I Put this in your pipe and smoke it: ** LOTS ** of CEOs don't know many ofsH the details about their organizations. You find exceptions (like KO was)D at times, but the CEO title does not confer Deific, or even angelic, understanding on a mortal.   Glenn Everhart     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]# Sent: Friday, May 17, 2002 12:41 PMl To: Info-VAX@Mvb.Saic.Com A Subject: Re: Comments on ITUG/DECUS joint Euro conference in Lyone     Kenneth Farmer wrote:iI > better idea of what issues were covered.  Until you know who was in thee< > clean room, stating they had 8 months is a bit misleading. > ; > I agree with Robert.  Give them some time to sort it out.o  L I go by what Carly stated publicly many many times prior to the merger beingG signed. She repeatedly said that her integration team had gone over alloJ product lines and long ago hgad decided on the product line which would be; unveiled a few days after the transaction is made official.   8 What they published on week 1 was their true intentions.  J Now, Stallard may have been told that his statements were too damaging andL that they needed to be toned down.  But util there is a clear statement FROMH CARLY that they are fine tuning the product roadmap, no amount of covertL changes to existing documents will convince me that the true intentions have changed.  K Had Carly mentioned that it was only an initial roadmap that would get somegL fine tuning over the next few months, perhaps I would recieve Stallard coverL changes less negatively. But Carly was very authoritative and said that theyG had consulted partners and customers etc etc in designing that officials roadmap.    F **********************************************************************J This transmission may contain information that is privileged, confidentialO and/or exempt from disclosure under applicable law. If you are not the intendedvN recipient, you are hereby notified that any disclosure, copying, distribution,N or use of the information contained herein (including any reliance thereon) isG STRICTLY PROHIBITED. If you received this transmission in error, pleaserP immediately contact the sender and destroy the material in its entirety, whether, in electronic or hard copy format. Thank youF **********************************************************************   ------------------------------   End of INFO-VAX 2002.275 ************************