1 INFO-VAX	Fri, 09 May 2003	Volume 2003 : Issue 255       Contents:, Re: Are Bridgeworks and Multinet compatible?, Re: Are Bridgeworks and Multinet compatible?, Re: Are Bridgeworks and Multinet compatible? Re: as2100 inside pictures Re: as2100 inside pictures Re: as2100 inside picturesN Re: Bug? Pipe search /window (was: Re: How to determine boot device from DCL?)N Re: Bug? Pipe search /window (was: Re: How to determine boot device from DCL?). Re: Computerworld: HP continues to support VMS. Re: Computerworld: HP continues to support VMS. Re: Computerworld: HP continues to support VMS' Re: creating licenses for my own demos?  Re: DECNET node deletion Re: DECNET node deletionA Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary? A Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary? * Re: determining when a file is closed/open* Re: determining when a file is closed/open* Re: determining when a file is closed/open* Re: determining when a file is closed/open* Re: determining when a file is closed/open$ DS10 Motherboards in AlphaStation500( Re: DS10 Motherboards in AlphaStation500' For Sale on Ebay OpenVMS V7.3-1 and SPL + Re: For Sale on Ebay OpenVMS V7.3-1 and SPL + Re: For Sale on Ebay OpenVMS V7.3-1 and SPL + Re: For Sale on Ebay OpenVMS V7.3-1 and SPL ! Re: Go to an AS/400 from VAX/VMS? ! Re: Go to an AS/400 from VAX/VMS? ! Re: Go to an AS/400 from VAX/VMS? ! Re: Go to an AS/400 from VAX/VMS? < Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd= Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! 2 How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?6 Re: How do I automate a response after a program fail?* Re: How to determine boot device from DCL?* Re: How to determine boot device from DCL?H Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyG Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBMmonopoly " Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance" Re: INDEX.SYS size and performance Re: Java "Unknown host" problem ; Re: MicroVAX and VAX models EOSL list (end of service life) ; Re: MicroVAX and VAX models EOSL list (end of service life) ; Re: MicroVAX and VAX models EOSL list (end of service life) ; Re: MicroVAX and VAX models EOSL list (end of service life) ; Re: MicroVAX and VAX models EOSL list (end of service life)  Re: Migrate email to VMS server & Re: Not entirely OT: RSHELL to Solaris8 Problem to localy logon on a Pathworks 6.1 domain member< Re: Problem to localy logon on a Pathworks 6.1 domain member< Re: Problem to localy logon on a Pathworks 6.1 domain member$ Re: Problem with Openvms 7.2 hobbyst8 Re: Problems changing from serial port to DecServer port7 Redimensioning formal parameter arrays in OpenVMS BASIC ' Re: Second SCSI adapter fro PSW/AU - UK  Re: Spamfilter for OpenVMS?  Re: Spamfilter for OpenVMS?  Re: Spamfilter for OpenVMS?  Re: Spamfilter for OpenVMS? - Re: Synch-on-Green LCD monitor for Vaxstation - Re: Synch-on-Green LCD monitor for Vaxstation - Re: Synch-on-Green LCD monitor for Vaxstation - Re: Synch-on-Green LCD monitor for Vaxstation  Re: TCPIP libraries? Re: TCPIP libraries?7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 RE: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification?  Re: Where is VMSBACKUP?  Re: Where is VMSBACKUP?  Re: Where is VMSBACKUP?  Re: Where is VMSBACKUP?  Re: Where is VMSBACKUP?  Re: Where is VMSBACKUP?  RE: Where is VMSBACKUP?  Re: Where is VMSBACKUP? 8 [Fwd: OpenVMS Pearl - VAXscan is now available on Alpha]< Re: [Fwd: OpenVMS Pearl - VAXscan is now available on Alpha] [OT] 8-may-1945  Re: [OT] 8-may-1945   F ----------------------------------------------------------------------  % Date: Thu, 08 May 2003 14:28:38 -0400 + From: Michael Corbett <corbett@PROCESS.COM> 5 Subject: Re: Are Bridgeworks and Multinet compatible? * Message-ID: <3EBAA1D6.8070708@PROCESS.COM>   Javier Henderson wrote:     M >>>Would anyone know if Bridgeworks can run on an OpenVMS instance that uses  K >>>Multinet rather than UCX?  The Bridgeworks docs list UCX as an optional  N >>>requirement, but seem to say nothing about alternative tcpip stacks.  (And E >>>the salesperson hasn't returned my call from yesterday afternoon.)  >>>  >>> D >>  Try asking Process.  DOn't be suprised if they are very helpful. >> > @ > If UCX is listed as compatible, then MultiNet will most likelyH > work. If issues come up our (TGV) policy was to work with the customerB > and the vendor to get MultiNet to play nice with the third party
 > product. > H > It's my understanding that Process Software follows the same practice, > so try contacting them.  >   C 	We do follow the same practice.  Our goal is to have Multinet, and H TCPware be 100% compatible with TCP/IP services, aka UCX.  You should beH able to take an image that runs on UCX and run it unchanged on MultiNet.D If there are problems we want to know about them so we can fix them.  < 	I don't know of any problems with Bridgeworks and Multinet.   regards  Mike   --  K +-------------------------------------------------------------------------+ D Michael Corbett                           Email: Corbett@process.comB Process Software                          Phone: 800 722-7770 x369B 959 Concord St.                                  508 879-6994 x369= Framingham MA 01701-4682                  FAX:   508 879-0042    ------------------------------  % Date: Thu, 08 May 2003 14:14:35 -0000 - From: wspencer@ap.nospam.org (Warren Spencer) 5 Subject: Re: Are Bridgeworks and Multinet compatible? 5 Message-ID: <93756447Cwarrenspencer1977@216.168.3.30>   + javier@KJSL.COM (Javier Henderson) wrote in # <86vfwmolj1.fsf@skylane.kjsl.com>:    > >koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > 8 >> In article <9373757A6warrenspencer1977@216.168.3.30>,3 >> wspencer@ap.nospam.org (Warren Spencer) writes:   >> > Hi folks, >> >  I >> > Would anyone know if Bridgeworks can run on an OpenVMS instance that H >> > uses Multinet rather than UCX?  The Bridgeworks docs list UCX as anD >> > optional requirement, but seem to say nothing about alternativeE >> > tcpip stacks.  (And the salesperson hasn't returned my call from  >> > yesterday afternoon.)   >> >   >>  E >>   Try asking Process.  DOn't be suprised if they are very helpful.  > ? >If UCX is listed as compatible, then MultiNet will most likely G >work. If issues come up our (TGV) policy was to work with the customer A >and the vendor to get MultiNet to play nice with the third party 	 >product.  > G >It's my understanding that Process Software follows the same practice,  >so try contacting them. >  >-jav (former TGV geek)   J Thanks Bob and Jav for your responses.  HP still hasn't returned my call, L so if anyone else out there has a Bridgeworks/Multinet combination running, B I'd be very interested to hear of success and any issues.  Thanks!   ws   --     Warren Spencer' Senior Software Engineer (not a writer)  The Associated Press  + ** What's brown and sticky?    A stick.  **    ------------------------------  % Date: Thu, 08 May 2003 19:12:18 -0000 - From: wspencer@ap.nospam.org (Warren Spencer) 5 Subject: Re: Are Bridgeworks and Multinet compatible? 5 Message-ID: <93759AF87warrenspencer1977@216.168.3.30>   . corbett@PROCESS.COM (Michael Corbett) wrote in  <3EBAA1D6.8070708@PROCESS.COM>:    >Javier Henderson wrote: >  > H >>>>Would anyone know if Bridgeworks can run on an OpenVMS instance thatG >>>>uses Multinet rather than UCX?  The Bridgeworks docs list UCX as an I >>>>optional requirement, but seem to say nothing about alternative tcpip H >>>>stacks.  (And the salesperson hasn't returned my call from yesterday >>>>afternoon.)  >>>> >>>>E >>>  Try asking Process.  DOn't be suprised if they are very helpful.  >>>  >>  A >> If UCX is listed as compatible, then MultiNet will most likely I >> work. If issues come up our (TGV) policy was to work with the customer C >> and the vendor to get MultiNet to play nice with the third party  >> product.  >>  I >> It's my understanding that Process Software follows the same practice,  >> so try contacting them. >>   > H >     We do follow the same practice.  Our goal is to have Multinet, andI >TCPware be 100% compatible with TCP/IP services, aka UCX.  You should be I >able to take an image that runs on UCX and run it unchanged on MultiNet. E >If there are problems we want to know about them so we can fix them.  > A >     I don't know of any problems with Bridgeworks and Multinet.  >  >regards >Mike  >   K Thanks Mike - and your colleague Glen in Tech support said essentially the  & same thing to me in a private email.    K What I'm really hoping for at this point is for someone to step in and say  J "We're running Bridgeworks on Multinet and it works fine", before I start 9 the exploratory surgery effort on our target application.   I If you happen to have a reference site, it would be very helpful to hear  : from that reference, confidentiality respected, of course.   Many thanks!   ws   --     Warren Spencer' Senior Software Engineer (not a writer)  The Associated Press  + ** What's brown and sticky?    A stick.  **    ------------------------------  % Date: Thu, 08 May 2003 09:06:49 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1># Subject: Re: as2100 inside pictures ) Message-ID: <3EBA1019.945217FF@127.0.0.1>    Antti Jrvinen wrote:  >   F > Another question is that what is the size of memory bank measured inH > SIMM slots? I've got one memory module where 3/4 of the SIMM slots areE > empty -> how many do I need to fill to add one more bank and do the M > SIMMs need to be similar on whole memory module or only within memory bank?   H You'll find that bank is the discrete parity/ECC bank, one SIMM to matchG a bank of 4 equally sized SIMMs. Most servers generally, somewhere have   a diagram of how it is laid out.   e.g.  2 BANK 0 (4 SIMMs) --> PARITY SLOT 0 (total 5 SIMMs)2 BANK 1 (4 SIMMs) --> PARITY SLOT 1 (total 5 SIMMs)   etc.  G It should NOT be illegal to have different sizes between the banks, but C you cannot mix and match inside the banks. The exception to this if H you're trying to Galaxy inside a multi CPU system, it's memory sensitiveD and the LP_*'s at console (variables) need to work on equal physical boundaries.    --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------  $ Date: Thu, 8 May 2003 12:42:29 +0200/ From: Roland Barmettler <spamsink@crapmail.com> # Subject: Re: as2100 inside pictures ; Message-ID: <20030508124229.76332570.spamsink@crapmail.com>    Hi Antti  / I've got some pictures of my AS2100 on the Web: # http://naboo.freestone.net/sysinfo/   F If you'd like me to take some more, I wouldn't mind as long as I don't" have to deassemble the machine ;-)   Cheers, Roland   --" %SYSTEM-W-MNDYMRNG, monday morning   ------------------------------    Date: 08 May 2003 22:54:03 +03009 From: costello@iki.fi (Antti =?iso-8859-1?q?J=E4rvinen?=) # Subject: Re: as2100 inside pictures / Message-ID: <m31xz9qko4.fsf@muikku.katiska.org>   * Nic Clews <sendspamhere@127.0.0.1> writes:J > You'll find that bank is the discrete parity/ECC bank, one SIMM to matchI > a bank of 4 equally sized SIMMs. Most servers generally, somewhere have " > a diagram of how it is laid out.  G yes, for me this somewhere is hp website as the machine came with zero  4 documentation. and hp website is not that detailed.   4 > BANK 0 (4 SIMMs) --> PARITY SLOT 0 (total 5 SIMMs)4 > BANK 1 (4 SIMMs) --> PARITY SLOT 1 (total 5 SIMMs)  
 makes sense.     --   Antti Jrvinen, costello@iki.fi 5             "concerto for two faggots and orchestra"     ------------------------------   Date: 8 MAY 2003 19:03:29 GMT + From: Dave Greenwood <greenwoodde@ornl.gov> W Subject: Re: Bug? Pipe search /window (was: Re: How to determine boot device from DCL?) 1 Message-ID: <8MAY03.19032924@feda34.fed.ornl.gov>   6 In a previous article, briggs@encompasserve.org wrote:` > In article <OFD5686937.4766B95F-ON85256D20.0052BC4D@metso.com>, norm.raphael@metso.com writes: > >  > > Is this a bug? > > 9 > > I tried this with pipe and get the following, whereby 1 > > it is seen that pipe with search/window gives - > > "-RMS-F-RAC, invalid record access mode":  >   8 > I've always assumed that when you're using SEARCH withD > a unit record device (such as a PIPE mailbox) you lose the ability? > to backspace or use RFA access and so you lose the ability to @ > display lines above or below the current line -- e.g. /WINDOW.  G Actually, you only lose the abaility to display lines above the current H line.  Eg,  PIPE ... | SEARCH SYS$PIPE xxx /WINDOW=(0,5)  is okay.  This: issue has been discussed a few times in this forum before.   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOV H Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------   Date: 8 May 2003 13:49:26 -0500  From: briggs@encompasserve.orgW Subject: Re: Bug? Pipe search /window (was: Re: How to determine boot device from DCL?) 3 Message-ID: <bH3aYgWjmjPU@eisner.encompasserve.org>   ^ In article <OFD5686937.4766B95F-ON85256D20.0052BC4D@metso.com>, norm.raphael@metso.com writes: >  > Is this a bug? > 7 > I tried this with pipe and get the following, whereby / > it is seen that pipe with search/window gives + > "-RMS-F-RAC, invalid record access mode":   6 I've always assumed that when you're using SEARCH withB a unit record device (such as a PIPE mailbox) you lose the ability= to backspace or use RFA access and so you lose the ability to > display lines above or below the current line -- e.g. /WINDOW.   	John Briggs   ------------------------------  % Date: Thu, 08 May 2003 00:13:39 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>7 Subject: Re: Computerworld: HP continues to support VMS ) Message-ID: <3EB9D94C.38ECEEE4@istop.com>    Dave Gudewicz wrote:K > If I get a spare 2 hours, which I doubt, I'll try to listen to the entrie 
 > webcast.    M Only if you have wireless ethernet and a windows media player on a pocket PDA I and wear earphones while mowing the lawn (or shoveling snow, depending on 3 where you live). The 2 hours are devoid of content.    ------------------------------  % Date: Thu, 08 May 2003 09:49:35 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1>7 Subject: Re: Computerworld: HP continues to support VMS ) Message-ID: <3EBA1A1F.49A8BB5A@127.0.0.1>    Dean Woodward wrote: > H > > Can one still get support of Alpha-Based NT systems from HP/Compaq ? > J > As I understand it, MS stopped supporting NT 4.0 around the first of the% > year, give or take a couple months.   B I thought it was 5 years, then "its dead". You won't be seeing new? security patches for the older systems, so as even more ways to D compromise these vulnerable systems are discovered, it will be these" systems perpetuating the problems.  D For Digital/Compaq/HP, their operating systems had nowhere near thatE level of bugginess, so it is easier to maintain some form of support.  --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------  # Date: Thu, 08 May 2003 10:59:36 GMT # From: "John Smith" <a@nonymous.com> 7 Subject: Re: Computerworld: HP continues to support VMS I Message-ID: <sMqua.113274$M81.12472@news02.bloor.is.net.cable.rogers.com>   > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0305071356.6d5545e6@posting.google.com... ? > Some positive coverage of VMS in an article in Computerworld:  > B > 'HP is continuing to support the OpenVMS operating system, whichD > Compaq acquired through its purchase of Digital Equipment Corp. inB > 1998.  Some users had been concerned about HP's support plan for? > OpenVMS running on VAX and Alpha processor systems, since the  company D > is moving all of its high-end servers, including NonStop, to IntelC > Corp.'s 64-bit Itanium chips.  But HP appears to have ameliorated  > those concerns.  > E > Arthur McClinton, a principal scientist at Mitretek Systems Inc., a D > Falls Church, Va., company that runs U.S. weather satellites, said HPE > recommitted to Compaq's support road map for VAX and Alpha and will A > continue to maintain the system until 2012.  That's "what I was  > after," he said.'  >  > F http://www.computerworld.com/managementtopics/management/helpdesk/stor$ y/0,10801,80716,00.html?nas=PM-80716    F It's pretty clear to anyone outside HP that there is a vast differenceA between support and marketing to new customers. Dare I be so bold E and/or wrong in saying that the people who want support are those who E have large applications and are close enough to retirement (<8 years) + that 'support' until 2011 is 'good enough'.   B Those who want the VMS market to be expanded are those who want toD commit to VMS but for whom the 'support' commitment until 2011 isn't enough.    ------------------------------  % Date: Thu, 08 May 2003 02:00:57 -0400 ! From: Beyonder <beyonder@vrx.net> 0 Subject: Re: creating licenses for my own demos?8 Message-ID: <tasjbvcn07on0u2p8io7n7v05nkafggpfb@4ax.com>  A On Wed, 07 May 2003 00:23:15 -0500 (CDT), sms@antinode.org wrote: ; >   I don't know, but perhaps he tried something like this:  >  >ALP $ license generate = >%DCL-W-ACTIMAGE, error activating image PAK$DIR:PAK$USER.EXE 9 >-CLI-E-IMGNAME, image file PAK$DIR:[SYSEXE]PAK$USER.EXE; L >-RMS-F-DEV, error in device name or inappropriate device type for operation > 1 >ALP $ dire sys$sysdevice:[000000...]PAK$USER.EXE " >%DIRECT-W-NOFILES, no files found > , >ALP $ write sys$output f$getsyi( "HW_NAME") >AlphaStation 200 4/233  > , >ALP $ write sys$output f$getsyi( "VERSION") >V7.2-1    yep thats about the size of it:    $ license generate< %DCL-W-ACTIMAGE, error activating image PAK$DIR:PAK$USER.EXE8 -CLI-E-IMGNAME, image file PAK$DIR:[SYSEXE]PAK$USER.EXE;A -RMS-F-DEV, error in device name or inappropriate device type for 	 operation    nice!    and it gets better-  $DISK1:[SYS0.SYSCOMMON.SYSEXE]  > doesn't even exist for me! (by this I mean I don't have a SYS0  directory anywhere on my drives)   B.   ------------------------------  $ Date: Thu, 8 May 2003 19:45:59 +0100G From: "systematipltoddemontodcotoduk" <system@ipldot.demondot.codot.uk> ! Subject: Re: DECNET node deletion 4 Message-ID: <b9e8md$js9$2$8302bc10@news.demon.co.uk>   Bob,  L Once you've done the deletion and registration in decnet_register.exe, don't( forget to do the purging of the database  5 $ mc ncl flush session control naming cache entry "*"    off the top of my head....I If you don't flush the cache you'll still appear to have the registration & live and even a reboot won't clear it!   Steve    -- Steve Reece.3 System Consultancy, Training and Project Management     4 "Bob Dalby" <bob.dalby@spicers.net> wrote in message7 news:b865d7eb.0305080334.7a5529ee@posting.google.com... F > I am having trouble ammending a node - I appear to have 2 nodes thatF > are showing the same ethernet address and i can't seem to get out of > the situation: > E > I thought i could simply go into DECNET_register.exe and deregister G > the nodes and then reregister  however although this exe allows me to H > put in new nodes it does not remove or ammend the ncl database details< > when i derigeter (Even though it states that deregister isH > successful). Is this a bug? Is there an NCL del node command that i am > not aware of >  > Details are: > 
 > NCL>sho imp   >           Name = OpenVMS VAX ,  >           Version = "V7.2    "3 >           Name = Compaq DECnet-Plus for OpenVMS , < >           Version = "V7.2-1 ECO02 16-JUN-2000 16:00:14.45" >  > NCL>sho node x25per  > 
 > Node x25per & > at 2003-05-08-13:26:59.110+01:00Iinf > 
 > Identifiers  > 3 >     Name                              = 0:.X25PER ) >     Address                           = 
 >        {
 >           (  >           [ DNA_CMIP-MICE ] , 4 >           [ DNA_SessionControlV3 , number = 19 ] , >           [ DNA_NSP ] , = >           [ DNA_OSInetwork , 49::00-01:AA-00-04-00-FA-04:20  > (LOCAL:.X25SAW) ]  >  >  > NCL>show node x25saw > 
 > Node x25saw & > at 2003-05-08-13:27:26.010+01:00Iinf > 
 > Identifiers  > 3 >     Name                              = 0:.X25PER ) >     Address                           = 
 >        {
 >           (  >           [ DNA_CMIP-MICE ] , 4 >           [ DNA_SessionControlV3 , number = 19 ] , >           [ DNA_NSP ] , = >           [ DNA_OSInetwork , 49::00-01:AA-00-04-00-FA-04:20  > (LOCAL:.X25SAW) ]  > F > If i set ncl def ent to each node i end up on the same node (x25per) > everytime.   ------------------------------   Date: 8 May 2003 13:38:48 -0700 ( From: bob@instantwhip.com (Bob Ceculski)! Subject: Re: DECNET node deletion = Message-ID: <d7791aa1.0305081238.71697ce1@posting.google.com>   l bob.dalby@spicers.net (Bob Dalby) wrote in message news:<b865d7eb.0305080334.7a5529ee@posting.google.com>...F > I am having trouble ammending a node - I appear to have 2 nodes thatF > are showing the same ethernet address and i can't seem to get out of > the situation: > E > I thought i could simply go into DECNET_register.exe and deregister G > the nodes and then reregister  however although this exe allows me to H > put in new nodes it does not remove or ammend the ncl database details< > when i derigeter (Even though it states that deregister isH > successful). Is this a bug? Is there an NCL del node command that i am > not aware of >    on phase IV it would be    NCP> CLEAR NODE X.XX ALL NCP> PURGE NODE X.XX ALL   ------------------------------  % Date: Thu, 08 May 2003 14:02:38 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>J Subject: Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary?) Message-ID: <3EBA9BBC.16900539@istop.com>    Jenny Butler wrote: I >      The learning curve is a little steep, but once you get used to the 	 > Phase V N >  NCL, it's not too bad.  However, if you don't need to do it, it's not worth >  the trip.  M From a business point of view, how much time (money) will you and others have L to spend learning NCL and all its quirks, how much time will you be fiddlingJ to avoid all the unnecessary OPCOM messages and generally tune 5 to behave like what you really need ?   N And what will 5 give you that 4 doesn't give you in terms of what you actually need ?  K If 5 doesn't give you anything of value in your environment, can you really C justify spending time/money learning/installing/fiddling with  it ?    ------------------------------  % Date: Thu, 08 May 2003 14:12:28 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>J Subject: Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary?) Message-ID: <3EBA9E09.16BBA56A@istop.com>    Bob Koehler wrote:J > A properly configured Phase V system will talk to a Phase IV system withJ > no extra work.  I think you have to do extra work, and really understandF > Phase V, to set up a system that wouldn't talk to a Phase IV system.  L Agreed that to get a new node on 5 configured to talk to an existing phase 4J node, it is not difficult. But the defaults aren't enough because DECNET-5I comes with a whole lot of kibbles and bits that are extra and to properly L manage the system, you really need to spend time figuring out what all those7 defaults are in order to tune this to your preferences.   K Perhaps the best suggestion would be to get a consultant in for a couple of M hours to give you a general idea of the decnet 5 philosophy so you know which I files you need to modify when you need to change something to ensure that K similar commands in other files executed later don't override your changes.    ------------------------------  % Date: Thu, 08 May 2003 13:22:36 +0100 + From: John Laird <john@laird-towers.org.uk> 3 Subject: Re: determining when a file is closed/open 8 Message-ID: <ogikbvk8efriqptnbkhtikfv2f85tmgipk@4ax.com>  A On 7 May 2003 21:39:02 -0700, jnboomer@yahoo.com (jboomer) wrote:   N >> Use the DCL lexical function f$file_attributes() see below.  You will get a' >> error message if the file is locked.  > G >Thanks John, this looks to be what we're looking for.  And yes, we did D >go thru this a week ago, but being my 1st time in the group, I lost >the thread somehow!  K "Locked" is not the same as "open".  I think it's a header flag showing the D file was not closed *properly* by the application (for some value ofH properly).  There is a set file/unlock command which in 20+ years I haveL never had to use, despite any number of application and system crashes.  (InF other words, I've not yet seen an application "lock" a file this way.)  K Most applications don't create new files with any form of shared access, so G the easiest way to tell it is still open is to try to open it yourself:   & $ open/read/err=fail lfile <file-spec>
 $ close lfile ' $ write sys$output "File may be copied"  $ exit $err:  $ savs = $statusD $ if savs.eq.%x1001828a then $ write sys$output "File is still open"E $ if savs.eq.%x10018292 then $ write sys$output "File does not exist"      	John    ------------------------------  % Date: Thu, 08 May 2003 17:46:27 +0100 + From: John Laird <john@laird-towers.org.uk> 3 Subject: Re: determining when a file is closed/open 8 Message-ID: <o82lbv81f5hrbtrf2e9tk7t1po8jprsh4d@4ax.com>  = On 8 May 2003 11:21:54 -0500, briggs@encompasserve.org wrote:   g >In article <ogikbvk8efriqptnbkhtikfv2f85tmgipk@4ax.com>, John Laird <john@laird-towers.org.uk> writes: D >> On 7 May 2003 21:39:02 -0700, jnboomer@yahoo.com (jboomer) wrote: >>  P >>>> Use the DCL lexical function f$file_attributes() see below.  You will get a) >>>> error message if the file is locked.  >>> I >>>Thanks John, this looks to be what we're looking for.  And yes, we did F >>>go thru this a week ago, but being my 1st time in the group, I lost >>>the thread somehow! >>  N >> "Locked" is not the same as "open".  I think it's a header flag showing theG >> file was not closed *properly* by the application (for some value of K >> properly).  There is a set file/unlock command which in 20+ years I have O >> never had to use, despite any number of application and system crashes.  (In I >> other words, I've not yet seen an application "lock" a file this way.)  > K >Yes that much is true, f$file_attributes("your-file-name.here", "LOCKED")  G >does not tell you whether the file is open.  It does not even tell you D >whether it's locked.  It tells you whether it is "deaccess locked". > B >But if the file is open for writing with read sharing disallowed,L >the f$file_attributes lexical will fail and _that_ will tell you something. > E >The code sequence referred to above was designed to detect a failure  >of the f$file_attributes call.   H Can't argue with that.  It will, however, also fill up the log file withJ error messages from the f$file failure (unless you want to start using setL mess/nofac/nosev/noid/notext).  At least open/read/err=<label> is silent ;-)     	John    ------------------------------   Date: 8 May 2003 11:56:55 -0500  From: briggs@encompasserve.org3 Subject: Re: determining when a file is closed/open 3 Message-ID: <KI$Kuan86c2M@eisner.encompasserve.org>   b In article <f56c6aaf.0305071346.1e4b129d@posting.google.com>, jnboomer@yahoo.com (jboomer) writes:E > Thanks John, I'm impressed by the speed of response in this forum.  F > Unforturnately the report generation process is via vendor supplied,H > menu driven applications which we are not authorized to alter.  We hadF > been thinking of doing the rename as you suggested in a program thatD > would run prior to the FTP.  But to do that we would first have to4 > determine whether the report files are still open. >  > So is this the best I can do? ; >   $PIPE SHOW DEV dsax/files | SEARCH SYS$INPUT filename     E If performance is a concern then attempting to open the file yourself ? looking for an access conflict is far less expensive than doing = the FID to file name reverse lookup on every open file on the  volume that SHOW DEV involves.   	John Briggs   ------------------------------  # Date: Thu, 08 May 2003 17:59:47 GMT < From: "John E. Malmberg" <Malmberg@dskwld.zko.dec.compaq.hp>3 Subject: Re: determining when a file is closed/open 0 Message-ID: <nWwua.544$WZ2.294@news.cpqcorp.net>   JF Mezei wrote:  > jboomer wrote: > F >>Unforturnately the report generation process is via vendor supplied,@ >>menu driven applications which we are not authorized to alter. >   N > Use logical names to point the report's location to a serial device which is > spooled to a queue. J > The application will try to write to REPORT_DIR:MyReport.txt which meansP > TXA0:MyReport.TXT with TXA0 going to a queue whose symbiont is written to takeI > the file, and perhaps use COPY/FTP or even email it to the destination.   ? Unfortunately any premature termination of the process that is  H generating the file will cause the incomplete file to be relayed to its 
 desitination.   E Some computer programs do not deal well with receiving partial files.    -John ! malmberg@dskwld.zko.dec.compaq.hp    ------------------------------   Date: 8 May 2003 13:53:45 -0500  From: briggs@encompasserve.org3 Subject: Re: determining when a file is closed/open 3 Message-ID: <5qCLpoX+Ebvq@eisner.encompasserve.org>   o In article <nWwua.544$WZ2.294@news.cpqcorp.net>, "John E. Malmberg" <Malmberg@dskwld.zko.dec.compaq.hp> writes:  > JF Mezei wrote:  >> jboomer wrote:  >>  G >>>Unforturnately the report generation process is via vendor supplied, A >>>menu driven applications which we are not authorized to alter.  >>  O >> Use logical names to point the report's location to a serial device which is  >> spooled to a queue.K >> The application will try to write to REPORT_DIR:MyReport.txt which means Q >> TXA0:MyReport.TXT with TXA0 going to a queue whose symbiont is written to take J >> the file, and perhaps use COPY/FTP or even email it to the destination. > A > Unfortunately any premature termination of the process that is  J > generating the file will cause the incomplete file to be relayed to its  > desitination.  > G > Some computer programs do not deal well with receiving partial files.   G But if the program can blow up and leave partial files, that's an issue ? regardless of whether or not those partial files are being sent  to a spooled device.  B If you get a partial file in a directory and FTP that out, you end up with a partial file.   B If you get a partial file spooled to a queue and FTP that out, you end up with a partial file.d  
 Six of one...n   	John Briggs   ------------------------------  % Date: Thu, 08 May 2003 17:02:39 +0200i7 From: Robert Trawinski <robert.trawinski@softax.com.pl>e- Subject: DS10 Motherboards in AlphaStation500r/ Message-ID: <b9drij$fkl$1@bozon2.softax.com.pl>    Hello,  ? Islands sells DS10 system motherboards. Is it possible replace :G motherboard in AlphaStation500 with DS10 motherboard? What about power V' supply, graphics card, SCSI cards etc.?s   Robert   ------------------------------  $ Date: Thu, 8 May 2003 14:09:37 -0400, From: "Island" <dbturner@nospamislandco.com>1 Subject: Re: DS10 Motherboards in AlphaStation500c/ Message-ID: <vbl7djhffu3ca1@news.supernews.com>p  % Motherboard and Power Supply may work/  6 We'll take a look - may need some metal work done also   Davidh   -- l David B Turner Island Computers US Corporationc 2700 Gregory St., Suite 180  Savannah GA 31404  Tel: 912 447 6622d Fax: 912 201 04020 Email: dbturner@islandco.com www.hpaq.net   ------------------------------  # Date: Thu, 08 May 2003 13:38:43 GMTS3 From: "George Samuelson" <samuelsong@insightbb.com> 0 Subject: For Sale on Ebay OpenVMS V7.3-1 and SPL. Message-ID: <D5tua.517307$OV.491679@rwcrnsc54>  , This is a multi-part message in MIME format.  + ------=_NextPart_000_004E_01C3153D.160C5080r Content-Type: text/plain;o 	charset="iso-8859-1"u+ Content-Transfer-Encoding: quoted-printable    Greetings All,  H I have up for auction on E-Bay a complete set of OpenVMS  Alpha V7.3-1 =F which includes the SPL and Doc set. In addition, I also have OpenVMS =, V7.3 for Vax which includes the SPL and Doc.  ? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3D3023066159g  ? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3D3023239611B   George Samuelson=20  George Samuelson=20u        + ------=_NextPart_000_004E_01C3153D.160C5080n Content-Type: text/html; 	charset="iso-8859-1"i+ Content-Transfer-Encoding: quoted-printable   > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>7 <META http-equiv=3DContent-Type content=3D"text/html; =l charset=3Diso-8859-1">9 <META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>u <STYLE></STYLE>f </HEAD>o <BODY bgColor=3D#ffffff>< <DIV><FONT face=3DArial size=3D2>Greetings All,</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>C <DIV><FONT face=3DArial size=3D2>I have up for auction on E-Bay a =m complete set of=20C OpenVMS&nbsp; Alpha V7.3-1 which includes the SPL and Doc set. In =i addition, I=20; also have OpenVMS V7.3 for Vax which includes the SPL and =m Doc.</FONT></DIV>r4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>& <DIV><FONT face=3DArial size=3D2><A=20J href=3D"http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&amp;item=3D30230661=J 59">http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&amp;item=3D3023066159</= A></FONT></DIV> 4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>& <DIV><FONT face=3DArial size=3D2><A=20J href=3D"http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&amp;item=3D30232396=J 11">http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&amp;item=3D3023239611</= A></FONT></DIV>i <DIV> 8 <P></P><FONT face=3D"PT Quill" color=3D#0000ff size=3D5>@ <P>George Samuelson</FONT> <BR><B><FONT face=3D"MS Sans Serif" = size=3D1>George=20< Samuelson</B></FONT> <BR></P><FONT face=3D"Monotype Sorts" = color=3D#ff0000 size=3D4>p( <P></FONT>&nbsp;</P></DIV></BODY></HTML>  - ------=_NextPart_000_004E_01C3153D.160C5080--    ------------------------------  # Date: Thu, 08 May 2003 14:35:03 GMTi' From: "Mark E. Levy" <melevy@attbi.com>d4 Subject: Re: For Sale on Ebay OpenVMS V7.3-1 and SPL- Message-ID: <rWtua.778210$F1.98400@sccrnsc04>i  J Don't be too suprised if you get a call from HP's legal department... ThatI is licensed, copyrighted material. I think you better check the agreement B under which you acquired this material before continuing with this
 auction...    > "George Samuelson" <samuelsong@insightbb.com> wrote in message( news:D5tua.517307$OV.491679@rwcrnsc54... Greetings All,  L I have up for auction on E-Bay a complete set of OpenVMS  Alpha V7.3-1 whichK includes the SPL and Doc set. In addition, I also have OpenVMS V7.3 for Vax  which includes the SPL and Doc.e  = http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3023066159r  = http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3023239611m George Samuelson George Samuelson   ------------------------------  # Date: Thu, 08 May 2003 16:36:30 GMTp3 From: "George Samuelson" <samuelsong@insightbb.com>e4 Subject: Re: For Sale on Ebay OpenVMS V7.3-1 and SPL? Message-ID: <iIvua.256812$Si4.201823@rwcrnsc51.ops.asp.att.net>f  I All of which requires a PAK to run which must be purchased through HP. InGJ addition, it is up to the end user to purchase either the RTNV or Software Update Licenses.2 "Mark E. Levy" <melevy@attbi.com> wrote in message' news:rWtua.778210$F1.98400@sccrnsc04... L > Don't be too suprised if you get a call from HP's legal department... ThatK > is licensed, copyrighted material. I think you better check the agreementrD > under which you acquired this material before continuing with this > auction... >  >e@ > "George Samuelson" <samuelsong@insightbb.com> wrote in message* > news:D5tua.517307$OV.491679@rwcrnsc54... > Greetings All, > H > I have up for auction on E-Bay a complete set of OpenVMS  Alpha V7.3-1 whichVI > includes the SPL and Doc set. In addition, I also have OpenVMS V7.3 fors VaxA! > which includes the SPL and Doc.a >s? > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3023066159w >a? > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3023239611- > George Samuelson > George Samuelson >- >-   ------------------------------  % Date: Thu, 08 May 2003 22:03:17 -0500o1 From: "David J. Dachtera" <djesys.nospam@fsi.net>g4 Subject: Re: For Sale on Ebay OpenVMS V7.3-1 and SPL' Message-ID: <3EBB1A75.A946E3F5@fsi.net>n   > George Samuelson wrote:  >  > Greetings All, > H > I have up for auction on E-Bay a complete set of OpenVMS  Alpha V7.3-1F > which includes the SPL and Doc set. In addition, I also have OpenVMS. > V7.3 for Vax which includes the SPL and Doc. > ? > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3023066159. > ? > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3023239611e  9 Please don't post MIME or HTML to a text only newsgroup. n   -- e David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Thu, 8 May 2003 15:37:09 -04002 From: John Eisenschmidt <jweisen@eisenschmidt.org>* Subject: Re: Go to an AS/400 from VAX/VMS?5 Message-ID: <20030508193709.GE21270@eisenschmidt.org>e   --MIdTMoZhcV1D07fI* Content-Type: text/plain; charset=us-ascii Content-Disposition: inline + Content-Transfer-Encoding: quoted-printablet  6 Rumor has it that RC Bryan (rcbryan@hotmail.com) said:L > "rob kas" <bob@paychoice.com> wrote in message news:<vbi87t8d6ngi66@corp.= supernews.com>...  > > Bob- > >=20" > >   AS400 gear is VERY reliable. >=20. > OK, I never had a problem with the hardware. >=20 > >   OS400 is a good O/Ss >=20H > OS400 is a "good" operating system, kind of the way Sears sells "good"E > "better" and "Sears Best."  Seriously, if all you want to do is runmE > production software, OS400 is quite functional.  Only it is the old-C > style IBM batch oriented software.  I get the idea that there arecF > still people at IBM who long for the days of punch cards (aka, "IBM"C > cards).  The idea that I can't compile and see the results of the.H > compilation without having to go to look at something in a print queueH > is boggling to me.  I have not dealt with new software like that since > the early 80's.   F I have an accounting/erp system I'd like to introduce you to. It has aF Windows, Unix, and AS/400 version (and everything is a queue no matter  what platform you run it on).=20  I > >   Maybe you just didn't know what you were doing and IBM got tired ofs > > dealing with you.> >=20E > As for support, if you don't mind paying top dollar, IBM can supplypF > one of the biggest army of support people in the world.  By the way,E > it takes quite a while for a problem to find its way from the lowlypG > customer to a person that actually knows what is going on but that ise% > common in any support organization.   C Their engineers are *enginners*, you have to keep that in mind. Oure@ AS/400 guy has an EE degree and he "doesn't like Unix, and neverF learned to use OS/2 or other PC operating systems". Luckily, I leard a? little IBM along the way, so he actually did lead me to solve a E problem once that had to do with spanning tree and an ancient version + of OS/400 (he knew nothing about Ethernet).d  4 > >                                              Rob > >=20 > > ">= > > > yes ... buy lots of tylenol ... and pick up a bottle ofc- > > > Grecian formula while you are at it ...h >=20E > Go to Costco and get the super-economy size.  In all honesty, I did-E > not have headaches so much as a massive time waste.  Something that = > would take a few hours on VMS would take days on the AS400.g >=20> > > > and get ready for a lot of OS crashes, and when you call< > > > IBM support (oxymoron), don't expect to hear back from& > > > them on what caused the crash=20 >=20F > I never had a crash.  The system works the way it supposed to, firstE > time, every time... Mind you, the way it is supposed to work is nothE > necessarily the way you may expect or the way you may want.  I havetG > had our software crash and then played hell trying to figure out what E > went wrong where but I have never had any trouble with the official>C > supported OS400 software.  Mind you, the GNU utilities are rather E > buggy on the AS400 but they are not supported, you kind of get whatlD > you pay for.  The manuals are ... fine.  What I wanted to know wasH > generally there somewhere, it took hours to find something trivial.  IB > can't believe they don't have something like the VMS ProgrammingE > Concepts Manual. They have half a dozen manuals with similar titles  > but none are near as useful.   If I may interject...   D as someone who came late to both OS/400 and VMS (with a Windows/UnixB background first) *both* vendor's manuals stink! If you go back to? about 1999 or early 2000 you'll see I made that point there.=20   ? And while I've really grown to like VMS, I have a couple AS/400 C developers who report to me that wish it would live forever. It's a F boring box with a green screen, but damn if it doesn't work 365 days a year.a     > > > ... also get ready for9 > > > the most constricted locked in menu system ever ...n >=20F > The menu system is the biggest pain in the neck I have ever seen butF > there are alternatives such as typing in the ultra-mnemonic commandsH > like "CRTCMOD" and "CPYFRMSTMF".  People that have never seen an AS400 > will think is am joking.   Hi, I'm FMS, have we met??  7 Again, both VMS and OS/400 need some work on the menus.c  B For the command line stuff, back to my IBm engineer. He *love* the> OS/400 commands (logical, but without vowels), and thinks Unix? commands sound like line noise. Unix people like theirs becausei> they're short. VMS people like theirs because they make sense.   So you have:. 	-logical and can sometimes be shortened (VMS)% 	-logical but without vowels (OS/400)i 	-short (Unix)   > > > been there, done that ...  >=20H > What it all comes down to is what someone said in another posting, "ItH > is the application that drives business."  If your application is onlyH > available on the AS400, I guess you are kind of stuck... I would think/ > about getting a new application or a new job.b  C I used to think this, I really did, but more and more I keep sayingeB "best tool for the job". Sometimes that's OS/400, sometimes that'sG VMS, sometimes that's Unix, and sometimes that's Netware. All omissions>  from this list were intentional.  @ Would I quit because they're forcing me off the VAX and onto theF AS/400? Hell no, I'd stay through the implemntation at least and buildE that skill. If it sucks when you get done, move on, but IT people whoo@ choose not to learn new things become obsolete themselves pretty quickly.  
 > Regards, > /RC Bryan    --=20,/ John W. Eisenschmidt (jweisen@eisenschmidt.org)i.   http://www.eisenschmidt.org/jweisen/pgp.html  K "As an adolescent I aspired to lasting fame, I craved factual certainty,=20eH and I thirsted for a meaningful vision of human life -- so I became a=20F scientist. This is like becoming an archbishop so you can meet girls."H                                                           -Matt Cartmill     --MIdTMoZhcV1D07fI' Content-Type: application/pgp-signatures Content-Disposition: inlines   -----BEGIN PGP SIGNATURE-----  Version: GnuPG v1.0.7 (OpenBSD)   @ iD8DBQE+urHkH5fmozfjvvIRAnBMAKDIhtNgGJd0mz5muAFOp2h1D1xYmACdEys2 VgP7UlrTaFv16KcdP2NfmAM= =GxjWi -----END PGP SIGNATURE-----=   --MIdTMoZhcV1D07fI--   ------------------------------  % Date: Thu, 08 May 2003 10:38:17 +0200 + From: "Thomas F. Howald" <howag@bluewin.ch>:* Subject: Re: Go to an AS/400 from VAX/VMS?* Message-ID: <3EBA1779.B5CEF1AA@bluewin.ch>   Bill Gunshannon wrote: > , > In article <3EB96A3E.C2A9E666@bluewin.ch>,7 >         "Thomas F. Howald" <howag@bluewin.ch> writes:  > >b) > > But I already have some grey hair ;-)e > L > Either you hide it well in the picture or you need to put a newer one. :-) >  > bill >   C It is indeed about 7 years old but I find I looked better that way!s   Thomas   -- tH ------------------------------------------------------------------------G T.F. Howald    |It's difficult to soar with eagles,|Ph:+41 32 686 61 86 H Otto Howald AG | when you work with turkeys.| http://www.garagehowald.ch> Engestrasse 13, 4500 Solothurn, Switzerland | howag@bluewin.ch   ------------------------------  % Date: Thu, 08 May 2003 09:34:25 -0400i! From: Jim Agnew <jpagnew@vcu.edu>:* Subject: Re: Go to an AS/400 from VAX/VMS?' Message-ID: <3EBA5CE1.10BBFA13@vcu.edu>o  H I once told someone I had a "Milwaukee Tumor"... he really thought I had cancer or something...       jimt   "Thomas F. Howald" wrote:h >  > Jim Agnew wrote: > >A= > > least Swiss or German Beer is stronger than it's AmericanhE > > counterparts...  Not having been over the pond, I would not know.E > >bL > > Actually, make the best of it, and learn a/s 400 best you can.  It wouldL > > be another skill set to eat with.. Change is the name of the game in our > > trade... > >n > > jimh > >iJ > > "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship > > of the Ring" >  > Thanks Jim > D > that's what I intended to do. Yes the the beer is stronger indeed.A > That also means it also has more calories and beer bellies grow.	 > faster.i >  > Thomas > --J > ------------------------------------------------------------------------I > T.F. Howald    |It's difficult to soar with eagles,|Ph:+41 32 686 61 86uJ > Otto Howald AG | when you work with turkeys.| http://www.garagehowald.ch@ > Engestrasse 13, 4500 Solothurn, Switzerland | howag@bluewin.ch   -- tF "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"   ------------------------------  % Date: Fri, 09 May 2003 00:07:39 +0200g+ From: "Thomas F. Howald" <howag@bluewin.ch>h* Subject: Re: Go to an AS/400 from VAX/VMS?* Message-ID: <3EBAD52B.9A74D6F8@bluewin.ch>   Paul Sture wrote:A > Z > In article <3EB8B1BD.D04433D7@bluewin.ch>, "Thomas F. Howald" <howag@bluewin.ch> writes: > > Hi > >aF > > I know it's a bad idea but we have to change our business softwareH > > (Automotive Dealer/Repairshop) to an AS/400 because the Car Importer@ > > only supports this system. I will sure miss the verbose DCL.I > > We now have a MicroVax 3100 server with VMS 4.7 that is 13 years old.  > >s > > Any hints and/or comments? > >  > D > Does the Importer offer any data migration assistance? A practicalF > example: When booking my last car service, I was advised that it wasD > time to renew the camshaft belt. I pointed out that it had alreadyD > been done recently. With my help he quickly located the details ofD > the repair on his system, saw what had been done, down to the lastD > part used, and amended my service book accordingly. That saved me, > the customer, money :-)c >  > > http://www.garagehowald.ch > E > If the pump prices displayed on your main page are up to date, next 9 > time I'm in your area, I'll come with an empty tank :-)  > + > Nice clean looking and fast website, BTW.t >  > -- > Paul Sture    E Yes the importer payed for certain programs on the AS400 and will pay < some for education on the AS400. The program is called CARE.  = Our present program can do that too and certainly the new onet	 will too.i  ! Yes the pump prices are for real!v  	 Thank You      Thomas --  H ------------------------------------------------------------------------G T.F. Howald    |It's difficult to soar with eagles,|Ph:+41 32 686 61 86 H Otto Howald AG | when you work with turkeys.| http://www.garagehowald.ch> Engestrasse 13, 4500 Solothurn, Switzerland | howag@bluewin.ch   ------------------------------   Date: 8 May 2003 11:42:42 -0700m' From: icerq4a@spray.se (David Svensson)uE Subject: Re: How Alpha will save Itanium - must reading for Bill Todd2= Message-ID: <734da31c.0305081042.2fe87099@posting.google.com>e  d "Bill Todd" <billtodd@metrocast.net> wrote in message news:<nnOdnblgSMHPPSWjXTWcpw@metrocast.net>...: > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:Bmythi5WF2LA@eisner.encompasserve.org...VG > > In article <3EB802B4.278D46F2@eps.zko.dec.com>, Hein van den Heuveli* >  <hein_netscape@eps.zko.dec.com> writes: > >e > > >eL > > > Now if we could just build a big fast smp system, like a marvel,  fast	 >  [soon]i( > > > enough to handle oodles of them...J > > > In the mean time the Superdome solution will have to do, and will do >  veryH& > > > nicely (See recent 650K  TPC-C). > H > See it indeed:  16 times as many processors as the 4-processor MadisonK > result, and only 5.44 times the performance.  Now *that's* scaling!  (ToodG > bad HP won't run TPC-C tests on EV7, a platform which actually *does*l	 > scale.)n  B Yes, the TPC-C result for the Superdome was lower than I expected,C especially compared to NECs 32-way. I do think however that we willaD see better results in the future on the same hardware. SQL Server isD known to not scale good at all with many users and Windows do have aF good API for database-work but it is uncertain how well it scales with many CPU's.g  9 I expect a HP-UX Oracle combination to scale much better.a   /David   ------------------------------  $ Date: Thu, 8 May 2003 02:05:39 -0400* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddh2 Message-ID: <6O-cnUX_SpMrbiSjXTWcow@metrocast.net>  H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:XmaWfS+0DYi1@eisner.encompasserve.org...:@ > In article <Dpidna8mErJ6ASWjXTWcqg@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes:B > > Larry was one of the more gullible of Compaq's hangers-on, and
 apparently, > > remains so.  At least he's consistent... > >  > I >    Larry is consistent in getting the technical facts straight, insteadP. >    of laying his own interpretation on them.  I In the case under discussion, Larry is a fool.  If you agree with him, sod are you.   - bill   ------------------------------  $ Date: Thu, 8 May 2003 02:14:40 -0400* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Todde2 Message-ID: <4t-cnRdfbINCaCSjXTWcpg@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:repWUZp2UI37@eisner.encompasserve.org...E@ > In article <nnOdnblgSMHPPSWjXTWcpw@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes:   ...i  B > >> So the value add *MUST* come from services/software as littleB > >> will be left to the collective engineering imagination *WHEN*C > >> Intel drags glueless on-CPU and sells it at a very fair price.  > >-F > > 2006-7 seems like kind of a long time to wait for Itanic to get it	 (assuminglH > > that it does then - no one's saying yet) given that Alpha and Hammer have itlK > > now and POWER and SPARC got it well over a year ago.  Even *I* expectedy itH > > earlier (and I was assuming that Intel started in 2001 when they got handed! > > the team and the technology).n > >u >s6 > But you don't need on-chip switches for performance.  L Perhaps you'd care to offer some kind of evidence to that effect?  The suckyL scaling of SuperDome in TPC-C moving from 4 to 64 processors doesn't seem toJ offer any, and the excellent aggregate-bandwidth and remote-memory-latencyB characteristics of EV7 (and Hammer) when compared with Itanic shed- considerable further doubt on your assertion.l     And I see from5 > other posts of yours the angle now is $ per metric.e  J Just more of Itanic's many weaknesses, both absolute and relative.  Though< why you imagine that this has any relevance here is unclear.   - bill   ------------------------------  $ Date: Thu, 8 May 2003 02:50:41 -0400* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddr2 Message-ID: <a9CcnW5A76PZYySjXTWcoQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:hoBM96QvoKS7@eisner.encompasserve.org...=@ > In article <LumcnWzcmIWWMiWjXTWcqA@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > > J > > "Hein van den Heuvel" <hein_netscape@eps.zko.dec.com> wrote in message- > > news:3EB802B4.278D46F2@eps.zko.dec.com...- >2 > >1I > >> The 2003 Itanium (Madison) @1.5 Ghz is outperforming Alpha big time.  > >:L > > Indeed it is, at least in many areas - or at least it will when it shipsH > > this summer.  Of course, it still uses considerably more power, it's still a K > > 4-year-newer core design, and now it is a full process generation aheadA asH > > well, has grown its on-chip cache to 6 MB, and is clocked 30% faster thanH > > Alpha (whose clock speed HP just doesn't seem all that interested in pushingaL > > very hard:  they significantly reduced the target clock rates for EV79 aA > > while ago as well), so you might say that if Madison *didn't*  out-perform ) > > Alpha it would be something of a dog., > >  > : > You left out the angle of SpecInt/MHz and/or SpecFp/MHz.  I Because it's irrelevant:  even you managed to get that right (at least ifa# that's what you're implying below).5  ; > "Does it matter how many RPM the engine turns or how many : > horsepower it has?  Isn't the more important criteria is: > it is fast - if the race calls for speed?"  (And similar< > analogies.)  Point is you are highlighting how inefficient< > Madison is , all those tired comp.arch freshmen arguments.  I Even a comp.arch freshman could have understood better than you did, Rob.IL If speed were the only figure of merit, Cray would have taken over the worldE decades ago (and Intel wouldn't be bothering to produce a low-voltagey Itanic).  J But to bring the conversation back to the specific discussion I was havingL with Hein (which you, as usual, seem to have been clueless about), the pointL was that his holding up Madison's superior performance to suggest that AlphaL couldn't have maintained its superiority ignored the fact that Alpha stoppedE competing in any real sense nearly 4 years ago, while Intel continuedDJ full-tilt developing Itanic and finally managed to produce something that,G at least by some measures, took the lead (from Alpha, anyway:  it stilloC looks pretty silly and/or ridiculously expensive when compared witho	 Opteron).?   >sK > > And, of course, there remain areas where there's no indication that theaG > > current Itanic architecture (i.e., everything prior to 2006-7) will  *ever*B > > match EV7, such as linear scalability and aggregate bandwidth. > >  >e > But it has better SpecFp/MHz.f  L So was that actually a *serious* observation, then?  I didn't think even you were that much of a dolt.t   >i > >uI > > Which, of course, is only half the story.  The other half is that theeL > > complete lack of any significant improvement to the McKinley core (rightJ > > through the Montecito release in 2005) makes it clear that shrinks andI > > speed-bumps is *all* that Intel knew what to do with it.  Without theg EV8/I > > team, THEY HAD NOWHERE TO GO - which means that Alpha and POWER would- haveE > > had the low-volume but very high-margin high-end to split betweeno
 themselvesE > > (and the Sun loyalists), while AMD hammered Itanic at the bottom.s > >  >s) > No proof as it won't play out that way.o  L Right.  Just like Wildfire took the world by storm.  Your crystal ball is as cracked as you are.t     Who's to say; > Intel doesn't have a dozen "Andy Glews" left?  After all,t@ > Andy Glew and crew created P6 and P6 was a shot out of nowhere: > and an indicator that Intel could make a pig fly (IA32).  G Regardless of how many good engineers Intel had before being handed theaK Alpha team, the *fact* is that they clearly weren't succeeding in salvagingoF Itanic, because if they had been the fruits of their labors would haveH started to appear - and Intel has made it clear that no significant coreL changes are scheduled before 2006.  The first hope for a better core is what3 the EV8 team is working on for 2006-7:  Tanglewood.p   >o > >>D > >> My immediate reference for this is the SAP SD 2-tier benchmark.I > >> 4-p Madison @1.5 Ghz = 860 users, 4-p McKinley @1.0 Ghz = 600 users.tK > >> 32-p Marvel @1 4-p ES45 @1.15Ghz = 4500 users --> about 600 user / 4p.a > >3I > > And, ironically, that number says it all.  Because IIRC a 4-processor: EV7rL > > system *does* do about 600 users.  But I'll bet you a good dinner that aL > > 32-processor McKinley won't come anywhere *near* 4500 users, and I'll atL > > least bet you dessert that a 32-processor Madison (at least one from HP)J > > won't either:  SGI seems to have worked its magic to make large ItanicH > > systems scale, but there's no indication that HP has a clue how to - and, ofuI > > course, HP's systems (rather than SGI's) are the ones to look at wheniA > > determining whether they are adequate replacements for Alpha.  > >w >n= > That's funny to suppose HP is standing still and resting onp > their laurels (SuperDome).  F What's funny is that the only available evidence suggests that this isI *exactly* what HP is doing, despite its clear inferiority to servers likeaF SGI's.  Unless you'd care to provide evidence that suggests otherwise.  $   Dave Fenwick and crew are employed > by HP last I heard.   I Right - the group that screwed up Wildfire and then played Judas to AlphaaI when the EV7 group took most of the serious server design away from them.dC And HP thought so highly of that group that they scrapped Fenwick'swI Avalanche/Wind/Fire/Water/whatever the silly names were Grand Server PlansK (that Alpha just didn't seem to fit into, so bye-bye Alpha), last *I* heard-E (so exactly what Fenwick et al. may be doing at HP now is not clear).d  ! >  Emer is heading up Tanglewood.i  J So come 2006-7 the Alpha chip group may once again rescue VMS's owner from% the incompetence of its server group.-  ; > What other proof would one need that very high performinge' > IA64 boxes are heading down the pike?L  F As noted above, Rob, you missed the point, which was that by virtue ofJ owning the Alpha team Compaq had the opportunity to retain a major lead inL high-end systems rather than give away that technology to someone else.  TheL question is not whether Emer's team in its new surroundings can finally makeD the pig fly a few years from now, but why in hell Compaq didn't takeI advantage of that team, already in place, to let Alpha soar several yearss= earlier while the pig stayed securely anchored to the ground.    - bill   ------------------------------  % Date: Thu, 08 May 2003 03:56:55 -0400e* From: JF Mezei <jfmezei.spamnot@istop.com>E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddd) Message-ID: <3EBA0D90.9A96902D@istop.com>e   Bill Todd wrote:K > In the case under discussion, Larry is a fool.  If you agree with him, sou
 > are you.  I Some people here require good relationship with whoever owns VMS and feeldG compelled/motivated to defend the owner of VMS because their fear their Q relationship would be jeoperdized if they were seen criticising the onwer of VMS.l  M Some people are in possession of information others do not have and that alson0 changes one's attitude towards the owner of VMS.  K Some people are involved in businesses where VMS is safe and sound, so theyiA don't see any of the doom and gloom that the naysayers spout out.e  J If someone has unqualified support of the owner of VMS, then I tend to askK myself what sort of situation is he in that either has convinced him all is H fine, or compells him to say nice things about the owner of VMS. This isM especially puzzling in teh case of certain folks who used to be naysayers buteM suddently turned into unqualified defenders of the owners of VMS and or IA64.f    A but it isn't right to call someone "fool" because he supports HP.w   ------------------------------  $ Date: Thu, 8 May 2003 04:04:21 -0400* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddr2 Message-ID: <v2mdnbSdKrv_kiejXTWcpQ@metrocast.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in messageo# news:3EBA0D90.9A96902D@istop.com...t > Bill Todd wrote:J > > In the case under discussion, Larry is a fool.  If you agree with him, so > > are you. > K > Some people here require good relationship with whoever owns VMS and feelnI > compelled/motivated to defend the owner of VMS because their fear theiraK > relationship would be jeoperdized if they were seen criticising the onwere of VMS.n >eJ > Some people are in possession of information others do not have and that also2 > changes one's attitude towards the owner of VMS. > H > Some people are involved in businesses where VMS is safe and sound, so theyC > don't see any of the doom and gloom that the naysayers spout out.2 >nL > If someone has unqualified support of the owner of VMS, then I tend to askJ > myself what sort of situation is he in that either has convinced him all isJ > fine, or compells him to say nice things about the owner of VMS. This isK > especially puzzling in teh case of certain folks who used to be naysayersh butlI > suddently turned into unqualified defenders of the owners of VMS and orR IA64.X >i >TC > but it isn't right to call someone "fool" because he supports HP.n  J That's correct - I was just giving Larry and Bob the benefit of the doubt.K If one supports HP in such a manner, one is either a fool for believing thecK blatant and largely transparent lies that Compaq and its toadies spewed outeE or a knave for encouraging (for some form of personal gain) others toa+ believe something that you yourself do not.-   - bill   ------------------------------  % Date: Thu, 08 May 2003 10:52:10 +0100o' From: Andrew Harrison SUNUK ConsultancyiE Subject: Re: How Alpha will save Itanium - must reading for Bill Todd . Message-ID: <3EBA28CA.6040308@nospamn.sun.com>   Bill Todd wrote:: > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:repWUZp2UI37@eisner.encompasserve.org...  > @ >>In article <nnOdnblgSMHPPSWjXTWcpw@metrocast.net>, "Bill Todd" > " > <billtodd@metrocast.net> writes: >  > ...  >  > A >>>>So the value add *MUST* come from services/software as littleiA >>>>will be left to the collective engineering imagination *WHEN*oB >>>>Intel drags glueless on-CPU and sells it at a very fair price. >>> E >>>2006-7 seems like kind of a long time to wait for Itanic to get ita >> > (assumingP > G >>>that it does then - no one's saying yet) given that Alpha and Hammer  >>	 > have itt > J >>>now and POWER and SPARC got it well over a year ago.  Even *I* expected >> > it > G >>>earlier (and I was assuming that Intel started in 2001 when they gotr >> > handed >   >>>the team and the technology). >>>p >>6 >>But you don't need on-chip switches for performance. >  > N > Perhaps you'd care to offer some kind of evidence to that effect?  The suckyN > scaling of SuperDome in TPC-C moving from 4 to 64 processors doesn't seem toL > offer any, and the excellent aggregate-bandwidth and remote-memory-latencyD > characteristics of EV7 (and Hammer) when compared with Itanic shed/ > considerable further doubt on your assertion.2 >   F The SuperDome64 has a backplane bandwidth of ~25 GB/s according to the the HP STREAMS results.h  D There is no indication that the IA-64 SuperDome has any interconnect. changes just the CELL boards to support IA-64.  D The Dome also scales terribly on SPECrate_fp generally an indication that the backplane is an issue.r  D These are probably the root cause though Windows and SQL server alsoE do not have a history of scaling on large systems so HP's TPC scalings9 could well also be influenced by the OS and DBMS as well.a   Regardse Andrew Harrisonh   ------------------------------   Date: 8 May 2003 07:41:56 -0500/; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) E Subject: Re: How Alpha will save Itanium - must reading for Bill ToddG3 Message-ID: <51+dBKd4mFjG@eisner.encompasserve.org>4  V In article <3EBA0D90.9A96902D@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:  C > but it isn't right to call someone "fool" because he supports HP.   B    For the record:  I do not support HP.  I did not suport Compaq.?    I wasn't always happy with DEC.  I just like VMS and HP just>+    happens to be the current owners of VMS.a   ------------------------------   Date: 8 May 2003 20:29:16 -0500t+ From: young_r@encompasserve.org (Rob Young)nE Subject: Re: How Alpha will save Itanium - must reading for Bill Toddt3 Message-ID: <IWfble+hgFTo@eisner.encompasserve.org>=  _ In article <a9CcnW5A76PZYySjXTWcoQ@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:e > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:hoBM96QvoKS7@eisner.encompasserve.org...eA >> In article <LumcnWzcmIWWMiWjXTWcqA@metrocast.net>, "Bill Todd"e" > <billtodd@metrocast.net> writes: >> >K >> > "Hein van den Heuvel" <hein_netscape@eps.zko.dec.com> wrote in message1. >> > news:3EB802B4.278D46F2@eps.zko.dec.com... >> >> >J >> >> The 2003 Itanium (Madison) @1.5 Ghz is outperforming Alpha big time. >> >M >> > Indeed it is, at least in many areas - or at least it will when it shipsoI >> > this summer.  Of course, it still uses considerably more power, it'sD	 > still agL >> > 4-year-newer core design, and now it is a full process generation ahead > asI >> > well, has grown its on-chip cache to 6 MB, and is clocked 30% fasteri > thanI >> > Alpha (whose clock speed HP just doesn't seem all that interested in 	 > pushinghM >> > very hard:  they significantly reduced the target clock rates for EV79 arB >> > while ago as well), so you might say that if Madison *didn't*
 > out-performe* >> > Alpha it would be something of a dog. >> > >>; >> You left out the angle of SpecInt/MHz and/or SpecFp/MHz.I > K > Because it's irrelevant:  even you managed to get that right (at least ift% > that's what you're implying below).D >    	Equally as tangential.<  < >> "Does it matter how many RPM the engine turns or how many; >> horsepower it has?  Isn't the more important criteria is3; >> it is fast - if the race calls for speed?"  (And similarm= >> analogies.)  Point is you are highlighting how inefficientf= >> Madison is , all those tired comp.arch freshmen arguments.< > K > Even a comp.arch freshman could have understood better than you did, Rob.FN > If speed were the only figure of merit, Cray would have taken over the worldG > decades ago (and Intel wouldn't be bothering to produce a low-voltage1
 > Itanic). >   . 	Speed as it relates to performance - not MHz.  L > But to bring the conversation back to the specific discussion I was havingC > with Hein (which you, as usual, seem to have been clueless about)0  % 	Bill "Denigrate" Todd at his finest.y   , the pointrN > was that his holding up Madison's superior performance to suggest that AlphaN > couldn't have maintained its superiority ignored the fact that Alpha stoppedG > competing in any real sense nearly 4 years ago, while Intel continuedbL > full-tilt developing Itanic and finally managed to produce something that,I > at least by some measures, took the lead (from Alpha, anyway:  it still1E > looks pretty silly and/or ridiculously expensive when compared withV > Opteron).  >    	Opteron.  So what.D   >>L >> > And, of course, there remain areas where there's no indication that theH >> > current Itanic architecture (i.e., everything prior to 2006-7) will > *ever*C >> > match EV7, such as linear scalability and aggregate bandwidth.6 >> > >>  >> But it has better SpecFp/MHz. > N > So was that actually a *serious* observation, then?  I didn't think even you > were that much of a dolt.c  B 	If "linear scalability" and "aggregate bandwidth" would translate? 	into something other than fine sounding terms just as relevantsC 	as SpecFp/Mhz.  One would think "linear scalabilty" and "aggregate.> 	bandwidth" would somehow translate into superior performance?; 	Oh... that would be Madison compared to EV7.  "But oh, EV7l< 	has been hamstrung and nothing has been done with Alpha the# 	last few years..." blah blah blah.    >  >> >> >J >> > Which, of course, is only half the story.  The other half is that theM >> > complete lack of any significant improvement to the McKinley core (righteK >> > through the Montecito release in 2005) makes it clear that shrinks anduJ >> > speed-bumps is *all* that Intel knew what to do with it.  Without the > EV8tJ >> > team, THEY HAD NOWHERE TO GO - which means that Alpha and POWER would > haveF >> > had the low-volume but very high-margin high-end to split between > themselvesF >> > (and the Sun loyalists), while AMD hammered Itanic at the bottom. >> > >>* >> No proof as it won't play out that way. > N > Right.  Just like Wildfire took the world by storm.  Your crystal ball is as > cracked as you are.. >  >   Who's to say< >> Intel doesn't have a dozen "Andy Glews" left?  After all,A >> Andy Glew and crew created P6 and P6 was a shot out of nowherer; >> and an indicator that Intel could make a pig fly (IA32).  > I > Regardless of how many good engineers Intel had before being handed the,M > Alpha team, the *fact* is that they clearly weren't succeeding in salvagingpH > Itanic, because if they had been the fruits of their labors would haveJ > started to appear - and Intel has made it clear that no significant coreN > changes are scheduled before 2006.  The first hope for a better core is what5 > the EV8 team is working on for 2006-7:  Tanglewood.  >   9 	The fruits of their labor are here today and shipping in-< 	the next 6 months.  Do continue to FUD up Madison.  Perhaps: 	a few more $ per metric arguments and you gain a handfull
 	of converts.S     >> >> >>ME >> >> My immediate reference for this is the SAP SD 2-tier benchmark.hJ >> >> 4-p Madison @1.5 Ghz = 860 users, 4-p McKinley @1.0 Ghz = 600 users.L >> >> 32-p Marvel @1 4-p ES45 @1.15Ghz = 4500 users --> about 600 user / 4p. >> >J >> > And, ironically, that number says it all.  Because IIRC a 4-processor > EV7vM >> > system *does* do about 600 users.  But I'll bet you a good dinner that a M >> > 32-processor McKinley won't come anywhere *near* 4500 users, and I'll at M >> > least bet you dessert that a 32-processor Madison (at least one from HP) K >> > won't either:  SGI seems to have worked its magic to make large ItanicaI >> > systems scale, but there's no indication that HP has a clue how to -t	 > and, of-J >> > course, HP's systems (rather than SGI's) are the ones to look at whenB >> > determining whether they are adequate replacements for Alpha. >> > >>> >> That's funny to suppose HP is standing still and resting on >> their laurels (SuperDome).t > H > What's funny is that the only available evidence suggests that this isK > *exactly* what HP is doing, despite its clear inferiority to servers likeeH > SGI's.  Unless you'd care to provide evidence that suggests otherwise. >   
 	Stand by.  & >   Dave Fenwick and crew are employed >> by HP last I heard. > K > Right - the group that screwed up Wildfire and then played Judas to AlphaeK > when the EV7 group took most of the serious server design away from them.,E > And HP thought so highly of that group that they scrapped Fenwick'srK > Avalanche/Wind/Fire/Water/whatever the silly names were Grand Server Plan M > (that Alpha just didn't seem to fit into, so bye-bye Alpha), last *I* heardtG > (so exactly what Fenwick et al. may be doing at HP now is not clear).n >   ? 	Doing what high paid hardware engineers do day to day.  Design  	next generation boxes.,  " >>  Emer is heading up Tanglewood. > L > So come 2006-7 the Alpha chip group may once again rescue VMS's owner from' > the incompetence of its server group.e > < >> What other proof would one need that very high performing( >> IA64 boxes are heading down the pike? > H > As noted above, Rob, you missed the point, which was that by virtue ofL > owning the Alpha team Compaq had the opportunity to retain a major lead inN > high-end systems rather than give away that technology to someone else.  TheN > question is not whether Emer's team in its new surroundings can finally makeF > the pig fly a few years from now, but why in hell Compaq didn't takeK > advantage of that team, already in place, to let Alpha soar several years ? > earlier while the pig stayed securely anchored to the ground.  >   : 	But Bill, at this point all you have left is $ per metric< 	and FUDing up HP's current IA64 lineup.  As IA64 in Madison: 	is top of the pack on most performance metrics.  McKinley= 	servers today by SGI and NEC top performers.  I'm sure IBM'sh$ 	IA64 boxes will be good performers.  = 	With $ per metric as an argument, it doesn't hold much waterIE 	at all.  After all, Alpha was never a top $ per metric architecture.a  > 	Where the difference lies, it won't stay that way.  Dell will: 	drive down the cost of 8, 16 , 32 CPU boxes - eventually.   				Rob    ------------------------------  $ Date: Thu, 8 May 2003 14:55:53 -0400* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddg2 Message-ID: <eZCcnQvwyqSmNSejXTWcoA@metrocast.net>  4 "David Svensson" <icerq4a@spray.se> wrote in message7 news:734da31c.0305081042.2fe87099@posting.google.com...h7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageb. news:<nnOdnblgSMHPPSWjXTWcpw@metrocast.net>...< > > "Rob Young" <young_r@encompasserve.org> wrote in message1 > > news:Bmythi5WF2LA@eisner.encompasserve.org...vI > > > In article <3EB802B4.278D46F2@eps.zko.dec.com>, Hein van den Heuvele, > >  <hein_netscape@eps.zko.dec.com> writes: > > >n > > > >eH > > > > Now if we could just build a big fast smp system, like a marvel, fast > >  [soon]c* > > > > enough to handle oodles of them...L > > > > In the mean time the Superdome solution will have to do, and will do	 > >  verys( > > > > nicely (See recent 650K  TPC-C). > > J > > See it indeed:  16 times as many processors as the 4-processor MadisonG > > result, and only 5.44 times the performance.  Now *that's* scaling!n (TooI > > bad HP won't run TPC-C tests on EV7, a platform which actually *does*I > > scale.)H >lD > Yes, the TPC-C result for the Superdome was lower than I expected,E > especially compared to NECs 32-way. I do think however that we willhF > see better results in the future on the same hardware. SQL Server isF > known to not scale good at all with many users and Windows do have aH > good API for database-work but it is uncertain how well it scales with
 > many CPU's.   J Well, you don't have to look *all* that far to see how well SQL Server canL handle at least 32 CPUs:  the same software was used for the NEC 32-way testI you mentioned above, and HP's 64-way score was only 1.28x that of the NECe
 32-way score.r   - bill   ------------------------------  $ Date: Fri, 9 May 2003 00:44:04 -0400* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddt2 Message-ID: <-KKdnSAZXeu0ryajXTWcqQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:IWfble+hgFTo@eisner.encompasserve.org...o@ > In article <a9CcnW5A76PZYySjXTWcoQ@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > >l< > > "Rob Young" <young_r@encompasserve.org> wrote in message1 > > news:hoBM96QvoKS7@eisner.encompasserve.org... C > >> In article <LumcnWzcmIWWMiWjXTWcqA@metrocast.net>, "Bill Todd"w$ > > <billtodd@metrocast.net> writes:   ...a  G > > But to bring the conversation back to the specific discussion I was  havingE > > with Hein (which you, as usual, seem to have been clueless about)T > & > Bill "Denigrate" Todd at his finest.  J "Denigration where denigration is due" is my motto, and you qualify for itF with exceptional regularity.  Given the increasingly blatant levels ofG unscrupulousness in industry and national leadership these days and thesJ eagerness with which fools like you rush to embrace their fabrications, myE belief is that the time for some extremely straight talk has arrived.G   >E
 > , the pointTJ > > was that his holding up Madison's superior performance to suggest that Alpha H > > couldn't have maintained its superiority ignored the fact that Alpha stoppedfI > > competing in any real sense nearly 4 years ago, while Intel continued H > > full-tilt developing Itanic and finally managed to produce something that,wK > > at least by some measures, took the lead (from Alpha, anyway:  it still G > > looks pretty silly and/or ridiculously expensive when compared withe
 > > Opteron).  > >i >  > Opteron.  So what.  H Given the enthusiasm with which Opteron has been received, as contrastedJ with the prolonged industry yawn that has greeted both launches of Itanic,F the rest of the world seems to be saying "Itanic - so what?"  Yet moreJ evidence that Compaq got spooked (or just bought off) by a large, menacing1 shadow rather than by something more substantial.i   >  > >>J > >> > And, of course, there remain areas where there's no indication that thegJ > >> > current Itanic architecture (i.e., everything prior to 2006-7) will
 > > *ever*E > >> > match EV7, such as linear scalability and aggregate bandwidth.. > >> > > >>" > >> But it has better SpecFp/MHz. > > L > > So was that actually a *serious* observation, then?  I didn't think even your > > were that much of a dolt.t >AC > If "linear scalability" and "aggregate bandwidth" would translate @ > into something other than fine sounding terms just as relevant > as SpecFp/Mhz.  E Which, of course, they do.  Scalability and bandwidth are measures oftL ability to perform actual work, whereas 'SPECfp/MHz' (as contrasted with rawJ SPECfp, for example) is a number of at most academic interest (it might beH more interesting in the real world if clock-rate correlated closely withH power consumption across architectures, but of course Itanic has clearlyF demonstrated a decidedly above-average appetite for power at its clock rate).  4   One would think "linear scalabilty" and "aggregate? > bandwidth" would somehow translate into superior performance?   I And indeed they do.  Scalability is what allows EV7 to come from slightly3D behind Itanic2 in SPECint and significantly behind it in SPECfp in aJ single-processor configuration to slightly ahead of Itanic2 in both scoresK when the processor count rises to 4 (a lead which will most likely increasemD as the count rises further, at least in the poorly-scaling HP Itanic	 systems).M  G And aggregate bandwidth is what will keep Marvel systems *far* ahead of L *all* competition in STREAM benchmarks for the foreseeable future (certainlyI through Montecito in 2005) - including the SGI Altix boxes (which with 64oJ processors score less than 24% higher than EV7 scores with 16 processors).  . > Oh... that would be Madison compared to EV7.  I 'Fraid not.  As noted above, Madison (and Montecito) systems won't hold atE candle to EV7 systems in STREAM performance (don't count on SuperDome L technology to work well with STREAM:  a 64-processor PA-RISC SuperDome turnsK in less than 1/4 the performance of the 64-processor SGI Altix system notediJ above that was only slightly faster than the 16-processor EV7).  And givenH the poor scaling that even the small-system-optimized HP boxes offer forB SPECfp, I wouldn't count on Madison beating current EV7 systems inK SPECfp_rate scores at large system sizes (though it might at SPECint_rate -eF we'll just have to wait and see how badly the SuperDomes scale there).     "But oh, EV7= > has been hamstrung and nothing has been done with Alpha thee$ > last few years..." blah blah blah.  J Yeah yeah yeah.  Once again, you seem to have lost sight of the underlyingL discussion with Hein that you presumed to join:  it involved Alpha's abilityE to remain ahead of Itanic *given the will to do so*, not a comparisonoG between a neglected, tired product and its new, well-funded but bloatedr challenger.    <much drivel snipped>   J > > As noted above, Rob, you missed the point, which was that by virtue ofK > > owning the Alpha team Compaq had the opportunity to retain a major leadt inK > > high-end systems rather than give away that technology to someone else.s The K > > question is not whether Emer's team in its new surroundings can finally- makeH > > the pig fly a few years from now, but why in hell Compaq didn't takeG > > advantage of that team, already in place, to let Alpha soar several  years-A > > earlier while the pig stayed securely anchored to the ground.d > >l >d; > But Bill, at this point all you have left is $ per metricw  F Repeating your misconceptions really doesn't add to their weight, Rob.  = > and FUDing up HP's current IA64 lineup.  As IA64 in Madisont1 > is top of the pack on most performance metrics.d  G 'Madison is top of the pack on most performance metrics?'  Hmmm - let's & review a few of the better-known ones:  J SPECint?  While AFAIK we don't yet know what is claimed there for Madison,H unless it scales super-linearly with clock rate from McKinley it will beG hard-pressed to match the 3.2 GHz P4s and 2.0 GHz Opterons that will beiK shipping when it launches, though it may be slightly ahead of IBM's 1.7 GHz  POWER4+.  D SPECfp?  I'll give you that one for small systems, but HP has yet toK demonstrate the ability to scale Itanic FP performance at all linearly likeeF EV7 can so we'll have to wait and see whether it leads in large-systemH SPECfp_rate (it probably will in SGI systems, but your accusation of FUD* above related specifically to HP systems).  H SPECweb99_SSL (a favorite Itanic benchmark until now)?  Not according toE AMD's numbers, which show even today's 1.8 GHz Opteron edging it out.i  J STREAM?  As noted, EV7 is in a different league from everyone else, but inJ the group of also-rans Madison systems won't come close to POWER4+ systems8 (and likely won't come close to Opteron systems either).  I TPC-C?  I was tempted to say I'd give you that one - though again only inDK smaller systems unless HP tests a large EV7 system and SuperDome beats it -pF but then started wondering how the new 1.7 GHz POWER4+ systems will doL (they're clocked about 30% faster than the current POWER4 system whose TPC-C9 score the 32-Madison NEC system beats by only about 20%).t  @ And that's just raw speed metrics.  Move to price-performance orL performance/Watt (which also certainly qualify as 'performance metrics') andJ Opteron makes Madison look sick (POWER4+ of course also makes Madison look sick in performance/Watt).  I As usual, Rob, when one examines your statements they just come up empty. K If you're going to persist in trying to spin, perhaps you should take a few4L lessons from Andrew:  his statements usually have at least *some* underlyingI basis in fact (though he often veers as far off the original point as youp do).   - bill   ------------------------------  $ Date: Thu, 8 May 2003 03:06:28 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!2 Message-ID: <rvWcnTlxdOFMnCejXTWcpQ@metrocast.net>  D "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> wrote in message* news:NWbua.466$uS1.433@news.cpqcorp.net... >I5 > "jlsue" <jefflsxxxz@sbcglobal.net> wrote in messagep4 > news:l78ibvgc3c12mkffu5plcit2m6v2fkvjj7@4ax.com...L > > On Tue, 06 May 2003 17:52:34 -0400, JF Mezei <jfmezei.spamnot@istop.com>
 > > wrote: > >t >  >J > > >We know that Compaq had seriously considered killing VMS in 2000 if I
 > rememberG > > >correctly. But they realised that they needed the revenus. Now, if  > VMS/AlphayG > > >were kept only because of revenus, why would they have jeoperdized' thoseoL > > >revenus in 2001 ? It would have been far smarter for Compaq to announce aeK > > >project to transform VMS into a less platform dependant OS, and a yearo or > twooI > > >later, announce that as a result of this, they would also port it tom IA64% > > >which would not be an easy task.n > > >r9 > > How do we know this about Compaq killing VMS in 2000?t > 
 > They don't.l  J Only because jlsue parsed JF's statement incorrectly:  Compaq wasn't goingL to *kill VMS* in 2000, it was *considering* in 2000 (actually, 1999) killing VMS in 2003.  @   The twisted logic is that in a moment of candor, Rich MarcelloL > (apparently, I wasn't there) told a group of people that *all* options forL > OpenVMS's future had been put on the table for hard decisions to be made -$ > including just simply retiring it.  - Wrong, Fred - as you said, you weren't there.g  J But I was.  And what Rich said was that there had been a *plan* to put VMSF in code freeze by 2003 (which is rather more specific than the kind ofL wildly-ranging brain-storming that your description suggests) - a plan whichJ was shelved when Compaq was persuaded to give VMS a chance to increase itsE revenues (with, of course, zero marketing) during Y2K and (hopefully)zK beyond.  The single-digit-percentage increase did in fact occur, giving VMSaL a reprieve - but of course since then (and particularly since the Alphacide)H VMS revenues have plunged, which, given this series of events, gives oneH good cause to suspect that the long knives may be coming out again soon.  K Furthermore, none other than Mike Capellas mentioned the planned retirementcL of VMS in an unguarded moment at a sales-group meeting in the spring of 19997 (I wasn't there for that one, but someone I trust was).    - bill   ------------------------------  $ Date: Thu, 8 May 2003 03:15:16 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!2 Message-ID: <etmdnYV9jJdoniejXTWcqg@metrocast.net>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in message 7 news:d7791aa1.0305070722.518ab6e6@posting.google.com...n7 > "Bill Todd" <billtodd@metrocast.net> wrote in messager. news:<Md6dnd_-kdYqIyWjXTWcpQ@metrocast.net>.../ > > "Dirk Munk" <munk@home.nl> wrote in messaget0 > > news:b96ebd$hru$1@news1.tilbu1.nb.home.nl... > >,J > > > Today I read an article in by Terry Shannon in the april issue of HP Worlda > >  (ItH > > > think), where he explains how this whole thing happened. He writes that
 > >  the movevI > > > came from the Alpha engineers, who saw big problems occuring in the- design > >  of. > > > the EV8. > >cF > > It is not true if the 'Alpha engineers' being referred to were EV8K > > engineers.  But there is some indication that Compaq's server group wash lessJ > > than enthused about the EV7/EV8 on-chip support that drew attention to thedA > > inadequacies of their Wildfire server implementation and to aa significant G > > degree made them seem somewhat superfluous, and indeed at one pointn afterlH > > the EV8 people had publicly denied making any such statements Compaq seemedK > > to suggest that the impetus for axing Alpha came from the server group,e who E > > may have felt that they were protecting their own jobs (though mys
 impressionB > > is that HP has not rewarded them as they might have expected). > >hL > > > The result of this marketing blunder: years of paranoid discussions in
 > >  this andaI > > > other news groups, and lack of confidence in anything Compaq and HPy > >  managementrI > > > tell us. Of course still asuming Terry is telling us the truth, and  this > >  is noto3 > > > a later fabricated story to explain the move.  > > L > > Well, as noted Terry is not telling the truth - just revisit some of theI > > discussions in c.o.v. back then if you'd like the citations to verify  that.eF > > But the story wasn't fabricated later:  it appeared along with theK > > announcement of the Alphacide, presumably because Compaq had an inkling  thatG > > they needed to say *something* to try to rationalize such a blatanth breachI > > of promise, even if it flatly contradicted their previous statements.  > >s
 > > - bill > @ > if the GS series was so flawed, why is the GS1280 kicking butt > right now?  K Surely, Bob, even someone as tenuously connected to reality as you are mustoE be aware that the Wildfire (EV6-based) platform (GS80/160/320) that IwG referred to above is *completely different* from the Marvel (EV7-based)e platform (GS1280).   - bill   ------------------------------  $ Date: Thu, 8 May 2003 02:52:26 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!2 Message-ID: <3P6cnXidHu8zYySjXTWcrg@metrocast.net>  H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:j9xZcrq$$Pgr@eisner.encompasserve.org... @ > In article <Md6dnd_-kdYqIyWjXTWcpQ@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: >e9 > > Multiple engineers in the EV8 group have stated, somes= > > publicly, that there was *no* problem with the EV8 effort  >3 >    Reference, please..  F Dig it up yourself, Bob:  you've been around for the entire period andF involved in the discussion, so if you've forgotten it due to premature+ senility the exercise will be good for you.    - bill   ------------------------------  $ Date: Thu, 8 May 2003 15:02:42 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!2 Message-ID: <jK6cnV53pJ9JNCejXTWcqw@metrocast.net>  H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:jpclq3FZe79b@eisner.encompasserve.org...G@ > In article <3P6cnXidHu8zYySjXTWcrg@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > > J > > Dig it up yourself, Bob:  you've been around for the entire period andJ > > involved in the discussion, so if you've forgotten it due to premature/ > > senility the exercise will be good for you.g >e# >    All I've seen is _your_ claim.s  C Then you haven't been paying attention to the multiple times it wase1 accompanied by the exact citations you requested.y  G I guess I've just gotten tired of responding to losers who have been inlK denial for the past decade about VMS's owner's intentions.  Feel free to gogI down with the ship if you care to:  my only interest is in keeping likelyeL well-meaning but seriously misguided people like you from taking others downH with them who might have missed the relevant portions of the discussion.   - bill   ------------------------------   Date: 8 May 2003 15:50:28 -0500l; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)7F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!3 Message-ID: <p+BcvkIa4r7U@eisner.encompasserve.org>u  _ In article <jK6cnV53pJ9JNCejXTWcqw@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:  > E > Then you haven't been paying attention to the multiple times it wasa3 > accompanied by the exact citations you requested.n  =   Me?  Pay attention to you?  You sound too much like Andrew.n   ------------------------------  $ Date: Thu, 8 May 2003 18:41:27 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!2 Message-ID: <-oudnVCUGIJrQSejXTWcpQ@metrocast.net>  H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:p+BcvkIa4r7U@eisner.encompasserve.org... @ > In article <jK6cnV53pJ9JNCejXTWcqw@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > >mG > > Then you haven't been paying attention to the multiple times it wase5 > > accompanied by the exact citations you requested.a > ? >   Me?  Pay attention to you?  You sound too much like Andrew.   B Ah, yes - form before content:  the credo of the credulous and theJ analytically-challenged.  Package up any old crapola in an exterior that'sJ pleasing to them and they'll consider it gospel (hey, it works for Dubya),K but just present unvarnished facts and they don't even bother to read them.s  C But considering that you couldn't even analyze take-off and orbital G mechanics properly (a subject supposedly closer to your area of nominalnE expertise) during the Columbia discussion, your failure to appreciatesL subtleties (and not-so-subtleties) here is hardly surprising.  In defense ofI my own general credibility and analytical acumen in an area that might beeL more meaningful to you I could point out that people like Sally Ride and theL Columbia investigation board have come around during the past month or so toL the same observations that I posted on 2/2/03 (Sally referred to 'disturbingE echoes of the Challenger disaster', I believe), but since as I said I-G couldn't care less whether you find me convincing or not I won't botheroL dredging up any further level of detail, especially as you've noted that you+ probably wouldn't pay any attention anyway.K   - bill   ------------------------------  * Date: Fri, 9 May 2003 00:41:13 +0000 (UTC)+ From: david20@alpha2.mdx.ac.uk (David Webb)TF Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!+ Message-ID: <b9etf8$79k$1@aquila.mdx.ac.uk>p  q In article <jpclq3FZe79b@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:S` >In article <3P6cnXidHu8zYySjXTWcrg@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes: >> eI >> Dig it up yourself, Bob:  you've been around for the entire period andtI >> involved in the discussion, so if you've forgotten it due to premature . >> senility the exercise will be good for you. >S" >   All I've seen is _your_ claim. >e  I Well to start with check out some of the postings on comp.arch by BrannonhL Batson made during the brief period between he's being a Compaq and an Intel	 employee.u   To get a flavour of them :-c   "c  / From: Brannon Batson (Brannon_Batson@yahoo.com) 0 Subject: Re: Alpha: an invitation to communicate$ View: Complete Thread (307 articles) Original Format " Newsgroups: comp.os.vms, comp.arch Date: 2001-07-21 00:11:53 PSTt   .n .  .V  F Perhaps you misunderstood...I'm not trying to *prove* anything to you.E  It has been suggested that this deal was technically motivated.  I'mBE an Alpha architect, and I claim otherwise.  If you (and whoever else)i@ would rather believe Compaq's bullshit, then that's your choice.   > [snip]   Brannoni   "a    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Thu, 08 May 2003 10:31:02 +0200 ( From: Andreas Davour <ante@update.uu.se>; Subject: How do I automate a response after a program fail? * Message-ID: <cs91xz9u9fd.fsf@update.uu.se>   Hi guys!  G I'm trying to help out moving some VMS MAIL to a unix account. (yeah, I>+ know it's not fun but it had to be done...)e  G I have found a nice little fortran program called V2_MAIL (I think). Ite7 converts a VMS MAIL folder into a 'mbox' file for unix.a  E The problem is that after processing a few MAILs it stops complaining G about a missing file. Its always a .MAI file names as a big hexadecimali number.   A I 'CREATE' the file with nothing but an empty line and re-run the  Fortran program. It works ok.   E The problem is there are quite a lot of those "missing files" and I'mtD beginning to wonder what they mean, what they are and if I can maybe automate the creation of them.  B Is there a good way to "catch" the error message and automaticallyF 'CREATE' a new empty file of that name and then restart the conversionG program? I'm not that good at DCL scripting, but I guess it could maybea be done, somehow.a  
 Any ideas?   /Andreas   ------------------------------  % Date: Thu, 08 May 2003 09:36:16 +0100e( From: Nic Clews <sendspamhere@127.0.0.1>? Subject: Re: How do I automate a response after a program fail? ) Message-ID: <3EBA1700.E794C65F@127.0.0.1>    Andreas Davour wrote:e > 
 > Hi guys! > I > I'm trying to help out moving some VMS MAIL to a unix account. (yeah, Ih- > know it's not fun but it had to be done...)r > I > I have found a nice little fortran program called V2_MAIL (I think). It 9 > converts a VMS MAIL folder into a 'mbox' file for unix.h > G > The problem is that after processing a few MAILs it stops complaininguI > about a missing file. Its always a .MAI file names as a big hexadecimalE	 > number.n > C > I 'CREATE' the file with nothing but an empty line and re-run theb > Fortran program. It works ok.a > G > The problem is there are quite a lot of those "missing files" and I'm F > beginning to wonder what they mean, what they are and if I can maybe  > automate the creation of them. > D > Is there a good way to "catch" the error message and automaticallyH > 'CREATE' a new empty file of that name and then restart the conversionI > program? I'm not that good at DCL scripting, but I guess it could maybem > be done, somehow.r  E In VMSmail, if the size of the mail exceeded (approx) 4k, then it gotpE put into one of these mail$big-hex-number files. If it's missing then F technically that mail is missing. (Maybe its on an old backup, but how" much effort do you want to go to?)  H There is an orphan program which can find maail$big-hex-number files andF determine if the related message is in the mail file, but I don't know  of anything the other way round.  H In terms of what you are trying to do, you need I think to flag the factF that there is a missing file because someone deleted the external fileF which is the message. you have only the sender, subject, date and time1 (and of course a reference to the external file).Y  F How you process it is a decision only you can take. Ignore the messageF and carry on, or populate the new file with something that states thatA the content was deleted from the source system before it could be>> converted. Program modifications required anyhow. Over to you.   -- g? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences> nclews at csc dot comi   ------------------------------  % Date: Thu, 08 May 2003 10:56:26 +0200 ( From: Andreas Davour <ante@update.uu.se>? Subject: Re: How do I automate a response after a program fail?d* Message-ID: <cs9y91hstol.fsf@update.uu.se>  * Nic Clews <sendspamhere@127.0.0.1> writes:   Thanks for your speedy reply!!   > Andreas Davour wrote:h >> c >> Hi guys!n >> cJ >> I'm trying to help out moving some VMS MAIL to a unix account. (yeah, I. >> know it's not fun but it had to be done...) >> dJ >> I have found a nice little fortran program called V2_MAIL (I think). It: >> converts a VMS MAIL folder into a 'mbox' file for unix. >> eH >> The problem is that after processing a few MAILs it stops complainingJ >> about a missing file. Its always a .MAI file names as a big hexadecimal
 >> number. [snip]G > In VMSmail, if the size of the mail exceeded (approx) 4k, then it gotDG > put into one of these mail$big-hex-number files. If it's missing thennH > technically that mail is missing. (Maybe its on an old backup, but how$ > much effort do you want to go to?)  C 4k wasn't much! Strange. As far as I understand it, no messages aregG missing. Sure, some messages have been deleted since they came but theys: should be long gone. I wonder why traces of them linger...  J > In terms of what you are trying to do, you need I think to flag the factH > that there is a missing file because someone deleted the external fileH > which is the message. you have only the sender, subject, date and time3 > (and of course a reference to the external file).e >nH > How you process it is a decision only you can take. Ignore the messageH > and carry on, or populate the new file with something that states thatC > the content was deleted from the source system before it could be'@ > converted. Program modifications required anyhow. Over to you.  E Ick! I had hoped to avoid to modify the program. I don't know enoughtnB about MAIL and it's format to know how to chnage it and be sure it doesn't do something stupid.  B Is there a way to traverse the MAIL folder and get a list of thoseG "missing files"? Then maybe they could be created all at once instead.     /andreas   ------------------------------  % Date: Thu, 08 May 2003 05:21:28 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>? Subject: Re: How do I automate a response after a program fail?c) Message-ID: <3EBA2159.426CE2F9@istop.com>l   One thing you could look at is:   & MAIL> EXTRACT/ALL/NOHEADER bigfile.txt  E and then somehow process the bigfile.txt into your unix mail program.y  * MAIL> HELP EXTRACT gives you more details.   ------------------------------  % Date: Thu, 08 May 2003 13:16:11 +0200g, From: Albrecht Schlosser <ajs856@tiscali.de>? Subject: Re: How do I automate a response after a program fail?p, Message-ID: <o9ed9b.bpp.ln@news.hus-soft.de>   Andreas Davour wrote:  > D > Is there a way to traverse the MAIL folder and get a list of thoseH > "missing files"? Then maybe they could be created all at once instead.   I don't know, but I would try    MAIL> COMPRESS  3 This might (should ?) complain about missing files.    Albrecht   ------------------------------  % Date: Thu, 08 May 2003 13:26:27 +0200 , From: Albrecht Schlosser <ajs856@tiscali.de>? Subject: Re: How do I automate a response after a program fail?k, Message-ID: <1ted9b.5vp.ln@news.hus-soft.de>   I wrote: >  > Andreas Davour wrote:V > >>F > > Is there a way to traverse the MAIL folder and get a list of thoseJ > > "missing files"? Then maybe they could be created all at once instead. >  > I don't know, but I would try  >  > MAIL> COMPRESS > 5 > This might (should ?) complain about missing files.   ; Sorry, it doesn't. But JF's suggestion EXTRACT/ALL does :-)    Albrecht   ------------------------------  % Date: Thu, 08 May 2003 10:02:17 -0400s& From: David M Smith <dsmit115@csc.com>? Subject: Re: How do I automate a response after a program fail? 8 Message-ID: <jgokbvkh1vsjk6obs8oasaff0dfu0dou4k@4ax.com>  M On Thu, 08 May 2003 09:36:16 +0100, Nic Clews <sendspamhere@127.0.0.1> wrote:    >Andreas Davour wrote: >>   	...H >> The problem is that after processing a few MAILs it stops complainingJ >> about a missing file. Its always a .MAI file names as a big hexadecimal
 >> number. 	...I >There is an orphan program which can find maail$big-hex-number files andeG >determine if the related message is in the mail file, but I don't knowi! >of anything the other way round.d  L There is a program called MAILCOUNT on the Freeware V5 CD which will "match"I these external files against the MAIL.MAI file. You can download it from:c  9 	http://h71000.www7.hp.com/freeware/freeware50/mailcount/>  + A sample run looks like this on my account:t   $ run mailcountn  : Scanning folders in mail file xxxx:[xxxxx.VMSMAIL]MAIL.MAI<   Scanning folder MAIL...31 messages, 16 with external files@   Scanning folder MAIL_xxxx..15 messages, 11 with external files<   Scanning folder NEWMAIL...1 message, 1 with external files    Total of 3 folders processed   A  Total of 28 external messages found following processing of filei    xxxx:[xxxxx.VMSMAIL]MAIL.MAI5  / Scanning directory xxxx:[xxxxx.VMSMAIL]MAIL.MAIt  F  Total of 44 external messages found following processing of directory    xxxx:[xxxxx.VMSMAIL]s  G No mail file pointer exists for external file MAIL$1054343C00050098.MAI G No mail file pointer exists for external file MAIL$1114965600050098.MAIeG No mail file pointer exists for external file MAIL$1454365F00050098.MAI G No mail file pointer exists for external file MAIL$145559A600050098.MAIeG No mail file pointer exists for external file MAIL$1461BB9400050098.MAI G No mail file pointer exists for external file MAIL$14C0A29D00050099.MAI G No mail file pointer exists for external file MAIL$371E6ABE00050098.MAIkG No mail file pointer exists for external file MAIL$3923D54A00050097.MAIsG No mail file pointer exists for external file MAIL$8B5E3C4E00050096.MAIlG No mail file pointer exists for external file MAIL$9A3D036B00050096.MAIlG No mail file pointer exists for external file MAIL$CCBEA17500050096.MAIrG No mail file pointer exists for external file MAIL$D1243EC500050096.MAIhG No mail file pointer exists for external file MAIL$D154F1D200050096.MAImG No mail file pointer exists for external file MAIL$D7C5C46D00050096.MAIoG No mail file pointer exists for external file MAIL$DABED3C600050096.MAIeG No mail file pointer exists for external file MAIL$DEEAF03400050096.MAIg  I In this case, it found a number of "external" files with no correspondingnO pointers. "Pointing" the image at another user on the system, I found a missing % external file (similar to your case):     $ mailcount xxxx:[user2.vmsmail]  : Scanning folders in mail file xxxx:[user2.VMSMAIL]MAIL.MAI=   Scanning folder MAIL...184 messages, 40 with external filess    Total of 1 folder processed  A  Total of 40 external messages found following processing of filea    xxxx:[user2.VMSMAIL]MAIL.MAIs  / Scanning directory xxxx:[user2.VMSMAIL]MAIL.MAIn  F  Total of 40 external messages found following processing of directory    xxxx:[user2.VMSMAIL]   C Pointer exists but no external file MAIL$D5708EC1000500A1.MAI foundaI -------------------------------------------------------------------------aI David M. Smith 302.391.8533                       dsmit115 at csc dot comlI Computer Sciences Corporation     (Opinions are those of the writer only)rI -------------------------------------------------------------------------c   ------------------------------  % Date: Thu, 08 May 2003 16:11:46 +0200r( From: Andreas Davour <ante@update.uu.se>? Subject: Re: How do I automate a response after a program fail?a* Message-ID: <cs9addxply5.fsf@update.uu.se>  . Albrecht Schlosser <ajs856@tiscali.de> writes:  
 > I wrote: >> n >> Andreas Davour wrote: >> >G >> > Is there a way to traverse the MAIL folder and get a list of those-K >> > "missing files"? Then maybe they could be created all at once instead.B >> o  >> I don't know, but I would try >> R >> MAIL> COMPRESSa >> a6 >> This might (should ?) complain about missing files. >S= > Sorry, it doesn't. But JF's suggestion EXTRACT/ALL does :-)e  H It was a nice idea. I actually tried doing that before posting, since itD was my first idea. Sorry, I should have mentioned it. Thanks for the hint anyway!   /andreas   ------------------------------  % Date: Thu, 08 May 2003 16:20:34 +0200 ( From: Andreas Davour <ante@update.uu.se>? Subject: Re: How do I automate a response after a program fail?n* Message-ID: <cs97k91pljh.fsf@update.uu.se>  , JF Mezei <jfmezei.spamnot@istop.com> writes:  ! > One thing you could look at is:m >y( > MAIL> EXTRACT/ALL/NOHEADER bigfile.txt > G > and then somehow process the bigfile.txt into your unix mail program.r >e, > MAIL> HELP EXTRACT gives you more details.  H Thanks! I will try that. Even if it fails to dump the mail, but gives meE a list of all missing files I might be able to create them all in onen go.    /andreas   ------------------------------  % Date: Thu, 08 May 2003 19:45:43 +0200sB From: Michiel Erens <I.dont.want.spam@this.mailaddress.is.invalid>? Subject: Re: How do I automate a response after a program fail? 6 Message-ID: <3EBA97C7.C1D@this.mailaddress.is.invalid>   David M Smith wrote: >  > G > There is a program called MAILCOUNT on the Freeware V5 CD which will eB > "match" these external files against the MAIL.MAI file. You can  > download it from:  > B >         http://h71000.www7.hp.com/freeware/freeware50/mailcount/  5 There is another one on the V4 freeware CD : VFYMAIL    7  http://h71000.www7.hp.com/freeware/freeware40/vfymail/e   -- - ME Posted by news://news.nb.nud   ------------------------------  % Date: Thu, 08 May 2003 12:45:42 -0500l' From: Chris Olive <nospam@raytheon.com>e? Subject: Re: How do I automate a response after a program fail?r> Message-ID: <9Jwua.3236$c6.3256@bos-service2.ext.raytheon.com>   Andreas Davour wrote:g, > Nic Clews <sendspamhere@127.0.0.1> writes: >   > Thanks for your speedy reply!! >  >  >>Andreas Davour wrote:+ >> >>>Hi guys!m >>>rJ >>>I'm trying to help out moving some VMS MAIL to a unix account. (yeah, I. >>>know it's not fun but it had to be done...) >>>uJ >>>I have found a nice little fortran program called V2_MAIL (I think). It: >>>converts a VMS MAIL folder into a 'mbox' file for unix. >>>@H >>>The problem is that after processing a few MAILs it stops complainingJ >>>about a missing file. Its always a .MAI file names as a big hexadecimal
 >>>number. >  > [snip] > G >>In VMSmail, if the size of the mail exceeded (approx) 4k, then it got"G >>put into one of these mail$big-hex-number files. If it's missing thenoH >>technically that mail is missing. (Maybe its on an old backup, but how$ >>much effort do you want to go to?) >  > E > 4k wasn't much! Strange. As far as I understand it, no messages arehI > missing. Sure, some messages have been deleted since they came but theyt< > should be long gone. I wonder why traces of them linger... >  > J >>In terms of what you are trying to do, you need I think to flag the factH >>that there is a missing file because someone deleted the external fileH >>which is the message. you have only the sender, subject, date and time3 >>(and of course a reference to the external file).i >>H >>How you process it is a decision only you can take. Ignore the messageH >>and carry on, or populate the new file with something that states thatC >>the content was deleted from the source system before it could be @ >>converted. Program modifications required anyhow. Over to you. >  > G > Ick! I had hoped to avoid to modify the program. I don't know enought D > about MAIL and it's format to know how to chnage it and be sure it > doesn't do something stupid. > D > Is there a way to traverse the MAIL folder and get a list of thoseI > "missing files"? Then maybe they could be created all at once instead. >  D Just FYI in case you need to come to this later, the best way to go G mucking around with MAIL internals is using the callable MAIL$ utility  E routines.  Sounds like you maybe are minimally familiar with VMS, so eB this might be a bit to bite off, but... it's there if you need it.   Chris  -----t Chris Olivea Systems Consultant' Raytheon Technical Services Corporation  Indianapolis, IN  * email: olivec(AT)indy(DOT)raytheon(DOT)com   ------------------------------  * Date: Fri, 9 May 2003 00:05:23 +0000 (UTC)+ From: david20@alpha2.mdx.ac.uk (David Webb)h? Subject: Re: How do I automate a response after a program fail?o+ Message-ID: <b9erc2$722$1@aquila.mdx.ac.uk>S  U In article <cs9y91hstol.fsf@update.uu.se>, Andreas Davour <ante@update.uu.se> writes:i+ >Nic Clews <sendspamhere@127.0.0.1> writes:  >l >Thanks for your speedy reply!!l >l >> Andreas Davour wrote: >>>  >>> Hi guys! >>> K >>> I'm trying to help out moving some VMS MAIL to a unix account. (yeah, I / >>> know it's not fun but it had to be done...)n >>> K >>> I have found a nice little fortran program called V2_MAIL (I think). Ite; >>> converts a VMS MAIL folder into a 'mbox' file for unix.t >>> I >>> The problem is that after processing a few MAILs it stops complainingeK >>> about a missing file. Its always a .MAI file names as a big hexadecimalt >>> number.  >[snip]hH >> In VMSmail, if the size of the mail exceeded (approx) 4k, then it gotH >> put into one of these mail$big-hex-number files. If it's missing thenI >> technically that mail is missing. (Maybe its on an old backup, but howa% >> much effort do you want to go to?)e >mD >4k wasn't much! Strange. As far as I understand it, no messages areH >missing. Sure, some messages have been deleted since they came but they; >should be long gone. I wonder why traces of them linger...  >tK >> In terms of what you are trying to do, you need I think to flag the factnI >> that there is a missing file because someone deleted the external fileaI >> which is the message. you have only the sender, subject, date and timep4 >> (and of course a reference to the external file). >>I >> How you process it is a decision only you can take. Ignore the messagelI >> and carry on, or populate the new file with something that states that D >> the content was deleted from the source system before it could beA >> converted. Program modifications required anyhow. Over to you.s > F >Ick! I had hoped to avoid to modify the program. I don't know enoughtC >about MAIL and it's format to know how to chnage it and be sure itE >doesn't do something stupid.t >gC >Is there a way to traverse the MAIL folder and get a list of those H >"missing files"? Then maybe they could be created all at once instead.  >   9 Get vfymail - never used it myself but the readme says :-A   "sG VFYMAIL, UTILITIES, Check for missing or extra MAIL$xxxxxxxx.MAI files.a  : This utility checks a mail directory for extra and missingD MAIL$xxxxxxxxxxxxxxxx.MAI files.  When the 'repair' feature is used,D the utility can move messages that have lost their external file andC rename external files that have lost their message header (for easyl identification).   "s  ) It's available from the Freeware 4.0 CD  t  6 http://h71000.www7.hp.com/freeware/freeware40/vfymail/    P (I thought it was also available from Process' PMDF site along with a number of H other mail and PMDF related programs but I can't seem to find them there	 anymore).o      
 David Webb VMS and Unix team leader CCSS Middlesex University    	 >/andreas    ------------------------------  # Date: Thu, 08 May 2003 08:36:01 GMTp& From: Woland <weiland@no.spam.post.cz>3 Subject: Re: How to determine boot device from DCL? / Message-ID: <CFN37749435572419@news.cup.hp.com>a  8 On Wed, 07 May 2003 17:59:34 +0100 (MET) Phillip Helbig + <HELBPHI@sysdev.deutsche-boerse.com> wrote:a  E >          Auto_action, Boot_dev, Bootdef_dev, Booted_dev, Boot_file,PK >          Booted_file, Boot_osflags, Booted_osflags, Boot_reset, Dump_dev,e= >          Enable_audit, License, Char_set, Language, Tty_devl >    How does it work on a VAX ?    Jirkan   ------------------------------  % Date: Thu, 08 May 2003 21:39:53 -0500b1 From: "David J. Dachtera" <djesys.nospam@fsi.net>C3 Subject: Re: How to determine boot device from DCL? ' Message-ID: <3EBB14F9.148B1A6A@fsi.net>a  
 Woland wrote:o > 9 > On Wed, 07 May 2003 17:59:34 +0100 (MET) Phillip Helbig - > <HELBPHI@sysdev.deutsche-boerse.com> wrote:t > G > >          Auto_action, Boot_dev, Bootdef_dev, Booted_dev, Boot_file, M > >          Booted_file, Boot_osflags, Booted_osflags, Boot_reset, Dump_dev,l? > >          Enable_audit, License, Char_set, Language, Tty_dev1 > >z >  > How does it work on a VAX ?    IIRC, it doesn't.a   -- e David J. Dachteray dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------  $ Date: Thu, 8 May 2003 07:09:26 -04005 From: ab528@freenet.carleton.ca (Heinz W. Wiggeshoff)eQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyg/ Message-ID: <b9ddu0$lb4$1@freenet9.carleton.ca>e  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in messagew' news:87znlyo80q.fsf@prep.synonet.com...eD > What I really want is a 200/556/800 7 track to go with it. WithoutA > having to sweat over valves blowing when a tape has to be read!q  2   Hell, those things can be read by eye using that,   magnetic juice that ancient CEs had.   B-)   ------------------------------  # Date: Thu, 08 May 2003 14:04:27 GMTn4 From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyA8 Message-ID: <9qokbvg28td84vkj4gjsbu81ljc18r936l@4ax.com>  < On Thu, 8 May 2003 07:09:26 -0400 in alt.folklore.computers,6 ab528@freenet.carleton.ca (Heinz W. Wiggeshoff) wrote:   >-: >"Paul Repacholi" <prep@prep.synonet.com> wrote in message( >news:87znlyo80q.fsf@prep.synonet.com...E >> What I really want is a 200/556/800 7 track to go with it. Without B >> having to sweat over valves blowing when a tape has to be read! >m3 >  Hell, those things can be read by eye using that6- >  magnetic juice that ancient CEs had.   B-)f  8 You should be able to read seven track tapes nowadays by= replacing the heads with a hand scanner and a damp sponge fed56 from a VueBits (or whatever it was called) reservoir.   9 Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canadai --  F Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca),     fake address		use address above to reply   ------------------------------  * Date: Thu, 8 May 2003 22:13:30 +0000 (UTC)8 From: hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins)P Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBMmonopoly- Message-ID: <b9ekqa$p6i$4@f04n12.cac.psu.edu>l  G In article <b9di09$h57$2@bob.news.rcn.net>,  <jmfbahciv@aol.com> wrote: / >In article <b9b79f$1clq$2@f04n12.cac.psu.edu>, = >   hawk@slytherin.ds.psu.edu (Dr. Richard E. Hawkins) wrote:   E >>>>Close.  They actually dried out: with no water in the canals, them@ >>>>gondolas left them stranded.  Unlike the other planet, whichL >>>>successfully relocated its citizens to an italian city, they had the ill$ >>>>fortune to choose Atlantis . . .  - >>>But how do you explain the Mars candy bar?   
 >>Mummies.  8 >Now all we have to do is knot this thread together with? >the thread up above (aliens airing spam) and there might even  # >be pretty good scifi story here.  n  H If you can make candy bars from mummies, making spam should be trivial . . .p   hawk -- dK Richard E. Hawkins, Asst. Prof. of Economics    /"\   ASCII ribbon campaigniG dochawk@psu.edu  Smeal 178  (814) 375-4700      \ /   against HTML maillD These opinions will not be those of              X    and postings. 6 Penn State until it pays my retainer.           / \      ------------------------------   Date: 8 May 2003 14:45:58 -0700c. From: spamsink2001@yahoo.com (Alan E. Feldman)+ Subject: Re: INDEX.SYS size and performancec= Message-ID: <b096a4ee.0305081345.754e27f0@posting.google.com>e  g "John Travell" <john@travell.uk.net> wrote in message news:<b9e1i7$ik61s$1@ID-120847.news.dfncis.de>...n= > "Alan E. Feldman" <spamsink2001@yahoo.com> wrote in messagef8 > news:b096a4ee.0305080713.5614776@posting.google.com...9 > > "John Travell" <john@travell.uk.net> wrote in message 4 >  news:<b9d2bo$hh516$1@ID-120847.news.dfncis.de>...@ > > > "Roose Chua" <XNCGULCTLUMA@spammotel.com> wrote in message; > > > news:6273a2.0305072235.66e8dec3@posting.google.com...i [...]sJ > > > > 3. If this is not normal, how then can you "re-size" the index.sysN > > > > file so that it would be within the level of normal range? Preferably,1 > > > > not having the disk to be re-initialized.  > > > >@ > > >s4 > > > I would say 200,000 blocks probably IS normal.N > > > INDEXF.SYS does contain the file header for every file on the disk, plus >  the+ > > > volume bitmap and a few other things.o > >  > >aG > > You mean the index file bitmap. The volume bitmap is in BITMAP.SYS.  > > 5 >  You are of course correct, a slip of the memory.... > >rN > > > There is NO WAY to shrink INDEXF.SYS without re-init'ing the disk with a > > > smaller MAXFILES value.  > >o > > H > > Agreed. But it is /HEADERS that controls the size of INDEXF.SYS. The= > > qualifier /MAXIMUM_FILES controls the size of BITMAP.SYS.t  $ Oops! That second sentence is wrong!   > >eN > /HEADERS sets the initial header count, which is usually the biggest portion > of INDEXF.SYS.K > /MAXIMUM_FILES limits the space reserved in INDEXF.SYS for the index filesL > bitmap, since this cannot grow it sets the limit on how big the index file > can grow to. > N > The size of BITMAP.SYS is defined by the number of clusters on the disk, andB > has nothing to do with the number of files the disk may contain.    3 Oops. You're right. I got the bitmaps confused too!s     > -- > John Travell" > VMS crashdump expertise for hire > john@travell.uk.net  > http://www.travell.uk.net/   Disclaimer: JMHO Alan E. Feldman    ------------------------------  % Date: Thu, 08 May 2003 22:55:44 +0100h+ From: John Laird <john@laird-towers.org.uk>e+ Subject: Re: INDEX.SYS size and performancen8 Message-ID: <efklbv8hh3ett5i0tdj75l6gtms6tmsgre@4ax.com>  G On Thu, 8 May 2003 17:42:16 +0100, "John Travell" <john@travell.uk.net>  wrote:  M >The size of BITMAP.SYS is defined by the number of clusters on the disk, anddA >has nothing to do with the number of files the disk may contain.b  7 Let's see you create more files than clusters, then :-)t  6 [Actually, it can be done quite easily by cheating...]     	John    ------------------------------   Date: 8 May 2003 15:22:34 -0700h. From: spamsink2001@yahoo.com (Alan E. Feldman)+ Subject: Re: INDEX.SYS size and performance = Message-ID: <b096a4ee.0305081422.4af62acd@posting.google.com>8  a brandon@dalsemi.com (John Brandon) wrote in message news:<03050812392444@dscis6-0.dalsemi.com>...eH > > I have been doing some cleanup activities on our nodes and one thingI > > that have caught my attention and just seems to be abnormal to me, isdG > > that some of our disks, ie. RZ28, had their index.sys' file size ate > > more than 200,000 blocks.0 > >m > > My questions are:@E > > 1. Is it normal for index.sys files to have these amount of size? G > > 2. Having this amount of size, would there be significant impact onb( > > the overall disk/system performance?F > > 3. If this is not normal, how then can you "re-size" the index.sysJ > > file so that it would be within the level of normal range? Preferably,- > > not having the disk to be re-initialized.g > O > 1) Normal is as normal does.  Depends on how you initialize your disk drive.  ' > Do you use the /header=x qualifier?    > O > 2) Typically, the larger the size of index.sys the better.  Especially if younN > have thousands or tens of thousands (or more) of files.  This keeps you from% > having to initialize the disk when   >  > Do a HELP INIT /HEADER > C >         The default value for the /HEADERS qualifier is generallytB >         insufficient for ODS-2 disks. To improve performance andB >         avoid SYSTEM-F-HEADERFULL errors, Compaq recommends thatD >         you set this value to be approximately the number of filesC >         that you anticipate having on your disk. However, grosslytE >         overestimating this value will result in wasted disk space.r > " > I set my disks to /header=400000  F I am puzzled as to why this HEADERFULL error is still of such concern.F The algorithm for extending INDEXF.SYS has been greatly improved. This> page contains the improved extension algorithm for INDEXF.SYS:  J  http://ftp1.support.compaq.com/public/vms/vax/v5.5-2/vaxf11x03_070.README  / Here is the algorithm as quoted from that page:u  A  o  Disk space is inefficiently used due to the default extensions?      size of INDEXF.SYS.  The algorithm now tries to extend thesA      file by 15% of MAX_FILES - HEADERS_USED.  It does this until @      the index file has grown to 90% of MAX_FILES.  From then on;      the file is extended in increments of 1% of MAX_FILES.   /      This problem is fixed in OpenVMS VAX V6.0.d  B      CSC NOTE:  This problem may also occur on OpenVMS Alpha V6.1.A                 The AXPF11X02_061 ECO kit will fix the problem on #                 OpenVMS Alpha V6.1.a  E Is this new algorithm not being used anymore? I know that there was a7D bug in an early version of it that I fell victim to once on one diskB at my previous job. Because of this bug this disk's INDEXF.SYS hadB dozens of extents each of which were less than 100 blocks in size!  F I called DEC and they said to apply the fix from a general Y2K ECO kitD and that fixed it. I have not had the HEADERFULL problem since (I am> running VAX systems with VMS v6.1 and v6.2 at my current job.)  # Here is the description of the bug:R  N http://ftp.support.compaq.com.au/pub/patches/Readmes/wnt/vaxy2k01_u2055.README  A PROBLEMS ADDRESSED IN VAXF11X01_U2055 KIT FOR OPENVMS VAX V5.5-2:m   [...]s  C  o  A previous attempt  to  solve  the  problem  of  extending  the.D      INDEXF.SYS  file  has introduced new problems which resulted inD      sometimes  leaving  the  INDEXF.SYS   file   very   fragmented.D      Therefore  a  new simplified algorithm for INDEXF.SYS extending      has been introduced.a  C Anyway, it is because of these ECO's that I would have thought that 5 the dreaded HEADERFULL error was a thing of the past.u  7 > 3) As previously stated, backup, initialize, restore.c >  > John Brandon > VMS Systems Administratord > Dallas Semiconductor > first.last@dalsemi.com > 972.371.4172 wke   Disclaimer: JMHO Alan E. Feldmanv   ------------------------------  % Date: Thu, 08 May 2003 18:04:00 -0500t( From: brandon@dalsemi.com (John Brandon)+ Subject: Re: INDEX.SYS size and performanceo1 Message-ID: <03050818040048@dscis6-0.dalsemi.com>y  O > 2) Typically, the larger the size of index.sys the better.  Especially if youiN > have thousands or tens of thousands (or more) of files.  This keeps you from% > having to initialize the disk when u >  > Do a HELP INIT /HEADER > C >         The default value for the /HEADERS qualifier is generallyuB >         insufficient for ODS-2 disks. To improve performance andB >         avoid SYSTEM-F-HEADERFULL errors, Compaq recommends thatD >         you set this value to be approximately the number of filesC >         that you anticipate having on your disk. However, grosslyeE >         overestimating this value will result in wasted disk space.' > " > I set my disks to /header=400000  O I have run into this problem when I took the defaults for initialize - on oldermJ VAX servers running 5.5-2 and 6.1.  Ever since then I have always used the" /HEADER qualifier quite liberally.  6 The above statement is from HELP on an Alpha V7.2-1h1.  H > I am puzzled as to why this HEADERFULL error is still of such concern.H > The algorithm for extending INDEXF.SYS has been greatly improved. This@ > page contains the improved extension algorithm for INDEXF.SYS: > L >  http://ftp1.support.compaq.com/public/vms/vax/v5.5-2/vaxf11x03_070.README > 1 > Here is the algorithm as quoted from that page:r > C >  o  Disk space is inefficiently used due to the default extensioneA >      size of INDEXF.SYS.  The algorithm now tries to extend thetC >      file by 15% of MAX_FILES - HEADERS_USED.  It does this untilrB >      the index file has grown to 90% of MAX_FILES.  From then on= >      the file is extended in increments of 1% of MAX_FILES.s > 1 >      This problem is fixed in OpenVMS VAX V6.0.m > D >      CSC NOTE:  This problem may also occur on OpenVMS Alpha V6.1.C >                 The AXPF11X02_061 ECO kit will fix the problem on % >                 OpenVMS Alpha V6.1.o > G > Is this new algorithm not being used anymore? I know that there was aaF > bug in an early version of it that I fell victim to once on one diskD > at my previous job. Because of this bug this disk's INDEXF.SYS hadD > dozens of extents each of which were less than 100 blocks in size! > H > I called DEC and they said to apply the fix from a general Y2K ECO kitF > and that fixed it. I have not had the HEADERFULL problem since (I am@ > running VAX systems with VMS v6.1 and v6.2 at my current job.) > % > Here is the description of the bug:9 > P > http://ftp.support.compaq.com.au/pub/patches/Readmes/wnt/vaxy2k01_u2055.README > C > PROBLEMS ADDRESSED IN VAXF11X01_U2055 KIT FOR OPENVMS VAX V5.5-2:  >  > [...]n > E >  o  A previous attempt  to  solve  the  problem  of  extending  theIF >      INDEXF.SYS  file  has introduced new problems which resulted inF >      sometimes  leaving  the  INDEXF.SYS   file   very   fragmented.F >      Therefore  a  new simplified algorithm for INDEXF.SYS extending >      has been introduced.  > E > Anyway, it is because of these ECO's that I would have thought thate7 > the dreaded HEADERFULL error was a thing of the past.n  K There is still a suport document for this, below is a brief of the problem:e  : *TITLE: [OpenVMS] Explanation Of SYSTEM-F-HEADERFULL Error *eG *Copyright (c) Digital Equipment Corporation 1994. All rights reserved.r *h$ *PRODUCT:   OpenVMS VAX All Versions$ *           OpenVMS AXP All Versions * 
 *QUESTION: *,5 *Why does the creation of a file result in the error:- *-/ *     %SYSTEM-F-HEADERFULL, file header is full0 *  *m *ANSWER: *sG *Normally when an extend operation is executed on a file and the header F *for the file has no more room for retrieval pointers, the file system* *creates an extension header for the file. *tC *However, the file system has an option to prohibit the creation ofiG *extension file headers.  This is utilized for several system files andf= *is available for use by application programmers.  Under thisMF *condition, if there is not enough space in the file header to map allG *the new extents that are gathered as a result of the extend operation,t% *the extend will fail with the error:a *i/ *     %SYSTEM-F-HEADERFULL, file header is fulln *iC *Most often this error is caused by the failure to extend the indexaF *file for the volume, INDEXF.SYS.  By design, INDEXF.SYS is restrictedC *to 1 file header.  When this single file header is full, the errorc; *occurs and no new files can be created on the disk volume.g * D *NOTE:  The error may also be produced when using the SYSGEN UtilityE *       to extend pagefiles or swapfiles, or by any application whichnG *       sets the FIB$M_NOHDREXT bit in the File Information Block (FIB)mF *       field, FIB$W_EXCTL, for an ACP-QIO file extend operation.  ForF *       more information on using the ACP-QIO extend operation, please1 *       refer to either of the following manuals:i  N And it does say that it is for both VAX and AXP all versions - so I would haveN to assume that your statement of the problem is a different problem entirely - with the same results.   John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wkn   ------------------------------   Date: 8 May 2003 08:13:28 -0700m. From: spamsink2001@yahoo.com (Alan E. Feldman)+ Subject: Re: INDEX.SYS size and performance < Message-ID: <b096a4ee.0305080713.5614776@posting.google.com>  g "John Travell" <john@travell.uk.net> wrote in message news:<b9d2bo$hh516$1@ID-120847.news.dfncis.de>... < > "Roose Chua" <XNCGULCTLUMA@spammotel.com> wrote in message7 > news:6273a2.0305072235.66e8dec3@posting.google.com...o > > Hi,f > >oH > > I have been doing some cleanup activities on our nodes and one thingI > > that have caught my attention and just seems to be abnormal to me, is-G > > that some of our disks, ie. RZ28, had their index.sys' file size ata > > more than 200,000 blocks.c > >: > > My questions are:sE > > 1. Is it normal for index.sys files to have these amount of size?>    B If you at one point had approx. 200,000 file headers on that disk,6 yes. If you initialized the volume with something likeE /HEADERS=200000, yes. I don't know any other way to get an index filet> that large. Note that INDEXF.SYS only grows; it never shrinks.    G > > 2. Having this amount of size, would there be significant impact on ( > > the overall disk/system performance?    / No. But if it is severely fragmented, yes. Run p  5     $ DUMP disk:[000000]INDEXF.SYS/BLOCK=COUNT=0/HEADs  E and look at Map area Retrieval pointers. If there are dozens of them, F it is very fragmented and you might benefit from "repacking" the disk.E To "repack" the disk you would need to use BACKUP/IMAGE to copy it tos4 tape and back to disk or to copy it to another disk.    F > > 3. If this is not normal, how then can you "re-size" the index.sysJ > > file so that it would be within the level of normal range? Preferably,- > > not having the disk to be re-initialized.  > >b > 0 > I would say 200,000 blocks probably IS normal.N > INDEXF.SYS does contain the file header for every file on the disk, plus the' > volume bitmap and a few other things.i    D You mean the index file bitmap. The volume bitmap is in BITMAP.SYS.     J > There is NO WAY to shrink INDEXF.SYS without re-init'ing the disk with a > smaller MAXFILES value.o    D Agreed. But it is /HEADERS that controls the size of INDEXF.SYS. The9 qualifier /MAXIMUM_FILES controls the size of BITMAP.SYS.a     Disclaimer: JMHO Alan E. Feldmanm   ------------------------------   Date: 8 May 2003 12:11:12 -0500t From: briggs@encompasserve.org+ Subject: Re: INDEX.SYS size and performance 3 Message-ID: <gFTyh$jm$T4P@eisner.encompasserve.org>o  b In article <b9d2bo$hh516$1@ID-120847.news.dfncis.de>, "John Travell" <john@travell.uk.net> writes: > < > "Roose Chua" <XNCGULCTLUMA@spammotel.com> wrote in message7 > news:6273a2.0305072235.66e8dec3@posting.google.com...d >> Hi, >>G >> I have been doing some cleanup activities on our nodes and one thingmH >> that have caught my attention and just seems to be abnormal to me, isF >> that some of our disks, ie. RZ28, had their index.sys' file size at >> more than 200,000 blocks. >> >> My questions are:D >> 1. Is it normal for index.sys files to have these amount of size?F >> 2. Having this amount of size, would there be significant impact on' >> the overall disk/system performance?aE >> 3. If this is not normal, how then can you "re-size" the index.systI >> file so that it would be within the level of normal range? Preferably,p, >> not having the disk to be re-initialized. >> > 0 > I would say 200,000 blocks probably IS normal.N > INDEXF.SYS does contain the file header for every file on the disk, plus the' > volume bitmap and a few other things. J > There is NO WAY to shrink INDEXF.SYS without re-init'ing the disk with a > smaller MAXFILES value.   C Agreed.  It is probably normal.  And aside from wasted space, there1@ is essentially no performance impact.  In fact, one might expectI _very_ slightly better performance from the sparsely populated index file1I bitmap on a large index file (if the index file bitmap is correspondingly C large) than from a densely populated bitmap on a smaller index filetB (if the index file bitmap is correspondingly small).  The sparsityB of the actual file headers is irrelevant since those aren't cached in multi-header chunks.h  G If you were to re-init the disk, /HEADERS is controls the pre-allocateds0 size of INDEX.SYS only.  It defaults very small.  @ /MAXIMUM_FILES is an upper limit on the size to which INDEXF.SYS< could be extended later.  In implementation terms, it is the3 statically allocated size of the index file bitmap.    	John Briggs   ------------------------------  % Date: Thu, 08 May 2003 14:13:33 -0400w* From: JF Mezei <jfmezei.spamnot@istop.com>+ Subject: Re: INDEX.SYS size and performancei) Message-ID: <3EBA9E4B.18505FF3@istop.com>s  N I gave my vax one of those highly advertised pills, and its indexf.sys grew by 3 "l   ------------------------------  % Date: Thu, 08 May 2003 21:48:49 -0500x1 From: "David J. Dachtera" <djesys.nospam@fsi.net>g+ Subject: Re: INDEX.SYS size and performance ' Message-ID: <3EBB1711.1A5C8F9B@fsi.net>s   John Laird wrote:L > I > On Thu, 8 May 2003 17:42:16 +0100, "John Travell" <john@travell.uk.net>e > wrote: > O > >The size of BITMAP.SYS is defined by the number of clusters on the disk, andiC > >has nothing to do with the number of files the disk may contain.l > 9 > Let's see you create more files than clusters, then :-)L > 8 > [Actually, it can be done quite easily by cheating...]   No need to cheat, really...x   $ ON WARNING THEN EXIT $TAG:f9 $ FNAM = F$CVTIME(,,) - "-" - "-" - " " - ":" - ":" - "."l $ COPY NLA0: 'FNAM'.NULd $ WAIT 00:00:00.01
 $ GOTO TAG  C ...will eventually exhaust /MAXFILES while leaving freespace almostSE untouched (except for the space allocated to the directory containingT the files created).e   -- f David J. Dachterae dba DJE Systemsy http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Thu, 08 May 2003 21:55:35 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>1+ Subject: Re: INDEX.SYS size and performancei' Message-ID: <3EBB18A7.40F37C0D@fsi.net>9   "Alan E. Feldman" wrote: > [snip]H > I am puzzled as to why this HEADERFULL error is still of such concern.  @ As more and more VMS systems are left unattended due to SysAdmin9 layoffs, defections to other o.s.-es, etc., even the mosti9 well-intentioned plan-ahead will eventually get thwarted.A  C That, and since many mission critical app.'s have been abandoned by.H their former vendors, ODS-2 will continue to rule some sites until those VMS systems vanish forever.i  $ Now I know how a cemetarian feels...   -- r David J. Dachterat dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/0   ------------------------------   Date: 8 May 2003 13:55:14 -07000* From: ashoffman@comcast.net (Alan Hoffman)( Subject: Re: Java "Unknown host" problem= Message-ID: <838d7cb0.0305081255.2e4f3eca@posting.google.com>0  b lewis@PROBE.mitre.org (Keith A. Lewis) wrote in message news:<b994av$nbe$1@newslocal.mitre.org>... > ashoffman@comcast.net (Alan Hoffman) writes in article <838d7cb0.0305060756.51f21008@posting.google.com> dated 6 May 2003 08:56:25 -0700:iG > >I'm using Java 1.4.0-1 on OpenVMS 7.3-1. When I start my applicationiB > >there is about a 2 minute time where nothing happens, after theF > >timeout the message "Unknown host: WSA1" shows up on the screen andF > >then my application starts and runs fine. Can anyone tell me how toF > >eliminate the 2 minute timeout and the "Unknown host" message? I'veI > >just started using OpenVMS so I'm not very familiar with how it works.s' > >My application does simple file I/O.A > F > My demo app starts out by saying "Unknown host: _WSA64" (WSA64 is myM > Decwindows display device) and then runs.  The delay is only about 10 secs, 
 > though.  > L > If I bypass the WSA device with "DEF DECW$DISPLAY my-xterm:0.0", I get the5 > same amount of delay but no "Unknown host" message.- > N > How's your nameserver configuration?  Try "TCPIP SHOW HOST WSA1" and see howA > long that takes.  (I'm assuming you use Compaq's tcp/ip stack.)   E     I ran the command and the timeout was 2 minutes (the same as whenu; I run Java). How do you check the nameserver configuration?:   > J > Some commands which may be enlightening if you don't know what a WSA is: >  >     $ show log decw$displayo >     $ show dev wsa1  >     $ show display wsa1l! >     $ show display wsa1 /symbol   E     These all show WSA1 as a device that is local (which I understand>F is what it should be). What I don't understand is why Java is treatingE WSA1 as a host (Unknown host: WSA1) instead of a device (are they the E same thing??) and how to get rid of the message all together (and not.F just mask it). I would also like to find out how to set the timeout soF that it is more like your 10 seconds instead of 2 minutes (as timed byE a watch) so I'm not wasting so much time while I'm debugging my code. E     There was an older version of Java on the machine (1.1.8 I think)fA that didn't produce the Unknown host problem on the same machine.        Thanks, 
          Alans   ------------------------------  % Date: Thu, 08 May 2003 11:02:25 -0700o+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>rD Subject: Re: MicroVAX and VAX models EOSL list (end of service life)' Message-ID: <3EBA9BB1.6060501@MMaz.com>    Rich Jordan wrote:  E >An HP representative was able to give me a list of the MicroVAX 3100 C >and VAX 4000 systems that are scheduled for EOSL at the end of the0G >year.  This means those systems will not be coverable under a hardwares, >support contract after the retirement date. >s >MV3100-85,90,95,96   >VAX4000-100,100A,105A,106A,705A >sF >We have some very unhappy customers as a result of this; they've beenF >paying good money for support on top of hefty dollars on the originalA >purchases, and do not like the direction HP is taking with thesei@ >really not _that_ old systems, given the history of longer term >support in the past...s >o >  o >o  J Ouch, well looks like a good opportunity for SRI's Charon-VAX to step in.   B Ironic, in the context of JF's posting about OS's being great but = without the apps, the OS doesn't really mean anything (major  E paraphrase)...  I have to believe that most of these VAX folks, like eG myself, are still running them not because they have a passionate love eG for the VAX architecture, or can't get enough of Macro-32, but because h the apps are there...   I No apps, no need for VMS, therefore no need for Alpha or Itanium 2's (at >E least from HP)...  It will be very interesting to see what computing nA will be like in 10 years, I just hope I'm retired before then :-))   Barry>   --    @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028e   ------------------------------   Date: 8 May 2003 15:01:37 -0700>& From: jordan@ccs4vms.com (Rich Jordan)D Subject: Re: MicroVAX and VAX models EOSL list (end of service life)= Message-ID: <cc5619f2.0305081401.33bc38f8@posting.google.com>o  Z "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message news:<3EBA9BB1.6060501@MMaz.com>... > D > Ironic, in the context of JF's posting about OS's being great but ? > without the apps, the OS doesn't really mean anything (major sG > paraphrase)...  I have to believe that most of these VAX folks, like eI > myself, are still running them not because they have a passionate love rI > for the VAX architecture, or can't get enough of Macro-32, but because u > the apps are there...  > .....h > Barryi  ? How about customers who have been using VAXen for 20 years, who D amassed a considerable number of multiyear uptimes between scheduledF downs for upgrades and the like, who have the apps customized just the@ way they want them for their specific business, and who have hadD experience with other platforms and solutions (including wintel) andA are frankly quite happy to be running, and risking their businesso; critical information, on a platform they have come to trust  absolutely.!  D Three of these customers were burned in the past by attempts to move? to either a *nix platform of the week, or to a wintel networked D environment; in the wintel case they lost data (or would have if theB VMS system wasn't running in parallel).  They made the decision toD stay where they were with equipment they trusted.  Unfortunately you> don't bet your business on hardware you may not be able to get) repaired or replaced in a timely fashion.$  B All the apps have source.  Moving to Alpha would be an afternoon'sD work.  It just wasn't necessary until the service rug got pulled outD from under them, and if you haven't priced new Alpha systems (with aB warranty) lately, given the string of price increases, the payback1 time on maintenance savings is not exactly short.-   Rich   ------------------------------  % Date: Thu, 08 May 2003 14:07:26 -0400x* From: JF Mezei <jfmezei.spamnot@istop.com>D Subject: Re: MicroVAX and VAX models EOSL list (end of service life)) Message-ID: <3EBA9CDB.C893051B@istop.com>o   Rich Jordan wrote: > F > An HP representative was able to give me a list of the MicroVAX 3100D > and VAX 4000 systems that are scheduled for EOSL at the end of the > year.  > MV3100-85,90,95,96! > VAX4000-100,100A,105A,106A,705Av    J Interesting that openvms.org is running a survey of vax users at about theE same time they are preparing to end support for some of the machines.c   ------------------------------  % Date: Thu, 08 May 2003 19:29:41 -0400f* From: JF Mezei <jfmezei.spamnot@istop.com>D Subject: Re: MicroVAX and VAX models EOSL list (end of service life)) Message-ID: <3EBAE84F.8F774563@istop.com>   N Sort of strange to pull the plug on some VAX support at this juncture in time.I If IA64 is to become a reality for customers in a year, shouldn't HP havebM waited until IA64 was a reality before starting to pull the plug on old VAXes J so that those customers not leaving HP/VMS could move directly from VAX to that IA64 thing ?e   ------------------------------  % Date: Thu, 08 May 2003 22:10:22 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> D Subject: Re: MicroVAX and VAX models EOSL list (end of service life)' Message-ID: <3EBB1C1E.625B1BD8@fsi.net>t   JF Mezei wrote:c > P > Sort of strange to pull the plug on some VAX support at this juncture in time.K > If IA64 is to become a reality for customers in a year, shouldn't HP have O > waited until IA64 was a reality before starting to pull the plug on old VAXessL > so that those customers not leaving HP/VMS could move directly from VAX to > that IA64 thing ?g  C I64 should have been a reality before the Alphacide, much less thise latest insanity.  H Spilt milk, I realize, but it just goes to underscore the endless streamG of unfailingly astounding stupity we can expect from once-great HP, nowt+ reduced to just another Bill Gates stooge. t  E Why don't we just crown him King, appoint petro-lobby-puppet Bush hist8 Prime Minister and be done with it - stop the hypocrisy.   -- " David J. Dachterao dba DJE Systemsl http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/U   ------------------------------  % Date: Thu, 08 May 2003 11:57:41 +0100i+ From: Rok Vidmar <Rok.Vidmar@NUK.Uni-Lj.Si>i( Subject: Re: Migrate email to VMS server& Message-ID: <3eba4636$1@NUK.Uni-Lj.Si>   Jonathan Boswell wrote:hR > Has anybody figured out how to import SMTP mail, headers and all, into VMS mail?2 > I'm running V7.2-2 and TCPIP Services V5.3 ECO1.     Get MX042.ZIP.8   Install Base MX software, Site-provided interface, and Documentation only. ?   Configure LOCAL paths, take care of long lines; SMTP stuff ist< irrelevant in your case, so you really don't need NEDLIB. No= need to configure SITE Transport Interface either as you willn be using SITE Message Entry.?   Startup MX - in this configuration it will not interfere with-
 TCPIP's SMTP.0@   The documentation is excellent: use MX_PROG_GUIDE to figure it8 out how to use SITE Message Entry - it's trivial in DCL.B   How much would it take? For me minutes, for you hours, not days.   -- Regards,  D Rok Vidmar                       Internet:  rok.vidmar@nuk.uni-lj.si; National and University Library  Phone:     +386 1 421 5461_; Turjaska 1, SI-1000 Ljubljana    Fax:       +386 1 421 5464  Slovenia   ------------------------------  % Date: Thu, 08 May 2003 22:24:33 -0500l1 From: "David J. Dachtera" <djesys.nospam@fsi.net>-/ Subject: Re: Not entirely OT: RSHELL to Solaris ' Message-ID: <3EBB1F71.85C0781C@fsi.net>h   "David J. Dachtera" wrote: >  > Dave Greenwood wrote:n
 > > [snip]A > > I don't have access to a Solaris system, but the man file foro? > > /etc/hosts.equiv on a T64 system implies that an entry likei > >  > >   vms.system.adr + > >sJ > > will give *any* user on vms.system.adr access to the T64 system.  Then > > I'd expect a command likeB > >_9 > >   $ rshell /user=Solaris_user_name Solaris.system.adr  > > K > > to provide password-less access to the Solaris system.  I've not testedo > > this, however. > ; > I'll try it tomorrow and post my results later this week.t  5 Great news! It works on Solaris-8/SPARC! Great stuff!n  5 Functionality is similar to this in the DECnet world:-   proxy: node_name::* *    --   David J. Dachtera0 dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/s   ------------------------------  $ Date: Thu, 8 May 2003 20:59:21 +0200' From: "Seghers Bruno" <tips@euronet.be>oA Subject: Problem to localy logon on a Pathworks 6.1 domain membere4 Message-ID: <b9e99q$1d6cb$1@sinclair.be.wanadoo.com>   Hi,.  9 I have installed pathworks 6.1 on a openVMS 7.2-2 system.aJ I configure it as a member of a resources Windowt NT domain A trusted by a Windows NT domain BnL During installation, Pathworks ask me a password for the local Administrator account.  G The server pathworks is up and running, I see from domain B the defaults3 shares created by pathworks (USERS PWUTIL, etc ...)M  E My problem is that when I try to manage my Patworks server (add usersnE localy, add share with security permissions, etc ...) with ADMINISTERe4 commands, the server says : "your are not Logged on"
 I try to do :p   $ADMINISTERt& domainA\\Myserver> LOGON Administrator4 password : 'the one I introduce during installation'  2 You are logged on but not authantified by a server9 You will not have permissions..... or something like thatm  3 Of course, I'm sure of the validity of the password   J Does anybody can explain me how can I locally logon with the administratorF account on the pathworks server. I am not admin of the domain, but I'mJ responsible for giving access to dedicated user on dedicated shares on the pathworks server.r   Thanks a lot for your help   Regardsi  
 Seghers Brunol Belgiumm   ------------------------------  # Date: Fri, 09 May 2003 03:29:29 GMT ! From: rob.buxton@wcc.spam.govt.nz-E Subject: Re: Problem to localy logon on a Pathworks 6.1 domain memberm% Message-ID: <3ebb1fa0.199397238@news>d  D On Thu, 8 May 2003 20:59:21 +0200, "Seghers Bruno" <tips@euronet.be> wrote:  B When you install Pathworks it needs an Account and Password on theE domain, sufficient to be able to add itself in. I believe the accountI= used needs Domain Admin privs. It's not a local administratorr	 password.d  7 So, when you then logon you're logging onto the Domain.a  ' Note also passwords are case sensitive.   E Finally, Pathworks can lose the plot with the NT Domain and Pathworks> needs to be restarted.  9 But, your account and password needs to be in the domain.n   Rob. >Hi, >t: >I have installed pathworks 6.1 on a openVMS 7.2-2 system.K >I configure it as a member of a resources Windowt NT domain A trusted by ae >Windows NT domain BM >During installation, Pathworks ask me a password for the local Administrator 	 >account.m > H >The server pathworks is up and running, I see from domain B the default4 >shares created by pathworks (USERS PWUTIL, etc ...) > F >My problem is that when I try to manage my Patworks server (add usersF >localy, add share with security permissions, etc ...) with ADMINISTER5 >commands, the server says : "your are not Logged on"a >I try to do : >  >$ADMINISTER' >domainA\\Myserver> LOGON Administrator35 >password : 'the one I introduce during installation'  >d3 >You are logged on but not authantified by a servere: >You will not have permissions..... or something like that > 4 >Of course, I'm sure of the validity of the password >sK >Does anybody can explain me how can I locally logon with the administrator2G >account on the pathworks server. I am not admin of the domain, but I'miK >responsible for giving access to dedicated user on dedicated shares on the  >pathworks server. >@ >Thanks a lot for your help  >  >Regards >" >Seghers Bruno >Belgium >  >t   ------------------------------  $ Date: Fri, 9 May 2003 07:30:46 +0200' From: "Seghers Bruno" <tips@euronet.be>lE Subject: Re: Problem to localy logon on a Pathworks 6.1 domain memberl4 Message-ID: <b9fe9m$159pu$1@sinclair.be.wanadoo.com>  K The NT administrator add my pathworks in the domain, thus I have no idea ofl the domain Admin password.  I I just want to be local Administrator (Admin account located in the local ! SAM file) of the pathworks servere  I The local administrator password is a question asked at the first time ofm8 the config when you change the domain name and the role.   Thanks for your help  
 Seghers Bruno. Belgium . <rob.buxton@wcc.spam.govt.nz> wrote in message news:3ebb1fa0.199397238@news... F > On Thu, 8 May 2003 20:59:21 +0200, "Seghers Bruno" <tips@euronet.be> > wrote: >sD > When you install Pathworks it needs an Account and Password on theG > domain, sufficient to be able to add itself in. I believe the account ? > used needs Domain Admin privs. It's not a local administratore > password.  >I9 > So, when you then logon you're logging onto the Domain.N >F) > Note also passwords are case sensitive.h >cG > Finally, Pathworks can lose the plot with the NT Domain and Pathworks  > needs to be restarted. > ; > But, your account and password needs to be in the domain.h >  > Rob. > >Hi, > > < > >I have installed pathworks 6.1 on a openVMS 7.2-2 system.K > >I configure it as a member of a resources Windowt NT domain A trusted bys ao > >Windows NT domain BA > >During installation, Pathworks ask me a password for the locale
 Administrator- > >account.- > >-J > >The server pathworks is up and running, I see from domain B the default6 > >shares created by pathworks (USERS PWUTIL, etc ...) > >nH > >My problem is that when I try to manage my Patworks server (add usersH > >localy, add share with security permissions, etc ...) with ADMINISTER7 > >commands, the server says : "your are not Logged on"s > >I try to do : > >s > >$ADMINISTER) > >domainA\\Myserver> LOGON Administratorn7 > >password : 'the one I introduce during installation'  > > 5 > >You are logged on but not authantified by a server]< > >You will not have permissions..... or something like that > >16 > >Of course, I'm sure of the validity of the password > >)? > >Does anybody can explain me how can I locally logon with thea
 administrator4I > >account on the pathworks server. I am not admin of the domain, but I'm I > >responsible for giving access to dedicated user on dedicated shares onn thee > >pathworks server. > >n > >Thanks a lot for your helpv > >g
 > >Regards > >n > >Seghers Bruno
 > >Belgium > >i > >  >h   ------------------------------  % Date: Thu, 08 May 2003 22:01:36 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net>@- Subject: Re: Problem with Openvms 7.2 hobbystv' Message-ID: <3EBB1A10.8996BB55@fsi.net>h   Leiv wrote:z > L > I just downloaded OpenVMS VAX 7.2 hobbyist.img image file (twice) , then I= > tried to boot with SIMH , then I ge t the following error :i > [snip] >   2..s > -DUA3  > ?43 FILESTRUCT, DUA3  H Well, not sure where you "downloaded" the disk image from, or how it wasD created. The easiest way to create a disk image is to do it on a VMS machine:   $ MOUNT/FOREIGN ddcu:e $ COPY ddcu: DISK.IMG    ...or a UN*X machine using dd.  F Assuming the disk image itself is not corrupted, make sure to transfer$ it as binary to the target location.   -- e David J. Dachterai dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/i   ------------------------------  % Date: Thu, 08 May 2003 00:01:14 -0400m( From: David Froble <davef@tsoft-inc.com>A Subject: Re: Problems changing from serial port to DecServer port , Message-ID: <3EB9D68A.6040904@tsoft-inc.com>   JF Mezei wrote:t   > brandon@dalsemi.com wrote: > P >>That is the function of REMOTE.  Use LOCAL when you have an interactive deviceN >>attached to the port, i.e. VT340.  Use REMOTE when you have a printer deviceQ >>attached to the port.  If you attach a VT340 to a REMOTE port you you will onlyl >>be able to send to the port. >> > L > Are you sure ? I was under the impression that REMOTE, LOCAL etc pertained5 > only to call establishement and not data transfer ?     M I agree.  Once the connection is made, the device on the terminal server can   send over the connection.      Dave     -- .4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------   Date: 8 May 2003 13:11:28 -0700C$ From: tkb@tkb.mpl.com (T. Kurt Bond)@ Subject: Redimensioning formal parameter arrays in OpenVMS BASIC= Message-ID: <a3db6b24.0305081211.6f867ad0@posting.google.com>   F The BASIC for OpenVMS Reference Manual says, in the fifth item of the  Remarks section:  L     The executable DIM statement cannot be used to dimension virtual arrays,L     arrays received as formal parameters, or arrays declared in COMMON, MAP,$     or nonexecutable DIM statements.  E     http://h71000.www7.hp.com/doc/73final/cobol/bas_ref_013.htm#noisnt  D The "no formal parameters" rule is inconvienent.  It means that you G can't pass an array to a function, redimension it, fill it with values,iF and then use LBOUND and UBOUND in the caller to find out its new size.  D Presumably it is illegal because there is no way at compile time to F know if the function will be called with a dynamic array created with > the executable DIM statement or a static array created with a  non-executable DIM statement.r  = However, the programmer *can* know, so it ought to be safe toy@ redimension the array directly when the programmer knows it was ) created by an executable DIM statement.  d  @ Using Alpha BASIC V1.4-000 under OpenVMS V7.2 and looking at the? listing of some code with some executable dimension statements  C compiled with /LIST/MACHINE revealed the existance of DBASIC$RT_DIMB> and after a little experimentation lead to a program that usedD DBASIC$RT_DIM directly to redimension dynamically dimensioned arrays in functions, included below.-  C DBASIC$RT_DIM is not documented for users (probably by design) and aD could *theoretically* lead to flying monkeys and access violations, ? and is probably bad style.  However, are there any *practical* c5 reasons why this wouldn't work safely?  Are there anye4 conditions under which this hack would fail to work?   Here is an example program:        program redim 3 	option type = explicit, constant type = integer, &D, 	    size = integer long, size = real double  ) 	external sub redim_in_sub (string dim())u5 	external long function my_redim (string dim(), long)    	declare long i, r   	i = 10 F 	dim string vs(i) ! has to be a variable to make it an executable dim.   	r = my_redim (vs(), 30)  	print "ubound(vs):"; ubound(vs)H 	for i = lbound(vs) to ubound(vs) \ vs(i) = "vs 30-" + num1$(i) \ next i 	gosub print_vss   	call redim_in_sub (vs())   	print "ubound(vs):"; ubound(vs) 	gosub print_Vsp  
 	exit programk  
     print_vs: A 	for i = lbound(vs) to ubound(vs) \ print i; ": "; vs(i) \ next in 	return ! from print_vsd       end program ! redimt  4     function long my_redim (long s by value, long n)3 	option type = explicit, constant type = integer, &R, 	    size = integer long, size = real double 	declare long rdH 	external long function dbasic$rt_dim (long by value, long by value)     	r = dbasic$rt_dim (s, n)I     end function r ! my_redims  !     sub redim_in_sub (string s())-3 	option type = explicit, constant type = integer, &s, 	    size = integer long, size = real double0 	external sub set_strings (string dim(), string) 	declare long if 	call my_redim (s(), 40)= 	for i = 0 to 40 \ s(i) = "redim in sub " + num1$(i) \ next iE     end sub ! redim_in_sub    E (Interestingly, a slightly different approach was necessary using VAX 7 BASIC V3.5 under VMS V5.5-2: using BY VALUE in functionSB definition statements is not allowed by this version of VAX BASIC,C and BAS$RT_DIM had to be used instead of DBASIC$RT_DIM, of course.)    --   T. Kurt Bond, tkb@tkb.mpl.com    ------------------------------  $ Date: Thu, 8 May 2003 20:13:38 +0100G From: "systematipltoddemontodcotoduk" <system@ipldot.demondot.codot.uk>u0 Subject: Re: Second SCSI adapter fro PSW/AU - UK4 Message-ID: <b9eaa9$m2l$1$830fa17d@news.demon.co.uk>   Chris,  I For second user kit in the UK, I tend to use Abacus Computing, based nearbH Reading.  I'm not linked to the company in any way, I'm just a satisfied- customer of several (about 7) years standing.   # Their phone number is 0118 940 3111    Steven     -- Steve Reece.  4 Systems Consultancy, Training and Project Management    C "Chris Townley" <news@townleyc.nospam.demon.co.uk> wrote in messageh2 news:h4ddbv4urojtgmd52eedpvcrk6oc83kja7@4ax.com.../ > On Mon, 05 May 2003 12:33:51 -0500, Bob Blunt % > <robert.blunt@hp.nospam.com> wrote:v >s > >Chris Townley wrote: K > >> I want to add a second  SCSI adapter to my home PSW 433 AU in order tobJ > >> use a BA356 shelf. This should be fast, rather than ultra, as it is a > >> beige shelf.  > >>: > >> Currently have "device type Qlogic ISP1020 SCSI port" > >>I > >> Is this the best to get, and if so where can I get one at a sensiblea > >> price in the UK?t > >> > >> TIAI > >Chris, first questions:  Does your BA356 have a personality module andoH > >what type drives are installed in the shelf?  This can determine what > >controller you need to find.E > > K > >Second question:  What/how do you want to use that shelf?  Do you simply J > >want JBOD access?  Depending on the type personality module and drives,K > >you may be able to get by with a KZPAA-AA (if you want inexpensive).  If-K > >you want more "modern," look for a DS-KZPBA-CA or KZPDA-AA.  All are PCI F > >to Single-ended NON-RAID variants with a single channel.  If you'reH > >short on slots, look for a KZPCM-DA which is a combo board with threeD > >channels and one Ethernet (be CAREFUL, the KZPCM comes in NON-VMSH > >versions that will NOT work on a VMS system, you need the DS-KZPCM-DA > >specifically).r > >rJ > >If you want RAID, there are also a handful of bus adapters for the PCI,H > >depending on how many channels you want, etc.  A single channel RAID,J > >PCI adapter is the KZPAC-AA and this is one of the older models.  ThereK > >are several other RAID controllers with support for more modern giblets, I > >but you might be stretching it a bit to use them with the older shelf.o> > >For the older shelves, I'd probably stick with the KZPAC... > >EG > >Let us know more about the setup of the BA356 because you may end up 2 > >with the wrong adapter if we just stab at it... > >  > >bob > G > I have the beige shelves - ie non Ultra, and have both a narrow and aN> > fast personality module - the latter is labelled CT60801228.H > I have a collection of 4 and 9 Gb Ultra wide drives (blue cases) and IA > simply want to add more storage for a single machine - the PSW.xH > Although I dont want to spend loads, I would like to go for fast wide,% > which I think this lot can support.t > 1 > I had not considered RAID, mostly due to price.i >s >r > -- > Chris Townleye+ > chris at townleyc dot demon dot co dot uk    ------------------------------  $ Date: Thu, 8 May 2003 08:39:22 +0300- From: "Esa Laitinen" <punkki@suespammers.org>a$ Subject: Re: Spamfilter for OpenVMS?1 Message-ID: <b9cqic$avd$1@phys-news1.kolumbus.fi>-  A "Keith Parris" <keithparris_NOSPAM@yahoo.com> kirjoitti viestissy7 news:cf15391e.0305071739.3ec20dd9@posting.google.com...n@ > gartmann@immunbio.mpg.de (Christoph Gartmann) wrote in message, news:<b9bmjp$p29$3@n.ruf.uni-freiburg.de>...3 > > is there any spam filter running under OpenVMS?n >.G > Sophos Anti-Virus runs under OpenVMS.  See http://www.sophos.com/ andaL > specifically http://www.sophos.com/products/software/antivirus/savvms.html  L I fail to see how Sophos Antivirus could be classified as spam filter. It is) what the name says, an antivirus product.t  D MX (see http://www.madgoat.com/ ) contains some spam filtering stuff5 (heuristics, rbl and ability to add filtering rules).s  K Also, there apparently has been some success in getting spamassassin to runv) in OpenVMS (search google for specifics).    esaa     --E The suespammers.org mail server is located in California; do not sende> unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org addressl   ------------------------------  % Date: Thu, 08 May 2003 05:18:30 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: Spamfilter for OpenVMS?) Message-ID: <3EBA20A8.5DFD6F3D@istop.com>f   Christoph Gartmann wrote:e1 > is there any spam filter running under OpenVMS?K  J With TCP Services 5.1 and 5.3, there are spam protection features with theM SMTP server. Perhaps not the most elaborate compared to others, but there ares" some. (including support for RBLs)   ------------------------------  % Date: Thu, 08 May 2003 08:12:07 -0500 - From: Hunter Goatley <goathunter@goatley.com>m$ Subject: Re: Spamfilter for OpenVMS?; Message-ID: <rBsua.44972$Pv6.34409@fe05.atl2.webusenet.com>a   Bob Ceculski wrote:  > 9 > when are you going to improve spam filtering beyond thel@ > subject level in TCPware smtp plus have antivrus fuctionality?8 > Same for Multinet and UCX ... we shouldn't have to buy& > another smtp stack (PMDF) to get it!  : There are lots of reasons to consider PMDF in any case....  = If you'd like to see our anti-spam product work with MultiNet-= and TCPware (and TCP/IP Services), then drop a line to Laurend: Maschio <maschio@process.com> and let her know.  The first> release will run with PMDF; support for the others will depend on customer interest.l   Thanks.a   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/m9 goathunter@goatley.com     http://www.goatley.com/hunter/    ------------------------------  % Date: Thu, 08 May 2003 21:41:19 -0500t1 From: "David J. Dachtera" <djesys.nospam@fsi.net>h$ Subject: Re: Spamfilter for OpenVMS?' Message-ID: <3EBB154F.1C7CE2E4@fsi.net>m   Brian Tillman wrote: > 3 > >The first release will run on OpenVMS with PMDF.. > M > Does this mean that PMDF will be a requirement?  Why not have a stand-aloneh
 > product?  B I guess that about takes care of the customer interest question...   -- o David J. Dachtera. dba DJE Systemsi http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------  # Date: Thu, 08 May 2003 18:23:58 GMTo# From: "John Smith" <a@nonymous.com>p6 Subject: Re: Synch-on-Green LCD monitor for VaxstationI Message-ID: <2hxua.142013$kYH.89059@news01.bloor.is.net.cable.rogers.com>o   Andy,w  D I have not purchased one of those LCD panels yet but before I do I'mA going to download/read the manual for the various models and callpB Samsung pre-sales tech support if there's even the slightest doubtF that it'll work. I'd buy from a place like Costco or other vendor that# had a 'no questions' refund policy.S  F I have a BNC->VGA adapter from Mitsubishi called FA-1. Mitsubishi soldF this with some of their 15" CRT's ages ago. This was used in a tradingD room to take a synch-on-green signal  from a signal distribution boxC to individual monitors scattered all over the trading room. Hope itm still works.    5 "Andy Zillins" <afzillins@yahoo.com> wrote in messagea6 news:309332ed.0305080945.282847d@posting.google.com...@ > Has anyone tried and succeeded at connecting a PC monitor to aF > VAX-Station via a BNC to VGA adaptor.  I bought a BNC to VGA adaptorD > cable from BlackBox several years ago.  Tried it with a PC monitor andDD > got nothing.  In hindsight, it probably didn't have Sync-On-Green. >vE > I have 6 Vaxstations with 1280x1024 color at 60 (and 72?) Hz that IEF > need to support for some time.  I wan't to move some of them to LCD,A > but can't find any current models that support BNC connections.  SomeB > of the Samsung LCD monitors mentioned would be a perfect if they work > via an adaptor.. >m0 > "John Smith" <a@nonymous.com> wrote in messageD news:<iVBsa.78893$kYH.72546@news01.bloor.is.net.cable.rogers.com>...9 > > "Nic Clews" <sendspamhere@127.0.0.1> wrote in messageg& > > news:3EB26F39.99BDBC2@127.0.0.1... > > > John Smith wrote:a > > > >:E > > > > Looking for a recommendation (specific make/model) for an LCDc > >:E > > Thanks for the pointers, Nic & Stan. Iiyama is hard to get aroundt hereD > > so I spoke with Samsung today and found that Samsung has quite a few F > > LCD models with synch-on-green available as a built-in feature (15 pin ? > > sub-D  connector). Some models with synch-on-green built-int include: >o; > > They say that all that's required is a VGA-BNC adapter.r > >e/ > > A couple of notes for others picking up olda Vaxstations/Alphastationsh > > on eBay:   ------------------------------  % Date: Thu, 08 May 2003 19:09:41 -0500C( From: Michael Rice <marice@whiteice.com>6 Subject: Re: Synch-on-Green LCD monitor for Vaxstation/ Message-ID: <vblse9mcvcknb1@corp.supernews.com>i  H I'm not using BNC, but I am using a 3W3<->HD15 adapter cable to connect I my VAXstation 4000/96 to a PC monitor with a Sony Trinitron tube.  Works   fine.    Michaelt  ) On 5/8/2003 12:45 PM, Andy Zillins wrote: @ > Has anyone tried and succeeded at connecting a PC monitor to aF > VAX-Station via a BNC to VGA adaptor.  I bought a BNC to VGA adaptorH > cable from BlackBox several years ago.  Tried it with a PC monitor andD > got nothing.  In hindsight, it probably didn't have Sync-On-Green. > E > I have 6 Vaxstations with 1280x1024 color at 60 (and 72?) Hz that I F > need to support for some time.  I wan't to move some of them to LCD,G > but can't find any current models that support BNC connections.  SomemG > of the Samsung LCD monitors mentioned would be a perfect if they work  > via an adaptor.i > u > "John Smith" <a@nonymous.com> wrote in message news:<iVBsa.78893$kYH.72546@news01.bloor.is.net.cable.rogers.com>...y > 7 >>"Nic Clews" <sendspamhere@127.0.0.1> wrote in message.$ >>news:3EB26F39.99BDBC2@127.0.0.1... >> >>>John Smith wrote: >>>/A >>>>Looking for a recommendation (specific make/model) for an LCD/ >>H >>Thanks for the pointers, Nic & Stan. Iiyama is hard to get around hereF >>so I spoke with Samsung today and found that Samsung has quite a fewH >>LCD models with synch-on-green available as a built-in feature (15 pinF >>sub-D  connector). Some models with synch-on-green built-in include: >  >  e > 9 >>They say that all that's required is a VGA-BNC adapter.a >>G >>A couple of notes for others picking up old Vaxstations/Alphastations6
 >>on eBay:   ------------------------------  % Date: Thu, 08 May 2003 21:37:02 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>r6 Subject: Re: Synch-on-Green LCD monitor for Vaxstation' Message-ID: <3EBB144E.98280588@fsi.net>a   Michael Rice wrote:i > I > I'm not using BNC, but I am using a 3W3<->HD15 adapter cable to connectiJ > my VAXstation 4000/96 to a PC monitor with a Sony Trinitron tube.  Works > fine.v  # Who makes it? Where did you get it?    -- t David J. Dachterae dba DJE Systemsd http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Thu, 08 May 2003 22:01:31 -0500h( From: Michael Rice <marice@whiteice.com>6 Subject: Re: Synch-on-Green LCD monitor for Vaxstation/ Message-ID: <vbm6gcnk36c4ad@corp.supernews.com>o  - On 5/8/2003 9:37 PM, David J. Dachtera wrote:h > Michael Rice wrote:  > I >>I'm not using BNC, but I am using a 3W3<->HD15 adapter cable to connect J >>my VAXstation 4000/96 to a PC monitor with a Sony Trinitron tube.  Works >>fine.r >  > % > Who makes it? Where did you get it?a >   G If you are asking about the monitor, it is a standard 17" Dell monitor i+ (which is just a rebranded Sony Trinitron).d  H If you are asking about the cable, it is a Digital cable.  The markings I on the cable are "FUJIKURA-T E49075 AWM STYLE 20276 VW-1".  The person I  F bought it from had one up on eBay, but I missed it.  See a picture of G the cable at eBay auction # 3411445511.  The cable he sold me, outside r* of eBay, was $25, which included shipping.  G Notice that the HD15 end is a female.  I am connecting to a KVM, which iC expects a male plug, so I am also running it through a regular VGA a8 monitor cable, which is basically a long gender changer.  @ If you want his name and e-mail address, just send me an e-mail.   Michaelf   ------------------------------  $ Date: Thu, 8 May 2003 22:00:28 +01005 From: Ian Wing Yin Chung <iwyc@maddoginc.demon.co.uk>- Subject: Re: TCPIP libraries?14 Message-ID: <ew+16gAsVsu+EwRr@maddoginc.demon.co.uk>   Thanks for the response!  0 Here a dump of what's going on (with errors) ...   $- $ type try.c   #include        <stdio.h>r #include        <in.h> #include        <socket.h>! #include        <tcpip$inetdef.h>a   main() {y         int     sd;l           printf("Socketing\n");-         sd = socket(AF_INET, SOCK_STREAM, 0);r  !         printf("Do something\n");r           close(sd);         printf("Finish\n");5 }  $V $0	 $ gcc try, $A $6 $ type newlink.com $ LINK 'P1', -$ !       SYS$LIBRARY:TCPIP$IPC/LIB, -         SYS$INPUT/OPTIONSy GNU_CC:[000000]GCCLIB/LIBy" SYS$LIBRARY:DECW$XLIBSHR.EXE/SHARE SYS$SHARE:TCPIP$IPC_SHR/SHARE  SYS$SHARE:VAXCRTL.EXE/SHAREa     $  $a $ @newlink try% %LINK-W-NUDFSYMS, 1 undefined symbol:o %LINK-I-UDFSYM,         SOCKET4 %LINK-W-USEUNDEF, undefined symbol SOCKET referenced(         in psect $CODE offset %X0000004B<         in module TRY file DISK$CLUS_USER_01:[IWYC]TRY.OBJ;5 $  $s $h    F Had a go at the TCPIP$EXAMPLES as you suggested but could not find theD file "uio.h" referenced in "socket.h". As far as I know, gcc doesn't accept the prefix option.s     Iano          2 In message <3EB99943.FC533613@istop.com>, JF Mezei" <jfmezei.spamnot@istop.com> writes >Ian Wing Yin Chung wrote:< >> Does anyone know where TCPIP$IPC.OLB gets installed from? >mJ >> Installed TCPIP services and FTP, etc works fine. Tried some simple "C"K >> network programming using sockets, connect calls but when I try to link,r= >> I get undefined symbols for all the network related calls.  >aB >Can you give an example of an unresolved external ? It could be a >question of prefixes. >-I >> network programming libraries get installed from a proper installation)< >> of the "C" compiler? Currently using an old gcc compiler. >lL >No, the TCPIP libraries would be with the TCPIP Services, not the compiler.I >Also, normally, you woudlN't need the .OLB since it would link against az >shareable image.n > O >Have you tried compiling and linking some of the programs in TCPIP$EXAMPLES: ?h   -- e Ianr   ------------------------------  % Date: Thu, 08 May 2003 13:00:22 +0200 , From: Albrecht Schlosser <ajs856@tiscali.de> Subject: Re: TCPIP libraries? , Message-ID: <3cdd9b.bpp.ln@news.hus-soft.de>   Ian Wing Yin Chung wrote:f >  > Running OpenVMS v7.1 on VAX. > ; > Does anyone know where TCPIP$IPC.OLB gets installed from?e > I > Installed TCPIP services and FTP, etc works fine. Tried some simple "C"rJ > network programming using sockets, connect calls but when I try to link,E > I get undefined symbols for all the network related calls. Does the H > network programming libraries get installed from a proper installation; > of the "C" compiler? Currently using an old gcc compiler.i  H You need to compile your sources with "cc/prefix=all" or similar, if youF are using a DEC/CPQ/HP compiler like VAXC/DECC. You need this, becauseD the network related functions are all prefixed with ... I don't know( right now, maybe ucx$ or decc$ or vaxc$.  E If you're using gcc, then you _may_ have to change all these calls top> have the proper prefixes, which could be done with macros like   #define socket DECC$socket  2 etc., if there isn't a VMS specific option in gcc.  J > What do I need in order to develop network apps on OpenVMS? I'm familiarI > with C networking programming on the Unix environment. Is there specialw/ > link options that I need to apply on OpenVMS?o  F Nothing special, but some network calls have VMS specific restrictions@ (e.g. max socket number for select must be <= 32). IIRC you must7 explicitly link to vaxcrtl.olb or vaxcrtl.exe (on VAX).i   Albrecht Schloer-   ------------------------------   Date: 8 May 2003 06:13:35 -0000z4 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>@ Subject: Re: What is the schedule for the DII COE certification?6 Message-ID: <20030508061335.29038.qmail@gacracker.org>  B On Thu, 08 May 2003, Paul Repacholi <prep@prep.synonet.com> wrote:< >"Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes: >eF >> Note that the DII/COE Kernel is subject to export restrictions, and@ >> is not generally available to everyone.  If you need specificE >> details on the DII/COE Kernel, feel free to contact me, and I will = >> refer you to someone who can make an "official" statement.a >0D >What is there about COE VMS that puts it under export control? Does' >it include SEVMS stuff out of the box?(  H The rules on encryption were relaxed, so I don't think that could be it.G What else is there about SEVMS that might be included and bring COE VMSf under export control?a     Doc. -- eK OpenVMS.  Eight out of ten hackers                   https://vmsbox.cjb.nettK           prefer *other* operating systems.        http://althacker.cjb.netS   ------------------------------  # Date: Thu, 08 May 2003 14:51:16 GMT-9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>m@ Subject: Re: What is the schedule for the DII COE certification?0 Message-ID: <E9uua.528$Ct2.295@news.cpqcorp.net>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in messagec' news:87issmo6aa.fsf@prep.synonet.com...o= > "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes:e >eG > > Note that the DII/COE Kernel is subject to export restrictions, and6A > > is not generally available to everyone.  If you need specificoF > > details on the DII/COE Kernel, feel free to contact me, and I will> > > refer you to someone who can make an "official" statement. > E > What is there about COE VMS that puts it under export control? Doesb( > it include SEVMS stuff out of the box? >e   There is no COE VMS.  L There is a "DII/COE Kernel" - which is provided by the US government and theH rules for it's distribution are covered by their rules (of which I am noH expert).  We port that Kernel to OpenVMS, and it is that Kernel which is controlled.a  A The DII/COE Kernel is a set of applications, user interfaces, andiJ programming API's for creating a "Common Operating Environment" - which inJ theory makes applications written for it portable, and the look & feel the same across platforms.  H The Kernel sits on top of a standard VMS release.  But changes that wereK needed to support the Kernel were done in a seperate release stream for the H first release to manage schedule and risk.  Those changes will be in the' next general V7.3-* release of OpenVMS.X  K The packaging itself of the DII/COE Kernel consists of the base OS, Kernel,o and required LPs.r   ------------------------------  % Date: Thu, 08 May 2003 19:01:14 -0500c( From: Michael Rice <marice@whiteice.com>@ Subject: Re: What is the schedule for the DII COE certification?/ Message-ID: <vblrubq0915d97@corp.supernews.com>s  + On 5/8/2003 9:51 AM, Fred Kleinsorge wrote:I; > "Paul Repacholi" <prep@prep.synonet.com> wrote in messageD) > news:87issmo6aa.fsf@prep.synonet.com...  > = >>"Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes:t >> >>F >>>Note that the DII/COE Kernel is subject to export restrictions, and@ >>>is not generally available to everyone.  If you need specificE >>>details on the DII/COE Kernel, feel free to contact me, and I will = >>>refer you to someone who can make an "official" statement.- >>E >>What is there about COE VMS that puts it under export control? Doese( >>it include SEVMS stuff out of the box? >> >  >  > There is no COE VMS. > N > There is a "DII/COE Kernel" - which is provided by the US government and theJ > rules for it's distribution are covered by their rules (of which I am noJ > expert).  We port that Kernel to OpenVMS, and it is that Kernel which is
 > controlled.  > C > The DII/COE Kernel is a set of applications, user interfaces, andsL > programming API's for creating a "Common Operating Environment" - which inL > theory makes applications written for it portable, and the look & feel the > same across platforms. > J > The Kernel sits on top of a standard VMS release.  But changes that wereM > needed to support the Kernel were done in a seperate release stream for theeJ > first release to manage schedule and risk.  Those changes will be in the) > next general V7.3-* release of OpenVMS.r > M > The packaging itself of the DII/COE Kernel consists of the base OS, Kernel,P > and required LPs.y >  >  >  >  >   G It will be interesting to see what the effort will be to move from COE mH to NCES if/when it is rolled out.  Even more interesting will be to see % if HP supports NCES on VMS platforms.-   ------------------------------   Date: 8 May 2003 21:41:17 -0500l- From: Kilgallen@SpamCop.net (Larry Kilgallen) @ Subject: Re: What is the schedule for the DII COE certification?3 Message-ID: <1hVViMQzYlel@eisner.encompasserve.org>t  Z In article <vblrubq0915d97@corp.supernews.com>, Michael Rice <marice@whiteice.com> writes:  I > It will be interesting to see what the effort will be to move from COE EJ > to NCES if/when it is rolled out.  Even more interesting will be to see ' > if HP supports NCES on VMS platforms.h  F The reason for supporting COE on VMS is that customers required to runF COE wanted to run VMS.  They were offered COE on Tru64 and they wanted VMS.   ------------------------------  % Date: Thu, 08 May 2003 22:10:31 -0500'( From: Michael Rice <marice@whiteice.com>@ Subject: Re: What is the schedule for the DII COE certification?/ Message-ID: <vbm718t71cod69@corp.supernews.com>t  + On 5/8/2003 9:41 PM, Larry Kilgallen wrote: \ > In article <vblrubq0915d97@corp.supernews.com>, Michael Rice <marice@whiteice.com> writes: >  > I >>It will be interesting to see what the effort will be to move from COE sJ >>to NCES if/when it is rolled out.  Even more interesting will be to see ' >>if HP supports NCES on VMS platforms.- >  > H > The reason for supporting COE on VMS is that customers required to runH > COE wanted to run VMS.  They were offered COE on Tru64 and they wanted > VMS.  H If they are required to support COE, it's probable those same customers I will be required to support NCES - at least if they are building systems sG any strategic C2, C3, or C4I[SR] systems.  However, I think the formal o: NCES requirements from DISA are still a bit in the future.   ------------------------------  $ Date: Thu, 8 May 2003 20:38:46 -0700# From: "Tom Linden" <tom@kednos.com>n@ Subject: RE: What is the schedule for the DII COE certification?9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOEIJHCAA.tom@kednos.com>d   >-----Original Message----- 0 >From: Michael Rice [mailto:marice@whiteice.com]% >Sent: Thursday, May 08, 2003 8:11 PMh >To: Info-VAX@Mvb.Saic.ComA >Subject: Re: What is the schedule for the DII COE certification?a >A >u, >On 5/8/2003 9:41 PM, Larry Kilgallen wrote:@ >> In article <vblrubq0915d97@corp.supernews.com>, Michael Rice  ><marice@whiteice.com> writes: >> k >> uJ >>>It will be interesting to see what the effort will be to move from COE K >>>to NCES if/when it is rolled out.  Even more interesting will be to see w( >>>if HP supports NCES on VMS platforms. >>   >> iI >> The reason for supporting COE on VMS is that customers required to runrI >> COE wanted to run VMS.  They were offered COE on Tru64 and they wanted  >> VMS.i >tI >If they are required to support COE, it's probable those same customers eJ >will be required to support NCES - at least if they are building systems H >any strategic C2, C3, or C4I[SR] systems.  However, I think the formal ; >NCES requirements from DISA are still a bit in the future.l  K Does the C2, etc refer to the Orange Book classifications?  I thought thesem+ had been supreceded by the Common Criteria.g   >  >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003- >- ----& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003   ------------------------------  % Date: Thu, 08 May 2003 23:13:27 -0500m( From: Michael Rice <marice@whiteice.com>@ Subject: Re: What is the schedule for the DII COE certification?/ Message-ID: <vbman8sbmb3e3d@corp.supernews.com>   ' On 5/8/2003 10:38 PM, Tom Linden wrote:o >  >>-----Original Message-----1 >>From: Michael Rice [mailto:marice@whiteice.com] & >>Sent: Thursday, May 08, 2003 8:11 PM >>To: Info-VAX@Mvb.Saic.ComeB >>Subject: Re: What is the schedule for the DII COE certification? >> >>- >>On 5/8/2003 9:41 PM, Larry Kilgallen wrote:0 >>@ >>>In article <vblrubq0915d97@corp.supernews.com>, Michael Rice  >> >><marice@whiteice.com> writes:n >> >>>aK >>>>It will be interesting to see what the effort will be to move from COE vL >>>>to NCES if/when it is rolled out.  Even more interesting will be to see ) >>>>if HP supports NCES on VMS platforms.o >>>o >>>lI >>>The reason for supporting COE on VMS is that customers required to runcI >>>COE wanted to run VMS.  They were offered COE on Tru64 and they wanted  >>>VMS.o >>J >>If they are required to support COE, it's probable those same customers K >>will be required to support NCES - at least if they are building systems 2I >>any strategic C2, C3, or C4I[SR] systems.  However, I think the formal A< >>NCES requirements from DISA are still a bit in the future. >  > M > Does the C2, etc refer to the Orange Book classifications?  I thought theseT- > had been supreceded by the Common Criteria.o >  >    C2 = Command & Control C3 = C2 + CommunicationsD C4ISR = C3 + Computers, Intelligence, Surveillance, & Reconnaissance   ------------------------------  % Date: Thu, 08 May 2003 11:06:28 -0700s+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>s  Subject: Re: Where is VMSBACKUP?' Message-ID: <3EBA9CA4.3000809@MMaz.com>T   Steve Spires wrote:r  H >I've tried to get this from ftp.process.com but get the following error	 >message;  >Y >200 TYPE command okay.a >200 PORT command okay. ! >550 %%RMS-E-FNF, file not found,.? >ANONYMOUS_ROOT:[VMS-FREEWARE.FREE-VMS.TESTING]VMSBACKUP4-1.ZIPi >yI >So has it gone? I want to try this as an alternative to VMSTAR which, asgD >discussed in another thread, doesn't appear to be able to cope with >files larger than 4GB.  > D >Unless someone has a 64-bit version of VMSTAR which [I think] BarryI >Treahy mentioned might solve the problem... Or how can I make VMSTAR usev* >64-bit addressing [is that what I mean?]? >  l >m Steve,  E I can't answer that but if you have an abundance of disk space, what 1G about 'zipping' the file(s) first or just zipping the entire directory RD tree?  I've never zipped a file that large, so it may have the same F problems as VMSTAR, but I doubt it and would bet that it would work...   Barrya   --    @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------  % Date: Thu, 08 May 2003 22:59:04 +0200r6 From: Adolf Sonderegger <adolf.sonderegger@bluewin.ch>  Subject: Re: Where is VMSBACKUP?* Message-ID: <3EBAC518.2BFA1CF8@bluewin.ch>   Steve Spires wrote:d  I > I've tried to get this from ftp.process.com but get the following error 
 > message; >  > 200 TYPE command okay. > 200 PORT command okay." > 550 %%RMS-E-FNF, file not found,@ > ANONYMOUS_ROOT:[VMS-FREEWARE.FREE-VMS.TESTING]VMSBACKUP4-1.ZIP >/J > So has it gone? I want to try this as an alternative to VMSTAR which, asE > discussed in another thread, doesn't appear to be able to cope withl > files larger than 4GB. > E > Unless someone has a 64-bit version of VMSTAR which [I think] BarryMJ > Treahy mentioned might solve the problem... Or how can I make VMSTAR use+ > 64-bit addressing [is that what I mean?]?v >e > Cheers >h > Steve Spires > Technical Consultant > Torex Health > [P](44)01295 274388h > [F](44)01295 275131  > www.torex.com    Hellop   Have a look at URL:  ftp://ftp.lp.se/free-vms/r or, ftp://ftp.process.com/vms-freeware/free-vms/   regardsR Adolf Sondereggerr   ------------------------------  $ Date: Thu, 8 May 2003 19:55:06 +0100* From: "John Travell" <john@travell.uk.net>  Subject: Re: Where is VMSBACKUP?5 Message-ID: <b9ei8m$ike0e$1@ID-120847.news.dfncis.de>e  6 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message! news:3EBA9CA4.3000809@MMaz.com...6 > Steve Spires wrote:  > J > >I've tried to get this from ftp.process.com but get the following error > >message;4 > >  > >200 TYPE command okay.- > >200 PORT command okay.1# > >550 %%RMS-E-FNF, file not found, A > >ANONYMOUS_ROOT:[VMS-FREEWARE.FREE-VMS.TESTING]VMSBACKUP4-1.ZIPV > >SK > >So has it gone? I want to try this as an alternative to VMSTAR which, asIF > >discussed in another thread, doesn't appear to be able to cope with > >files larger than 4GB.b > >MF > >Unless someone has a 64-bit version of VMSTAR which [I think] BarryK > >Treahy mentioned might solve the problem... Or how can I make VMSTAR uset, > >64-bit addressing [is that what I mean?]? > >o > >/ > Steve, >/F > I can't answer that but if you have an abundance of disk space, whatH > about 'zipping' the file(s) first or just zipping the entire directoryE > tree?  I've never zipped a file that large, so it may have the same H > problems as VMSTAR, but I doubt it and would bet that it would work... > K At least one of the varieties of ZIP has a substantially similar problem, IeI believe it is something to do with 32-bit byte count overflowing in the C 	 compiler.b     -- John Travell  VMS crashdump expertise for hire john@travell.uk.neta http://www.travell.uk.net/       ---w& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.478 / Virus Database: 275 - Release Date: 06/05/2003w   ------------------------------  % Date: Thu, 08 May 2003 14:49:23 -0700e+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>e  Subject: Re: Where is VMSBACKUP?' Message-ID: <3EBAD0E3.1020500@MMaz.com>t   John Travell wrote:i  7 >"Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message " >news:3EBA9CA4.3000809@MMaz.com... >    >o >>Steve Spires wrote:  >>     >>J >>>I've tried to get this from ftp.process.com but get the following error >>>message;e >>>a >>>200 TYPE command okay.  >>>200 PORT command okay.o# >>>550 %%RMS-E-FNF, file not found,sA >>>ANONYMOUS_ROOT:[VMS-FREEWARE.FREE-VMS.TESTING]VMSBACKUP4-1.ZIPo >>> K >>>So has it gone? I want to try this as an alternative to VMSTAR which, as F >>>discussed in another thread, doesn't appear to be able to cope with >>>files larger than 4GB.a >>>gF >>>Unless someone has a 64-bit version of VMSTAR which [I think] BarryK >>>Treahy mentioned might solve the problem... Or how can I make VMSTAR use , >>>64-bit addressing [is that what I mean?]? >>>u >>>)	 >>>      l >>>( >>Steve, >>F >>I can't answer that but if you have an abundance of disk space, whatH >>about 'zipping' the file(s) first or just zipping the entire directoryE >>tree?  I've never zipped a file that large, so it may have the samerH >>problems as VMSTAR, but I doubt it and would bet that it would work... >> >>     >>L >At least one of the varieties of ZIP has a substantially similar problem, IJ >believe it is something to do with 32-bit byte count overflowing in the C
 >compiler. >e >  a >oF Perhaps you are correct but it is not something I would have expects, I considering its Unix roots and that it was designed to operate on stream tD data...  Maybe where the flaw is when attempting to zip more than a 0 single file (ie. multiple streams) of that size?   Barry_   --    @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028n   ------------------------------  $ Date: Thu, 8 May 2003 23:23:56 +0100* From: "John Travell" <john@travell.uk.net>  Subject: Re: Where is VMSBACKUP?5 Message-ID: <b9eldv$id038$1@ID-120847.news.dfncis.de>n  6 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message! news:3EBAD0E3.1020500@MMaz.com...  > John Travell wrote:p >o9 > >"Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message0$ > >news:3EBA9CA4.3000809@MMaz.com... > >n > >t > >>Steve Spires wrote:n > >> > >>L > >>>I've tried to get this from ftp.process.com but get the following error
 > >>>message;. > >>>o > >>>200 TYPE command okay.u > >>>200 PORT command okay.u% > >>>550 %%RMS-E-FNF, file not found,nC > >>>ANONYMOUS_ROOT:[VMS-FREEWARE.FREE-VMS.TESTING]VMSBACKUP4-1.ZIPu > >>>oJ > >>>So has it gone? I want to try this as an alternative to VMSTAR which, asH > >>>discussed in another thread, doesn't appear to be able to cope with > >>>files larger than 4GB.y > >>>@H > >>>Unless someone has a 64-bit version of VMSTAR which [I think] BarryI > >>>Treahy mentioned might solve the problem... Or how can I make VMSTAR  useb. > >>>64-bit addressing [is that what I mean?]? > >>>w > >>>  > >>>w > >>>a
 > >>Steve, > >>H > >>I can't answer that but if you have an abundance of disk space, whatJ > >>about 'zipping' the file(s) first or just zipping the entire directoryG > >>tree?  I've never zipped a file that large, so it may have the samesJ > >>problems as VMSTAR, but I doubt it and would bet that it would work... > >> > >> > >>L > >At least one of the varieties of ZIP has a substantially similar problem, InL > >believe it is something to do with 32-bit byte count overflowing in the C > >compiler. > >e > >  > >EG > Perhaps you are correct but it is not something I would have expects,yJ > considering its Unix roots and that it was designed to operate on streamE > data...  Maybe where the flaw is when attempting to zip more than an2 > single file (ie. multiple streams) of that size? > I Nope, The problems I saw were trying to zip huge (4Gb+) dumpfiles. If thesI zipfile went over 2 million blocks something wrapped and zip continued byw7 over-writing the beginning of the file it was creating.e   -- John Travell  VMS crashdump expertise for hire john@travell.uk.netk http://www.travell.uk.net/           --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.478 / Virus Database: 275 - Release Date: 06/05/2003l   ------------------------------  % Date: Thu, 08 May 2003 16:28:15 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com>   Subject: Re: Where is VMSBACKUP?' Message-ID: <3EBAE80F.3080305@MMaz.com>    John Travell wrote:e  
 >>>>Steve, >>>>H >>>>I can't answer that but if you have an abundance of disk space, whatJ >>>>about 'zipping' the file(s) first or just zipping the entire directoryG >>>>tree?  I've never zipped a file that large, so it may have the samebJ >>>>problems as VMSTAR, but I doubt it and would bet that it would work... >>>> >>>>         >>>>L >>>At least one of the varieties of ZIP has a substantially similar problem,	 >>>      a >>>  >I >  w > L >>>believe it is something to do with 32-bit byte count overflowing in the C >>>compiler. >>>u >>>k >>>g	 >>>      w >>> G >>Perhaps you are correct but it is not something I would have expects,mJ >>considering its Unix roots and that it was designed to operate on streamE >>data...  Maybe where the flaw is when attempting to zip more than a82 >>single file (ie. multiple streams) of that size? >> >>     >>J >Nope, The problems I saw were trying to zip huge (4Gb+) dumpfiles. If theJ >zipfile went over 2 million blocks something wrapped and zip continued by8 >over-writing the beginning of the file it was creating. >  c >.I 2 million blocks is only 1G.  I can state without hesitation that I have <E zipped without flaw files much larger than that and entire directory nG trees totaling 5,493,177 blocks (what is that, about 2.7 G?), just two tH months ago...  Perhaps you need to update your zip, though mine is very D old (Zip 2.0 (Sept 7th 1993)), I believe the question at had is the D 32bit barrier at 4G which I do not think will be an issue for zip...   Barryt   -- X  @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------  $ Date: Fri, 9 May 2003 00:38:39 +0100- From: "Steve Spires" <Steve.Spires@torex.com>   Subject: RE: Where is VMSBACKUP?E Message-ID: <91947A84607D9D48B8E674A5FAB54DA6854525@tahiti.tinuk.com>s  H A question then before I fetch zip from somewhere and install it - if myF file is 6GB [which it is] what sort of compression will I get? Will itH end up less than 4GB? The reason for asking is that of course I've stillE got to get it onto tape in a format I can then get the files onto the  Tru64 box, eg via VMSTAR.n   Steve Spires Technical Consultant Torex Health [P](44)01295 274388t [F](44)01295 275131t www.torex.com=20   -----Original Message-----3 From: Barry Treahy, Jr. [mailto:Treahy@MMaz.com]=20s Sent: 09 May 2003 00:28- To: Info-VAX@Mvb.Saic.Com   Subject: Re: Where is VMSBACKUP?     John Travell wrote:y  
 >>>>Steve, >>>>H >>>>I can't answer that but if you have an abundance of disk space, what  C >>>>about 'zipping' the file(s) first or just zipping the entire=20eH >>>>directory tree?  I've never zipped a file that large, so it may have  H >>>>the same problems as VMSTAR, but I doubt it and would bet that it=20 >>>>would work...b >>>> >>>>       =20 >>>>F >>>At least one of the varieties of ZIP has a substantially similar=20 >>>problem,u >>>     =20e >>>a >I > =20o >tI >>>believe it is something to do with 32-bit byte count overflowing in=20o >>>the C compiler. >>>o >>>e >>>m >>>     =20  >>> J >>Perhaps you are correct but it is not something I would have expects,=20F >>considering its Unix roots and that it was designed to operate on=20H >>stream data...  Maybe where the flaw is when attempting to zip more=209 >>than a single file (ie. multiple streams) of that size?- >> >>   =20 >>I >Nope, The problems I saw were trying to zip huge (4Gb+) dumpfiles. If=20hD >the zipfile went over 2 million blocks something wrapped and zip=20E >continued by over-writing the beginning of the file it was creating.n > =20S >tH 2 million blocks is only 1G.  I can state without hesitation that I have  G zipped without flaw files much larger than that and entire directory=20oI trees totaling 5,493,177 blocks (what is that, about 2.7 G?), just two=20pJ months ago...  Perhaps you need to update your zip, though mine is very=20F old (Zip 2.0 (Sept 7th 1993)), I believe the question at had is the=20D 32bit barrier at 4G which I do not think will be an issue for zip...   Barryh   --=20   B Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO=20  A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028e   ------------------------------  % Date: Thu, 08 May 2003 17:09:47 -0700n+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>   Subject: Re: Where is VMSBACKUP?' Message-ID: <3EBAF1CB.9010008@MMaz.com>.   Steve Spires wrote:i  I >A question then before I fetch zip from somewhere and install it - if myeG >file is 6GB [which it is] what sort of compression will I get? Will ittI >end up less than 4GB? The reason for asking is that of course I've stilleF >got to get it onto tape in a format I can then get the files onto the >Tru64 box, eg via VMSTAR. >  >  n >o Great question... I can't answer that because I know nothing about your data, but zipping Codasyl DBMS files (which is what my example was all about), I see about 80% compression...n   Regards,   Barryo --    @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028r   ------------------------------  % Date: Thu, 08 May 2003 11:58:39 -0700.% From: Dean Woodward <deanw@rdrop.com>1A Subject: [Fwd: OpenVMS Pearl - VAXscan is now available on Alpha]m( Message-ID: <3EBAA8DF.5040708@rdrop.com>  C Thanks for the news, Sue. That would have been useful to us... six e< months ago. Now we've re-written our old VAXscan routines...   ------------------------------   Date: 8 May 2003 17:16:32 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen)eE Subject: Re: [Fwd: OpenVMS Pearl - VAXscan is now available on Alpha]23 Message-ID: <LxOizRq3YUM6@eisner.encompasserve.org>@  P In article <3EBAA8DF.5040708@rdrop.com>, Dean Woodward <deanw@rdrop.com> writes:E > Thanks for the news, Sue. That would have been useful to us... six ,> > months ago. Now we've re-written our old VAXscan routines...  D I did not see anything in there about VMS providing VAXSCAN debugger' support on Alpha, like there is on VAX.u   ------------------------------  % Date: Thu, 08 May 2003 12:03:33 +0200g4 From: Didier Morandi <Didier.Morandi.nospam@Free.fr> Subject: [OT] 8-may-1945& Message-ID: <3EBA2B75.2040600@Free.fr>   End of WW2 for France. Merci.   D.   ------------------------------  * Date: Thu, 8 May 2003 19:46:20 -0700 (PDT). From: Fabio Cardoso <fabiopenvms@yahoo.com.br> Subject: Re: [OT] 8-may-1945@ Message-ID: <20030509024620.97611.qmail@web20208.mail.yahoo.com>   9-may-2003 p  . Friday, I will watch X-Men 2 at the cinema :-)   Reg>   FC a9 --- Didier Morandi <Didier.Morandi.nospam@Free.fr> wrote:o > End of WW2 for France. > Merci. >  > D. >      =====  ========================== Fbio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.br ==========================  " __________________________________ Do you Yahoo!?. The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com    ------------------------------   End of INFO-VAX 2003.255 ************************