1 INFO-VAX	Wed, 31 May 2006	Volume 2006 : Issue 300       Contents: Re: 2 Nameservers on 1 node  Re: 2 Nameservers on 1 node  Re: ANN: VMS Mosaic 4.0  Re: ANN: VMS Mosaic 4.0 $ Re: Compaq board member sent to jail Re: DCL: IF   and .AND.  logic Re: DCL: IF   and .AND.  logic Re: DCL: IF   and .AND.  logic	 Re: DN-11 	 Re: DN-11 " Error installing VMS732_PCSI-V0300& Re: Error installing VMS732_PCSI-V0300& Re: Error installing VMS732_PCSI-V0300B Re: Need freespace but SYS$QUEUE_MANAGER.QMAN$JOURNAL won't deleteB Re: Need freespace but SYS$QUEUE_MANAGER.QMAN$JOURNAL won't deleteB Re: Need freespace but SYS$QUEUE_MANAGER.QMAN$JOURNAL won't delete. Re: So how representative is this experience ?. Re: So how representative is this experience ?. Re: So how representative is this experience ?0 Re: speeding up LAVC with switch instead of hub?D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)' Re: VMS, XDM, and remote connections...   F ----------------------------------------------------------------------  % Date: Tue, 30 May 2006 16:40:02 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> $ Subject: Re: 2 Nameservers on 1 node, Message-ID: <447CAD99.2FD59A25@teksavvy.com>   "Steven M. Schweda" wrote:J >    Maybe I missed something in the original posting, but I don't see the
 > problem.    F He wants to combine the enternal DNS and the LAN   DSN into one node. G So you either run a BIND9 where a single instance supports the erternal A and internal zonefiles, or you find a way to run 2 distinct BIND8  instances on the same node  D within TCPIP>, you can probably configure BIND to listen only on oneG interface (instead of 0.0.0.0 which listens on all interfaces). And you > could then create a BIND2 that listens to different interface.  G With this, you couldn't make use of cluster aliases etc since you're on F fixed interface IPs and cannot dynamically start using a new interface as it is created.   H You'd need to edit all the startup files to ensure that the logicals areE created in a group table and run both instances in a different group, D and hope that the code doesn't specify LNM$SYSTEM in its requests to translate logicals.   G YOu'd then need to worry about any mailbox etc. Also, BIND2 wouldn't be E controllable through some of the bind control utilities (and not sure   the first BIND would also work).  H In my opinion, it isn't worth the trouble to try to combine 2 bind8 on a single node.   ------------------------------  + Date: Tue, 30 May 2006 16:07:44 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)$ Subject: Re: 2 Nameservers on 1 node2 Message-ID: <06053016074447_2020743C@antinode.org>  - From: JF Mezei <jfmezei.spamnot@teksavvy.com>    > "Steven M. Schweda" wrote:L > >    Maybe I missed something in the original posting, but I don't see the > > problem. > H > He wants to combine the enternal DNS and the LAN   DSN into one node. I > So you either run a BIND9 where a single instance supports the erternal C > and internal zonefiles, or you find a way to run 2 distinct BIND8  > instances on the same node  B    Isn't that what I have?  Do a DNS look-up on urtx.antinode.org,G alp-l.antinode.org, and alp.antinode.org.  "alp", strictly speaking, is G the DSL router, but it NAT/PAT forwards popular ports to "alp-l".  (The < names could be changed, of course, if, say, "ext" and "alp",% respectively, would make more sense.)   E    Users in the real world can do DNS look-ups on all my systems, but 9 the 10.x.x.x addresses won't be useful except on the LAN.   J > In my opinion, it isn't worth the trouble to try to combine 2 bind8 on a > single node.  <    And I still don't see the need.  But I may just be dense.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Tue, 30 May 2006 17:09:17 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net>   Subject: Re: ANN: VMS Mosaic 4.0: Message-ID: <Oo6dnaIvo-bgKeHZnZ2dnUVZ_sidnZ2d@comcast.com>   JF Mezei wrote:  > "Richard B. Gilbert" wrote:  > J >>A self signed certificate is a cheap way to provide encryption of thingsG >>like user-ids and passwords and allows your users to log in securely.  >  >  > I > https://accesd.desjardins.com is a financial institution's web-banking   > host :-) :-) :-)   >  <snip>  D I just visited the above URL.  The site has a Certificate signed by F "Entrust.net" which is an authority my browser is prepared to accept. D This is, by definition, not "self signed".  If I were a customer, I G would have no hesitation about logging in to this site.  I suppose the  H site might still be fraudulent but, if so, the perpetrators have done a  superb job!    ------------------------------   Date: 30 May 06 17:46:04 EDT) From: cook@wvnvms.wvnet.edu (George Cook)   Subject: Re: ANN: VMS Mosaic 4.0! Message-ID: <Rpr7GWKpenFX@wvnvms>   \ In article <447CAACA.778238AC@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > "Richard B. Gilbert" wrote: K >> A self signed certificate is a cheap way to provide encryption of things H >> like user-ids and passwords and allows your users to log in securely. >  > I > https://accesd.desjardins.com is a financial institution's web-banking   > host :-) :-) :-)   > D > They seem to be fairly conservative in the sense that they haven'tI > abused  "web features", although their site requires javascript. (as do F > most banking sites, and this is a big mistake). However, their loginI > page takes minutes to display on netscape 4.7 due to structural bugs in J > the HTML.   So if their certificates are self-signed, then it shows thatF > someone isn't so bright within that bank.  Is this pretty common for
 > banks ?   E Did you install the CERT.PEM file into the appropriate SSL directory?   E I get a crash when I access the site on a system which doesn't have a G CERT.PEM.  I didn't see the self-signed messages on this site the other 8 day, but I see them now.  Something strange is going on.     George Cook  WVNET    ------------------------------  % Date: Wed, 31 May 2006 03:30:50 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> - Subject: Re: Compaq board member sent to jail ; Message-ID: <26929$447cf1cb$50db5015$32684@news.hispeed.ch>    etmsreec@yahoo.co.uk wrote: F > So, if I weren't a god-fearing christian, one could suggest tht he's. > both a crook (allegedly) and a bible basher. >    Or just a plain hypocrite?   ------------------------------  % Date: Tue, 30 May 2006 21:17:48 +0200 3 From: Michael Unger <spam.to.unger@spamgourmet.com> ' Subject: Re: DCL: IF   and .AND.  logic , Message-ID: <4e3ka5F1cgrvmU2@individual.net>  . On 2006-05-29 23:01, "Norman Lastovica" wrote:  2 > in this case, I believe that you could just use " > the "built-in" $SEVERITY symbol.  F If *only* the severity level is to be checked -- then yes. But in mostE cases it is desirable to get more detailled information if "something 9 went wrong" and therefore $STATUS has to be saved before.    > Michael Unger wrote: >>   >> [...] >>   >> I'd prefer a construct like:  >>   >> $ status   = $STATUS       ^^^^^^^^^^^^^^^^^^  >> $ severity = status .AND. 71 >> $ IF severity .EQ. 0 THEN WRITE SYS$OUTPUT ...   >> $ IF severity .EQ. 1 THEN ... >> $ ...   Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------  % Date: Tue, 30 May 2006 22:43:14 +0200 3 From: Michael Unger <spam.to.unger@spamgourmet.com> ' Subject: Re: DCL: IF   and .AND.  logic , Message-ID: <4e3p7nF1d10vgU1@individual.net>  * On 2006-05-30 18:47, "Hoff Hoffman" wrote:   > [...]  > J >    Run-time computed goto operations -- one of the reasons why it would F > be comparatively "fun" to write a compiler for DCL -- are available: >  >    $ GOTO LABEL_'severity'  C I don't like "GOTO" at all -- it is much simpler to "go back" using I "GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".    > [...]    Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------  % Date: Wed, 31 May 2006 03:28:09 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> ' Subject: Re: DCL: IF   and .AND.  logic ; Message-ID: <510cd$447cf12a$50db5015$32684@news.hispeed.ch>    Michael Unger wrote:, > On 2006-05-30 18:47, "Hoff Hoffman" wrote: >  >  >>[...]  >>J >>   Run-time computed goto operations -- one of the reasons why it would F >>be comparatively "fun" to write a compiler for DCL -- are available: >> >>   $ GOTO LABEL_'severity' >  > E > I don't like "GOTO" at all -- it is much simpler to "go back" using K > "GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".  >   I But before GOSUB, CALL etc existed (prior to V4.0 ?), one way of using a  ( common piece of code was something like:   $ return_label = "A100"  $ goto common_code $A100:   ...   
 $common_code:    ... do whatever ...    $ goto 'return_label'    ------------------------------  % Date: Wed, 31 May 2006 07:32:10 +0800 ) From: Tim Sneddon <tesneddon@bigpond.com>  Subject: Re: DN-119 Message-ID: <447cc86b$0$24314$88260bb3@free.teranews.com>    Hoff Hoffman wrote: ? > Easier, of course, would be a terminal server or other serial @ > connection, and a more modern modem.  (But if we're discussing? > a Unibus DN-11, I'm guessing the "easy way" isn't permissible ! > within the particular context.)  >   B Villy has written some code for the VAX simh module that throttles@ the VAX CPU so that while the emulator isn't doing much it dropsB a few VUPS. I haven't been following exactly how he does this, butD I believe there is a process on the emulated VAX that uses the DN-11! to let simh know what's going on.   
 Regards, Tim.   E *** Posted via a free Usenet account from http://www.teranews.com ***    ------------------------------    Date: 30 May 2006 20:45:44 -04003 From: Rich Alderson <news@alderson.users.panix.com>  Subject: Re: DN-11. Message-ID: <mddzmgzauo7.fsf@panix5.panix.com>  + Tim Sneddon <tesneddon@bigpond.com> writes:   L > Villy has written some code for the VAX simh module that throttles the VAXH > CPU so that while the emulator isn't doing much it drops a few VUPS. IK > haven't been following exactly how he does this, but I believe there is a O > process on the emulated VAX that uses the DN-11 to let simh know what's going  > on.   M No, what he did was to co-opt the DN-11 address for communication between the L emulated VAX and the external throuttling process, on the theory that no one needed a DN-11 for a VAX.    --  L Rich Alderson                                       | /"\ ASCII ribbon     |L news@alderson.users.panix.com                       | \ / campaign against |L "You get what anybody gets. You get a lifetime."    |  x  HTML mail and    |L                          --Death, of the Endless    | / \ postings         |   ------------------------------    Date: 30 May 2006 12:06:17 -0700# From: "Bobby" <colemanr7@yahoo.com> + Subject: Error installing VMS732_PCSI-V0300 C Message-ID: <1149015977.480764.184940@i39g2000cwa.googlegroups.com>   F I have just tried to install the VMS732_PCSI-V0300 on one of our AlphaD machines. The patch installs without reporting any errors.  However,B when trying to use the PROD procedure after the install, the errorD shown below occurs.  Has anyone else had this problem... or is there= some other patch that should be installed first?  The install E instructions do not list any dependencies.  Rebooting didn't help.  I F went through the process twice... once initially and again following a9 system disk restore.  The same issue occurred both times.   
 Thank you, Bobby   ? **** Error that follows a simple "prod show hist" command after  installing the patch ****    $ prod show hist  * %CLI-F-SYNTAX, error parsing 'DEFAULT_KIT': -CLI-E-ENTNF, specified entity not found in command tables/ %TRACE-F-TRACEBACK, symbolic stack dump follows G   image    module    routine             line      rel PC           abs  PC>                                             0 000000007AFB24A0 000000007AFB24A0>                                             0 000000007AFB23B4 000000007AFB23B4>                                             0 000000007AFB1644 000000007AFB1644>                                             0 FFFFFFFF8007A3F4 FFFFFFFF8007A3F4>                                             0 FFFFFFFF8007A3F4 FFFFFFFF8007A3F4>  PCSI$MAIN                                  0 0000000000051588 0000000000051588/  PCSI$MAIN  DCLQUALIFIER  set_common_qualifiers >                                         11550 0000000000000934 0000000000030934)  PCSI$MAIN  SPIU_COMMAND_VMS  process_DCL >                                         29963 000000000000C534 00000000000475E4>  PCSI$MAIN  SPIU_COMMAND_VMS  main      32413 00000000000111E8 000000000004C298>  PCSI$MAIN  SPIU_COMMAND_VMS  __main        0 000000000000009C 000000000003B14C>                                             0 FFFFFFFF80269ED4 FFFFFFFF80269ED4   ------------------------------    Date: 30 May 2006 13:11:29 -0700# From: "Bobby" <colemanr7@yahoo.com> / Subject: Re: Error installing VMS732_PCSI-V0300 C Message-ID: <1149019889.602849.127050@u72g2000cwu.googlegroups.com>   = Thanks for the reply... I tried your suggestion and have even G shutdown/rebooted the machine again... but the error is still the same.    Bobby    ------------------------------  # Date: Tue, 30 May 2006 22:17:16 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>/ Subject: Re: Error installing VMS732_PCSI-V0300 1 Message-ID: <Mv3fg.1258$Xl4.534@news.cpqcorp.net>    Bobby wrote:H > I have just tried to install the VMS732_PCSI-V0300 on one of our AlphaF > machines. The patch installs without reporting any errors.  However,D > when trying to use the PROD procedure after the install, the error > shown below occurs.  ... A > **** Error that follows a simple "prod show hist" command after  > installing the patch ****  >  > $ prod show hist > , > %CLI-F-SYNTAX, error parsing 'DEFAULT_KIT'< > -CLI-E-ENTNF, specified entity not found in command tables1 > %TRACE-F-TRACEBACK, symbolic stack dump follows   D    That error is reportedly and typically a skew between the images B present and the DCLTABLES.EXE command tables, but the trigger was * reported as being fixed with the V3.0 kit.  I    If this were a "simple" skew between the images present on the system  I and what is in the DCLTABLES.EXE command tables and the tables loaded by  J the particular process, I'd expect a system reboot should have fixed that.  F    Does this box have its DCLTABLES.EXE in SYS$SPECIFIC:[SYSLIB]?  Or E are there any PCSI*.EXE images in SYS$SPECIFIC:[SYSEXE] or [SYSLIB]?  . (Is the skew creeping in from another source?)   ------------------------------  # Date: Tue, 30 May 2006 18:35:50 GMT , From: "warren sander" <warren.sander@hp.com>K Subject: Re: Need freespace but SYS$QUEUE_MANAGER.QMAN$JOURNAL won't delete 2 Message-ID: <ag0fg.1234$gd4.1026@news.cpqcorp.net>  L since you should have your qman$journal file fixed have you thought of other ways+ to get disk space back on your system disk? 5 have you gotten rid of old release notes in sys$help? 3 have you looked in sys$update for old crufty stuff.   L assuming you are using an old enough system that your system disk is full as) you say and it's been around for a number K of years there is probably boat loads of old crufty stuff laying around you 4 could remove (assuming you knew what it was and that1 removing it didn't make your system not work.. ).   L I will assume you already purged the disk down and don't have lots of copies- of files you don't need (many log files etc). E how big is your operator.log and your security.audit$journal file(s)?  how about accountng.dat?@ in sys$help you could MOVE not delete but MOVE old release notes *.release_notes someplace I and you could MOVE again not delete but MOVE what's in the [.examples...]  area. You might need sometime F if you don't use decwindows you again could MOVE the $.decw$book stuff someplace else. J do you have paging and swapping on the system disk? and a dump file? if so- you could move the paging off to another disk I and then remove the paging file. (read up on how to do this in the system  managers guide).I look for BIG files ($dir/sel=siz=min=100000 sys$sysdevice:[*...]/siz=all) 2 and see if something stands out. IF YOU DON'T KNOW? WHAT IT IS DON'T DELETE IT. but *.tmp and *.log is fairly safe. H don't forget to look in the [000000] directory. some folks like to shove= stuff there and nobody ever sees it again. {again if you know 3 know what it is don't delete it until you find out} I do you have old kits laying around on disk? if they are somplace else you  can delete them.K And old stuff. Like files created say 'last century'? ie pick some date and G do a $dir/before=1-jan-2000/siz=all or some other date and see if those L files are still needed. Some might be so don't delete if you don't know what the file is.I Any user accounts on this disk? move them off (assuming you know what you  are doing). L How about mail files? do you have giant *.mai files on the disk? you can getI in mail and purge/reclaim and then compress (assuming again you know what $ you are doing (get the thread here?)  J and as was the advice given before if 33,000 blocks is a big chunk of free0 space to you then you really need a bigger disk.K besides that how fragmented is the disk? how long since you looked at that?    -warren       ) <norm.raphael@metso.com> wrote in message K news:OF4439B915.0E0CEE9B-ON8525717A.0069F290-8525717A.006B9DEF@metso.com...  >  > D > Dave Froble <davef@tsoft-inc.com> wrote on 05/26/2006 02:39:47 PM: >  > > rschiemel@gmail.com wrote:% > > > Compaq Open VMS VAX Version 7.2  > > > L > > > It was noticed that the freespace on the system disk was decreasing. A0 > > > search for large files showed a file namedE > > > SYS$QUEUE_MANAGER.QMAN$JOURNAL;1 which was about 11,000 blocks,  existed H > > > in three separate directories on the system disk, using a total of > > > about 33,000 blocks. > > > 4 > > > The directories were: [SYS0.SYSCOMMON.SYSEXE], [SYSE.SYSCOMMON.SYSEXE], > > > and [VMS$COMMON.SYSEXE]. > 0 > You only have one file in "SYS$COMMON:[SYSEXE] >  > type > $ dire/file/siz=all/nohead6 > sys$sysdevice:[*...]SYS$QUEUE_MANAGER.QMAN$JOURNAL;* > @ > and you will see that all three listings have the same fileid. > F > SYS0 is your root,  SYSE is for Standalone backup, vms$common is the actualH > location, the other two point to the files in that directory; they are > "entered" L > into the roots.  see help set file/enter.  Caution:  DO NOT MESS WITH THIS > STRUCTURE. >  >  > 2 > > > In an effort to reduce the size of the files' > > > we issued the following commands:  > > >> mcr  JBC$COMMAND  > > > JBC$COMMAND> DIAG 0 7  > > > L > > > The result was the original three files disappeared and in their placeI > > > were three new files each about 1100 blocks in size. We expected to F > > > find the freespace increased by about 30,000 blocks. Instead the< > > > freespace DECREASED by 3,300 blocks (The 3 new files). > > > . > > > How do we get those 33,000 blocks free ? > > >  > > 	 > > PURGE  > >  > > --8 > > David Froble                       Tel: 724-529-0450B > > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > > DFE Ultralights, Inc.  > > 170 Grimplin Road  > > Vanderbilt, PA  15486  >    ------------------------------  # Date: Tue, 30 May 2006 19:26:36 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>K Subject: Re: Need freespace but SYS$QUEUE_MANAGER.QMAN$JOURNAL won't delete 1 Message-ID: <M%0fg.1242$fg4.831@news.cpqcorp.net>    rschiemel@gmail.com wrote:! > Compaq Open VMS VAX Version 7.2  > F > It was noticed that the freespace on the system disk was decreasing.  F    Seeing disk space decrease on a system disk is normal and expected G behaviour in the typical default OpenVMS configuration, as various log  H files are extended, and as accounting and auditing data is accumulated, F and as users are added to SYSUAF.DAT, and as tools are installed, etc.  C    Others have discussed the specific question involving the queue  E manager journal file and the system disk structure, but I'm going to  I guess that there is actually a more general question lurking here.  That  I you're asking the question could imply the consumption rate is unusually  H fast, or that your system disk is unusually short on system disk space, A or that you have a run-away application chewing up storage space.   F    If there is a more general question here, then some information of  interest here can be:   B    - decreasing by how much storage space over what time interval?A      How quickly is the system disk hemorrhaging its free blocks?   ?    - which disk type and how big is the particular system disk? >      Older disks are, um, small.  Swapping to a bigger disk is@      often quite economical, given the capacity of many of these      older disks.   7    - which MicroVAX, VAXstation, VAXserver, or VAX box? C      This tends to indicate what storage I/O bus(es) are available, 8      and thus what sorts of upgrades might be available.  ?    - is the system configured for full or partial system dumps? @      This can provide some number of megabytes, depending on the!      system memory configuration.   D    - can you move files (page, swap, dump, etc) off the system disk?D      A variation of switching to a partial dump file, obviously, and@      obviously assuming you have free space available else-disk.  D    - is the system set up for gonzo auditing, image accounting, etc?C      There are system settings which can consume storage quickly...         --   F    As for locating applications that are churning away and filling up C disk storage space, I'll assume you have already found the command:   H       DIRECTORY/SIZE=ALL/SELECT=SIZE=MINIMUM=blocks SYS$SYSDEVICE:[*...]  D    If not, this can be useful for finding larger files, and several E passes can be used to find larger files that are increasing in size.  D You can also watch for processes with I/O counts that are (somewhat G unusually) churning away, and cross-match to determine which files are  0 referenced by these processes using the command:  +    SHOW DEVICE/FILE/NOSYSTEM SYS$SYSDEVICE:   2    There are other ways to track this information.   ------------------------------  % Date: Tue, 30 May 2006 17:06:00 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> K Subject: Re: Need freespace but SYS$QUEUE_MANAGER.QMAN$JOURNAL won't delete , Message-ID: <447CB3AE.7EB7CB06@teksavvy.com>  4 OK, I was always affraid to ask about this, but.....    ? What exactly does the SYS$QUEUE_MANAGER.QMAN$JOURNAL file do ?    H Mine is currently small (2 blocks of 222 allocated), but I recall a timeC where it had grown to many thousands of blocks and I had found some  utility to create a new one.   ------------------------------    Date: 30 May 2006 13:36:09 -0700) From: "Bob Gezelter" <gezelter@rlgsc.com> 7 Subject: Re: So how representative is this experience ? C Message-ID: <1149021369.219953.319230@i40g2000cwc.googlegroups.com>   
 mas wrote:I > http://www.aceshardware.com/forums/read_post.jsp?id=115165893&forumid=1  >  > " G > Well I can tell you of one company I know off who have decided NOT to F > go with Itanuim. It is a company that I used to work for (its in theE > FTSE 100) who currently has thousands of Alphas (some the new, some D > old), and a few old VAX system worldwide that need to be upgraded. > I > The software was ported from VAX/VMS to Alpha/VMS in the 90's, this was @ > typically done very poorly, but it worked and gave significant > performance increases. > E > After spending a few months in attempts to port to Itanium/VMS they F > decided that the problems were far to great. The problems being thatG > the performance was lower (significantly) than the system they needed D > to replace (ie: lastest Alphs ES40, ES45, and a few ES47), and the7 > problems caused by compilers optimisations were vast.  > D >  ... remainder of original post omitted in the interest of brevity   mas,  = In addition to my own work, I have been at two of the porting B workshops, Arizona in September 2004 and New Jersey in some monthsG later (I do not have the precise dates because my office DSL is offline D and I cannot check my email archives). In both cases, we were using,@ according to my recollection, pre-8.2 versions of all software).  F The results from both porting workshops did not experience substantial= problems (I wrote an article for OpenVMS.org about the second 
 workshop).  G Your comment about the VAX to Alpha port, "this was typically done very D poorly..." may give an inkling about where problems were. SuccessiveF architectures (Alpha, then IA64) are far less tolerant of a variety ofD poor practices that were sometimes popular on the VAX (oddly enough,G the VAX relaxed ironclad rules that existed for much of the lifespan of > the PDP-11, but this was a 1970's trend, byte-alignment--IBM's? System/370 also allowed byte aligned operands). The penalty for F accessing incorrectly aligned data on Alpha is far heftier than on the2 VAX, and the IA64 is in turn worse than the Alpha.  B However, it is not particularly difficult to identify code that isF prone to this, either by careful inspection or using various debuggingG tools. Many of the stories of poor performance have unaligned (or quite E a few cases, more accurately referred to as "mis-aligned data") as an  underlying issue.   F Certainly, it is unsurprising that there are bugs in optimizers. There= have been bugs in optimizers since the release of the initial G optimizing compilers for FORTRAN (in the 1960's from both CDC and IBM). F Digital/Compaq/HP compilers have not been immune to the occasional bugD in the past, and are likely to have an occasional bug in the future.  > In all cases, I strongly recommend resolving questions of poorE performance by careful investigation and identification of the actual E problem. Running code through a compiler and finding it does not work G (or perform to expectations) correctly does not resolve what the nature F or cause of the problem is. I have troubleshot many problems in depth,B only to find that the "compiler error" is actually code written inC contradiction to the applicable language specification. Often, such ? code works (or is thought to work) with earlier versions of the G compiler. A inconsequential change in the compiler (typically, fixing a F bug) uncovered the problem (like the patient who goes to the emergencyA room for indigestion, and in passing discovers a far more serious  condition).   F My apologies for being somewhat long-winded. To summarize, without theD technical review of what was really happening within the code, it isB relatively fruitless to speculate what was the actual problem. TheF experience of many people is that recompilation of language conformingC source bases has been overwhelmingly successful, with some problems F detected, in both the compilers and the code bases, which is preciselyC what would be expected (at least what I expected at Day 1 after the  IA64 announcement).   $ - Bob Gezelter, http://www.rlgsc.com   ------------------------------  % Date: Tue, 30 May 2006 15:54:05 -0700 # From: "Tom LINDEN" <tom@kednos.com> 7 Subject: Re: So how representative is this experience ? ) Message-ID: <op.tady8fd6lvpiaf@hyrrokkin>   I On Tue, 30 May 2006 07:51:19 -0700, John Reagan <john.reagan@hp.com> wro=  te:    > mas wrote:I >> http://www.aceshardware.com/forums/read_post.jsp?id=3D115165893&forum=  id=3D1 >>  " I >> Well I can tell you of one company I know off who have decided NOT to=   G >> go with Itanuim. It is a company that I used to work for (its in the F >> FTSE 100) who currently has thousands of Alphas (some the new, someE >> old), and a few old VAX system worldwide that need to be upgraded. I >>  The software was ported from VAX/VMS to Alpha/VMS in the 90's, this =  was A >> typically done very poorly, but it worked and gave significant  >> performance increases. G >>  After spending a few months in attempts to port to Itanium/VMS they G >> decided that the problems were far to great. The problems being that I >> the performance was lower (significantly) than the system they needed=   E >> to replace (ie: lastest Alphs ES40, ES45, and a few ES47), and the 8 >> problems caused by compilers optimisations were vast. >> > I > As a compiler person, while there have indeed been a few bugs in the  =   I > first releases of the compilers for OpenVMS I64, the compilers are mor=  e  =  I > stable than they were at first from VAX to Alpha.  We've had no real  =   < > major "oversights" that would have caused "vast problems". > H > As for performance differences, most tend to be caused by alignment  =  I > faults.  Alpha fixed these up quickly in PAL code.  On I64, a few are =   =  F > fixed in hardware, but most trap to the OS.  The overhead is much  =  
 > greater. > I > As a general rule, most alignment fauts are due to people assigning in=  to  =   I > pointers using typecasts.  The compiler assumes that a "pointer to a  =   I > struct" points to an aligned instance of the struct.  After all, you  =   E > used malloc() to allocate it right? :-)  When you shove a random  =   I > byte-aligned address into the pointer, subsequent memory accesses will=    =   H > use instructions that will get alignment faults.  The fix to either  =  I > align the data or use the correct pragma to tell the compiler that the=    =   I > pointer can point to unaligned data will usually fix the problem with =   =  4 > almost no effort.  It helps back on Alpha as well. > I > Code that uses /NOMEMBER_ALIGNMENT (or whatever the language syntax is=    =   I > for your language), tends not to be the cause of alignment faults.  In=    =   I > this situation, the compiler already knows that some "int" field in a =   =  I > struct is on byte 13 for instance.  We don't generate a 'ld4' or 'st4'=    =   I > instruction to access the field.  We already know to generate byte siz=  ed  =   H > instructions and shift/mask the results into the integer value.  It  =  F > would get somewhat faster if the data was aligned (one 'ld4' vs a  =  G > 'ld1/ld2/ld1 seqeunce with some shifts and ORs'), but we don't get  =   = > penalized with the huge OS overhead of the alignment fault.  > ( What do you do for Cobol, wrt alignment?     -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Tue, 30 May 2006 15:59:00 -0700 # From: "Tom LINDEN" <tom@kednos.com> 7 Subject: Re: So how representative is this experience ? ) Message-ID: <op.tadzgmfxlvpiaf@hyrrokkin>   H On Tue, 30 May 2006 13:36:09 -0700, Bob Gezelter <gezelter@rlgsc.com>  =   wrote:   > mas wrote:I >> http://www.aceshardware.com/forums/read_post.jsp?id=3D115165893&forum=  id=3D1 >> >> "I >> Well I can tell you of one company I know off who have decided NOT to=   G >> go with Itanuim. It is a company that I used to work for (its in the F >> FTSE 100) who currently has thousands of Alphas (some the new, someE >> old), and a few old VAX system worldwide that need to be upgraded.  >>I >> The software was ported from VAX/VMS to Alpha/VMS in the 90's, this w=  asA >> typically done very poorly, but it worked and gave significant  >> performance increases.  >>F >> After spending a few months in attempts to port to Itanium/VMS theyG >> decided that the problems were far to great. The problems being that I >> the performance was lower (significantly) than the system they needed=   E >> to replace (ie: lastest Alphs ES40, ES45, and a few ES47), and the 8 >> problems caused by compilers optimisations were vast. >>E >>  ... remainder of original post omitted in the interest of brevity  >  > mas, > ? > In addition to my own work, I have been at two of the porting D > workshops, Arizona in September 2004 and New Jersey in some monthsI > later (I do not have the precise dates because my office DSL is offlin=  e F > and I cannot check my email archives). In both cases, we were using,B > according to my recollection, pre-8.2 versions of all software). > I > The results from both porting workshops did not experience substantial=   ? > problems (I wrote an article for OpenVMS.org about the second  > workshop). > I > Your comment about the VAX to Alpha port, "this was typically done ver=  y F > poorly..." may give an inkling about where problems were. SuccessiveI > architectures (Alpha, then IA64) are far less tolerant of a variety of=   F > poor practices that were sometimes popular on the VAX (oddly enough,I > the VAX relaxed ironclad rules that existed for much of the lifespan o=  f @ > the PDP-11, but this was a 1970's trend, byte-alignment--IBM'sA > System/370 also allowed byte aligned operands). The penalty for I > accessing incorrectly aligned data on Alpha is far heftier than on the=   4 > VAX, and the IA64 is in turn worse than the Alpha. > D > However, it is not particularly difficult to identify code that isI > prone to this, either by careful inspection or using various debugging=   I > tools. Many of the stories of poor performance have unaligned (or quit=  e G > a few cases, more accurately referred to as "mis-aligned data") as an  > underlying issue.  > I > Certainly, it is unsurprising that there are bugs in optimizers. There=   ? > have been bugs in optimizers since the release of the initial I > optimizing compilers for FORTRAN (in the 1960's from both CDC and IBM)=  . I > Digital/Compaq/HP compilers have not been immune to the occasional bug=   F > in the past, and are likely to have an occasional bug in the future. > @ > In all cases, I strongly recommend resolving questions of poorG > performance by careful investigation and identification of the actual G > problem. Running code through a compiler and finding it does not work I > (or perform to expectations) correctly does not resolve what the natur=  e I > or cause of the problem is. I have troubleshot many problems in depth,=   D > only to find that the "compiler error" is actually code written inE > contradiction to the applicable language specification. Often, such A > code works (or is thought to work) with earlier versions of the I > compiler. A inconsequential change in the compiler (typically, fixing =  a I > bug) uncovered the problem (like the patient who goes to the emergency=   C > room for indigestion, and in passing discovers a far more serious 
 > condition).  > I > My apologies for being somewhat long-winded. To summarize, without the=   F > technical review of what was really happening within the code, it isD > relatively fruitless to speculate what was the actual problem. TheI > experience of many people is that recompilation of language conforming=   E > source bases has been overwhelmingly successful, with some problems I > detected, in both the compilers and the code bases, which is precisely=   E > what would be expected (at least what I expected at Day 1 after the  > IA64 announcement).   F I certainly wouldn't disagree with your comments, but the fact is thatG changes were made to many things both for the VAX->Alpha and Alpha->IPF I transitions requiring some ponderable effort on the part of the customer=   F beyond simply rehosting, and that is not good if you wish to be a goodF partner to your customer.   Note that you can probaly execute 360 code
 on a z390. > & > - Bob Gezelter, http://www.rlgsc.com >        -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  + Date: Tue, 30 May 2006 22:16:00 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)9 Subject: Re: speeding up LAVC with switch instead of hub? $ Message-ID: <e5ig70$lgo$1@online.de>  > In article <y9_eg.1216$l94.963@news.cpqcorp.net>, Hoff Hoffman" <hoff-remove-this@hp.com> writes:   J >    I still believe that the base limit here is that the VAX systems are H > correspondingly slow by any current standards (well, by any standards J > other than the "free hardware" standard, and even that one is certainly  > debatable :-),     That's certainly true.  8 > and this hardware configuration is attempting to slam J > large volumes of data (shadow disk copies, et al) over a very slow IEEE D > 802.3 (AKA Ethernet; 1MB, 10Mb) network link -- and you won't get F > anywhere near all of the 802.3 link, for that matter.   The fastest C > network switch in existence just won't make typical VAX hardware  # > configuration operate any faster.   F Right.  However, I'm hoping for two things: 1) WHEN the VAXes saturateG the network with the shadow copies, perhaps this could be isolated from G other systems by avoiding collisions and 2) the one node in the cluster H which IS reasonably fast (5305/AS1200) should be able to run at 100 Mb/sG and full duplex to make the most of the internet connection, especially E considering that this node is a satellite which is only booted when I  (or my wife) needs Mozilla.    ------------------------------    Date: 30 May 2006 15:22:48 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) 3 Message-ID: <sTyct5AbZi1R@eisner.encompasserve.org>   W In article <4e3049F1cmogeU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > F > Unix programmers are free to provide whatever API they wish to theirG > applications.  It should say something that in the 30-some years Unix C > has been around no one has ever found a need  or desire to do it.   ?    Leading by poor example is a common problem in our industry.    ------------------------------    Date: 30 May 2006 15:24:25 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) 3 Message-ID: <Sejh76TIRLqC@eisner.encompasserve.org>   p In article <69idnaotGN065OHZnZ2dnUVZ_smdnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes: > H > It's been something like eight years now but It was a big VAX 6000 or E > 7000 series.   The processor speed is not terribly important.  The  C > problem was that VMS V6.2 did not handle directories larger than  J > something like 100 blocks very well.  Unless you wrote something clever K > to delete files in descending alphanumeric order, every time you emptied  F > a directory block, every succeeding block got moved down!  It's the J > incredible amount of disk I/O that takes the time!  We were still using F > RA series disks and some RZ26 & RZ28 SCSI-2 disks and those weren't  > blindingly fast.  G    OK, I have an RA90 on that 11/785.  Must have been a smaller several     thousand than you had.    ------------------------------  % Date: Wed, 31 May 2006 00:01:51 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) = Message-ID: <447cc09d$0$60781$157c6196@dreader1.cybercity.dk>    Bob Koehler wrote:Y > In article <4dpq96F1936phU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > I >>That's a shell shortcoming and has little. if anything, to do with Unix 4 >>or the file system.  And, it's easy to get around. >  > J >    It has a lot to do with UNIX.  As in depending on the shell to expand> >    wildcards instead of providing an API to the application. > I Well in order to get parameters on VMS you have to learn the CLI API and  G you have to write a CLD file.  Compare that to the *NIX way of passing  G two parameters to the "main" routine.  The later does not require half  G as much education.  Further it is my experience that you need to write  G much more code when using the CLI API than when writing an interpreter  I for *NIX options.  Further, wildcard processing is not directly included  D in languages like Pascal.  You end up having to write a lot of code 5 before you have an interface like VMSes own commands.   H Say simple wildcards are not enough, e.g., you need a /since qualifier. F   On VMS it has to be part of the program or you are out of luck.  On C *NIX you can pass the output from the find command directly to any  F command.  It that is not enough, you can either write your own filter I for the output of, e.g., find or ls.  Then the output of that filter can  I be passed as command parameter.  You can also generate a file containing  A a list of files and pass the contents of that file as parameters.   G The fact that there is a limit on how many parameters you can pass has  F been mostly solve on modern *NIXes by raising the limit so high, that  you seldom run into it.   I So if you are a big enough nerd to use, e.g., find, then it is difficult  8 to see that the VMS way is any better than the *NIX way.   ------------------------------   Date: 30 May 2006 22:37:18 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e3vouF1cn7prU1@individual.net>  3 In article <sTyct5AbZi1R@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:Y > In article <4e3049F1cmogeU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  >>  G >> Unix programmers are free to provide whatever API they wish to their H >> applications.  It should say something that in the 30-some years UnixD >> has been around no one has ever found a need  or desire to do it. > A >    Leading by poor example is a common problem in our industry.   D Except that this seems to be the only place in the world that thinksE Unix is a poor example.  Most people in the industry admit that there H is more than one right way to do most tasks. This little (and shrinking)H conclave seems to be unique in in the idea that they have the only rightF way to do things.  Kind of reminds me of the story of the Lutheran whoG died and went to heaven and when St. Peter was showing him around he is K suddenly told to be very quiet.  The Lutheran asks why. And St. Peter says, G "We're going by the Catholics, they think they are the ony one's here."    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 30 May 2006 19:28:24 -0400 - From: bradhamilton <bradhamilton@comcast.net> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) * Message-ID: <447CD518.4050702@comcast.net>   Bill Gunshannon wrote:5 > In article <sTyct5AbZi1R@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:Z >> In article <4e3049F1cmogeU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:H >>> Unix programmers are free to provide whatever API they wish to theirI >>> applications.  It should say something that in the 30-some years Unix E >>> has been around no one has ever found a need  or desire to do it. B >>    Leading by poor example is a common problem in our industry. > F > Except that this seems to be the only place in the world that thinksG > Unix is a poor example.  Most people in the industry admit that there J > is more than one right way to do most tasks. This little (and shrinking)J > conclave seems to be unique in in the idea that they have the only rightH > way to do things.  Kind of reminds me of the story of the Lutheran whoI > died and went to heaven and when St. Peter was showing him around he is M > suddenly told to be very quiet.  The Lutheran asks why. And St. Peter says, I > "We're going by the Catholics, they think they are the ony one's here."   C I dispute the argument that "this little...conclave" is shrinking;  F certainly, participation here has remained relatively consistent over G the past five years, despite those who wish that we would just go away.   D ISTM that your consistent stand that VMS is not the right way to do C things shows that you think that Unix is "the only right way to do  A things".  Certainly, folks who use Windows or VMS would disagree. I Time and time again, you have brought problems to us that you wish us to  I solve; in many cases, we have provided solutions, to which your response  I (many times) has been, "but it's *so* much easier to do X in Unix".  I'm  I getting a little tired of looking at it.  I've never killfiled anyone in  D this mailing list before; (not even bob@instantwhip) you may be the  first.  Congratulations.   ------------------------------  # Date: Tue, 30 May 2006 23:57:41 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) 1 Message-ID: <VZ4fg.1262$9j4.180@news.cpqcorp.net>   % "Perpetual fruitless debate", anyone?       -- from the FAQ --     0           2.4  Which is better, OpenVMS or UNIX?  I                     This question comes up periodically, usually asked by E                     new subscribers and new posters who are long-time C                     UNIX or Linux users. Sometimes, the question is                      ignored F                     totally; other times, it leads to a long series ofH                     repetitive messages that convince no one and usuallyB                     carry little if any new information. Please do?                     everyone a favor and avoid re-starting this 0                     perpetual, fruitless debate.  H                     That said, OpenVMS and the better implementations ofF                     UNIX are all fine operating systems, each with itsE                     strengths and weaknesses. If you're in a position F                     where you need to choose, select the one that bestI                     fits your own requirements, considering, for example, F                     whether or not the layered products or specific OSH                     features you want are available, and considering theG                     expected cost-of-ownership over the lifetime of the (                     system installation.  E                     If you are asking this question, you are probably D                     comparing OpenVMS to UNIX. It was once certainlyD                     true that OpenVMS and UNIX were quite different.G                     In more recent times, there are tools and C APIs on H                     OpenVMS that directly provide or that easily supportE                     porting UNIX programs and commands, and there are I                     equivalent packages bringing various OpenVMS features 5                     and mechanisms to UNIX platforms.   E                     If you seek UNIX tools on OpenVMS rather than the H                     more philosophical discussion found in this section,H                     please see the GNV package and other GNU discussionsE                     in Section 13.2.6, and please see the plethora of D                     C calls currently available in the HP C Run-TimeD                     Library documentation, briefly discussed over in#                     Section 13.2.1.    ------------------------------  % Date: Tue, 30 May 2006 19:58:10 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <447CDC11.A61BF658@teksavvy.com>   bradhamilton wrote: H > (many times) has been, "but it's *so* much easier to do X in Unix".  I    - But its is easier to do X  *PROPERLY* on VMS.     B There is a big difference between doing a prototype that works and@ making a fully productised product with all the right checks forD arguments etc. VMS may require more work, but you end up with better quality software.    ------------------------------   Date: 31 May 2006 01:17:23 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e4952F1c7u84U1@individual.net>  * In article <447CD518.4050702@comcast.net>,0 	bradhamilton <bradhamilton@comcast.net> writes: > Bill Gunshannon wrote:6 >> In article <sTyct5AbZi1R@eisner.encompasserve.org>,A >> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: [ >>> In article <4e3049F1cmogeU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: I >>>> Unix programmers are free to provide whatever API they wish to their J >>>> applications.  It should say something that in the 30-some years UnixF >>>> has been around no one has ever found a need  or desire to do it.C >>>    Leading by poor example is a common problem in our industry.  >>  G >> Except that this seems to be the only place in the world that thinks H >> Unix is a poor example.  Most people in the industry admit that thereK >> is more than one right way to do most tasks. This little (and shrinking) K >> conclave seems to be unique in in the idea that they have the only right I >> way to do things.  Kind of reminds me of the story of the Lutheran who J >> died and went to heaven and when St. Peter was showing him around he isN >> suddenly told to be very quiet.  The Lutheran asks why. And St. Peter says,J >> "We're going by the Catholics, they think they are the ony one's here." > E > I dispute the argument that "this little...conclave" is shrinking;  H > certainly, participation here has remained relatively consistent over I > the past five years, despite those who wish that we would just go away.   D I wasn't talking about c.o.v, I was talking about the VMS user base. > F > ISTM that your consistent stand that VMS is not the right way to do E > things shows that you think that Unix is "the only right way to do   > things".    H I have never said that VMS was the wrong wqay to do anything.  I supportG both Unix and VMS within the CS Department here even though no one else I here at the University gives a rat's patootie about VMS or it's continued   presence in the edu environment.  C >           Certainly, folks who use Windows or VMS would disagree. K > Time and time again, you have brought problems to us that you wish us to  K > solve; in many cases, we have provided solutions, to which your response  G > (many times) has been, "but it's *so* much easier to do X in Unix".     H Show me one place where after having a VMS problem of mine solved I saidI it was easier on Unix!!  I usually show things to be easier on Unix after G someone here either says "Unix can't do that" or they come up with some F totally convoluted way of doing it on Unix.  It is actually the peopleH here who consistantly argue that everything is harder on UNix and easierF on VMS.  Ease or difficulty is in most cases more related to knowledgeE of the system rather than any inherent superiority/inferiority of any  system.   J >                                                                     I'm K > getting a little tired of looking at it.  I've never killfiled anyone in  F > this mailing list before; (not even bob@instantwhip) you may be the  > first.  Congratulations.  D More power to you. But, remember that this whole thread started withE someone here posting total drivel about Unix in order to somehow make D VMS look superior.  There are ways that VMS is superior. But, as hasE been proven by success in the market place, Unix is more than capable D of doing what most people need to do and trying to make it look likeG that isn't true just makes some people here look foolish and that makes H their favorite OS look foolish too.  Some of us think that's a bad idea.F (And I am no the only one to make this comment here recently.)  So, goF ahead, killfile me.  But, somehow, I don't think sticking your head in0 the sand is going to do anything to further VMS.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 31 May 2006 01:20:23 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e49anF1c7u84U2@individual.net>  , In article <447CDC11.A61BF658@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > bradhamilton wrote: I >> (many times) has been, "but it's *so* much easier to do X in Unix".  I  >  > / > But its is easier to do X  *PROPERLY* on VMS.  >   F Absolutely no support for this beyond the typical religious arguments.   > D > There is a big difference between doing a prototype that works andB > making a fully productised product with all the right checks forF > arguments etc. VMS may require more work, but you end up with better > quality software.   D And, if you put in the same level of work on a Unix system you wouldD also end out with a better product.  Heck, the same is probably trueD of Windowas as well. Unfortunately, MS doesn't believe in putting in that effort. :-)   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 30 May 2006 21:11:41 -0400 ' From: Dave Froble <davef@tsoft-inc.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) / Message-ID: <C8OdnX4veaX3ceHZRVn-vQ@libcom.com>    Bill Gunshannon wrote:5 > In article <6ui+tbxfwpVs@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article <nospam.News.Bob-F397A0.20400626052006@news.verizon.net>, Bob Harris <nospam.News.Bob@remove.Smith-Harris.us> writes: C >>> And when it comes to doing OpenVMS I/O, there are not a lot of  G >>> people that do $QIO.  Most likely few even use $RMS.  Most use the  D >>> language I/O package which today is mostly C and the C Run-time E >>> library.  And that uses buffered RMS files which are also just a  # >>> promise, unless you do a flush. H >>    OK, if you write using the C RTL then you are using RMS and RMS is >>    using $QIO.  >>K >>    Way back in the late 70's when we got our first VAXen Fortran allowed C >>    us direct control over buffering.  The VMS C RTL and some DCL % >>    commands also give you control.  >> >>> Don't pick on UNIX I/O.  >>    Why not?   >>E >>    1) It is, after all limited to byte streams.  Ever try to port  G >>    a program which controls the density of a magtape between various G >>    UNIX?  What part of the byte stream is density?  Gee, its not, so 6 >>    you use an IOCTL interface which ports like mud. >>F >>    2) Ever check the FAQ for how to overwrite a record:  you don't. >>M >>    3) I know why folks buy Oracle for their UNIX systems.  Guess where my   >>    money doesn't go.  >> > I > And still there are more people getting the job done with Unix than VMS H > every day and the ratio is growing wider with every hour.  Go figure!! >  > bill >   J Just proves that the person who claimed humans were intelligent was wrong.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 31 May 2006 01:49:20 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e4b10F1d14maU1@individual.net>  , In article <447CF378.2DFA184C@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Bill Gunshannon wrote:G >> And, if you put in the same level of work on a Unix system you would & >> also end out with a better product. >  > C > Not true for everything. Consider DECNET. When you write a decnet G > server, you have a notification mailbos that gets messages when a new E > call comes in, and when a call is dicsonnected. So the server knows A > right away that the connection to a client has been terminated.  > F > For TCPIP, you need to wait for a timeout vecause the TCPIP software1 > doesn't realise that a connection has been cut.   B And that's because DECNET and TCPIP were not designed for the sameD purposes.  Define "cut",  Do you mean disconected by one end?  Well,B in that case, the same method is used to break the connection downC that was used to establish it.  Do you mean some intermediate piece A goes away?  Well, TCPIP was designed to try to survive what could B be a transient outage.  By the same token, lets see you connect toE the VAX in my basement using DECNET?  What yousay, the INTERNET won't B route DECNET from your machine to mine?  Sounds rather limiting toD me.  Or could it just be that DECNET and TCPIP weren't designed with the same purpose in mind?    > 7 > This makes writing robust applications easier on VMS.   B If the application requires robustness, then it isn't TCPIP's job,A it's the applications.  TCPIP provides all the tools needed to do A that.  You can always write your application using UDP and do all B of the session management in your application, making it as robust as you want.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 30 May 2006 21:38:08 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <447CF378.2DFA184C@teksavvy.com>   Bill Gunshannon wrote:F > And, if you put in the same level of work on a Unix system you would% > also end out with a better product.     A Not true for everything. Consider DECNET. When you write a decnet E server, you have a notification mailbos that gets messages when a new C call comes in, and when a call is dicsonnected. So the server knows ? right away that the connection to a client has been terminated.   D For TCPIP, you need to wait for a timeout vecause the TCPIP software/ doesn't realise that a connection has been cut.   5 This makes writing robust applications easier on VMS.    ------------------------------  % Date: Tue, 30 May 2006 17:00:14 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS, XDM, and remote connections..., Message-ID: <447CB254.D4AE4CE0@teksavvy.com>   "Schroeder, AJ" wrote:L > Oh - that would make more sense. I have stripped off bascially any and allN > authorization and security from my VMS X server. Still no go on connections.  H The MIT_COOKIES is a very low level authentication, it has nothint to do' with authetification you can configure.     I > I will look again, but I didn't seem to find the logicals you speak of.     C The TCPIP Services management manual has a whole chapted on XDMCP.    8 You do need to setup a few files. It is well documented.  G To manually get XDM to serve specific hosts, you setup the XSERVERS.TXT D file and put in the addresses of each Xterminal you want serviced byE XDM. But this causes XDM to takle control of that X terminal with its < dumbed down login screen. (bypasses the actual XDM protocol)  H But looking at the doc, you are right, the logicals aren't there.  But ID recall there being a way to get lots of info in the log file, so theH info may have been in the release notes for 5.3 when XDM was introduced.8 Or I may have found it by reading the actual procedures.    B It has been a while, but when I learned that it didn't support MITE COOKIES and my X terminal on an old mac used MIT COOKIES, I just gave  up.   G much quicker to just use MC DECW$STARLOGIN to get the login screen onto  an X terminal.   ------------------------------   End of INFO-VAX 2006.300 ************************                                                                                                                                                                                                                                                                                                                                                                                                                      ry_entries.d
 <<< LIST >>> 150 List started.i >>> 226 Transfer completed.o
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,226)/O <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/script_files m >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/script_files.h
 <<< LIST >>> 150 List started.g >>> 226 Transfer completed.c
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,227)/N <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_filesl >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files.
 <<< LIST >>> 150 List started.l >>> 226 Transfer completed.5
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,228)d_ <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/compressed_files<} >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/compressed_files.l
 <<< LIST >>> 150 List started.  >>> 226 Transfer completed.r
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,229) t <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/compressed_files/language_independent >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/compressed_files/language_independent.
 <<< LIST >>> 150 List started.- >>> 226 Transfer completed.u
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,230)n <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/compressed_files/language_independent/os_independentd >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/compressed_files/language_independent/os_independent.c
 <<< LIST >>> 150 List started.f >>> 226 Transfer completed.<
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,231)a <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/uncompressed_filesm >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/uncompressed_files.m
 <<< LIST >>> 150 List started.- >>> 226 Transfer completed.u
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,232)>v <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/uncompressed_files/language_independent >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/uncompressed_files/language_independent.
 <<< LIST >>> 150 List started.3 >>> 226 Transfer completed.e
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,233)r <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/uncompressed_files/language_independent/os_independent8 >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/setup_files/uncompressed_files/language_independent/os_independent.d
 <<< LIST >>> 150 List started.s >>> 226 Transfer completed.I
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,12,234) P <<< CWD /freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/shell_objectsn >>> 250 Connected to /disk$misc/decus/freewarev70/htmldoc/htmldoc-1_8_23/visualc/htmldoc-free/shell_objects.
 <<< LIST >>> 150 List started./ >>> 226 Tr