1 INFO-VAX	Sat, 09 Sep 2000	Volume 2000 : Issue 505       Contents: Re: aircraft are not Sun Re: aircraft are not Sun Re: aircraft are not Sun Re: DECSERVER 90m AND TCPIP ( Re: GTK+ now available for OpenVMS Alpha( Re: GTK+ now available for OpenVMS Alpha# Re: Is there any new Alpha CPU out? + Re: Jupiter (was Re: Q: Why not (2^n)-bit?) + Re: Jupiter (was Re: Q: Why not (2^n)-bit?) % Re: Off-Topic: DS10 Hardware question  Re: Q: Why not (2^n)-bit?  Re: RTR and DECdtm! Re: Sun Hardware problems persist ! Re: Sun Hardware problems persist P Re: visual interpretation of algorithms. -> Sound interpretation of algorythmes.% Re: Why I hate C on VMS, reason #9321 % Re: Why I hate C on VMS, reason #9321 % Re: Why I hate C on VMS, reason #9321 % Re: Why I hate C on VMS, reason #9321  Xwindows tcpip  F ----------------------------------------------------------------------  % Date: Sat, 09 Sep 2000 18:37:26 +0010 % From: paddy.o'brien@zzz.tg.nsw.gov.au ! Subject: Re: aircraft are not Sun 5 Message-ID: <01JTZ9CIPW820040ZP@tgmail.tg.nsw.gov.au>    Darren Boyle said:  7 >> From: 	jgessling@YAHOO.COM[SMTP:jgessling@YAHOO.COM]  >>  G >> I guess this does confirms that well engineered products can operate I >> successfully under conditions outside of what the specs call for.  :-)  >>   >>  # >Sounds like it was modelled on VMS     O Yes, and if it is succesful, it is claimed as legacy.  I do a lot of flying in  O .au, but I would hate to fly Unix or Microsoft,  I think the ticketing is on a  N Unix system for Ansett but on VMS for Qantas.  I like to fly Qantas, so don't  disallusion me.    Regards, Paddy   Paddy O'Brien, Transmission Development, 
 TransGrid, PO Box A1000, Sydney South,  NSW 2000, Australia    Tel:   +61 2 9284-3063 Fax:   +61 2 9284-3050& Email: paddy.o'brien@zzz.tg.nsw.gov.au  M Either "\'" or "\s" (to escape the apostrophe) seems to work for most people, ; but that little whizz-bang apostrophe gives me little spam.    ------------------------------   Date: 9 Sep 2000 15:15:57 GMT ) From: leslie@clio.rice.edu (Jerry Leslie) ! Subject: Re: aircraft are not Sun ' Message-ID: <8pdk7d$a1s$1@joe.rice.edu>   1 Richard B. Gilbert (DRAGON@compuserve.com) wrote: D : ISTR he was fired for it too!!!  But there are things a man has to : do. . . . :-)  :   H I don't think so. IIRC, he was just told NOT to do that again, accordingI to the episode of "Wings". One source credits the rolling of the Dash-80  ; jet for getting the USAF to order the KC-135 version. From:   9   http://www.snowcloude.com/~vanstry/commentary/art2.html 
   Pioneers  J   "That plane was the 707. That Company was Boeing. And Tex did something K    that will live in aviation lore forever - he did a barrel roll at 500ft  K    with a 4 engine jet to prove to the world just how good a plane it was.  M    It also proved just how good a pilot he was, though I think that was lost  J    on many there that day. And he didn't just do it once, he did it twice.  M    That feat, and that feat alone had more to do with the sale of the 707 to  K    first the USAF, and then the commercial fleets of the world's airlines,  L    then anything else. It showed them just how well made the plane was, and J    what it could do. Important things for an aircraft in any day and age."  F There's an interview at with another test pilot of that era, Al Jones:  O   http://www.microsoft.com/Games/COMBATFS/BEHIND_THE_SCENES_PILOT_INTERVIEW.HTM #   Microsoft Combat Flight Simulator   A that mentions the rolling of the Dash-80, predecessor of the 707:   A   http://www.boeing.com/companyoffices/history/boeing/dash80.html A   Boeing: History -- Post-War Developments - 367-80 | The Dash 80   C Boeing reclaimed the Dash-80 from storage for display in a museum.    @ Where's DECPAQ's Tex Johnson, willing to do some gutsy things to market VMS ?  4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Sat, 09 Sep 2000 12:47:28 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)! Subject: Re: aircraft are not Sun L Message-ID: <rdeininger-0909001247280001@user-2ivec5i.dialup.mindspring.com>  r In article <OS8u5.75797$_s1.896834@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> wrote:   > RE: aircraft are not SunM > I hate to keep an off topic going, but there was an interesting show on the K > Discovery Channel recently on jet development.  I believe the aircraft in H > the show was the 777 - one of the tests that they perform is that theyH > restrain the fuselage downward, and push upwards on the wingtips until; > failure - pretty cool when the wing snaps off - big bang.   D I saw that a few years ago.  Pretty cool. The wings lifted up a LONGI way before they broke.  It used to bother me when I looked out the window H of a plane and saw the wings bobbing up and down.  After I saw that 777,< I decided not to worry about a couple of inches of movement.  F I was also surprised at how close the actual breaking point was to the engineers' prediction.  I I was a shame to waste the whole plane testing the wings though.  (Please F don't tell me they glued the wings back on, painted it, and sold it to United.)   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Sun, 10 Sep 2000 00:43:03 +1200 4 From: "Mike Tock" <hiding_me@don't_spam.hotmail.com>$ Subject: Re: DECSERVER 90m AND TCPIP* Message-ID: <8pdb0g$gj6$1@news.ihug.co.nz>  @ "Michael Austin" <michaelaustininc@hotmail.com> wrote in message% news:39B99097.E2337F31@hotmail.com... I > This helped.... a little.  Thanks....   Now I need to figure out how to  set up a remote printer F > queue on the 90M using Telnet (without documentation...) because the routers being used do not K > understand LAT.  Which is too bad because it is a much "thinner" protocol  that TCPIP.  >  >  > Michael Austin > DBA Consultant.  >   F on the terminal server assuming you want to use port 4 on the terminal server.    define port 4 access remote 
 log port 4* change telnet listener 2004 ports 4 enableB change telnet listener 2004 ident "This funky reverse telnet port". change telnet listener 2004 connections enable   from VMS set up the queue. J init/que reverse_que/proc=ucx$telnetsym /on=node::"10.10.10.10:2004"/start  C as long as you have the gateway settings on the terminal server set K correctly you should be able to telnet directly to the port in question. ie  telnet 10.10.10.10 2004   K you get a blank line prompt but things you type on the screen will come out  on the printer.   L if your printer is on another port change the 4 to what ever.  If it doesn'tF work type playing with the telnet server settings for the port you areJ working with, I can't remember the syntax off hand, but there should be anK <LF> from the terminal, NONE from the host, NONE to the terminal and <CRLF>  to the host.  L hope that helps. if you don't want to have the IP address in the que you canI add a local host to the UCX database. so the que would say something like  reverse_que, node::"host:2004"   Cheers Mike   ------------------------------  * Date: Sat, 9 Sep 2000 12:08:13 +0000 (UTC)- From: dwparsons@nikocity.de (Dave W. Parsons) 1 Subject: Re: GTK+ now available for OpenVMS Alpha K Message-ID: <Ej0w7lFo08Zw-pn2-jFXdd8FhrvJ4@saturn.dwparsons.news.nikoma.de>   E On Wed, 9 Aug 2000 10:16:50, Colin Blake <colin@theblakes.com> wrote:    > Glen Martin wrote: >  > S > Looks like the gmake image that ships with the porting library was linked on V7.1 P > or similar, and so isn't happy on your V6.2 system. I sure someone will have aO > version that runs on V6.2. If not, you can always download gmake and build it  > yourself.  > 1 > Mind you, DEC C V5.6 is going to be pushing it.  >   G Yes the gmake that comes with the porting library was prebuilt on v7.1. F I am also using OVMS 6.2 and have built a version of gmake which worksE fine, but I am having trouble building the VMS_JACKETS due to missing J files, missing definitions and now it would seem, the compiler's inability) to handle the GENERIC_GETPWENT functions. F I'm not at the VMS box now, so I can't be more specific, but if anyoneK has succeeded in building the jackets libs with v6.2, I would be interested H to know if you had to make any changes to the build kit and if so, what.   Cheers,  --   Dave   ------------------------------  % Date: Sat, 09 Sep 2000 09:21:45 -0500 7 From: yyygac2@cccpa2.brk.navistar.com (Gerry Czadowski) 1 Subject: Re: GTK+ now available for OpenVMS Alpha 4 Message-ID: <00090909214568@cccpa2.brk.navistar.com>  ? I haven't been following this thread, but if you are seeking a  8 version of GTK+ for OpenVMS V6.2, I saw it yesterday at:   http://www.ourservers.net/  " Look in the OpenVMS ports section.   Gerry      Gerry Czadowski   P ================================================================================@ International Truck and Engine Corporation | Voice: 630-691-5660@ Navistar Information Organization          | Page:  888-350-8344@ Information Utility                        | Fax:   630-692-5638P Technical Support Truck Systems            | Email: gerry.czadowski@navistar.comF OpenVMS Systems                            | Epage: 3508344@skytel.comP ================================================================================H      My employer doesn't acknowledge my existence much less my opinions.   ------------------------------  % Date: Sat, 09 Sep 2000 17:09:26 +0930 % From: Jeremy Begg <jeremy@vsm.com.au> , Subject: Re: Is there any new Alpha CPU out?* Message-ID: <39B9E92E.EBDC6325@vsm.com.au>   "Terry C. Shannon" wrote:  > A > "Robert Deininger" <rdeininger@mindspring.com> wrote in message H > news:rdeininger-3008000158000001@user-2ive7j6.dialup.mindspring.com...J > > In article <LdRq5.55591$_s1.651572@typhoon.ne.mediaone.net>, "Terry C.- > Shannon" <terryshannon@mediaone.net> wrote:  > >  > >.... 7 > > Besides, I want one of these chips in a VMS laptop.  > L > The laptop would have to be at least three inches thick to accommodate the' > heat sink for the chip in question...   K I was wondering about that, and I'm not so sure that it has to be that way. L After all, Apple are selling PowerBooks with RISC processors running at overH 400MHz so obviously it's possible to have a high-speed CPU in a notebook form factor.   J I know that COMPAQ are focussing Alpha on the high-end, but a successor to the % Tadpole AlphaBook-1 would be nice :-)            Jeremy Begg   ;   +-------------------------------------------------------+ ;   |            VSM Software Services Pty. Ltd.            | ;   |                 http://www.vsm.com.au/                | ;   |       "OpenVMS Systems Management & Programming"      | ;   |-------------------------------------------------------| ;   | P.O.Box 801, Unley,     |  E-Mail:  jeremy@vsm.com.au | ;   | South Australia 5061    |   Phone:  +61 8 83592155    | ;   |-------------------------|  Mobile:  0414 422 947      | ;   |  A.C.N. 068 409 156     |     FAX:  +61 8 82231777    | ;   +-------------------------------------------------------+    ------------------------------  ! Date: Sat, 09 Sep 00 10:57:10 GMT  From: jmfbahciv@aol.com 4 Subject: Re: Jupiter (was Re: Q: Why not (2^n)-bit?)+ Message-ID: <8pdftp$jq1$5@bob.news.rcn.net>   - In article <8p9kpg$25cr$1@nntp1.ba.best.com>, $    inwap@best.com (Joe Smith) wrote:4 >In article <qhd7ipmcix.fsf_-_@ruckus.brouhaha.com>,6 >Eric Smith  <eric-no-spam-for-me@brouhaha.com> wrote:) >>A.Greig@viirgin.net (Alan Greig) wrote: 1 >>> Even the worst figures I've seen for the 2080 : >>> put it at 10 times the performance of the VAX 11-780.  >> >>jmfbahciv@aol.com writes: ? >>> Whoopy-skip.  It wouldn't have run a TOPS operating system.  >>, >>Really?  What would a 2080 have run, then? > I >The third-party 36-bit CPU from Systems Concepts was bug compatible with : >a KL - you could take a unmodified SYSTEM.EXE and run it  >on their hardware.   = Here's a question.  Was the Jupiter 36-bits?  I never saw one  so I really don't know.    > ; >The 2080 (and the XKL) were improvements on the KL design. H >TOPS-10 had to be modified to run on the 1080 when the KL came out, and8 >modified again to run on the 2020 when the KS came out.  ; I wouldn't call having to write a completely new CPU module 9 as a modification, Joe :-).  I usually thought of them as : the CPU device driver; note that nobody else in my hearing< ever called them that.  Thus we had KASER, KISER, KLSER, and KSSER.    E >I think Barb's point is that even if the Jupiter hardware was ready,  >the software was not.  = The device specific software could not be started until there ? was some hardware to run it on.  It is a rule of computing that ! specs never matched the hardware.   3 >  Neither TOPS-10 or TOPS-20 would have run on the ; >2080 until after many man-months of tweaking the software.   ( Tweaking, Joe?  You might try rewriting.   >  And software  >was not a priority (?!).   : Software was never a priority for the hardware types.  We 7 constantly had to fight to have a piece of new hardware 6 put on the system so developing, and more importantly,7 testing could be done.  There were always stories about ; delivery of a piece of gear to a customer, and astonishment 6 on DEC's part when the customer asked for the software to be able to use it.    /BAH    ' Subtract a hundred and four for e-mail.    ------------------------------  # Date: Sat, 09 Sep 2000 15:23:56 GMT % From: hg/jb <shsrms@bellatlantic.net> 4 Subject: Re: Jupiter (was Re: Q: Why not (2^n)-bit?)0 Message-ID: <39BA5626.BB6FD87C@bellatlantic.net>   data path was 36bits. 0 Address path was 30bits - I won't get into that.B MBOX was (not counting ECC) 36bits to cache and 36bits to CPU but % quadword fetch from the memory array. # Cache was four way set associative.  bo   jmfbahciv@aol.com wrote: > / > In article <8p9kpg$25cr$1@nntp1.ba.best.com>, & >    inwap@best.com (Joe Smith) wrote:6 > >In article <qhd7ipmcix.fsf_-_@ruckus.brouhaha.com>,8 > >Eric Smith  <eric-no-spam-for-me@brouhaha.com> wrote:+ > >>A.Greig@viirgin.net (Alan Greig) wrote: 3 > >>> Even the worst figures I've seen for the 2080 ; > >>> put it at 10 times the performance of the VAX 11-780.  > >> > >>jmfbahciv@aol.com writes: A > >>> Whoopy-skip.  It wouldn't have run a TOPS operating system.  > >>. > >>Really?  What would a 2080 have run, then? > > K > >The third-party 36-bit CPU from Systems Concepts was bug compatible with ; > >a KL - you could take a unmodified SYSTEM.EXE and run it  > >on their hardware.  > ? > Here's a question.  Was the Jupiter 36-bits?  I never saw one  > so I really don't know.  >  > > = > >The 2080 (and the XKL) were improvements on the KL design. J > >TOPS-10 had to be modified to run on the 1080 when the KL came out, and: > >modified again to run on the 2020 when the KS came out. > = > I wouldn't call having to write a completely new CPU module ; > as a modification, Joe :-).  I usually thought of them as < > the CPU device driver; note that nobody else in my hearing> > ever called them that.  Thus we had KASER, KISER, KLSER, and > KSSER. > G > >I think Barb's point is that even if the Jupiter hardware was ready,  > >the software was not. > ? > The device specific software could not be started until there A > was some hardware to run it on.  It is a rule of computing that # > specs never matched the hardware.  > 5 > >  Neither TOPS-10 or TOPS-20 would have run on the = > >2080 until after many man-months of tweaking the software.  > * > Tweaking, Joe?  You might try rewriting. >  > >  And software  > >was not a priority (?!).  > ; > Software was never a priority for the hardware types.  We 9 > constantly had to fight to have a piece of new hardware 8 > put on the system so developing, and more importantly,9 > testing could be done.  There were always stories about = > delivery of a piece of gear to a customer, and astonishment 8 > on DEC's part when the customer asked for the software > to be able to use it.  >  > /BAH > ) > Subtract a hundred and four for e-mail.    ------------------------------  " Date: Sat, 9 Sep 2000 08:08:58 GMT( From: Terry Kennedy <terry@gate.tmk.com>. Subject: Re: Off-Topic: DS10 Hardware question' Message-ID: <G0M1Ay.En2@spcuna.spc.edu>2  7 David J. Dachtera <djesys.nospam@earthlink.net> writes:aJ > For the time being however, "the world" is going USB. Time to get on the > stick and get with it...  H   I doubt the firmware will disable random USB adapters on the expansion2 bus: http://www.allusb.com/Products_Cards_PCI.html  H   For those folks with a pressing need for USB, the willingness to write8 drivers, and an open PCI slot, this might be a solution.  - 	Terry Kennedy             http://www.tmk.como5         terry@tmk.com             Jersey City, NJ USA    ------------------------------  ! Date: Sat, 09 Sep 00 10:48:36 GMTh From: jmfbahciv@aol.com " Subject: Re: Q: Why not (2^n)-bit?+ Message-ID: <8pdfdn$jq1$4@bob.news.rcn.net>M  0 In article <qh1yz2gy6x.fsf@ruckus.brouhaha.com>,7    Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:- >jmfbahciv@aol.com writes:* >> The 1091 wouldn't even have happened if@ >> somebody sane (Alan Titcomb) hadn't funded the project.  ThatA >> was another TOPS10 project that was a midnight hack (I'm using.> >> the word hack in the proper way...not the idiocy that seems >> to have evolved). >>8 >What were the technical issues to making the 1091 work? >tB >My understanding is that the 1091 hardware was basically the same >as the 2060.     As compared to the 1090:i >i >a >		1090				1091 5 >		-------------------------	------------------------a; >memory		DMA20 memory interface to	"internal" memory (whichU0 >		KI10 external memory bus	sometimes is mounted >						externally):  MA20/MB20 >						core or MF20/MG20 semiQ >a: >channels	external channels tied to	internal RH20 channels >		multiported memoryv >p4 >I/O		DIA20 interface to KI10		RH20 internal Massbus+ >		external I/O bus		channels, DIA20 avail.a >						as an option  >i% >console media	DECtape				RX01 floppyi >r- >packaging	three rack bays			two-wide "short"t >						corporate cabinet >  >tD >So obviously TOPS-10 needed new disk and tape drivers for the RH20,D >and I'm not trying to downplay the significance of that effort, but/ >I'm curious as to what else needed to be done.r  ; There's a whole lot more to shipping a piece of hardware to : the field than just doing the coding.  And with the advent: of the Project Notebook, establishing a product was almost impossible to do.   9 There is also the problem of getting signatures on littlea6 pieces of paper.  One person could hold up a ship just6 by refusing to sign, a great tool for those who wished to have their asses kissed.r   /BAH  ' Subtract a hundred and four for e-mail.t   ------------------------------  # Date: Sat, 09 Sep 2000 14:33:43 GMT ? From: Jim.Johnson@software-exploration.nospam.com (Jim Johnson)e Subject: Re: RTR and DECdtml/ Message-ID: <39ba105c.8242822@news.demon.co.uk>t   Richard,  F Thanks much for the names and pointers.  I will certainly be following1 these up, and let the newsgroup know how it goes.e  F I want to back up just a bit though, and talk again about RTR, DECdtm, and the meaning of life :-).  D First, let me be clear on one very important point -- I think RTR is@ actually quite a good product for what it does.  It has operatedD exceptionally well in a number of high performance, mission-criticalE environments.  Its success in the exchange markets is still a largely  unsung victory for Digital.t  A Having said that, there are two points that I do think need to beC made:/  C 1. What RTR does it not what DECdtm does, and vice versa.  ReliableaB queueing is not 2PC, and 2PC is not reliable queueing.  RTR gets aA request reliably, and once, to a target system.  2PC ensures thathA multiple actions can be coordinated to be a single atomic action. F They are different, and in many cases, complimentary sides of the sameD coin.  Consequently, in general it is not feasible to talk about RTR" 'replacing' DECdtm, or vice versa.  D   And, just to be clear, the MS DTC is a 2PC component, and TIP is a   2PC protocol.0    D 2. Compaq may have good reason for not extending DECdtm.  Although IF discount the technical reasons suggested, there are a few of reasons IA could easily imagine for not pursuing any further work on DECdtm..A Note well that I have not been a party to any of these decisions,y these are just my own guesses.  A   First, RTR is a charge-for product, and DECdtm is free.  If youtE   put work into RTR, you are likely to generate further revenues.  IfeB   you put work into a free facility, you are not.  Like it or not,.   the organization should be considering this.  E   Second, the organization has never had a large pool of expertise inlD   these technologies, and what they had is virtually gone.  AlthoughA   the original DECdtm team had to learn the technologies from theaB   ground up, we were helped by a pool of world-class talent in DECE   that is also almost entirely gone.  Thus, there is a learning curveaC   that would have to be built into any effort -- and this increases    risk.l  F   Third, the perceived customer need has rarely been very clear.  WhenE   we were building the first version, we had a vision of using 2PC assA   a glue for distributed applications, especially object orientednA   ones.  For a lot of reasons, that vision was never pushed  (Theg?   closest relative that I've seen to that is now to be found in,F   Microsoft's MTS/COM+ architecture, btw.  And it's much better workedB   through than our ideas were in '88).  In the absence of a 'push'E   vision, work on DECdtm depended on pull from customers.  Obviously,cF   there was little pull for our original vision (much like there wouldD   have been little direct pull for clusters from VMS customers circaD   VMS V2 -- especially if no one presented the ideas to the customer?   base in the first place).  However, there was rarely pull forLD   anything else, either.  Finally, there was one identified customerD   type: the database manufacturers, or rather Rdb.  The problem was )   that they had what they largely needed.4    Jim. Jim Johnsonr Software Exploration, Ltd.' Software Navigation and Discovery Toolsr   ------------------------------  % Date: Sat, 09 Sep 2000 06:15:04 +0100   From: Paul Sture <paul@sture.ch>* Subject: Re: Sun Hardware problems persist+ Message-ID: <VA.000000c3.069054fd@sture.ch>$  C In article <8p8q5v$177o$1@info.cs.uofs.edu>, Bill Gunshannon wrote: 3 > From: bill@triangle.cs.uofs.edu (Bill Gunshannon)l > Newsgroups: comp.os.vmsn, > Subject: Re: Sun Hardware problems persist > Date: 7 Sep 2000 19:26:55 GMT  > Reply-To: bill@cs.uofs.edu >  > Anecdote time!!iF > Back in 1971-72 I was a trainee second shift computer operator on anF > IBM 1401 at a place known as KAD in Germany (Anybody here know where > that is??).   : Go on, I'll bite. I know where Germany is (up for me :-) )  E Where, what, who is, KAD? (Yes, I _know_ it's 2 hours from Frankfurt)h   <rest snipped> ___m
 Paul Sture Switzerlandh   ------------------------------  % Date: Sat, 09 Sep 2000 06:15:05 +0100e  From: Paul Sture <paul@sture.ch>* Subject: Re: Sun Hardware problems persist+ Message-ID: <VA.000000c4.0690581e@sture.ch>e  C In article <7162F87E9EF4D311BA9900805FC1D3AE7A61D8@and02.drc.com>, 0 Ebinger . Eric wrote: + > From: "Ebinger . Eric" <EEbinger@drc.com>j > Newsgroups: comp.os.vms , > Subject: RE: Sun Hardware problems persist' > Date: Fri, 08 Sep 2000 08:59:13 -0400k >  >  > > -----Original Message-----( > > From: Steve.Spires@yellowpages.co.uk > > Bill G posted; > > I > > "Back in 1971-72 I was a trainee second shift computer operator on ansH > > IBM 1401 at a place known as KAD in Germany (Anybody here know where > > that is??). "a > > B > > Yes, it's just to the left of France as you look at the map... > >  > B > Over on your side of the pond maps get printed with south at the@ > top?  All the maps of Europe I've seen (with north at the top)6 > have Germany oriented to the right (east) of France. >  > F Come on, forgive him - he is obviously suffering from too much static!   ___E
 Paul Sture Switzerland,   ------------------------------  ! Date: Sat, 09 Sep 00 10:43:28 GMTo From: jmfbahciv@aol.comEY Subject: Re: visual interpretation of algorithms. -> Sound interpretation of algorythmes. + Message-ID: <8pdf43$jq1$3@bob.news.rcn.net>6  - In article <8pbs58$2uso$1@news.enteract.com>, &    Eric Fischer <enf@pobox.com> wrote:0 >Dale A. Dellutri <ddellutr@enteract.com> wrote: >- >> jmfbahciv@aol.com wrote:0 >>6 >> > "Dale A. Dellutri" <ddellutr@enteract.com> wrote: >> >K >> > > In the late 1960's and early 70's, the University of Chicago had theg >> > > MANIAC III. @ >> > >> > Do they still have it?    >> fB >> I doubt it, but I haven't been through the building since 1972. >pI >Was the machine in Ryerson or in the old Institute for Computer Research I >on the back of the Research Institutes?  In either case, I've spent time=K >in both buildings more recently than 1972, and it's pretty certainly gone.o > G >Fortunately there *are* still books and newsletters about it in CrerarO( >Library, shelved near call number QA76.  @ I asked because somebody, somewhen said that there was a display= of card art at UofChicago.  Anybody who saved that might havew saved old hardware.n   /BAH  ' Subtract a hundred and four for e-mail.8   ------------------------------  # Date: Sat, 09 Sep 2000 11:41:42 GMT== From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) . Subject: Re: Why I hate C on VMS, reason #93210 Message-ID: <009EFDB9.DC725CC9@SendSpamHere.ORG>   In article <4419BD3A357EFFC6.7C20317C805AAFA6.1E0C89516B947082@lp.airnews.net>, Chris Scheers <chris@applied-synergy.com> writes:c' >"Brian Schenkenberger, VAXman-" wrote:  >> b6 >> Consider the following simple C program (BBLINT.C): >>   >> #include <ssdef.h>0 >> #include <starlet.h>i  >> #define SYS$DCLEXH sys$dclexh >> < >> #include <stdio.h>t >> n >> typedef struct desblk >>   { >>     int *flink; >>     void (*exhadr)(); >>     char argcnt,__filler[3];  >>     int *cndadr;  >>   } DESBLK; >>   >> DESBLK exh; >> int final_status; >> i >> void exit_handler() >>   {H >>     printf("Accrued belly button lint has achieved critical mass\n"); >>   } >> s	 >> main()  >>   { >>     exh.argcnt = 1;" >>     exh.cndadr = &final_status;" >>     exh.exhadr = &exit_handler; >>     return SYS$DCLEXH(&exh);h >>   } >> e$ >> Now, compile it, link it, run it: >> n >> $ CC BBLINT >> $ LINK BBLINT >> $ RUN BBLINT 7 >> Accrued belly button lint has achieved critical massc >>  # >> Now, link it with the following:- >> -/ >> $ LINK BBLINT,SYS$LOADABLE_IMAGES:IMGDEF.STB  >>   >> and run it: >> v >> $ RUN BBLINT 6 >> %SYSTEM-F-ACCVIO, access violation, reason mask=04,F >>  virtual address=0000000000000014, PC=FFFFFFFF8626F130, PS=0000001B2 >> %TRACE-F-TRACEBACK, symbolic stack dump followsM >>   image    module    routine             line      rel PC           abs PC R >>                                             0 FFFFFFFF8626F130 FFFFFFFF8626F130R >>                                             0 FFFFFFFF805F2138 FFFFFFFF805F2138R >>                                             0 FFFFFFFF805F2184 FFFFFFFF805F2184R >>  EXH  EXH  __main                           0 0000000000000084 0000000000020084R >>                                             0 FFFFFFFF8626F3D4 FFFFFFFF8626F3D4 >$ >oA >I'm not convinced that this is a C problem.  I think you can get G >yourself into similar trouble using FORTRAN COMMONs.  Unfortunately, Iu7 >don't have an Alpha FORTRAN compiler loaded right now.a >cD >The simple solution is to follow the rule: If it doesn't need to beH >global, don't make it global.  (Of course, much of the Unix code I have >seen ignores this rule.)  >m >In any case, the declarationh >y >	static int final_status; >T >fixes the problem.  >>H >-----------------------------------------------------------------------% >Chris Scheers, Applied Synergy, Inc.p >bD >Voice: 817-237-3360            Internet: chris@applied-synergy.com  >  Fax: 817-237-3074    J Understanding the problem as well as a solution would really be the ideal.J The damned .LISing output from the C compiler leaves plenty to be desired.    G Here, for example, is the machine listing for the program *with static* H declared for the final_status variable.  Nowhere in the listing is thereB a storage reference for this variable.  (CC/LIST/MACHINE/SHOW=ALL)  2 				.PSECT	$CODE$, OCTA, PIC, CON, REL, LCL, SHR,- 					EXE, NORD, NOWRTd 	     0000	__MAIN:: 3 23DEFFC0     0000		LDA	SP, -64(SP)				; SP, -64(SP)E* 47E13419     0004		MOV	9, R25					; 9, R25/ B77E0000     0008		STQ	R27, (SP)				; R27, (SP)t3 B75E0020     000C		STQ	R26, 32(SP)				; R26, 32(SP)c1 B45E0028     0010		STQ	R2, 40(SP)				; R2, 40(SP) 1 B7BE0030     0014		STQ	FP, 48(SP)				; FP, 48(SP)c* 47FE041D     0018		MOV	SP, FP					; SP, FP, 47FB0402     001C		MOV	R27, R2					; R27, R23 23DEFFE0     0020		LDA	SP, -32(SP)				; SP, -32(SP)a3 A7420038     0024		LDQ	R26, 56(R2)				; R26, 56(R2) / 201D0018     0028		LDA	R0, argc				; R0, 24(FP)t- B41E0000     002C		STQ	R0, (SP)				; R0, (SP)s/ 203D0010     0030		LDA	R1, argv				; R1, 16(FP)f/ B43E0008     0034		STQ	R1, 8(SP)				; R1, 8(SP)a0 22DD0008     0038		LDA	R22, envp				; R22, 8(FP)3 A7620040     003C		LDQ	R27, 64(R2)				; R27, 64(R2)g3 B6DE0010     0040		STQ	R22, 16(SP)				; R22, 16(SP)h3 6B5A4000     0044		JSR	R26, DECC$MAIN				; R26, R26 5 2362FFB8     0048		LDA	R27, -72(R2)				; R27, -72(R2)-/ D340001C     004C		BSR	R26, MAIN				; R26, MAIN 3 A7420028     0050		LDQ	R26, 40(R2)				; R26, 40(R2)e, 47E00410     0054		MOV	R0, R16					; R0, R163 A7620030     0058		LDQ	R27, 48(R2)				; R27, 48(R2)8* 47E03419     005C		MOV	1, R25					; 1, R253 6B5A4000     0060		JSR	R26, DECC$EXIT				; R26, R26 * 47FD041E     0064		MOV	FP, SP					; FP, SP3 A75D0020     0068		LDQ	R26, 32(FP)				; R26, 32(FP)y1 A45D0028     006C		LDQ	R2, 40(FP)				; R2, 40(FP) 1 A7BD0030     0070		LDQ	FP, 48(FP)				; FP, 48(FP)g1 23DE0040     0074		LDA	SP, 64(SP)				; SP, 64(SP)J$ 6BFA8001     0078		RET	R26					; R26 47FF041F     007C		NOP						; 0 	     0080	EXIT_HANDLER::											    ; 0118193 23DEFFE0     0080		LDA	SP, -32(SP)				; SP, -32(SP)eE A61B0020     0084		LDQ	R16, 32(R27)				; R16, 32(R27)				    ; 011821a* 47E03419     0088		MOV	1, R25					; 1, R25? B77E0000     008C		STQ	R27, (SP)				; R27, (SP)				    ; 011819w1 B75E0008     0090		STQ	R26, 8(SP)				; R26, 8(SP) E A75B0030     0094		LDQ	R26, 48(R27)				; R26, 48(R27)				    ; 0118213A B7BE0010     0098		STQ	FP, 16(SP)				; FP, 16(SP)				    ; 011819 * 47FE041D     009C		MOV	SP, FP					; SP, FPE A77B0038     00A0		LDQ	R27, 56(R27)				; R27, 56(R27)				    ; 011821e6 6B5A4000     00A4		JSR	R26, DECC$GXPRINTF			; R26, R26: 47FD041E     00A8		MOV	FP, SP					; FP, SP				    ; 0118221 A75D0008     00AC		LDQ	R26, 8(FP)				; R26, 8(FP)n1 A7BD0010     00B0		LDQ	FP, 16(FP)				; FP, 16(FP) 1 23DE0020     00B4		LDA	SP, 32(SP)				; SP, 32(SP) $ 6BFA8001     00B8		RET	R26					; R26 47FF041F     00BC		NOP						; ) 	     00C0	MAIN::												    ; 011824o3 23DEFFE0     00C0		LDA	SP, -32(SP)				; SP, -32(SP) C A43B0020     00C4		LDQ	R1, 32(R27)				; R1, 32(R27)				    ; 011826R  / 			****	; R1 is loaded with address of EXH from ! 			****	; 20(16) in linkage psecte  C A41B0028     00C8		LDQ	R0, 40(R27)				; R0, 40(R27)				    ; 011827a  - 			****	; load R0 with the address stored in h, 			****	; linkage at 28(16).  (final_status)  : 47E03419     00CC		MOV	1, R25					; 1, R25				    ; 011829? B77E0000     00D0		STQ	R27, (SP)				; R27, (SP)				    ; 011824 1 B75E0008     00D4		STQ	R26, 8(SP)				; R26, 8(SP)w1 B7BE0010     00D8		STQ	FP, 16(SP)				; FP, 16(SP)d* 47FE041D     00DC		MOV	SP, FP					; SP, FPA A2210008     00E0		LDL	R17, 8(R1)				; R17, 8(R1)				    ; 011826o  1 			****	; R17 gets loaded with longword data at 8 1 			****	; bytes into EXH structure.  This corres-t0 			****	; ponds with EXH.argcnt and __filler[3].  > 43E10010     00E4		SEXTL	R1, R16					; R1, R16				    ; 0118295 A75B0030     00E8		LDQ	R26, 48(R27)				; R26, 48(R27) E A65B0040     00EC		LDQ	R18, 64(R27)				; R18, 64(R27)				    ; 011828aG 463FF111     00F0		BIC	R17, 255, R17				; R17, 255, R17				    ; 011826   . 			****	; Hmm.  EXH.argcnt is a byte so, clear. 			****	; first byte in R17.  (Note to myself:/ 			****	; $DCLEXH documentation states this MBZu0 			****	; and from the looks of this, it may not 			****	; be!)    A B001000C     00F4		STL	R0, 12(R1)				; R0, 12(R1)				    ; 011827   . 			****	; here, final_status address is stored 			****	; into EXH.i  D 42203011     00F8		ADDL	R17, 1, R17				; R17, 1, R17				    ; 011826  . 			****	; exh.argcnt = 1;  0 byte add 1.  Note/ 			****	; that none of the __filler[3] is zero!   E A77B0038     00FC		LDQ	R27, 56(R27)				; R27, 56(R27)				    ; 011829yA B2410004     0100		STL	R18, 4(R1)				; R18, 4(R1)				    ; 011828 A B2210008     0104		STL	R17, 8(R1)				; R17, 8(R1)				    ; 011826,  / 			****	; put longword (argcnt and __filler[3]) " 			****	; back into EXH structure.  D 6B5A4000     0108		JSR	R26, SYS$DCLEXH				; R26, R26				    ; 011829* 47FD041E     010C		MOV	FP, SP					; FP, SP1 A75D0008     0110		LDQ	R26, 8(FP)				; R26, 8(FP)a1 A7BD0010     0114		LDQ	FP, 16(FP)				; FP, 16(FP)e1 23DE0020     0118		LDA	SP, 32(SP)				; SP, 32(SP)e$ 6BFA8001     011C		RET	R26					; R26  5 				.PSECT	$LITERAL$, OCTA, PIC, CON, REL, LCL, SHR,-e 					NOEXE, RD, NOWRTrC 72636341     0000		.ASCII	\Accrued belly button lint has achieved\-e/ 20646575     0004			\ critical mass\<10><0>\<0>t 6C6C6562     0008			          ...     000A     0034			  / 				.PSECT	$LINK$, OCTA, NOPIC, CON, REL, LCL,-0 					NOSHR, NOEXE, RD, NOWRT  / 	     0000		; Stack-Frame invocation descriptor- 				Entry point:	       MAIN= 				Registers used:        R0-R1, R16-R27, FP, F0-F1, F10-F30u 				Registers saved:       FPe 				Fixed Stack Size:      32c    00000000     0020		.ADDRESS  EXH" 00000000     0028		.ADDRESS  $BSS$  	     0030		.LINKAGE  SYS$DCLEXH) 00000000     0040		.ADDRESS  EXIT_HANDLER2  / 	     0048		; Stack-Frame invocation descriptorD 				Entry point:	       __MAIN= 				Registers used:        R0-R2, R16-R27, FP, F0-F1, F10-F30t! 				Registers saved:       R2, FP  				Fixed Stack Size:      64t   	     0070		.LINKAGE  DECC$EXITd 	     0080		.LINKAGE  DECC$MAIN,  / 	     0090		; Stack-Frame invocation descriptoro$ 				Entry point:	       EXIT_HANDLER= 				Registers used:        R0-R1, R16-R27, FP, F0-F1, F10-F30h 				Registers saved:       FP  				Fixed Stack Size:      32o  & 00000000     00B0		.ADDRESS  $LITERAL$# 	     00C0		.LINKAGE  DECC$GXPRINTF     K The hex offsets in the psect breakouts is great but why are decimal offsetslL used in the code?  Just more C compiler brain damage.  Note that EXH is ref-K erenced in the above.  At offset 20(16) in the MAIN linkage section.  WhereH is EXH?  $BSS$?n  J The value final_status is declared outside of the routines in this code soJ it is visible to all of the routines in this module.  Therefore, I assume,K it is not allocated on the stack of any of these routines but in some psectsK set aside for this data.  I might be wrong but I would thing so as the var- 4 iable wouldn't exist until the routine is activated.  I Funny thing is that I changed the name from main() to establish_handler()bI to rid my listings of the __MAIN code.  The rest of the code generated is G exactly the same.  In addition, if I remove the 'static' the exact same G code is generated.  The .ADDRESS at 28(16) changes to read FINAL_STATUSh instead of $BSS$.o   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMu            rO city, n., 1. a place where trees are cut down and streets are named after them.    ------------------------------   Date: 9 Sep 2000 13:49:48 GMT 1 From: JONESD@er6.eng.ohio-state.edu (David Jones)i. Subject: Re: Why I hate C on VMS, reason #9321: Message-ID: <8pdf5s$2lg$1@charm.magnus.acs.ohio-state.edu>  0 In message <009EFDB9.DC725CC9@SendSpamHere.ORG>,A   system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:h >>> $ CC BBLINTn >>> $ LINK BBLINTa >>> $ RUN BBLINT8 >>> Accrued belly button lint has achieved critical mass >>>n$ >>> Now, link it with the following: >>>m0 >>> $ LINK BBLINT,SYS$LOADABLE_IMAGES:IMGDEF.STB >>>a >>> and run it:n >>>n >>> $ RUN BBLINT7 >>> %SYSTEM-F-ACCVIO, access violation, reason mask=04, G >>>  virtual address=0000000000000014, PC=FFFFFFFF8626F130, PS=0000001Bu3 >>> %TRACE-F-TRACEBACK, symbolic stack dump followsn  K >Understanding the problem as well as a solution would really be the ideal.,K >The damned .LISing output from the C compiler leaves plenty to be desired.T  L The 'problem' is that DEC didn't conform to their prefixing rules for globalJ symbols so IMGDEF.STB defines a value (20) for symbol FINAL_STATUS.  As anE external variable, the C compiler treats that value as the address offG a longword, which leads to the ACCVIO when image rundown tries to write.M to that address.  If imgdef.stb hadn't defined final_status, the linker would ( have magically allocated storage for it.  I If you change the declaration of final_status to "int final_status = 0;",s" the link will produce the message:  8     %LINK-W-MULDEF, symbol FINAL_STATUS multiply definedC             in module GLOBALS file SYS$COMMON:[SYS$LDR]IMGDEF.STB;1.  F since the initializer wil make the C compiler allocate storage for the1 variable and assign it's address to FINAL_STATUS.a  M Another workaround is to compile /name=as_is so FINAL_STATUS and final_status 
 are distinct.s    < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet:hL 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  + Disclaimer: Dogs can't tell it's not bacon.u   ------------------------------  # Date: Sat, 09 Sep 2000 13:59:40 GMTf= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) . Subject: Re: Why I hate C on VMS, reason #93210 Message-ID: <009EFDCD.2273F0F9@SendSpamHere.ORG>  n In article <8pdf5s$2lg$1@charm.magnus.acs.ohio-state.edu>, JONESD@er6.eng.ohio-state.edu (David Jones) writes:1 >In message <009EFDB9.DC725CC9@SendSpamHere.ORG>,aB >  system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes: >>>> $ CC BBLINT >>>> $ LINK BBLINT >>>> $ RUN BBLINT 9 >>>> Accrued belly button lint has achieved critical mass: >>>>% >>>> Now, link it with the following:> >>>>1 >>>> $ LINK BBLINT,SYS$LOADABLE_IMAGES:IMGDEF.STB  >>>> >>>> and run it: >>>> >>>> $ RUN BBLINTp8 >>>> %SYSTEM-F-ACCVIO, access violation, reason mask=04,H >>>>  virtual address=0000000000000014, PC=FFFFFFFF8626F130, PS=0000001B4 >>>> %TRACE-F-TRACEBACK, symbolic stack dump follows >eL >>Understanding the problem as well as a solution would really be the ideal.L >>The damned .LISing output from the C compiler leaves plenty to be desired. > M >The 'problem' is that DEC didn't conform to their prefixing rules for global K >symbols so IMGDEF.STB defines a value (20) for symbol FINAL_STATUS.  As an,F >external variable, the C compiler treats that value as the address ofH >a longword, which leads to the ACCVIO when image rundown tries to writeN >to that address.  If imgdef.stb hadn't defined final_status, the linker would) >have magically allocated storage for it.g >DJ >If you change the declaration of final_status to "int final_status = 0;",# >the link will produce the message:e > 9 >    %LINK-W-MULDEF, symbol FINAL_STATUS multiply defined D >            in module GLOBALS file SYS$COMMON:[SYS$LDR]IMGDEF.STB;1 > G >since the initializer wil make the C compiler allocate storage for theg2 >variable and assign it's address to FINAL_STATUS. >iN >Another workaround is to compile /name=as_is so FINAL_STATUS and final_status >are distinct.  K Thanks Dave.  That better explains it.  I can fix it by changing my programhK from FINAL_STATUS to MY_FINAL_STATUS.  I didn't look in IMGDEF but I shouldhB have.  I wondered why it was IMGDEF only which caused the problem.  , >Disclaimer: Dogs can't tell it's not bacon.  I Of course, dogs are also know for dining on their own feces so I'd not bea6 surprise about their inability to differentiate bacon.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM-            -O city, n., 1. a place where trees are cut down and streets are named after them.:   ------------------------------   Date: 9 Sep 2000 11:01:24 -0500r9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)n. Subject: Re: Why I hate C on VMS, reason #9321+ Message-ID: <cEA22Tl16IbI@eisner.decus.org>.  \ In article <39B990A9.B4E2913C@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:  N > Manually removing the lint from the belly button would do the trick too, andP > no fancy linker problems to contend with. However, this may be a bit difficult& > to acheive in an office environment.  8 Obviously Canadians have never heard of "casual Friday".   ------------------------------  # Date: Sat, 09 Sep 2000 07:19:46 GMT  From: thguest@nusun.jinr.ruI Subject: Xwindows tcpipe) Message-ID: <8pcoaa$srp$1@nnrp1.deja.com>   K How to open the X DISPLAY on my vax station, when the "export" and "setenv"rK commands do work, but the connection is not established. There	must be somel+ command under vms to allow this connection.o  ? It worked but then the vms crashed and after reboot the Xservern does not listen on tcp port. Thanks"                             Martin    & Sent via Deja.com http://www.deja.com/ Before you buy.-   ------------------------------   End of INFO-VAX 2000.505 ************************