1 INFO-VAX	Mon, 26 Aug 2002	Volume 2002 : Issue 469       Contents:P Re: Another conversion to MS Windows horror story - SC Dept. of Motor Vehicles V< Re: Charon-VAX (was: [VAX] VMS to [Alpha] OpenVMS conversion. Re: DECwindows/Printing from the TS10 emulator Re: LN17ps Ethernet G Re: Memo:  Re: Charon-VAX (was: [VAX] VMS to [Alpha] OpenVMS conversion   Re: set file/data_check (REPOST)  Re: set file/data_check (REPOST)  Re: set file/data_check (REPOST)  Re: set file/data_check (REPOST)  Re: set file/data_check (REPOST)$ Re: Why C is better than Fortran 95?$ Re: Why C is better than Fortran 95?  F ----------------------------------------------------------------------  % Date: Sun, 25 Aug 2002 18:30:51 -0400 # From: Ray <r_timmon@bellsouthx.net> Y Subject: Re: Another conversion to MS Windows horror story - SC Dept. of Motor Vehicles V - Message-ID: <3D695A9B.EBF6F16@bellsouthx.net>   C http://www.thestate.com/mld/state/2002/08/23/news/local/3921179.htm C http://www.thestate.com/mld/state/2002/08/23/news/local/3921182.htm C http://www.thestate.com/mld/state/2002/08/23/news/local/3921183.htm    Or any other SC newspaper.F ====================================================================== Kenneth Farmer wrote:  >  > Did you read that somewhere? >  > -- >  > Kenneth Farmer > http://www.Tru64.org > http://www.OpenVMS.org > http://www.LinuxHPC.org  > . > "Ray" <r_tim@bellsouth.net> wrote in message) > news:3D67B44A.C68FF96A@bellsouth.net... J > > South Carolina just converted their Department of Motor Vehicles to MSK > > Windows.  The result has been lines so long that the governor has given J > > a 30 day extension on getting anything done there.  The Highway patrolK > > has been blocked from doing Name look-ups since it brings the system to K > > a halt.  It crashes so frequently that most often law enforcement can't > > > get any information at all, putting their lives in danger. > > @ > > Don't know what they used before, but they had VT terminals. > >    ------------------------------  % Date: Sun, 25 Aug 2002 22:53:57 +0200 0 From: Robert Boers <robert.boers@softresint.com>E Subject: Re: Charon-VAX (was: [VAX] VMS to [Alpha] OpenVMS conversion - Message-ID: <3D6943E5.8070107@softresint.com>    Bill Gunshannon wrote:0 > In article <3D5FCCC3.10372.6BE45F6@localhost>,/ > 	"Stanley F. Quayle" <stan@stanq.com> writes:  > D >>*If* they don't install anything else on the Winbox, and just run H >>CHARON-VAX, it's very stable.  It's a server, not a general user box, % >>and should be treated the same way.  >> >  > G > I don't know how to break this to you, but if your talking Win2K here G > it isn't stable when it has nothing running on it.  I have a lab full G > of them. After the students left back in June, they were just sitting E > there all by themselves.  Inside of 30 days every one of them had a G > message on the screen informing someone that they had run dangerously F > low of Virtual Memory.  Within the next 15 days, they all ran out ofG > virtual memory and locked up.  A memory leak that big hardly fits the ! > definition of a stable machine.  >  > bill >    Bill,   A On the starting page of www.vaxemulator.com you can log into our  G CHARON-VAX Plus demo system (Windows 2000, 2 GHz P4) which delivers 40  G VUPs. It has been running since December 2001. Just logged in, it told  D me that VMS 7.3 has been up and running for 241 days (The log shows  about 3000 logins).   / A lot better than the 30 + 15 days you quote...    Robert   ------------------------------  # Date: Mon, 26 Aug 2002 00:04:09 GMT . From: peter@langstoeger.at (Peter LANGSTOEGER)7 Subject: Re: DECwindows/Printing from the TS10 emulator 4 Message-ID: <Zfea9.82154$y71.2129245@news.chello.at>  ~ In article <Pine.LNX.4.30.0208220016290.10420-100000@Linux.monceaux.com>, Kevin Monceaux <OwnedByDogs@ClearSource.net> writes: > I >Well, I got DECwindows running on Tim Stark's TS10 vax emulator with the F >display going to my Linux box.  What a rush.  Actually, my first time >seeing DECwindows.   ! And I still haven't seen TS10 ;-)   H >                   I saw a few posts saying it was possible to copy the% >DECwindows fonts from VMS to Linux.     I don't remember (details). E But to say something about fonts: Fonts are there in two forms, in a  D text/source form called Bitmap Distribution Format (.BDF on Alpha orE .DECW$BDF on VAX) and a binary/compiled form called Portable Compiled J Format PCF (.DECW$FONT) on VAX or Server Natural Form SNF (.SNF) on Alpha.H While the BDF files are identical/portable for all platforms, the binaryH files are not. I read (and maybe even tried many years ago) that the SNFL files from the Alpha are identical with (at least some) font files for U**X.3 Maybe LINUX is one of the matching U**X variants...   C But the VAX is not. Use the Alpha versions (SNF) of the font files. G Or get the BDF files from somewhere (they are unfortunately not part of F the DECwindows-MOTIF Kit) and compile them yourself on your LINUX box.    I >                                     The posts I've found simply said to J >copy the font files to a directory on the Linux box and add the directoryK >to it's font path.  I've tried this but I am getting some 'font not found'  >errors.  G Copy the correct (SNF) files and then its as easy as written. PCF files  won't help.   C btw: On VMS there is a utility (SYS$UPDATE:DECW$MKFONTDIR.COM which D invokes SYS$SYSTEM:DECW$MKFONTDIR.EXE for every font file it founds)K which builds the fonts dir file (fonts.dir on U**X, DECW$FONT_DIRECTORY.DAT K on VMS) automatically. You then only need to manipulate the font alias file @ (fonts.alias on U**X, DECW$FONT_ALIAS.DAT on VMS) if neccessary.  J >        I copyed the font files to Linux via FTP.  They ended up being inG >all uppercase and having a ;1 tacked on the end of the file name.  I'm H >guessing that may have confused Linux.  I've tried a few things such asE >removing the ;1, converting the file names to lower case, etc.  Does + >anyone have any details on this procedure?   > Use another FTP client/server combination or do what you done. The rest see above.   D >Also, I've been told by some that some Linux printing systems don'tH >cooperate with printing from VMS.  Before I beat my head against a wallJ >too much trying to set up my "VAX" to print to Linux does anyone know oneI >way or another of CUPS, the Common Unix Printing System, plays well with A >VMS?  I think I have both sides configured correctly but I get a I >%SYSTEM-F-REJECT, connect to network object rejected error when I try to J >print anything.  I haven't been able to find in any logs on the Linux boxK >any indication that a connection was even attempted.  If CUPS doesn't work J >well with Linux can someone recommend a printing subsystem for Linux that >does work with VMS?  . Better use LPD if you print from VMS to LINUX,J or use Stream (aka TELNET) if you print from VMS to HP JetDirect directly.O The setup on VMS depends on the chosen IP stack (UCX/TCPIP, TCPware, Multinet). K This has been discussed here at various times, so it must be in the FAQ now   6 	http://www.openvms.compaq.com/wizard/openvms_faq.html   HIH    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atP A-1030 VIENNA  AUSTRIA              I'm looking for (a) Network _and_ VMS Job(s)   ------------------------------  % Date: Mon, 26 Aug 2002 07:31:15 +0200 3 From: "Aus, Hans Magnus" <aus@vim.uni-wuerzburg.de>  Subject: Re: LN17ps EthernetB Message-ID: <aus-9E50C1.07311526082002@wrzx08.rz.uni-wuerzburg.de>   Eric:   E I've replaced my NIC with one from a Xerox DocuPrint N17. LAT is not  G available and the setup menu is different. Works fine for our purpose.  0 The IBM 17N should also be essentially the same.   --  4 Hans Magnus Aus, Wuerzburg, aus@vim.uni-wuerzburg.de   ------------------------------  % Date: Sun, 25 Aug 2002 22:27:42 +0200 0 From: Robert Boers <robert.boers@softresint.com>P Subject: Re: Memo:  Re: Charon-VAX (was: [VAX] VMS to [Alpha] OpenVMS conversion- Message-ID: <3D693DBE.6040806@softresint.com>    Stanley F. Quayle wrote:  H > Actually, the emulator is written in C++, so it's not optimized for a F > platform.  Performance is limited by what a particular C++ compiler F > can do.  Just for fun, SRI tried the emulator on Tru64Unix.  It was F > about 10% faster than the same code, on the same box, as on OpenVMS. > E Actually, it was about 25% faster... The problem was mainly in thread F switching. After some attempts to tune it we wrote from scratch a new H product (CHARON-VAX/AXP Plus for OpenVMS/Alpha) to replace the existing ) OpenVMS/Alpha based CHARON-VAX emulators.   H We used a new design (it emulates a 512 MB VAX 3100-98 and can directly F access SCSI-3 disks for very fast I/O), optimized for an EV6. You get H about 25 VUPs on a 1 GHz EV6 system. On an SMP Alpha it can put the VAX G CPU component emulation in a separate host CPU to maximize performance.   H CHARON-VAX/AXP Plus for OpenVMS/Alpha has been in field test for awhile 0 and will move to product status on September 30.   Regards, Robert Boers.   ------------------------------  # Date: Sun, 25 Aug 2002 19:22:44 GMT * From: "Bill Todd" <billtodd@metrocast.net>) Subject: Re: set file/data_check (REPOST) B Message-ID: <88aa9.189041$m91.7935237@bin5.nnrp.aus1.giganews.com>  ; "Alan E. Feldman" <spamsink2001@yahoo.com> wrote in message 7 news:b096a4ee.0208250931.50f80b4a@posting.google.com...    ...   F > IOW, is the data path between disks and tape drives any more or lessE > trustworthy than the data path between disks? If you trust the data E > path from disk to disk, and if that's just as good as the path from G > disk to tape, then why bother with BACKUP's CRC and redundancy groups G > for tape drives that have their own ECC if you don't use similar data & > checking for disk to disk transfers?  H That's something I've wondered about too, in the context of 'end to end'J validation.  I've always thought it would be nice for disks to support 8 -K 16 bytes of ancillary data associated with each disk sector, so that the OS J (if it cared to) could add some information describing the data (e.g., FIDK plus offset) and validating its content (CRC).  This would protect data all J the way from memory to disk and back again (or on a trip over the network,D if one chose) such that (at least with redundant data) a single readC operation could verify the integrity of what it fetched despite the C possibility that a 'wild write' might have trashed it or undetected H corruption occurred (either on the platter - unlikely - or in transit) -L and, if the data was not good, cause it to be refetched (and rewritten) from the redundancy information.   F Unfortunately, this still doesn't catch the failure of a wild write toD update what it was supposed to:  only something like an incrementingH sequence number plus comparison with redundancy information can do that.K But such an incrementing sequence number itself would need a place to live, 3 and the small ancillary data area would provide it.   H (Some systems already do this kind of thing.  E.g., AS/400 uses 520-byteG sectors and places self-identifying data in the extra 8 bytes, and some K storage systems claim 'end to end' protection, though naturally only within H their own boxes rather than all the way from main memory and back again.A But over-size sectors are not only a bit awkward to work with but  unavailable on IDE drives.)   L But in today's environment (to return to the question you asked), the simpleH difference between disk access patterns (in which data may often be readJ many times after being written, each time having some minor probability ofK generating an undetected error in the read data path which read-after-write I does nothing to protect against) and backup access patterns (in which the K tape will seldom be read more than once after being written, commensurately K reducing the likelihood of an undetected error in the read data path) could H alone account for a difference in recommendation.  Add in the end-to-endD validation ability of the tape CRC plus the ability of the redundantI information on the tape in many cases to correct data found to be invalid F (neither of which disk read-after-write provides), and a difference inH recommendation seems pretty understandable.  Then add in the overhead ofL executing read-after-write on disk (compared with the relatively minor addedK overhead of generating CRC and redundancy information on a streaming tape), ( and it becomes even more understandable.   - bill   ------------------------------    Date: 26 Aug 2002 06:58:43 +0800, From: Paul Repacholi <prep@prep.synonet.com>) Subject: Re: set file/data_check (REPOST) - Message-ID: <87lm6ufsv0.fsf@prep.synonet.com>   0 spamsink2001@yahoo.com (Alan E. Feldman) writes:  F > IOW, is the data path between disks and tape drives any more or lessE > trustworthy than the data path between disks? If you trust the data E > path from disk to disk, and if that's just as good as the path from @ > disk to tape, then why bother with BACKUP's CRC and redundancyA > groups for tape drives that have their own ECC if you don't use 3 > similar data checking for disk to disk transfers?   E I have had BACKUP error going disk to disk, with no sign of the error < until the saveset was listed. *Then* BACKUP gave the `errors recovered...' eeeep!!   E Note, that with out the CRCs, there would have been no warning at all  of the errors!  . So, no, I don't trust the disk-to-disk path...   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 25 Aug 2002 18:25:14 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ) Subject: Re: set file/data_check (REPOST) 3 Message-ID: <YOhIRPLD8cMM@eisner.encompasserve.org>   \ In article <87lm6ufsv0.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes:2 > spamsink2001@yahoo.com (Alan E. Feldman) writes: > G >> IOW, is the data path between disks and tape drives any more or less F >> trustworthy than the data path between disks? If you trust the dataF >> path from disk to disk, and if that's just as good as the path fromA >> disk to tape, then why bother with BACKUP's CRC and redundancy B >> groups for tape drives that have their own ECC if you don't use4 >> similar data checking for disk to disk transfers? > G > I have had BACKUP error going disk to disk, with no sign of the error > > until the saveset was listed. *Then* BACKUP gave the `errors > recovered...' eeeep!!  > G > Note, that with out the CRCs, there would have been no warning at all  > of the errors! > 0 > So, no, I don't trust the disk-to-disk path...  @ If you want to save 50% of your Backup time by avoiding /VERIFY,4 I can tell you how to save 100% of your Backup time.  G Nobody _ever_ needs to backup, but occasionally people need to restore.    ------------------------------  % Date: Sun, 25 Aug 2002 21:44:03 -0400 + From: Tim Shoppa <shoppa@trailing-edge.com> ) Subject: Re: set file/data_check (REPOST) 1 Message-ID: <3D694FA3.248F3039@trailing-edge.com>    Bill Todd wrote:J > That's something I've wondered about too, in the context of 'end to end'L > validation.  I've always thought it would be nice for disks to support 8 -= > 16 bytes of ancillary data associated with each disk sector    Most SCSI drives do;     , so that the OSL > (if it cared to) could add some information describing the data (e.g., FIDM > plus offset) and validating its content (CRC).  This would protect data all L > the way from memory to disk and back again (or on a trip over the network,F > if one chose) such that (at least with redundant data) a single readE > operation could verify the integrity of what it fetched despite the E > possibility that a 'wild write' might have trashed it or undetected J > corruption occurred (either on the platter - unlikely - or in transit) -N > and, if the data was not good, cause it to be refetched (and rewritten) from > the redundancy information.  > H > Unfortunately, this still doesn't catch the failure of a wild write toF > update what it was supposed to:  only something like an incrementingJ > sequence number plus comparison with redundancy information can do that.M > But such an incrementing sequence number itself would need a place to live,-5 > and the small ancillary data area would provide it.  > J > (Some systems already do this kind of thing.  E.g., AS/400 uses 520-byteI > sectors and places self-identifying data in the extra 8 bytes, and some M > storage systems claim 'end to end' protection, though naturally only withinnJ > their own boxes rather than all the way from main memory and back again.C > But over-size sectors are not only a bit awkward to work with butl > unavailable on IDE drives.)h > N > But in today's environment (to return to the question you asked), the simpleJ > difference between disk access patterns (in which data may often be readL > many times after being written, each time having some minor probability ofM > generating an undetected error in the read data path which read-after-writeaK > does nothing to protect against) and backup access patterns (in which the=M > tape will seldom be read more than once after being written, commensuratelyeM > reducing the likelihood of an undetected error in the read data path) couldtJ > alone account for a difference in recommendation.  Add in the end-to-endF > validation ability of the tape CRC plus the ability of the redundantK > information on the tape in many cases to correct data found to be invalid H > (neither of which disk read-after-write provides), and a difference inJ > recommendation seems pretty understandable.  Then add in the overhead ofN > executing read-after-write on disk (compared with the relatively minor addedM > overhead of generating CRC and redundancy information on a streaming tape), * > and it becomes even more understandable. >  > - bill   ------------------------------  # Date: Mon, 26 Aug 2002 02:47:47 GMT * From: "Bill Todd" <billtodd@metrocast.net>) Subject: Re: set file/data_check (REPOST) A Message-ID: <nFga9.209265$SS.8445357@bin3.nnrp.aus1.giganews.com>   8 "Tim Shoppa" <shoppa@trailing-edge.com> wrote in message+ news:3D694FA3.248F3039@trailing-edge.com...n > Bill Todd wrote:L > > That's something I've wondered about too, in the context of 'end to end'J > > validation.  I've always thought it would be nice for disks to support 8 -j? > > 16 bytes of ancillary data associated with each disk sectore >a > Most SCSI drives do;  J If that's read-long/write-long, I had the impression that this simply gaveL one access to an area the drive normally used for its own CRC data, and thatL using it therefore could compromise normal operation (though could be usefulG to force error conditions).  If that impression is inaccurate or you'reyF referring to something else, further information or a pointer would be appreciated.   - bill   ------------------------------    Date: 26 Aug 2002 07:02:39 +0800, From: Paul Repacholi <prep@prep.synonet.com>- Subject: Re: Why C is better than Fortran 95?n- Message-ID: <87hehifsog.fsf@prep.synonet.com>   + p_sture@elias.decus.ch (Paul Sture) writes:   d > In article <3d669d88$1@news.si.com>, "Brian Tillman" <tillman_brian@notnoone.notnohow.com> writes:H > >>What Fortran can do only now, and only on some platforms, C has been > >>able to do for a decade. > > D > > What C can do now, VAX Fortran has been able to do for a decade. > 0 > Nah. With a decent compiler, try 2 decades :-)  % If you can forgot the Vax, 3 decades.    -- :< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.e@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 26 Aug 2002 06:01:39 +0200 - From: Didier Morandi <Didier.Morandi@Free.fr>A- Subject: Re: Why C is better than Fortran 95? ' Message-ID: <3D69A824.A8376053@Free.fr>    Paul Repacholi wrote:e > - > p_sture@elias.decus.ch (Paul Sture) writes:d > f > > In article <3d669d88$1@news.si.com>, "Brian Tillman" <tillman_brian@notnoone.notnohow.com> writes:J > > >>What Fortran can do only now, and only on some platforms, C has been > > >>able to do for a decade. > > > F > > > What C can do now, VAX Fortran has been able to do for a decade. > > 2 > > Nah. With a decent compiler, try 2 decades :-) > ' > If you can forgot the Vax, 3 decades.r    If you can forgot the DECades...   :-)I   D.   ------------------------------   End of INFO-VAX 2002.469 ************************