1 INFO-VAX	Sun, 20 Mar 2005	Volume 2005 : Issue 158       Contents:: (",) Do You Want To Know For Sure You Are Going To Heaven?- Re: DECnet, LAT, Cterm over IP/GRE - Timeout? - Re: DECnet, LAT, Cterm over IP/GRE - Timeout?  Re: DECserver 700 differences? Re: DIFF/IGNORE=WHITE_SPACE  Re: DIFF/IGNORE=WHITE_SPACE @ Re: Fortran 77 vs. Fortran [90] and /ALIGN=MULTILANGUAGE problem Re: Memory for PWS500a Re: Memory for PWS500a Re: VMS 8.2 for VAX  Re: VMS mail nla0: as mailbox  Re: Windows anti-spyware Re: Windows anti-spyware Re: Windows anti-spyware Re: Windows anti-spyware Re: Windows anti-spyware Re: [Announce] FreeVMS 0.1.3  F ----------------------------------------------------------------------    Date: 20 Mar 2005 06:29:38 -0800 From: Ron038548@yahoo.com C Subject: (",) Do You Want To Know For Sure You Are Going To Heaven? C Message-ID: <1111328978.203472.171810@z14g2000cwz.googlegroups.com>   8 http://www.want-to-be-sure.blogspot.com << Click On Link   ------------------------------    Date: 20 Mar 2005 00:52:33 -0800) From: "Bob Gezelter" <gezelter@rlgsc.com> 6 Subject: Re: DECnet, LAT, Cterm over IP/GRE - Timeout?C Message-ID: <1111308753.371270.195930@g14g2000cwa.googlegroups.com>    Scott,  , Been there, done that, at many client sites.  E LAT is, emphatically, a LOCAL Area Network (10/100 Mbps, low latency, D low underlying error rate) protocol. Some of the situations that canG cause unpredictable behavior (well, disconnections are predictable, but ! the timing is generally not) are:  - Bridges (local and remote)9 - "transparent" bridging over IP (or other protcol) links   < The timeouts are short, and while they can be lengthened, myG recollection is that the lengthening is not of the order of delays that G are acceptable to protcols designed for WAN use, such as CTERM (DECnet)  or telnet (IP).   D telnet, and its underlying IP stacks often have disconnect detectionA values in the range of minutes. Whether this is desireable in all A situations is a debateable point. CTERM has shorter disconnection D times, but is reasonably tolerant of network "burps". A side note isC that DECnet and IP differ somewhat in how they view the network and C routing, and this does affect how they deal with changes in network F topology. Both schemes have their strong points, but they do differ in emphasis and effect.   So, to summarize:   B  LAT - Not suitable for routed/bridged connections that change its& underlying presumptions about latency.F  CTERM/DAP [DECnet] - If you see disconnects, somebody is not behavingE properly. Diagnosing this requires more information about the network  and its configuration.  ! I hope that the above is helpful.   $ - Bob Gezelter, http://www.rlgsc.com   ------------------------------    Date: 20 Mar 2005 10:20:48 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 6 Subject: Re: DECnet, LAT, Cterm over IP/GRE - Timeout?3 Message-ID: <E+A0tbRymRZQ@eisner.encompasserve.org>   g In article <BJ7%d.11507$gx3.657@tornado.rdc-kc.rr.com>, Scott Fisher <scott.fisher@remmele.com> writes:  > All, > E > (Warning, this may be a bit long, but we did lots of testing and I    > wanted to present some facts). >  > Question: H > Could we be timing out a DECserver (DS100, DS200) or Cterm across WAN G > (T1) and if so, what timers might I check?  Or, do you have a better   > idea on my problem?  >  > Situation:I > We have a WAN (T1) with Alphas, DECservers (DS100, DS200), and windows  J > boxes.  Everything is fine.  We run IP, DECnet, MOP, etc across the wan I > without problems.  The DS100 downloads across the wan without problem.     You have been lucky.  H > We want to move to MPLS which requires that all packets are IP  thus ( > the problem with the DS100 and DECnet.  % Typically a WAN costs a lot of money.   C Running in a manner not supported by the manufacturer seem improper  in such an environment.   B Going to a different environment (MPLS, whatever that is) that notA only is unsupported but also does not work is positively foolish.    ------------------------------    Date: 20 Mar 2005 09:43:59 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)' Subject: Re: DECserver 700 differences? 3 Message-ID: <QT+vd6IgeSBH@eisner.encompasserve.org>   ^ In article <1111176265.357599.325340@o13g2000cwo.googlegroups.com>, jordan@ccs4vms.com writes:G > Is either flash compatible?  They used to be available with the flash - > card socket installed but no flash present.   I Nope. One reseller tells me thay are 2 part numbers for the smae product. I Not that surprising. Yet other vendors have VERY different prices for the 
 two items.  G > My DSRVW-CA's are real antiques; not even a flash slot.  OTOH they're H > still running just fine (but then so are the DS200s and even one DS100  > once it had its fan replaced).  K Anything with a DEC logo is an antique now. THe servers still work, but I'm H losing power supplies everywhere. Just lost another since I started thisD thread. Looks like I'm going to order a handful of replacement power supplies...   1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  H Vulcans believe peace should not depend on force. -- Amanda, "Journey to Babel," stardate 3842.3    ------------------------------   Date: 20 Mar 2005 09:31:25 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>$ Subject: Re: DIFF/IGNORE=WHITE_SPACE? Message-ID: <DTiotGxQ0bj6-pn2-dnRQZdZL4224@dave2_os2.home.ours>   . On Sun, 13 Mar 2005 13:19:13 UTC, "Guy Peleg" % <guy.peleg@remove_this_hp.com> wrote:   , > Last month a request has been made in this2 > forum to add support for DIFF/IGNORE=WHITE_SPACE > ; > The request came from Dave W. but I do not have his email 6 > address so I'm announcing to the entire forum....... > 2 > I'm happy to report that we have implemented the; > request and it will ship with the next version of the O/S  >  > Here is a simple example:  >  > IPL31> ty a.c  > void main () > { ! >         status=routine_a(a,b,c)  > }  > IPL31> ty b.c  > void main () > { " >         status=routine_a (a,b,c) > } " > IPL31> diff a.c b.c/ignore=white( > Number of difference sections found: 0' > Number of difference records found: 0  > - > DIFFERENCES /IGNORE=(WHITE_SPACE)/MERGED=1- % >          $1$DKC600:[GUY.DIFF]A.C;1- $ >          $1$DKC600:[GUY.DIFF]B.C;2 >  > Guy Peleg  > OpenVMS Engineering  >  >   D Thanks very much Guy. A good reason to prepare for a move to 8.3 as  and when...    --   Cheers - Dave W.  = Sorry for the anonymity - the volume of spam got out of hand.    ------------------------------   Date: 20 Mar 2005 09:31:26 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>$ Subject: Re: DIFF/IGNORE=WHITE_SPACE? Message-ID: <DTiotGxQ0bj6-pn2-CV9Cz3ob2ZLU@dave2_os2.home.ours>   @ On Wed, 16 Mar 2005 18:40:30 UTC, JimStrehlow@data911.com wrote:  < > OpenVMS Engineering, thanks for that long awaited feature. >  <Snip>  B Jim it may be a long-awaited feature but the request that Guy has @ responded to was made on the 10'th Feb. Excellent response time 	 methinks.    --   Cheers - Dave W.   ------------------------------   Date: 20 Mar 2005 09:31:22 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>I Subject: Re: Fortran 77 vs. Fortran [90] and /ALIGN=MULTILANGUAGE problem ? Message-ID: <DTiotGxQ0bj6-pn2-B3qdfmpRhb5L@dave2_os2.home.ours>   3 On Sat, 12 Mar 2005 03:46:30 UTC, "Eric F. Milkie"   <eam23@beethoven.com> wrote:   > Hello, > C > I'm having some difficulty porting some Fortran 77 code (compiled E > /OLD_F77) to use the HP Fortran compiler.  Presented here is a test   > case illustrating the problem. >  > My Fortran versions are:: > Compaq Fortran 77 X5.5-197-48C8L on OpenVMS Alpha V7.3-2  > Compaq Fortran V7.5-2630-48C8L >  >  > Sample program TEST.FOR: >       program test >         integer*4 int1 >         integer*4 int2 >         integer*4 int3 >         integer*4 int44 >         common /test_block/ int1, int2, int3, int4' > !dec$ psect /test_block/     align=13  >       end  >  > ( > When I compile this program like this: > 6 > $ fortran /old/list test.for /align=common=multilang > = > .. the program sections in the listing file appear as such:  > PROGRAM SECTIONS > = >     Name                                 Bytes   Attributes  > e >   1 $CODE$                                  68   PIC CON REL LCL   SHR   EXE NORD NOWRT NOSEC OCTA  d >   2 $LINK$                                  56 NOPIC CON REL LCL NOSHR NOEXE   RD NOWRT NOSEC OCTAc >   3 TEST_BLOCK                              16 NOPIC OVR REL GBL NOSHR NOEXE   RD   WRT NOSEC *8K  > 0 >     Total Space Allocated                  140 >  > " > But when I compile it like this: > 2 > $ fortran /list test.for /align=common=multilang >   > ... the psects look like this: > PROGRAM SECTIONS > = >     Name                                 Bytes   Attributes  > ^ >   1 $CODE$                                  68   PIC CON REL LCL   SHR   EXE NORD NOWRT OCTA^ >   2 $LINK$                                  56 NOPIC CON REL LCL NOSHR NOEXE   RD NOWRT OCTA] >   3 TEST_BLOCK                            8192 NOPIC OVR REL GBL NOSHR NOEXE   RD   WRT *8K  > 0 >     Total Space Allocated                 8316 >  > d > This new behavior of padding to fill the entire aligned psect is causing me linking trouble, sincef > the psect is now longer than other programs' compiled with F77 with the same COMMON block.  But if Ik > turn off MULTILANGUAGE, it will link with F77 but not with C object code, since that's the whole point of h > using MULTILANGUAGE.  How do I fix this?  Is this a bug or did I just not scour the manuals thoroughlyN > enough? I still want the linker to align TEST_BLOCK psect on an 8k boundary. >  > -Eric    Hi Eric E                been away two weeks so have only just seen this. When  A you say "doesn't link' what do you mean? Does the linker issue a  E warning or an error message. Does it create an image and does it run.   D You quote to VMS versions X5.5. and V7.5; which one did you compile 7 your test with. The list and/or map file will tell you.   F I've not used the align = multilanguage so am not sure how it relates F to NATURAL or PACKED which are the things that normally cause problemsC because items in memory can then take different addresses. Here it  C _looks_ as if the qualifier and/or directive is ensuring the psect  F inhabited by the common fills a complete Alpha physical page. In that ( case I'd still expect the program to run  : I'll have to check what the psect directive align=13 does.   --   Cheers - Dave W.   ------------------------------  % Date: Sun, 20 Mar 2005 06:10:44 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: Memory for PWS500a ( Message-ID: <opsnxwb6x5zgicya@hyrrokkin>  9 On 19 Mar 2005 20:53:32 -0800, johnhreinhardt@yahoo.com   ! <johnhreinhardt@yahoo.com> wrote:    > Bill,  > E > I have 1GB in my PWS500. 512MB of it is 2 256MB MT18LSDT3272AG-10xx I > sticks I got on Ebay.  It's a Micron ECC, non-Reg, double-sided 18-chip H > PC100 CL2 stick.  I've bought a few and they work great in the PWS and
 > the AS1200.  > B > Funny thing is I used to have 4x256MB Infinion memory but it wasD > registered (which I tried because I thought a thread here had saidF > registered DIMMs were needed).  They worked great under SRM and VMS,H > but when I went to boot ARC to run the DAC960 raid utilities it alwaysE > hung.  I switched to the non-registered and now it works fine under  > both SRM and ARC.  > D > Sorry to wander, the point is if you search for MT18LSDT3272AG-10*I > memory on Ebay they will work.  The "-10xx" means they are PC100 speed. I >  If they are "-13xx" that is PC133.  I think those should work but I've G > not tried them.  Currently expect to pay somwhere in the neighborhood H > of $40 a stick for the 256MB.  The last batch of 5 I bought I paid $46 > each (shipping included) > I > If you can't find that particular memory, then any "low-density" PC100, I > ECC, non-registered should work also.  If you get the 256MB sticks look G > for ones with 18 chips. I don't know if the PWS memory controller can F > handle the higher density 9-chip versions.  If you can't find the CLC > rating in the description look for it on a picture of the memory. I > Usually it will be a string of 3 numbers, either "222" for CL2 or "322" C > for CL3.  Tom maybe right about CL3 working but I don't know from < > experience and I have not found the specs online anywhere.   DIMM Size		Chips/DIMM 
 72 bit ECC     16			3 or 9  32			5 0r 18  64			9 unbuffered or 36 buffered 128			18 256			36 buffered   D Now this spec is old and apparently 18 ubuffered works on 256 DIMMs,& I suspect 9 ubuffered would work also.   >  >  Hope this helps.  >  >    John H. Reinhardt >    ------------------------------    Date: 20 Mar 2005 10:16:56 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Memory for PWS500a 3 Message-ID: <bMnqhRPuN8TQ@eisner.encompasserve.org>   ^ In article <1111280670.950280.248130@f14g2000cwb.googlegroups.com>, mcbill20@yahoo.com writes:F > Hello all. I did a search of C.O.V. for info on memory for a PWS500a > and only found one thread.  C That makes sense, since this is a VMS newsgroup and the PSW500aU is  required for VMS support.    ------------------------------  % Date: Sun, 20 Mar 2005 09:44:16 -0500 # From: "John Smith" <a@nonymous.com>  Subject: Re: VMS 8.2 for VAX, Message-ID: <jtydnWxktMjYEaDfRVn-tw@igs.net>   JF Mezei wrote: = >>> But they accellerated the schedule for SuperDome support.  >>> 8 >>> When you change the schedule, something has to give. >  > H > The REAL question is whether VMS engineering will grow , stay the sameC > or shrink now that the Intel subsidized port to IA64 is complete.  > E > The ever shrinking roadmap leads me to believe that VMS engineering 6 > resources are not growing and are perhaps shrinking. > B > There is still a large gap with teh TCPIP services for instance,> > especially with regards to the applicatiosn such as SMTP. IfF > Digital/Compaq/HP/whatever isn't willing to put in the money to keep= > those products up to date, then they should open source the F > applications, and keep the TCPIP kermel inside VMS engineering to be > part of VMS. > G > Same with Motif. If they aren't going to upgrade to fcurrent versions E > of motif, they should open source the VMS specific portions so that ( > we can port the open source Motif 2.*. > F > The reality is that the focus seems to be on providing features that= > serve a small number of customers (such as fancy clustering D > interconnect between planets), while features that coudl benefit a? > large marklet place don't have priority, probably because VMS 9 > management has lost any hopes of capturing that market.  > H > When you consider the potential for Charon VAX to introduce VMS to theF > masses, you'd think that VAX VMS would have some strategic advantage > to regrow VMS.    J Tell me which prospective *new* VMS customer is deliberately going to tell their senior management,  K "We want to purchase an application which works fine but is no longer under H development to run on an operating system which has half-hearted supportK from its vendor, that is for an obsolete computing architecture, which runs L on a hardware emulator provided by a third company, running on hardware fromH a fourth company, all of which runs on top of that known virus incubator called Microsoft Windows."?      --L OpenVMS - The never advertised operating system with the dwindling ISV base.   ------------------------------  + Date: Sun, 20 Mar 2005 07:30:09 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)& Subject: Re: VMS mail nla0: as mailbox$ Message-ID: <d1j8q1$dn4$1@online.de>  6 In article <423CEC21.183CEB9D@vaxination.ca>, JF Mezei( <jfmezei.spamnot@vaxination.ca> writes:   $ > $create TCPIP$SMTP_COMMON:NLA0.DIS  F As one can see from the structure of the SMTP queues, it appears that I whoever implemented TCPIP on VMS had only a limited understanding of the  F concept of a cluster.  This is perhaps the reason why the default for : TCPIP$SMTP_COMMON appears to be SYS$SPECIFIC:[TCPIP$SMTP].,            ^^^^^^                   ^^^^^^^^  E I don't have any distribution lists (empty or not) in this directory, E but I do have TCPIP$SMTP_LOCAL_ALIASES.TXT.  Am I correct in assuming 9 that I could redefine TCPIP$SMTP_COMMON to point to, say, @ SYS$COMMON:[TCPIP$SMTP] (assuming this exists) and have just oneH TCPIP$SMTP_LOCAL_ALIASES.TXT for all systems which use that system disk?G (At the moment, I don't have any satellites, and each node has its own  I system disk, so this is not something I really need at the moment, but I  F am asking in order to understand the concept, also in relation to the  next paragraph.)  0 Taking this a bit further, if I want to have oneI TCPIP$SMTP_LOCAL_ALIASES.TXT for the entire cluster (with several system  : disks), could I define TCPIP$SMTP_COMMON to point to, say,E CLUSTER_SMTP, where CLUSTER_SMTP is a directory on a non-system disk  G which is visible from all nodes in the cluster (I have CLUSTER_MANAGER, H CLUSTER_SYSTEM and CLUSTER_LIBRARY to hold files pointed to by logicals B in SYLOGICALS.COM (actually, SYLOGICALS.COM mounts this disk then G executes a procedure on it defining these logicals) such as SYSUAF.DAT  I which are by default in SYS$SYSTEM etc)?  However, I would probably want  E other stuff such as TCPIP$SMTP_RECV_RUN.LOG to remain in the default  % location (SYS$SPECIFIC:[TCPIP$SMTP]).   G Does anyone have a list of ALL the TCPIP logicals, what their defaults  H are and, most important, which applications use them (or rather, in the F case of directories, which files are located in a "logical" directory % and which in a "physical" directory)?    ------------------------------   Date: 20 Mar 2005 09:31:29 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>! Subject: Re: Windows anti-spyware ? Message-ID: <DTiotGxQ0bj6-pn2-YQgvS7jsB09z@dave2_os2.home.ours>   E On Wed, 16 Mar 2005 15:30:02 UTC, greigaln@netscape.net (Alan Greig)   wrote:   > Bob Koehler wrote: > > I > >    I've been using Ad-Aware and Spybot ever since one of my coworkers I > >    used them to recover a "slow" PC.  When I told Windows to go ahead M > >    and download the MS tool, it never said anything about install or run.  > H > If I understand correctly that it failed to download and if running XPF > Service Pack 2 you might be falling victim to the changes to defaultG > security actions. XP Service Pack 2, by default, blocks needed popups G > and installations even from Microsoft's own update site. If downloads G > fail on SP2 it is always worth checking for miniscule lines under the G > browser toolbar referring to blocked popups, Active-X etc. Just click H > them. Occasionally you have to go round this loop a couple of times to > get everything.  > 4 > ALso I believe the tool is Windows 2000 and later.  D Just downloaded it and tried to install it. As wirth so many things C these days, the installer winges about needing IE 6. So I'll stick  D with Adaware. The same reason Acrobat reader stays at 5. V6 says it  needs IE6 to install - bah !!!   --   Cheers - Dave W.   ------------------------------  % Date: Sun, 20 Mar 2005 13:01:13 +0100 3 From: Wilm Boerhout <w4OLD.boerhout@PAINTplanet.nl> ! Subject: Re: Windows anti-spyware 6 Message-ID: <423d6609$0$31016$ba620dc5@nova.planet.nl>  I It (Antispyware, Acrobat V7) needs IE6 present to install. Nobody forces  B you to use IE after installing. I use Firefox and Thunderbird for , Mail/News/Internet, and IE6 just sits there.  H Of course, there's the risk that Acrobat or Antispyware actually uses a , IE6 library/DLL. Have not observed that yet.   Wilm  8 Dave Weatherall spoke the wise words on 20-3-2005 10:31:  F > Just downloaded it and tried to install it. As wirth so many things E > these days, the installer winges about needing IE 6. So I'll stick  F > with Adaware. The same reason Acrobat reader stays at 5. V6 says it   > needs IE6 to install - bah !!! --  
 Wilm Boerhout  Zwolle, The Netherlands   ( w4OLD dot boerhout at PAINTplanet dot nl2    (remove OLD PAINT from return address to reply)   ------------------------------  % Date: Sun, 20 Mar 2005 06:19:49 -0800 # From: "Tom Linden" <tom@kednos.com> ! Subject: Re: Windows anti-spyware ( Message-ID: <opsnxwrblzzgicya@hyrrokkin>  3 On Sun, 20 Mar 2005 13:01:13 +0100, Wilm Boerhout   & <w4OLD.boerhout@PAINTplanet.nl> wrote:  L > It (Antispyware, Acrobat V7) needs IE6 present to install. Nobody forces  E > you to use IE after installing. I use Firefox and Thunderbird for   . > Mail/News/Internet, and IE6 just sits there. > G Ditto, but with Opera.  How does Firefox compare to Opera, if you know?   K > Of course, there's the risk that Acrobat or Antispyware actually uses a   . > IE6 library/DLL. Have not observed that yet. >  > Wilm > : > Dave Weatherall spoke the wise words on 20-3-2005 10:31: > H >> Just downloaded it and tried to install it. As wirth so many things  L >> these days, the installer winges about needing IE 6. So I'll stick with  I >> Adaware. The same reason Acrobat reader stays at 5. V6 says it needs    >> IE6 to install - bah !!!    ------------------------------  % Date: Sun, 20 Mar 2005 17:25:22 +0100 3 From: Wilm Boerhout <w4OLD.boerhout@PAINTplanet.nl> ! Subject: Re: Windows anti-spyware 6 Message-ID: <423da3f3$0$31008$ba620dc5@nova.planet.nl>  H I recall having installed Opera a few years ago, didn't like it then. I " have no recent experience with it.  5 Tom Linden spoke these wise words on 20-3-2005 15:19:   I > Ditto, but with Opera.  How does Firefox compare to Opera, if you know?    --  
 Wilm Boerhout  Zwolle, The Netherlands   ( w4OLD dot boerhout at PAINTplanet dot nl2    (remove OLD PAINT from return address to reply)   ------------------------------    Date: 20 Mar 2005 12:30:52 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ! Subject: Re: Windows anti-spyware 3 Message-ID: <aKl+IdgZj9Zk@eisner.encompasserve.org>   : This does not seem to have anything at all to do with VMS.  A Can't you folks find somewhere else to discuss Windows problems ?    ------------------------------  % Date: Sun, 20 Mar 2005 07:28:39 -0800 # From: "Tom Linden" <tom@kednos.com> % Subject: Re: [Announce] FreeVMS 0.1.3 ( Message-ID: <opsnxzx1a5zgicya@hyrrokkin>  K On Sun, 20 Mar 2005 10:32:27 +0100, Karsten Nyblad <nospam@nospam.nospam>    wrote:   > Bill Gunshannon wrote:+ >> In article <opsnv4hzn6zgicya@hyrrokkin>, ) >> 	"Tom Linden" <tom@kednos.com> writes:  >>J >>> On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <bill@cs.uofs.edu> wrote: >>>  >>> 8 >>>> In article <aaA98OreXGZ2@eisner.encompasserve.org>,5 >>>> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:  >>>>> >>>>> In article <XMJ_d.4266$uw6.4216@trnddc06>, John Santos   >>>>> <john@egh.com>  writes:  >>>>>  >>>>> C >>>>>> This is where C loses.  To write safe code in C, you have to H >>>>>> bounds-check everything, and verify all string and buffer lengths >>>>>> and do it religiously.  >>>>>>A >>>>>> If all your code is reviewed and you always parameterize    >>>>>> *everything* J >>>>>> (so e.g. when someone changes the maximum size of a variable, everyI >>>>>> thing uses the correct new size automatically) and you have a good I >>>>>> version control system so everything gets recompiled when it needs D >>>>>> to be, and your subroutines are all prepared to deal with theI >>>>>> memory faults they might get when someone passes a null-terminated I >>>>>> string and forgets to add the null at the end, etc. etc., then you I >>>>>> can use C safely.  But isn't it easier to use a language that does G >>>>>> this for you and never forgets to check something, "because it's F >>>>>> just a little 1-byte local temp string and what can possibly go >>>>>> wrong?" >>>>> I >>>>> Ultimately, the problem is how does one _prove_ that all the proper + >>>>> steps were taken in a giant program ?  >>>>> H >>>>> Looking at a not-so-giant program, when DEC wrote an A1 Security   >>>>> KernelI >>>>> for the high-end VAX, they wrote it in Pascal, with no RTL allowed, A >>>>> in order to support mathematical proof of code correctness.  >>>>K >>>> And, did the code reviews include looking at the source for the Pascal K >>>> compiler as well?  If not, then you had no "mathematical proof of code J >>>> correctness".  Some things can not be "proven" to any real degree off >>>> certainty.  >>> E >>> There is still the Trojan horse issue as we have discussed before 7 >>> http://www.acm.org/classics/sep95/  by Ken Thompson A >>   That has already been mentioned here inthe recent past but I > >> also meant it is possible for the compiler to make mistakes? >> too.  And the more complex the language the more possible it @ >> becomes for an error to sit silently by waiting for the right2 >> combination of code to bring it to the surface. >>  bill > G > Actually this goes beyond the compiler.  You also have to prove the   J > correctness of the computer, including firmware and microcode.  Let us  L > assume that you have actually proved that.  Then you have to ensure that  J > the computer always work correctly no matter what, e.g., there may not  @ > be a single gate in some chips, that fails every 10**20 times. > K > Such proofs are so big that no human can carry them out without errors.   J >   Thus you have to have computer programs to check the proofs and then  G > you have to prove the correctness of the theorem provers.  But Kurt   J > Gdel proved in 1931 that in order to prove the consistency of a logic  G > you need a more powerful logic.  There are theorem provers that are   L > build to have a small trusted core that does the logical inferences, but  5 > even those small cores have been subject to errors.  > C > Then there is an other issue.  Somehow you have to convert your   L > requirement specification into logical formals before you can attempt to  L > prove that these formulas are theorems, but there is no 100% safe way of  K > to carry out that conversion.  To me that is a much more severe problem   L > than the problem of the correctness of the tools.  Besides, once we have  E > a method for developing correct programs, that method can also be   ' > applied to compilers and other tools.  > J > However, people tend to say that because there is no way of making the  H > perfect system to guarantee the correctness of computer systems, the  G > idea should be abandoned.  I do not think so.  We have to live with   I > technology that fails.  I cannot be 100% sure that the building, I am   L > sitting in while writing this, will not collapse.  I cannot be sure that  I > the computer screen in front of me will not implode and spray me with   C > glass splinter.  Why not use these methods an get the orders of   I > magnitude of better correctness that could most likely gained that way?   B Somewhat reminiscent of Hilbert's response to the Russell Paradox.2 http://plato.stanford.edu/entries/russell-paradox/   ------------------------------   End of INFO-VAX 2005.158 ************************