1 INFO-VAX	Sun, 09 May 2004	Volume 2004 : Issue 256       Contents:? Re: Alpha is phased out .... UltraSPARC V in the same way ..... ? Re: Alpha is phased out .... UltraSPARC V in the same way ..... ? Re: Alpha is phased out .... UltraSPARC V in the same way ..... ? Re: Alpha is phased out .... UltraSPARC V in the same way ..... J DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...]N Re: DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...]4 DCLER (DCL Enhancement Request) for SET PROMPT: Time8 Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time8 Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time DEC C fsync and fflush Re: DEC C fsync and fflush: Re: DEC/Compaq/HP C RTL v. multi-dot file/directory names? Re: DFO and SET FILE/NOMOVE  Re: EVE customizations Re: EVE customizationsM Re: HP World Magazine: For Business Continuity...the answer may be    OpenVMS J 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 OpenV< Re: looking for suggestions for new $GETDVI item codes . . . Re: more DFO questions) Re: Normal operating temerpature for ES40  Re: T4 and TLViz Re: T4 and TLViz Re: VMS news on news.com 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   F ----------------------------------------------------------------------  $ Date: Sat, 8 May 2004 18:24:50 +0200* From: "Karsten Nyblad" <nospam@nospam.com>H Subject: Re: Alpha is phased out .... UltraSPARC V in the same way .....- Message-ID: <c7j1kp$1okm$1@news.cybercity.dk>   2 "Main, Kerry" <kerry.main@hp.com> wrote in messageL news:FD827B33AB0D9C4E92EACEEFEE2BA2FB3143F4@tayexc19.americas.cpqcorp.net...  C >> From: Andrew Harrison [mailto:andrew_._remove_harrison@su_n.com]  >> Sent: May 8, 2004 5:39 AM >> To: Info-VAX@Mvb.Saic.Com< >> Subject: Re: Alpha is phased out .... UltraSPARC V in the >> same way .....  >> >> Keith Parris wrote: >>: >> > "Karsten Nyblad" <nospam@nospam.com> wrote in message, >> news:<c6csgq$1bmh$1@news.cybercity.dk>... >> >? >> >>Is Sun making it self ready for a Sparcide?  When Sun does  >> not have the = >> >>resources to complete the UltraSparc V project why don't  >> they collaborate 8 >> >>with Fujitsu on big servers?  Fujitsu has some very >> interesting projects on
 >> >>SPARC64.  >> > >> > >>C >> Funny, Sun is being slated for axing a processor (USV) in favour D >> of one that no one outside Sun knew existed before January (Rock)0 >> and this is being touted as the end of SPARC. >>@ >> It doesn't take much intelligence to work out that this isn't% >> actually a very logical possition.  >>I >> > But how long will Fujitsu continue to pour money down the SPARC hole : >> > when they see Sun themselves cancelling CPU projects? >> >C >> > Fujitsu has already started shipping systems based on Itanium:  >> >A >> http://www.computerworld.com/hardwaretopics/hardware/story/0,1 & >> 0801,88366,00.html?from=story_picks- >> > http://www.theinquirer.net/?article=7392  >> > >>9 >> Given Itaniums problems if you really think that SPARC 9 >> is a dead platform then Fuji don't seem to have made a  >> very smart move.  >>: >> Itanium is for HP, the sooner the rest of the Intel OEM< >> community wake up to that fact the better (for them), IBM@ >> already have and its only a matter of time before NEC, Unisys= >> and the rest give up on what have been a major problem for  >> HP and a disaster for them. >>
 >> Regards >> Andrew Harrison >> >  >Andrew, > ) >Those last two paragraph's are pure fud.  > F >Especially if you take at look at the following article that looks atF >why Sun is so anti-Itanium: (and potentially why Fujitsu has seen the >writing on the wall..)  > ( >http://www.techuser.net/index.php?id=46 >Will Sun adopt Itanium? >by latif  [Apr 17, 2004]   G When a company like Sun is loosing money, you will always find somebody E arguing that there processor architecture is dead.  However, the rosy H picture of Itanic does not fit that with what I see.  Intel has problemsK making processors that do not produce too much heat.  E.g. The Inquirer has C the following comment in http://www.theinquirer.net/?article=15777:   K "And here's some more speculation and rumour. We're hearing that some IA-64 K roadmap parts that weren't dropped before, are being dropped now or not too  long from now. "  F I have a hunch, Intel will have trouble producing significantly fasterH processors for a period of time.  I the meantime AMD64 may become the deK facto standard 64-bit architecture for Windows and Linux.  Then Itanic will L not be an industrial standard.  It will be the processor used by HP, SGI andH a few smaller players.  Then HP will have to pay much of the developmentL costs for Itanic.  Itanic processors seem more expensive to develop than theE other processors.  Suddenly it Itanic does not look like an automatic  winder.    Karsten Nyblad ibpit1202 at sneakemail dot com    ------------------------------  # Date: Sat, 08 May 2004 18:28:42 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> H Subject: Re: Alpha is phased out .... UltraSPARC V in the same way .....@ Message-ID: <fab2fdb6f5b6fbec65609478c00b9594@news.teranews.com>   Andrew Harrison wrote:B > Funny, Sun is being slated for axing a processor (USV) in favourC > of one that no one outside Sun knew existed before January (Rock) / > and this is being touted as the end of SPARC.   K The way I read it, they decided that there was still plenty of life left in 0 "4" so it was pointless to go to "5" right away.  J However, I think that Sun should have worded the announcement differently.  G From my VMS centric point of view, it seems to be that Sun is doing the I equivalent of cancelling EV8 because it can work on EV7 to improve it for L enough years until the next generation chip arrives. (For HP it is that IA64< thing, for Sun, it would be that Futjitsu version of Sparc).  M If Sun cancelled 5 because 4 was more than enough to bridge the gap until the N Futjitsu chip arrives, then its statements should have been more to that pointI to ensure customers and potential customers know full well that the Sparc ' architecture is still being developped.   L In fact, Sun could have simply stated that the Futjitsu products will arriveL so soon that it is pointless to develop 5 to bridge the gap. That would haveM put a much more positive spin on the story and most certaintly not have given M any ideas that Sun was trying to weasel itself out of the Sparc architecture.    ------------------------------  # Date: Sat, 08 May 2004 18:40:31 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> H Subject: Re: Alpha is phased out .... UltraSPARC V in the same way .....@ Message-ID: <5c14c9f40a2ff10ee7387c8b6563704e@news.teranews.com>   "Dr. Dweeb" wrote:M > I agree andrew.  The question for the collective crystal ball is whell will J > this event (the realisation that Itanic will actually sink) occur in the/ > collective boardrooms of NEC, UniSys et. al.?   : If we know, they know. They can't possibly be that stupid.  L Remember that just about everyone who has announced IA64 support has done soN due to sweet deals from Intel. (translate "sweet deals" with "threaths" if you	 like :-).   J They know that IA64 will never be "commodity" "low cost" and "high volume"K which was its whole premise for existance in the first place. And they know N that IA64 won't be a big performance leader, it will just tag along with Power probably now in the #1 leader.    N However, any company that has accepted the Intel offers to jump into IA64 knewF about the risk and they probably have exit strategies already devised.  K Consider the various statements from VMS engineers about the port of VMS to K IA64 where they made sure that they restructured the code to be more easily L portable and support multiple architectures from same code source. That is aM very good indication that even they know that IA64's future isn't so certain.    ------------------------------  # Date: Sat, 08 May 2004 18:50:05 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> H Subject: Re: Alpha is phased out .... UltraSPARC V in the same way .....@ Message-ID: <914395689aeb2f32d9e7e02a1b41b5f0@news.teranews.com>   Karsten Nyblad wrote: M > facto standard 64-bit architecture for Windows and Linux.  Then Itanic will N > not be an industrial standard.  It will be the processor used by HP, SGI and > a few smaller players.      N Ironic, that sounds like what MIPS was all about. But at least MIPS was a RISC$ architecture, not that EPIC fiasco.   H Since IA64 requires special compilers, will all the GNU compilers have a special version for IA64 only ?    ------------------------------   Date: 8 May 2004 22:11:44 -0700 . From: spamsink2001@yahoo.com (Alan E. Feldman)S Subject: DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...] = Message-ID: <b096a4ee.0405082111.1958a8f6@posting.google.com>   C How about directory listings sorted by date-time? Yes, you'd either D have to list a single directory or suppress the headers and trailersD 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.    ------------------------------  % Date: Sun, 09 May 2004 07:40:25 +0200 * From: Paul Sture <nospam@sture.homeip.net>W Subject: Re: DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...] * Message-ID: <2g5uibF4o8fkU1@uni-berlin.de>   Alan E. Feldman wrote:E > How about directory listings sorted by date-time? Yes, you'd either F > have to list a single directory or suppress the headers and trailersF > 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    H $ ! 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:    ------------------------------   Date: 8 May 2004 22:03:14 -0700 . From: spamsink2001@yahoo.com (Alan E. Feldman)= Subject: DCLER (DCL Enhancement Request) for SET PROMPT: Time < Message-ID: <b096a4ee.0405082103.c1b431a@posting.google.com>  B Any chance of having a time option added to SET PROMPT? Perhaps itF could be added F$FAO style. Note: The time would be static -- it would8 just be the time that the prompt appeared on the screen.   ------------------------------  % Date: Sun, 09 May 2004 07:33:20 +0200 * From: Paul Sture <nospam@sture.homeip.net>A Subject: Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time * Message-ID: <2g5u52F4orm9U1@uni-berlin.de>   Alan E. Feldman wrote:D > Any chance of having a time option added to SET PROMPT? Perhaps itH > 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.  H 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 >   ------------------------------  % Date: Sun, 09 May 2004 07:34:33 +0200 * From: Paul Sture <nospam@sture.homeip.net>A Subject: Re: DCLER (DCL Enhancement Request) for SET PROMPT: Time * Message-ID: <2g5u79F4orm9U3@uni-berlin.de>   Alan E. Feldman wrote:D > Any chance of having a time option added to SET PROMPT? Perhaps itH > 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.  H 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 >   ------------------------------  % Date: Sat, 08 May 2004 09:44:36 -0700  From: Z <z@no.spam>  Subject: DEC C fsync and fflush 0 Message-ID: <109q3iqifb3rid4@corp.supernews.com>  < If using fsync() to flush unwritten data to disk, should you; also call fflush(), first, to flush unwritten data from the  RTL to RMS?    ------------------------------  # Date: Sat, 08 May 2004 18:54:30 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: DEC C fsync and fflush @ Message-ID: <5b0ebda81d7392d6715102712227278e@news.teranews.com>   Z wrote: > > > If using fsync() to flush unwritten data to disk, should you= > also call fflush(), first, to flush unwritten data from the 
 > RTL to RMS?   C I have used both. Not sure if it is required, but it seemd to work:    fflush(logfil);  fsync(fileno(logfil));  # with logfil being the result of an  D 	fopen("chocolate.data","w","ctx=rec","shr=get","rfm=var","rat=cr").  K In my notes, I had written that fsync was an undocumented function that did M what fflush was supposed to do. Haven't revisited the issue since (many years  ago) because the code works.   ------------------------------  $ Date: Sat, 8 May 2004 22:22:20 -04005 From: "Brad McCusker" <brad.mccuskerNosp@Mcompaq.com> C Subject: Re: DEC/Compaq/HP C RTL v. multi-dot file/directory names? 0 Message-ID: <109r5f4bh0sf6ab@corp.supernews.com>  K I'm not sure what documentation you are seeing this stuff in, but, multiple H dots is not a problem as far as I can tell, if you set the right feature! switch (decc$filename_unix_only):    CRTL_$ ty mkdir_test.c #include <stdio.h> #include <stat.h>  #include <string.h>  #include <errno.h>   main() { ,     if (mkdir ( "junk/ab.cd/gh", 0777) != 0)>          printf("? mkdir() failed:\n\t%s\n", strerror(errno)); }  CRTL_$ cc mkdir_test CRTL_$ link mkdir_test CRTL_$ run mkdir_test  ? mkdir() failed: '         file specification syntax error ' CRTL_$ define decc$filename_unix_only 1  CRTL_$ run mkdir_test  CRTL_$ dir [.junk]ab*   ( Directory USER1$:[MCCUSKER.SCRATCH.junk]   ab^.cd.DIR;1   Total of 1 file. CRTL_$  . Get the latest ACRTL ECO if you dont' already.   Latest documentation is atL http://h71000.www7.hp.com/doc/732final/5763/5763pro.html - Section 1.6 talksJ about the feature switches.  Please let us know if that does the trick for you.  
 Brad McCusker  C RTL Project Leader   ------------------------------  * Date: Sat, 8 May 2004 22:58:45 +0000 (UTC)1 From: Jefferson Humber <matrix01@globalnet.co.uk> $ Subject: Re: DFO and SET FILE/NOMOVE0 Message-ID: <c7jon5$o1b$1@sparta.btinternet.com>   Phil,   1 I've asked the same question before over at ITRC.   K http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=436848    Hope it helps,   Jeff      / Phillip Helbig---remove CLOTHES to reply wrote: G > I'm a bit confused about SET FILE/NOMOVE and its relationship to DFO.  > K > When installing DFO, it asks if SET FILE/NOMOVE has been run against the  F > system disk.  In order to do this, one cannot have booted from that J > system disk.  In other words, one must boot from, for example, the boot F > CD and execute SET FILE/NOMOVE from there.  If the system disk is a 9 > shadow set, should one execute it against both members?  > K > Presumably, this "anchors" the system files to the disk, preventing them  J > from being moved about by DFO.  This would only make sense, however, if H > the disk is not fragmented, i.e. one should first defragment the disk E > via BACKUP/IMAGE then run SET FILE/NOMOVE then install DFO.  Right?  > H > Why do the system-disk files need this anchoring while files on other  > disks apparently don't?  > I > What happens if one later installs additional stuff---layered products, J > VMS upgrade, patches etc---on the system disk?  These new files will notI > have had SET FILE/NOMOVE run on them.  Should one periodically run this J > command (which would involve periodically booting from CD, defragmentingJ > the disk via BACKUP/IMAGE then running SET FILE/NOMOVE)?  Presumably, itF > is possible to install new stuff on the system disk after installing? > DFO.  In that case, why does one need SET FILE/NOMOVE at all?  > J > Presumably, one should have a disk defragmented by the node to which it H > has a direct connection.  What about shadow sets with members on more F > than one node?  Should they be defragmented by all nodes which host  > disks in that shadow set?  >    ------------------------------  % Date: Sat, 08 May 2004 18:38:33 +0200 ( From: Andreas Davour <ante@update.uu.se> Subject: Re: EVE customizations 0 Message-ID: <cs9isf6yiuu.fsf@Tempo.Update.UU.SE>  * Andreas Davour <ante@update.uu.se> writes:  * > David M Smith <dsmit115@csc.com> writes:Q >> I don't know emacs, and I don't know what you mean by "code-mode", but if what O >> you mean is a Cobol-sensitive editing environment then probably what you are P >> looking for is LSE (Language Sensitive Editor) which is a layered product andM >> (unfortunately) separately licensed. I've never used it myself, so I can't @ >> compare it or tell you feature, but you can read about it at: >>- >> 	http://h71000.www7.hp.com/doc/decset.html  >> >> (today's link). > J > Maybe I should have specified my needs more. A "mode" in emacs helps youE > with syntax hilighting and indention and completetion of code. It's G > fairly handy if you're doing FORTRAN or COBOL, since columns matters.  > G > Thanks for the link! I'll check it out and see if LSE might be what I  > need.   G LSE do indeed look nice. I don't find it on my OpenVMS7.2 CD. Do I have G to call HP to get it or is it possible and download it somehow, since I > have the hobbyist PAK? I find the HP site kind of confusing...   /andreas   ------------------------------  % Date: Sun, 09 May 2004 07:03:55 +0200 * From: Paul Sture <nospam@sture.homeip.net> Subject: Re: EVE customizations * Message-ID: <2g5sdtF4ig3fU1@uni-berlin.de>   Andreas Davour wrote: , > Andreas Davour <ante@update.uu.se> writes: >  > * >>David M Smith <dsmit115@csc.com> writes: >>Q >>>I don't know emacs, and I don't know what you mean by "code-mode", but if what O >>>you mean is a Cobol-sensitive editing environment then probably what you are P >>>looking for is LSE (Language Sensitive Editor) which is a layered product andM >>>(unfortunately) separately licensed. I've never used it myself, so I can't @ >>>compare it or tell you feature, but you can read about it at: >>> - >>>	http://h71000.www7.hp.com/doc/decset.html  >>>  >>>(today's link). >>J >>Maybe I should have specified my needs more. A "mode" in emacs helps youE >>with syntax hilighting and indention and completetion of code. It's G >>fairly handy if you're doing FORTRAN or COBOL, since columns matters.  >>G >>Thanks for the link! I'll check it out and see if LSE might be what I  >>need.  >  > I > LSE do indeed look nice. I don't find it on my OpenVMS7.2 CD. Do I have I > to call HP to get it or is it possible and download it somehow, since I @ > have the hobbyist PAK? I find the HP site kind of confusing... >   H It won't be on the 7.2 CD itself, but on one of the layered product CDs.. Look for DECset, which actually contains this:  ?   Compaq DECset for OpenVMS Systems, Version 12.4A, consists of $            the following components:  >            o  Compaq Code Management System (CMS), Version 4.1  6            o  Compaq Digital Test Manager, Version 4.0  C            o  Compaq Language-Sensitive Editor/Source Code Analyzer $               (LSE/SCA), Version 4.7  @            o  Compaq Module Management System (MMS), Version 3.4  E            o  Compaq Performance and Coverage Analyzer (PCA), Version                4.7A   ------------------------------  $ Date: Sat, 8 May 2004 22:09:21 +0100< From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>V Subject: Re: HP World Magazine: For Business Continuity...the answer may be    OpenVMS* Message-ID: <c7ji9u$2tp7$1@news.wplus.net>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message: news:15c65b4625ab07b71e212a42f5999e60@news.teranews.com... > John Smith wrote: J > > In many cases like that, they'd have a branch BIC running on the SwiftH > > gateway at galactic HQ and then delivering via internal networks. At least L > > that's been my experience, but it may be very different when HQ is in NY and F > > the branch is in Rio as opposed to HQ in Rome and the branch is in Zurich. I > > Banks and brokers often have a lightly different philosophy about how  they > > prefer to do these things. > K > For banks, due to regulations, a foreign branch in a country is generatly  ist I > own corporate entity with its own BIC code which include the country it J > operates in. (as opposed to being just a branch of the main corporation. > L > SWIFT gateways generally handle a single bank/country code and within thatI > code, multiple branches. Handling different bank/country codes requires F > duplication (key management for instance, and I am not sure multiple loginsJ > can be made on the same physical lines (although now that they are TCPIP! > based, berhaps it is possible).   H It being X25 or IP is irrelevant, both can handle multiple sessions to aK remote host. I have certainly had 3 different BIC's logged in over the same J X25 line and later TCP/IP line. These were separate BICS, not branch codes off a main BIC.   . The implementation of the CBT is what matters.  L With FastWire on VMS for example, you can have multiple BIC codes with their< own SCRs (Secure Card Readers), routing codes, KMAs etc etc.  A I'm not however convinced that this it is possible Swift Alliance  (unix/windows).    Alex   ------------------------------  * Date: Sat, 8 May 2004 20:43:37 +0000 (UTC)6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)S Subject: Re: HP World Magazine: For Business Continuity...the answer may be OpenVMS 0 Message-ID: <newscache$zfxexh$lxa$1@news.sil.at>  \ In article <409BC690.2FFCC8A0@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:G >You know, VMS may be really really really great for disaster recovery.    Why only MAY ?  M >But a former employer just spent 18 months and nearly 1000 hours of overtime I >to kicks the disaster tolerant VAXes I had setup for SWIFT transfers and 3 >replaced them with Sun servers with "replication".   5 Why does nobody read such horror stories in the ads ? = Everybody have seen it happen in the own company, but alas... E (I've seen my previous company paying millions to replace VMS instead J of paying only thousands to keep it ! Breakeven point in over 150 years...F And the argument was "strategic", "cost savings", "vendor support" and& "applications" and are still defended)  L >There is no way that the Sun solution would have the same functionality andD >data integrity as the VMS solution had. But guess what: because theO >application on VAX no longer existed, (Palmer had told SWIFT to stop using VMS I >as its key platform), the bank has had to learn to live with an inferior D >disaster recovery scheme. So they ru the risk of having to re-input4 >transactiosn from the current day after a failover.  % And it seems, they live good with it. E At least I haven't heard, anyone reverted to VMS again. Sad isn't it. E It's a little bit surprising that even SUN (you know, the U**X vendor D with the marketing and hence the applications) has problems now (oneH has to ask how long HP-UX and unfortunately Tru64 will live - 4 years ?)  M >But in the end, because that bank already has lots of Sun servers, they have M >expertise in-house (well, it has been outsourced to IBM, but there are still O >lost of people dedicated to that bank with Solaris experience). During the VAX 6 >days, there was nobody else in the bank who knew VMS.  0 And this is so in most other companies. And now.E If VMS is still in use, it is an island, not a strategic platform for F the company (group). And this happens even in the declared key marketsD (health, banking/stock-exchange, what-else) of OpenVMS. The ISVs are2 _still_ phasing out support for VMS. It's a shame.  J >What is more important, and something which the HP/Compaq heads refuse toJ >understand is that the damage caused by Palmer is still, to this day, theL >cause of loss of customers.  It has taken many years for that bank to swithE >from VMS to Solaris. So HP is having to deal today with decisions by M >customers/ISV during Palmer era which are finally reaching back to HP in the ' >form of non-renewed support contracts.   H No they understand it quite well. Palmers did no "damage" in their eyes.M They still want the customers to convert to mainstream (still meaning WINTEL) I applications and hope the customers buy the crap by them (hence the ads). 7 And still wonder why they are on the road to nowhere...   J My prediction: VMS will die with/cause-of ITANIC and earlier than we fear.   --   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: Sat, 08 May 2004 18:45:49 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: <15c65b4625ab07b71e212a42f5999e60@news.teranews.com>   John Smith wrote: H > In many cases like that, they'd have a branch BIC running on the SwiftL > gateway at galactic HQ and then delivering via internal networks. At leastN > that's been my experience, but it may be very different when HQ is in NY andL > the branch is in Rio as opposed to HQ in Rome and the branch is in Zurich.L > Banks and brokers often have a lightly different philosophy about how they > prefer to do these things.  M For banks, due to regulations, a foreign branch in a country is generatly ist G own corporate entity with its own BIC code which include the country it H operates in. (as opposed to being just a branch of the main corporation.  J SWIFT gateways generally handle a single bank/country code and within thatG code, multiple branches. Handling different bank/country codes requires K duplication (key management for instance, and I am not sure multiple logins H can be made on the same physical lines (although now that they are TCPIP based, berhaps it is possible).    ------------------------------  # Date: Sat, 08 May 2004 21:44:11 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: <d2cea5009f16b1a1c60301486a82d044@news.teranews.com>    Peter 'EPLAN' LANGSTOEGER wrote:L > My prediction: VMS will die with/cause-of ITANIC and earlier than we fear.  K I hope that in this probably long process, HP stops developping VMS on IA64 J and continues a few versions on Alpha since that is where the demand wouldP still be. That would send such a strong message to the likes of Curly and Carly.  D One article I read  had one HP rep state that VMS on IA64 might comeI (commercially) in 2005 rather than late 2004.   This opens up interesting   possibilities for speculation...  G Since we trust the VMS engineers, lets rule out VMS engineering delays.   M The delay in the release might be due to lack of applications being ready. It L wouldn't be smart to commercially launch an OS where there are less than 100? applications actually ready. (or whatever the number might be).   L Or, perhaps HP knows that Intel will cancel IA64 before 2005, so by delayingI the launch of VMS on IA64, they could simply abort it before they have to 7 honour any 5 year support commitments on that platform.   M It could also be that launching VMS on an inferior platform compared to Alpha K would remove a lot from the launch and just point to the huge mistake since I even a dead Alpha still outperforms that IA64 thing. Perhaps HP expects a L faster version of IA64 by early 2005 and would want to make sure they launch: with that version so that VMS on IA64 doesn't look so bad.   ------------------------------  * Date: Sat, 8 May 2004 20:57:08 +0000 (UTC)6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)E Subject: Re: looking for suggestions for new $GETDVI item codes . . . 0 Message-ID: <newscache$i2yexh$wza$1@news.sil.at>  _ In article <XxMmmXtUWzYu@cuebid.zko.dec.com>, brooks@cuebid.zko.dec.nospam (Rob Brooks) writes: C >"David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  >> Rob Brooks wrote: >>> ? >>>         dvi$_mpdev_current_path has been there since V7.3-1  >>  H >> ...but is not implemented (or not documented) in F$GETDVI(), which is >> where it is most needed.   H Are you sure it isn't in HELP Lexicals F$GETDVI. I think I saw it there.. And it definitely is there in VMS V7.3-2 HELP.  ? >It's documented in the System Services Reference Manual, which D >is the canonical source of the item codes for the $GETxxI routines. > J >**ANY** item code that is documented for SYS$GETxxx is guaranteed to workG >for both LIB$ and F$.  As it turns out, the VMS operating system build E >procedures are such that an engineer only has to do the work to make I >a new item code exist for SYS$GETxxx and the LIB$ and F$ implementations H >come along automatically.  If an engineer wants to verify the behaviourL >from DCL, he or she simply needs to build a version of DCL.EXE with updatedJ >item code definitions to test the lexical form.  Otherwise, we just buildH >a new version of IO_ROUTINES[_MON].EXE to test the SYS$ implementation. > @ >That's probably more information than anyone really wants . . .   :-)   F >Not every piece of documentation is updated for every dashed release.  7 Yes, But OTOH it's a shame that it is a dashed release. E A dash release is per your company's definition a maintenance version = hence no new features, only a sum up of ECOs, which it isn't.   G V7.3-1 and V7.3-2 had a lot new features and broke (initially) a lot of B (kernel mode or badly written) applications. They should have beenD called V7.4 and V7.5 (or V8.0 and V8.1) which they are. And then the1 dash documentation excuse wouldn't pop up here...   D >I'll make sure that is updated for V8.2, although not for the V8.2 B >field test (the documentation for that is done already, I think).  # Show me any bugfree environment ;-)    --   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: Sat, 8 May 2004 21:47:20 +0000 (UTC)6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: more DFO questions 0 Message-ID: <newscache$7e0fxh$iab$1@news.sil.at>  w In article <c7itq3$eka$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: C >I have DF0 2.6 on all nodes (2 VAX and 1 ALPHA).  Soon, I plan to   >install 2.7.    V2.8 is current.  F >               Things work fine on the VAXen, but on the ALPHA I get: > , >Disk File Optimizer for OpenVMS DFG ECOV2.6C >Copyright  Compaq Computer Corp. 1991,2001.   All rights reserved F >%DFG-F-IEDBDATA, logically inconsistent data in relation SCRIPT_NAMES  A Yup. I had a lot of such problems with the older versions of DFG.   I >According to the message, I should submit an SPR.  In my case, however,  < >the inconsistency was probably caused by me fiddling about.  4 Could be as well. But in my case, it was DFG itself.  B >What's the easiest way to get a "clean start", preferably withoutJ >de-installing DFO?  Can I delete some files in DFG$DATABASE and count on G >them being recreated, properly?  Related to that, presumably it would  G >make sense to move DFG$DATABASE to a non-system disk (such as the one  H >where I have SYSUAF.DAT and so on, with corresponding logicals defined H >in SYLOGICALS.COM).  In that case, are there any files I need to copy, 4 >or can I just count on them being created properly?  % $ RENAME DFG$DATABASE:*.DAT *.CORRUPT  $ MCR DFG$CREATE_DATABASE  $ MCR DFG$INIT_DATABASE  $ DEFRAGMENT VOLUME/SCRIPT=...   or  2 $ DEFINE/SYSTEM/EXEC DFG$DATABASE newdisk:[newdir] $ MCR DFG$CREATE_DATABASE  $ MCR DFG$INIT_DATABASE " $ CREATE DFG$DATABASE:DFG$MAIL.DIS SYSTEM ^Z $ DEFRAGMENT VOLUME/SCRIPT=...   -- O Peter "EPLAN" LANGSTOEGERe% Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  # Date: Sat, 08 May 2004 18:24:58 GMTe% From: "Mike Naime" <mnaime@kc.rr.com>u2 Subject: Re: Normal operating temerpature for ES408 Message-ID: <_B9nc.25495$ee7.4780@twister.rdc-kc.rr.com>  I David J. Dachtera <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in messageD0 news:409BA001.31840BB5@NeOaSrPtAhMlNiOnWk.net... > Thanks for this great info.! >n	 > ...but:e >  > Mike Naime wrote: 
 > > [snip]> > > The ES47/ES80/GS1280 (Marvel line) have an MBM console for environmentals9 > > and configuration as well as the Alphaserver Console./> > > You can query the MBM console for temperature information. >o$ > How does one access that from DCL?  F I'm not sure if you can.  I have not tried to pull that info from DCL.   > > The SHOW POWER8 > > command gives you temperature/fan speed information. >d > -- > David J. Dachterat > dba DJE Systems  > http://www.djesys.com/ >W* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/o   ------------------------------  # Date: Sat, 08 May 2004 21:11:06 GMTt1 From: Michael Austin <maustin@firstdbasource.com>e Subject: Re: T4 and TLVizT2 Message-ID: <409D4D61.A4FE4EDC@firstdbasource.com>   "David J. Dachtera" wrote: <snip>   >i* > T4 and TLViz are fine as far as they go. > F > Remember, however, that T4 takes MONITOR output as its input, and as5 > such, does not provide info. on memory utilization.  >,  K Not exactly!!  The lastest version of CSVPNG does do the calc.  You have to:G do a minor conversion, buy hey, you still get a neat graph --   but, to-G answer the question, there is enough information in the Monitor file tom7 calculate Memory Utilization.  This is  pretty slick...3  2 go to http://www.firstdbasource.com/t4/t4chart.php  < select any file ending in    2350.zip  !files are per day...   Check the radio button for NONE-1 Enter this in the SearchString text box as typed.u   Free List,Modfied List   Submit.a  G First, in the text summary at the top of the result page you should seep something like:m   Physical Memory = 32768 pagesw  L The 3rd graph should be Memory Utilization (scale is in 8K pages for Alpha.)  L Although, a lot of systems used for database servers, don't necessarily care; that their Memory Utilization is a flat line at 90-95%.  :)s   Michael Austin  L By the way, if anyone is interested in having a T4 Specialist configure yourI systems and a repository so you can find the data, I am available and canhJ even do this remotely.  Contact  maustin@firstdbasource.com_deletethis for rates.   <snip>   ------------------------------  % Date: Sat, 08 May 2004 19:44:24 -0500s@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: T4 and TLVizo6 Message-ID: <409D7EE8.2AC11CC2@NeOaSrPtAhMlNiOnWk.net>   Michael Austin wrote:U >  > "David J. Dachtera" wrote: > <snip> >  > >i, > > T4 and TLViz are fine as far as they go. > >wH > > Remember, however, that T4 takes MONITOR output as its input, and as7 > > such, does not provide info. on memory utilization.t > >7 > M > Not exactly!!  The lastest version of CSVPNG does do the calc.  You have to I > do a minor conversion, buy hey, you still get a neat graph --   but, to>I > answer the question, there is enough information in the Monitor file tow9 > calculate Memory Utilization.  This is  pretty slick...h > 4 > go to http://www.firstdbasource.com/t4/t4chart.php > > > select any file ending in    2350.zip  !files are per day... > ! > Check the radio button for NONE 3 > Enter this in the SearchString text box as typed.  >  > Free List,Modfied List > 	 > Submit.l > I > First, in the text summary at the top of the result page you should seet > something like:e >  > Physical Memory = 32768 pagesi > N > The 3rd graph should be Memory Utilization (scale is in 8K pages for Alpha.) > N > Although, a lot of systems used for database servers, don't necessarily care= > that their Memory Utilization is a flat line at 90-95%.  :)i >  > Michael Austin > N > By the way, if anyone is interested in having a T4 Specialist configure yourK > systems and a repository so you can find the data, I am available and can L > even do this remotely.  Contact  maustin@firstdbasource.com_deletethis for > rates.   Michael,  B Tell you what there *IS* a market for: a product that will take T4G output (or output directly from MONITOR) and produce performance metric  histograms like SPM or DCPA.  F It's a fair bet I could sell it to work if you can produce a prototypeF and output. We're all beating Cerner bloody over this very issue right now ("Cerner" = hint).   -- L David J. Dachteraw dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------   Date: 8 May 2004 11:51:27 -0700s( From: bob@instantwhip.com (Bob Ceculski)! Subject: Re: VMS news on news.comI= Message-ID: <d7791aa1.0405081051.4bf394b4@posting.google.com>l  W "John Smith" <a@nonymous.com> wrote in message news:<sv6dnTYdlfnTbQHdRVn-vg@igs.net>... 9 > "Dave Gudewicz" <k9jdk@NOSPAMarrl.net> wrote in messagey) > news:vVYmc.1431$BJ6.129064@attbi_s51....! > > Thought this was interesting:. > >s= > > http://news.com.com/2100-1016_3-5208195.html?tag=nefd.hed  >  > K > Not a bad article but it would have been better if the write *could* haveaK > also noted that HP was or and launched an advertising campaign to promote A > VMS as a far more secure alternative to unix/linux and windows.,  > not a bad article?  I emailed him about refering to everythingA as OLD ... decnet is that old protocol, vax is that old computer. ? Well, many sites are still using that OLD hardware and softwareM6 and without viruses and downtime and more reliability.   ------------------------------  # Date: Sat, 08 May 2004 19:44:50 GMTe- From: JF Mezei <jfmezei.spamnot@teksavvy.com>n! Subject: Re: VMS news on news.comA@ Message-ID: <71b0da28902b0e75ab96119610fba335@news.teranews.com>   Bob Ceculski wrote:c@ > not a bad article?  I emailed him about refering to everythingC > as OLD ... decnet is that old protocol, vax is that old computer.t  L I agree with you. It was terrible to mention DECNET as an "old" protocol. ItN is about the same age as TCPIP, and has far better security and robustness. Itv also has many features which TCPIP lacks (such as $edit PASTRY"chef pierre"::$OVEN:[RACK1.FRONT]chocolate_souffle.food  G The writer could have simply mentioned that the customer's VMS machines L support multiple protocols, including TCPIP and DECNET which is used between% VMS hosts with greater functionality.    ------------------------------  # Date: Sat, 08 May 2004 18:35:09 GMTs- From: JF Mezei <jfmezei.spamnot@teksavvy.com>.2 Subject: Re: You'll never guess what HP advertised@ Message-ID: <a6d489d4e159c36063bc076111ab25b9@news.teranews.com>   "Dr. Dweeb" wrote:L > Carley is a self proclaimed "visionary".  She has seen the future, and she! > alone will lead us towards it. a    L But in reality, she has reached her point of "peter's principle" and in factM is way above her head, and to survive, she needs to do "dramatic" things suchaM as a merger with Compaq, and using all possible buzzword-du-jour in grandioseoI "strategies" to make it look like she is moving the company forwards eveny. though they are totally devoid of any meaning.  L Meanwhile, it seems that HP is not being managed and turf wars are raging onG with some of the big managers eating other's turf. (a good example: AnnlM Livermore taking over both services and enterprise systems, putting BlackmoremO in an interesting position because he now reports to both Livermore and Carly).d  H Not sure if it was here or on CNET or the Inquirer, but there was a goodI article recently that stated that HP was essentially back to where it wasaN before the merger in terms of management/philosophy. The same company that was% about to fire Carly for incompetence.s   ------------------------------  # Date: Sun, 09 May 2004 01:17:00 GMTtL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")2 Subject: Re: You'll never guess what HP advertised6 Message-ID: <00A318B1.1EC7A261@SSRL.SLAC.STANFORD.EDU>  y In article <409CFF40.DB548F2B@NeOaSrPtAhMlNiOnWk.net>, "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes: + >Alan Winston - SSRL Admin Cmptg Mgr wrote:o	 >> [snip]xJ >> So the question which we're discussing, I think, is how to get HP to do >> anything. >SG >Actually, I think *THAT* is the part we're consistently getting wrong.S >sA >*WE* (interpret taht as you will) are not going to "get hp to doI >anything".  >cG >It's entirely up to us. Hp has demonstrated unmistakably that, forgivec* >the vernacular, they ain't gonna do shit.  + Then, forgive the vernacular, we're fucked.        >rH >In the motivational world, we have the saying: "If it is to be, it's upD >to me". By extension, then, it's up to us: individually to agree toH >co-operate in one all-or-nothing effort to save our businesses, careersG >etc., or to admit defeat and let hp slowly choke VMS to death (not fari? >from it now), and collectively to band togther to take action.  >tE >Grand-scale advertising can be costly, yes (as was posted at another I >point in this thread or another - I forget). However, if we (those of useC >who have the option) each take an ad to the local cable vendor formH >airing locally, that creates a potential nation(world?)-wide reach at aF >modicum of cost and effort. That will open many "enabling" doors thatG >will make it at least possible to schmooze, convince, finagle, cajole,eH >finesse, etc. others down the road to carry promo.'s (print, electonic,I >etc.) that will cause business types to look up their local VMS resellertI >and talk about doing some business. (Don't go there just yet - I'm stilll >working that out in head.)s  M Excuse me all to hell, but it seems like the best thing we're going to get byHL third-party advertising of an OS that HP isn't wholeheartedly behind is thatO people who do due diligence before going into an OS that they've never heard of E except through an ad on cable access will just find out that HP isn't L wholeheartedly behind it and may not even let them order it.  You think thatO people trying to order it will turn them around; I think we have ample evidence K of people trying to buy VMS and getting talked into Windows solutions, etc.d5 (Not so much from HP but from previous VMS vendors.) P   >:A >True, even hp is working against us at this point. I believe the>D >increase in $$$ can sway them toward, if not co-operation, at leastD >neutrality: they won't care if we're out here trying sell what they/ >wanna kill as long as the $$$ keep rolling in.t >sD >...but yes, it's *ENTIRELY* up to *US*. Hp has made it unmistakablyD >clear that they ain't gonna do shit (again, pardon the vernacular).  G Unless we can get them to point where they're willing to sell it to newFJ customers rather than take VMS queries as sales leads for HP/UX, Linux, orO Windows, and demonstrate some commitment to VMS's continued existence, what canhO third parties do that would make it make sense for new customers to buy in?  HPnG has to price it affordably, HP has to make it orderable, or advertisingi campaigns are for naught.c  N I wasn't proposing that we continue to watch the erosion and do nothing, I wasM proposing a PR campaign to surface the issue in the media that decisionmakers L read, and thus attempt to encourage/shame HP upper management into promoting' what could be their flagship product.  u   -- AlanD     --  O ===============================================================================n0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056eM  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025tO ===============================================================================o   ------------------------------  # Date: Sun, 09 May 2004 03:42:13 GMT0- From: JF Mezei <jfmezei.spamnot@teksavvy.com>"2 Subject: Re: You'll never guess what HP advertised@ Message-ID: <d60bdc1abaeb4232f949a66b91c35daa@news.teranews.com>  * Alan Winston - SSRL Admin Cmptg Mgr wrote:N > third-party advertising of an OS that HP isn't wholeheartedly behind is thatQ > people who do due diligence before going into an OS that they've never heard offG > except through an ad on cable access will just find out that HP isn't-> > wholeheartedly behind it and may not even let them order it.  E Correct. However, 3rd party advertising of VMS will achieve 2 things:a  3 1-prolong VMS' life by reducing the attrition rate.87 2-force HP to make a clear statement on VMS either way.t  Q > third parties do that would make it make sense for new customers to buy in?  HPrI > has to price it affordably, HP has to make it orderable, or advertising  > campaigns are for naught.k  I The challenge is to convince HP to give VMS a REAL chance. Compaq saw thetG potential during the short live "renaissance", but it refused to let itcH continue because it conflicted with its Microsoft and Intel commitments.  N However, HP has lately begun to gain some idependance from Intel and MicrosoftJ by adopting some AMD chips and selling Linux desktops. Perhaps there is anG opening here for HP to push another non-Wintel solution by pushing VMS,rH especially because it is not the target of so many viruses and still has leading clustering.g    N > read, and thus attempt to encourage/shame HP upper management into promoting' > what could be their flagship product.o  J At this point in time, the quickest way would be to reach shareholders andK shame HP management and force HP management to take VMS seriously and fullyi# leverage its potential for profits.    ------------------------------   End of INFO-VAX 2004.256 ************************ printf("? mkdir() failed:\n\t%s\n", strerror(errno)); }  CRTL_$ cc mkdir_test CRTL_$ link mkdir_test CRTL_$ run mkdir_test  ? mkdir() failed: '         file specification syntax error ' CRTL_$ define deccvosibirsk, Russia (2:5000/14)
X-FTN-SEEN-BY: 50/421 429 400/333 462 465 520 450/102 166 191 208 452/25 460/15
X-FTN-SEEN-BY: 461/33 74 132 435 640 462/30 463/68 220 327 469 464/36 465/204 253
X-FTN-SEEN-BY: 466/20 467/24 70 468/96 469/125 478/55 550/5068 2432/200 2437/335
X-FTN-SEEN-BY: 4614/9 4615/21 4625/9 4626/6 4633/1 4635/99 1024 4641/444 4651/25
X-FTN-SEEN-BY: 4657/50 5000/14 104 207 5000 5001/27 50 77 5002/5002 5004/16
X-FTN-SEEN-BY: 5005/14 5006/1 5008/9 5009/14 5010/53 77 303 5011/13 5014/5014
X-FTN-SEEN-BY: 5015/4 28 5019/22 28 5020/37 52 69 115 116 128 133 175 201 238 252
X-FTN-SEEN-BY: 5020/313 362 400 600 642 758 768 888 894 902 921 937 958 968 1100
X-FTN-SEEN-BY: 5020/1169 1234 1523 1535 1543 1626 1634 1642 1822 1877 1910 1951
X-FTN-SEEN-BY: 5020/2020 2200 2450 2871 3637 4045 4400 4441 5452 12000 5021/29 44
X-FTN-SEEN-BY: 5022/5 5023/11 5024/1 5025/3 39 51 5026/49 78 5027/16 28 31 5028/63
X-FTN-SEEN-BY: 5029/1 34 50 5030/69 115 175 195 382 436 473 573 638 781 920 953
X-FTN-SEEN-BY: 5030/966 1016 1023 1329 1400 1900 5031/26 50 63 5032/16 5033/1
X-FTN-SEEN-BY: 5036/1 5037/21 5038/4 5040/33 5041/4 5042/8 13 5045/7 57 5047/23
X-FTN-SEEN-BY: 5049/50 96 139 5050/9 41 5029 5051/35 5052/4 5053/16 18 777 5054/1
X-FTN-SEEN-BY: 5054/50 5055/8 95 181 5056/16 5058/24 106 5059/10 5060/90 5061/6 15
X-FTN-SEEN-BY: 5063/3 60 5064/7 35 5065/30 5066/9 18 5069/128 5070/26 66 254
X-FTN-SEEN-BY: 5071/1 5072/8 5074/9 5075/10 30 5077/36 5079/23 49 5080/80 111 301
X-FTN-SEEN-BY: 5080/1003 5081/3 5082/6 5083/13 5085/13 51 75 5090/68 91 109 117
X-FTN-SEEN-BY: 5090/1029 5093/4 23 27 5095/1 78 5096/9 19 5097/10 64 92 303
X-FTN-SEEN-BY: 5098/11 5099/11 5100/113 6009/3 6023/1 6045/7 6083/1 11 12
X-FTN-PATH: 5000/14 5000 5020/52 4441
X-FTN-PATH: 5020/400
Lines: 14
Path: mvb.saic.com!news-out.cwix.com!newsfeed.cwix.com!newsfeed.rt.ru!rt.ru!news.rosnet.ru!rosnet!newsfeed.sovam.com!newsfeed.gamma.ru!Gamma.RU!ddt.demos.su!f400.n5020!f4441.n5020!f52.n5020!f5000.n5000!f14.n5000!not-for-mail
Xref: mvb.saic.com f