1 INFO-VAX	Tue, 31 Dec 2002	Volume 2002 : Issue 723       Contents:1 Re: "VMS will be around long after we retire" ... 1 Re: "VMS will be around long after we retire" ... 8 Re: deporter the boot message from the console in a file Re: E-mailing pgm output! Re: First Hammer performance test  Re: is VMS really easy to use? Re: is VMS really easy to use? Re: is VMS really easy to use? Re: is VMS really easy to use? Re: is VMS really easy to use? Re: Link errors.1 Re: Of Galaxy, Infiniband and Distributed Caching 1 Re: Of Galaxy, Infiniband and Distributed Caching ! Pathworks MAC (printer) debugging % Re: Pathworks MAC (printer) debugging ; Re: Retrieve RMS Key information at runtime (using Fortran) ; Re: Retrieve RMS Key information at runtime (using Fortran) ; Re: Retrieve RMS Key information at runtime (using Fortran) 	 Re: rrd40  Re: vax6k.openecs.org rebirth  Re: vax6k.openecs.org rebirth > Re: Volume Shadowing (was: Re: Hello Kieth Parris... pls help)- VT220/320 Terminal emulator for Linux client? 1 Re: VT220/320 Terminal emulator for Linux client? ! [ANNOUNCE] OpenSSL 0.9.7 released   F ----------------------------------------------------------------------  % Date: Mon, 30 Dec 2002 10:32:34 -0800 1 From: Jason Brady <jrbrady@nospam.mindspring.com> : Subject: Re: "VMS will be around long after we retire" ...8 Message-ID: <4l311v8psmcgl73cck9hscmcq84c02jn34@4ax.com>  F On Tue, 24 Dec 2002 15:28:23 -0400, JF Mezei <jfmezei@vl.videotron.ca> wrote:   > O >A poof (gay) jumps on your back. Do you let him do it or do you pull him off ?  >   @ Some of us in the VMS community don't appreciate your homophobicE comments.  They are irresponsible, violent, and have no place in this C newsgroup.  On one hand you complain about VMS' alienation from the F mainstream I.T. world, but with the other you are doing the same thing- to a societal group you apparently condemn.     E I thought we are all I.T. professionals.  Let's stick with the topic, 3 people, and leave our personal biases to ourselves.   H >> Well, pornographic spam seems to be effective (otherwise why it be so >> prevalent?).  > N >The big question is what happens when you take that magic pill twice. Does itI >grow by 6" ? Does it continue to grow if you continue to take the pill ?    ------------------------------  + Date: Mon, 30 Dec 2002 23:50:04 +0100 (CET) % From: Nomen Nescio <nobody@dizum.com> : Subject: Re: "VMS will be around long after we retire" ...8 Message-ID: <c612951cd890006aab0dfb518d2eca33@dizum.com>   > F >A poof (gay) jumps on your back. Do you let him do it or do you pull 
 him off ?  >    H "Some of us in the VMS community don't appreciate your homophobic       G comments.  They are irresponsible, violent, and have no place in this   G newsgroup.  On one hand you complain about VMS' alienation from the     G mainstream I.T. world, but with the other you are doing the same thing  , to a societal group you apparently condemn."  @ Give us a break.  You escalate it to "violence language" becauseE that is a weak and pitiful technique and all you got.  He didn't say  ) pull him off and give him a good beating.   F Homophobic?  Let's be real.  3% of the world is of that bent.  If you E visualize it for just a bit, you want to puke don't you?  Meaning it  B ain't natural.  Just plumb ain't natural and a fringe element withB favoritisim and language censorship angles as they certainly can'tG convince people that there is a moral right in "up the chute" with each @ other.  Oh dear me lets get some hate legislation passed so when8 someone says something very naughty they can be fined or@ jailed.  Sure wish I could get someone fined or jailed when theyF say something naughty about me.  Must be nice to be a privliged group.   bleccchhhhhhhh.    ------------------------------  % Date: Mon, 30 Dec 2002 21:05:36 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>A Subject: Re: deporter the boot message from the console in a file / Message-ID: <3E10ED5F.41807D71@vl.videotron.ca>    "serge.zangheri" wrote: E > I configured the tta2 term as opa0 (speed, etc) in order to get the C > console messages in this decterm, after I can put them in a file. E > I created a term as follow create /term /input=tta2. But there's no  > signal on this blank decterm.   D You might want to create the decterm and once at the $ prompt, issue# 	 SET HOST/DTE TTA2:/LOG=myfile.txt   T You want your keyboard input to go to TTA2, and data from TTA2 to go to your screen.   ------------------------------   Date: 30 Dec 2002 21:49:42 GMT# From: hoff@hp.nospam (Hoff Hoffman) ! Subject: Re: E-mailing pgm output * Message-ID: <auqf1m$h2e$4@web1.cup.hp.com>  n In article <69d784c4.0212240802.4b3859cb@posting.google.com>, Jack.Trachtman@vmmc.org (Jack Trachtman) writes:C :We run all third party pkgs on our hosts, ie we can't modify them.   @   Sure you can.  (PATCH is an amazingly capable text editor. :-)  K :Occassionaly I get user requests to be able to automatically e-mail output @ :form an app that can only either be put into a file or put into
 :a print que.  : H :What tricks are people using to redirect this kind of output to e-mail?  F   If placed into a print queue, find or create a symbiont which emailsE   the enqueued messages.  There are various example symbionts around, C   and the MAIL API is documented in the utility routines reference. E   (It would not surprise me to learn that a symbiont already exists.)   C   If placed into a file, a periodic search or some hackery would be D   required.  Search for files of a known name in a known directory, &   and RENAME and MAIL all files found.  G   My personal favorite is to post the stuff in a notes conference, with F   Notes directly or using the Notes API.  (A PC Notes client is on the?   Freeware website, as is the OpenVMS Notes API documentation.)     N  ---------------------------- #include <rtfaq.h> -----------------------------J       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.comN  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  % Date: Mon, 30 Dec 2002 10:07:50 +0000 ' From: Andrew Harrison SUNUK Consultancy * Subject: Re: First Hammer performance test. Message-ID: <3E101AF6.9070004@nospamn.sun.com>   Bob Ceculski wrote: ` > Dirk Munk <munk@home.nl> wrote in message news:<fc680vs3ulrssfthkirarejoj73lcci54e@4ax.com>... > H >>The German magazine CT has issued a first comparisation test between aC >>1.2 GHz Hammer, a 1.2 GHz Athlon XP and a 2.2 GHz Pentium 4 (real  >>clock speeds). >> > A > and I am waiting to see what lawsuits hp files againset amd ... ? > some alpha people are there and most likely stole alpha stuff B > just like intel did, only Palmer was paid off to let them do it,@ > but Carly will be different ... hp should collect some hefty $ > for patent violations ...    Bob   : Its a bit difficult to sue someone for patent infringement: if they have licensed the technology from you in the first place.  + Or are you forgetting the AMD Digital deal.   4 In reality the people who should be worried and very1 probably are will be the Intel PC vendors who are / all facing potentially very damaging costs from - Intergraph which stem from Intergraphs patent  dispute with Intel.   / HP among others are in Intergraphs sights. Many / of them may well be regretting not using AMD in  more of their PC products.  / As an Intel cloner AMD will have been very very / carefull about how they design their processors / making sure that they don't infring any patents  they havn't licensed.    Regards  Andrew Harrison    ------------------------------  + Date: Mon, 30 Dec 2002 19:07:03 +0000 (UTC) 5 From: "John Wallace" <johnwallace4@yahoo.dotco.dotuk> ' Subject: Re: is VMS really easy to use? / Message-ID: <auq5gm$nlr$1@helle.btinternet.com>    doh!  D "Not that much closer than NT3.51" is what I meant to say ...  oops.  @ "John Wallace" <johnwallace4@yahoo.dotco.dotuk> wrote in message) news:auq4dn$m1d$1@helle.btinternet.com...  > / > "Z" <zarlenga@conan.ids.net> wrote in message * > news:v0q12cf0phcbd@corp.supernews.com...0 > > Rob Young <young_r@encompasserve.org> wrote:= > > : Every one of them.  How cost effective would that be or A > > : how realistic would it be to spend that money?  Not likely. > > > : Most of us could use more stable Windows too you know... > > ! > > Win 2000 is pretty damn good.  > > > > > Not quite Enterprise Critical quality yet, but damn close. > ; > Really? Not that much closer than >>>> NT 3.51 <<<<, imo.  > K > Windows 2000 is indeed a lot better than NT4 on any system I've used. But K > MS's current real offering for Enterprise Critical is Datacenter Edition.  SoI > let's look at that as our point of reference. (I'm ignoring .NET server  for I > now, though its idea of a set of language-independent runtime libraries  does1 > sound quite neat, wonder where that came from).  > K > Windows 2000 Datacenter Edition has SMP and clustering capabilities which L > might one day be comparable with a VMS from 10 years ago (or even a recentC > Unix). In the meantime its costs of ownership (compulsory support 
 contract?)G > need investigating before any purchase decision is made, and also its L > availability of quick fixes to the latest MS security flaws. (Fyi: WindowsK > Datacentre fixes are not available from MS; you have to get them from the F > hardware OEM ie Dell, HPQ, Unisys, etc. They are supposed to undergoL > extensive vendor testing before release, which kind of defeats the "quick"E > fix, but never mind. Correction/clarification welcome). The list of C > supported hardware for Datacentre Edition is also somewhat short.  > L > All versions of Windows 2000 (plus NT, XP, etc) seem to have a fundamentalE > Win32 architectural flaw which (allegedly) allows anyone capable of  running J > a program (or piece of code) to acquire privileged access to their localJ > system. Ie run code fragment non-priv, get immediate admin-class access. See % > description of "shatter" exploit at K > http://security.tombom.co.uk/moreshatter.html This isn't something MS can J > fix, it's part of the Win32 architecture. All it needs is a suitable wit toI > put this together with a buffer overflow exploit or the JVM flaw of the  weekG > and around 100% of the world's Win32 boxes can be 0wned by a bunch of  scriptL > kiddies. Where is the equivalent architectural flaw in either VMS or Unix? > 
 > have fun > john >  >    ------------------------------    Date: 30 Dec 2002 13:20:13 -0800. From: spamsink2001@yahoo.com (Alan E. Feldman)' Subject: Re: is VMS really easy to use? = Message-ID: <b096a4ee.0212301320.282f647f@posting.google.com>   X Z  <zarlenga@conan.ids.net> wrote in message news:<v0q34n11k2o2fe@corp.supernews.com>...3 > JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote: = > :> Yawn.  That's why many good sysadmins alias rm to rm -i.  >   N > : In a VMS context, it is not good de alias DELETE to DELETE/CONFIRM becauseN > : delete is used for many things other than deleting files. (DELET/ENTRY for' > : instance does not support /CONFIRM)  > @ > Even thee very-common /LOG creates problems, when using DELETE > for symbols, for example.   D It gives you an informational message. But it still works. I have no problem with it.  D You can also do DEL := DELETE/LOG and use DELE if you don't want the /LOG.   D In general, though, I agree that it is a bad idea to define a symbol that is also a command verb.   Disclaimer: JMHO Alan E. Feldman    ------------------------------  % Date: Mon, 30 Dec 2002 02:59:42 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>' Subject: Re: is VMS really easy to use? / Message-ID: <3E0FEEDB.EA10725E@vl.videotron.ca>    "Alan E. Feldman" wrote:H > A programmer was "cleaning up" on a development machine and decided toH > look at a very large file (maybe 60-90,000 blocks) and he used the EVE
 > editor. (!)   L Sacrilege :-)  I woudl never even consider submitting my all mighty microvax II to such torture :-)  E You should know however that this is what the PGFILQUOTA parameter in N Authorize is for. Not account should have a PGFILQUOTA that si larger than any! of the page files on your system.    ------------------------------  % Date: Mon, 30 Dec 2002 21:10:47 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>' Subject: Re: is VMS really easy to use? / Message-ID: <3E10EE95.4202ABF5@vl.videotron.ca>    "Alan E. Feldman" wrote:E > frequently just because a developer likes to use EVE to look at the @ > last few screens of a huge file he's considering for deletion!  I EDITR/EDT the_very_large_file.txt will save your programmer much time and G grief. BOTTOM and CHANGE will display the last page. Even though EDT is J nowhere near as good as TPU <ducking>, it does beat TPU for just viewing aM very large file. Note that going to the bottom will involve reading the whole  file but not all into memory.   M EDT is also superior to TPU wnen you need to change TAB characters in a file. ' TPU is extremely slow for such changes.    ------------------------------    Date: 30 Dec 2002 21:21:30 -0800. From: spamsink2001@yahoo.com (Alan E. Feldman)' Subject: Re: is VMS really easy to use? = Message-ID: <b096a4ee.0212302121.52e3ff8b@posting.google.com>   i bill@gw5.cs.uofs.edu (Bill Gunshannon) wrote in message news:<auo2mk$8s5at$1@ID-135708.news.dfncis.de>... ? > In article <b096a4ee.0212290032.7c93b4cc@posting.google.com>, 3 > 	spamsink2001@yahoo.com (Alan E. Feldman) writes: m > > bill@gw5.cs.uofs.edu (Bill Gunshannon) wrote in message news:<aulnok$89csf$1@ID-135708.news.dfncis.de>... B > >> In article <b096a4ee.0212281507.4b9134fc@posting.google.com>,6 > >> 	spamsink2001@yahoo.com (Alan E. Feldman) writes: > >> >  3 > >> > How would you define the factorial function?  > >>  E > >> I can't define it.  Somebody beat me to it by hundreds of years. B > >> I was rather surprised to find out that after 40 some years IA > >> had never had a single math course that actually gave me the B > >> correct definition.  Maybe that's why it has become one of myB > >> pet peeves.  Or maybe it's because I see the same inprecision" > >> in computer teaching as well. > >>  	 > >> bill  > > I > > 1. You mean they never mentioned in any of those math courses that 0! ! > > = 1? What were these courses?  > C > Nop, they mentioned that.  What they never mentioned was that the B > actual computation is much more complex and works for all cases.  6 Not true. The simple method is the actual computation.  A Short answer: The factorial function arises in the computation of E Taylor series, permutations and combinations, the binomial expansion, @ and perhaps other things. It is a very useful shorthand to avoidB having to write 1, 1, 1*2, 1*2*3, etc. It is therefore exact. OnlyF when you need to generalize its domain to non-integral real numbers do$ you need a more advanced definition.  > (The factorial function also allows one to write the otherwiseE cumbersome formulas that arise from these topics in beautiful compact E forms. [OK, they're not as beautiful in "typewriter form", but I have A no time to write up a LaTeX file, and you'd need LaTeX to read it 	 anyway.])   # Long answer: the rest of this post!   J > > 2. If you're happy with using the "wrong" definition for evaluating 1!G > > where no product is involved, it is not much of a stretch at all to H > > use it for 0! by invoking the multiplicative identity as I explained > > in a previous post.  > D > But my point is that, mathematically, factorials don't involve theD > products of all the numbers.  That's just an easier way to expressE > it requiring one exception and of course one solution that can't be ( > a product as there is only one number.  C The two are equivalent. Why use the complicated one when the simple D one will do fine? And the complicated one is a generalization of the@ simple one. You'd never have it without producing the simple one first!!! Here are the details.  B When you derive the Taylor series formula, you start by equating aC well behaved function to a general power series which is the sum of A coefficients times powers of x from 0 to plus infinity. (OK, that ? makes it a Maclaurin [sp?] series, but no generality is lost -- F actually, the Maclaurin series is a special case of the Taylor series,C so this is also a Taylor series). You repeatedly take deriviates of  that and you find that  < f(x) = f(0) + f'(0)/1 + f''(0)/(2*1) + f'''(0)/(3*2*1) + ...  @ where f'(x) is the first derivative of f w.r.t. x, f''(x) is the second..., etc.   = You can clearly see a pattern developing. So, it is obviously ? convenient to define a function, the factorial function, as the C product of positive integers from 1 to n. This enables you to write ( the above equation in the beautiful form       f(x) = Sum [f^(n)(0)]/n!    E where f^(n) is the nth derivitave of f w.r.t. x and the Sum goes from 	 0 to inf.   A THERE IS NOTHING WRONG WITH ANY OF THIS. All of it is correct and  exact.  B The factorial also comes up in the binomial expansion. When you go through it, you get   D     (1+x)^n = Sum(k=0->n) n!/[k!(n-k)!] * x^k   for n a non-negative integer   F Again, this is exact. There is no need to do anything more complicated? than the simpler definition, as n and k are always non-negative 	 integers.   F Factorials come up again in calculating permutations and combinations.8 Calculating a permutations is simpler, so let's do that.  % How may ways can I rearrange 5 cards?   B Well, the first place can hold any of 5 cards. For each of those 5C cases, there are 4 cards left available for the second slot. Then 3 ? left for the third ... one for the last. So the total number of F permutations is 5*4*3*2*1. So, the number of permutations of n objectsF is n!. Again, this is exact. There is nothing wrong with it. You don'tD need the Gamma function to calculate this and the Gamma function has5 nothing directly to do with it. We are counting here.   E Now, when you get to Bessel functions, you end up with a power series A whose coefficients include various factorials. Here is the Bessel & function of the first kind of order p:  8   J_p(x) = Sum(n=0->inf.) (-1)^n (x/2)^(2n+p)/[n!(p+n)!]                       9 Since this is a solution of the Bessel equation, which is   "   (x^2)y'' + xy' + (x^2-p^2)y = 0.  B and since p appears only as p^2, positive and negative values of pD produce the same equation, and hence have the same solutions, and weF need not be concerned any more with negative values of p. But with theD factorial function, which naturally results from the method of powerA series solution, we can only use the J_p formula for non-negative 	 integers.   ? For various reasons (applications in engineering and physics in A particular), it is desirable to calculate the Bessel equation for B positive, non-integral values of p. But we don't yet have a way to( compute p! for non-integral values of p.  C And this is where the Gamma function comes to the rescue. It can be 
 shown that       Gamma(p+1) = p!   E for all non-negative integral values of p where the Gamma function is  given by  ;     Gamma(p) = Int.(0->inf.) t^(p-1) exp(-t) dt  for p > 0.   F So, to calculate p! where p is a positive non-integral real number, we@ use the two forumulas directly above. This is crucial. The GammaD function is shown to be equivalent to the factorial function for all? values for which the factorial function is defined, and then we D generalize the factorial function by defining p! to be Gamma(p+1) as4 is seen above. I don't see how this makes the simpleC definition/formula/algorithm/whathaveyou wrong. How does it make it  wrong?  ? (For the factorial of negative numbers < -1, we need to use the E fundamental property of the factorial function and iterate -- details  upon request.)  D Astonishingly, this all works. And you don't need the Gamma functionD to calculate n! unless you're dealing with Bessel functions or otherD similar advanced topics. BTW, you still can't come up with a useful,E sensible definition for the factorial of a negative integers, because B for a given negative integer, it approaches plus or minus infinity> depending upon which side you approach it from. However, their@ reciprocals can be sensibly defined to be 0 with the result thatF 1/(x!) is defined for all real numbers (and is continuous, I believe).  E My reference for the Taylor Series and Gamma function stuff is George C F. Simmons, Differential Equations with Applications and HIstorical = Notes, McGraw-Hill, 1972, pp. 147-148, 232-237, respectively.   B > > 3. If we simply added 0! = 1 (and perhaps also 1! = 1) to thatI > > definition you quoted that you don't like, wouldn't that satisfy you? < > > And then you could offer that as the correct definition. > C > No, because that is not the mathematically correct way to compute 
 > factorials.   F I guess we'll just have to agree to disagree, because I still claim it= is correct. The answers are indistinguishable except that the C "advanced" method will use a hell of a lot more CPU cycles then the  simple method.  E Actually, that's not necessarily true. Any good programmer knows that C it pays to optimize your algorithm(s) before you code. And when you F optimize the advanced formula, you end up with the simple formula when? the factorials of non-negative integers are needed. So why code 3 integrals when you can just multiply a few numbers?   F Furthermore, if you actually try to evaluate the integral numerically,? you'll almost certainly introduce unavoidable errors due to the A limited precision of digital computers and actually get incorrect A answers! The simple method, which in this sense is an algorithmic E optimization of the advanced forumla, will give the the exact correct  answers very efficiently.   = Even more astonishingly, recent versions of Windows include a B calculator that calculates factorials for all, not too large, real= numbers except for negative integers. I really doubt that any D calculator performs integrals for integral values. (At least WindowsD 98 2nd Ed. and Windows NT v4 Service pack 6 (I think it's six -- I'm< not at work and therefore cannot check it.) has this amazingC calculator. And if this caculator is accurate (I haven't checked it 3 for accuracy), it is truly a very cool calculator.)   J > > 4. I'm sorry, but didn't you write "LOGICAL, SYMBOL, ALIAS, KNICKNAME,G > > in the end it's all the same"? Yet the factorial definition bothers  > > you? Please explain. > F > Apples and oranges.  All those terms above are merely jargon and theH > meaning varies from conversation to conversation.  In essence they allG > consist of using one simple term to describe a more complex function.   F In comp.os.vms, they are more than jargon. They have precise meanings.@ They are distinct entities with very distinguishable properties.  C > Computing a factorial is a well defined mathematical concept with D > proofs and all that other stuff mathemeticians love.  (I am not by3 > any stretch of the imagination a mathematician!!)  >  > > 5. OK, how's this:   > >  > > Factorial function:  > >  > >         0! = 1, 1 > >         n! = n * (n-1)!  for n an integer > 0  > > G > > It's easier to think of it as all the positive integers from 1 to n C > > multiplied together, isn't it? But the second line of the above H > > definition includes the defining property of the factorial function.G > > The first line provides the normalization (the scale, if you wish). * > > Both ways of looking at it are useful. > B > BUt that is not how mathematics defines it and that was my wholeD > point.  While that definition is reasonable and probably all rightC > for 5th graders, by the time one has had algebra and triginometry A > and most assuredly by the time one learns calculus one is ready 6 > to be given the real mathematics behind factorials.   C But it *is* the real mathematics. Moreover, one has no need for the : advanced formula until one studies differential equations.  B Please stop stating that it is wrong because of the existence of aB more advanced definition/formula/whathaveyou. That doesn't make itE wrong. It produces the correct answers for all non-negative integers. F If it is wrong, please tell me *how* it is wrong. It is "alternative",A but it is correct, and it is essential to the "derivation" of the  advanced formula!    > It seems from > > the people I have talked with here that unless one majors inB > mathematics one can not expect to actually go beyond the formula > you give above.   > Nonsense. I never majored in math yet I have studied the GammaC function in a differential equations class, as have many scientists  and engineers.  F > Let me add that when it was explained to me by a real mathemetician,H > I didn't understand it.  But at least he didn't patronize me by saying  > the formula above was correct.   But it *is* correct.    E How would you teach gravity for the first time to students? Would you E start with General Relativity? Of course not. You start with Newton's D Law of Gravitation. But Newton's law is not correct. Even Einstein's> is not correct because it does not take quantum mechanics intoD account. But you start with Newton's theory because it is mcuh, much? simpler and it is so close to the truth that it is difficult to D perform an experiment or observation to a precision that enables oneE to distinguish between Newton's theory and Gen. Rel. Also, NASA makes D frequent use of Newton's "wrong" theory, and it has served them very well.   E So if an approximate theory gets you to the moon, a simpler factorial F defintion/algorithm that gives you the exact correct answers, can't be
 any worse!  C Also, the simpler factorial formula gives the exact, correct answer ; for all non-negative integers! The advanced definition is a A generalization of that. Mathematicians used factorials before the $ advanced definition even came about.  F If you *really* want to get "pure mathematical", then you need to knowC that mathematicians define the natural numbers in terms of sets and B the successor fuction. Assume the natural numbers are 0, 1, 2, ...   0 = {}  
 1 = { {} }   2 = { { {} }, {} }  " 3 = ( { { {} }, {} }, { {} }, {} }  F etc. That is, zero is the null set. One is the set of zero. Two is theC set of one and zero. Three is the set of two, one, and zero. And so B on. And a number is larger than another number if it contains thatF other number. Fun, huh? And you thought you knew what numbers were :-)  # Fortunately, I've run out of steam.    Disclaimer: JMHO Alan E. Feldman    ------------------------------    Date: 30 Dec 2002 11:08:25 -0800: From: craig.berry@SignalTreeSolutions.com (Craig A. Berry) Subject: Re: Link errors. = Message-ID: <7f15589f.0212301108.7c0afb7c@posting.google.com>   . In article <3e105bee$1_2@hpb10302.boi.hp.com>,(  "Ed Vogel" <ed.vogel@compaq.com> wrote:  6 > | > Did you compile with the qualifier /PREFIX=ALL?   H > | That's the default, at least with non-ancient versions of DEC/Compaq > | C,    B >     With V6.5, the default is /PREFIX=C99_ENTRIES.  The snprintfG >     function is a new function for C99, so the V6.5 compiler prefixed 	 >     it.    Hmm, on-line help says  C      For /STANDARD=ANSI89, the default is /PREFIX=ANSI_C89_ENTRIES.   ;      For /STANDARD=C99, the default is /PREFIX=C99_ENTRIES.   >      For all other compiler modes, the default is /PREFIX=ALL.  B Since the default standard qualifier is /RELAXED_ANSI89 (which I'mF assuming falls under "other"), I would have thought /PREFIX=ALL is the" default.  Am I reading this wrong?  G >     The rest of Craig's analysis is right on the money.  The snprintf 
 > function: >     is (as far as I know) not yet implemented on OpenVMS  7 C v6.5 (and I think one or two earlier versions) define A __STDC_VERSION__=199901L, and so I think are obligated to provide F snprintf and nan and strtof and all the other functions defined in theE C99 standard.  I realize the compiler and the RTL are separate pieces E (owned by separate teams?), but the mismatch between what the version D macro claims and what's really there causes real porting headaches. < I've encountered open source packages that provide alternateC implementations to some functions but only make them visible if the D version macro says the environment is not C99-compliant; that scheme= fails on VMS because the compiler claims a level of standards % compliance that the RTL doesn't meet.   F I suppose you know this already and have it somewhere in the middle of> your 10,000-item to-do list.  Thanks for a generally excellent product.   ------------------------------  % Date: Mon, 30 Dec 2002 03:29:52 -0500 * From: "Bill Todd" <billtodd@metrocast.net>: Subject: Re: Of Galaxy, Infiniband and Distributed Caching2 Message-ID: <VQGdnSXrCtSImY2jXTWc2Q@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:zUavRscexpo8@eisner.encompasserve.org... @ > In article <QRmdnTxQPOVmlJCjXTWc2Q@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes:   ...   2 > > However, there's no reason for inter-partitionK > > transfers (though shared memory) within a Galaxy system to be *anywhere H > > nearly* as CPU-intensive as message-structured transfers over commonF > > interconnects (including FC and, later, IB) are, so if that's what you'reH > > talking about I strongly suspect that you're reasoning from a flawed > > premise. > >  > = > I couldn't find a reference for that, where is a reference?   G It falls into the category of common sense, at least when compared with H anything like Ethernet where bulk transfers must be packetized and causeC zillions of interrupts.  FC and IB are better (bigger packets, more C intelligence), but still require considerable set-up.  By contrast, J partition-to-partition transfers through Galaxy shared memory shouldn't beG notably more expensive than application-to-application transfers though K shared global areas:  both can be managed by standard locking mechanisms in K the shared memory (including some clean-up code that would be executed only J when one of the partitions' OSs died) and simple memory-to-memory copying.  H Of course, if the shared memory is only used to simulate message-passingJ mechanisms rather than to replace them efficiently, a lot of the potential efficiency will be lost.   ...   H > > The story of the past year has been one of IB startups dropping like flies.L > > There may still be enough industry interest to preserve IB as a high-endL > > niche product, but as of now there's clearly nothing more than that (and> > > still some possibility that it will simply be still-born). > >  > . > I don't think so.  IBM has a great interest.  L Yeah.  So much that they've just announced that they're selling all their IBJ hardware development to Agilent.  Another Intel moment:  "We *really* likeC the technology, but we're just going to let someone else handle the E development and then jump on the bandwagon if/when it actually starts  rolling well."  J Ditto Microsoft.  They didn't have any hardware development to cancel, but? they've put supporting software on the back burner for a while.    ...   A > >> That fact that Dell is jumping on Infiniband is an indicator  > >> that it is cost effective.  > >  > > Reference, please? > >  > > > Yes, type: "dell infiniband" in Google, the ones towards the9 > top are stale but at the bottom of the first page, more ! > recent ones including this one:  > K > http://www.serverworldmagazine.com/newsflash2/2002/12/19_infiniband.shtml   J Interesting.  For a slightly less rose-colored-glasses view of exactly the same announcement, see  4 http://news.com.com/2100-1001-978407.html?tag=fd_top  L In both articles, it would be interesting to know exactly what Dell means byK saying that its servers will be 'Infiniband-ready' (apparently the complete D extent of its 'jump onto IB').  Sounds to me kind of like if someoneH provides PCI cards and IB drivers to run them, Dell won't do anything to3 prevent their use (and might even use them itself).   E By the way, note that HP abstained from giving even that level of lip  service to IB:   <quote>   C Not all are so bullish. HP--one of the inventors of InfiniBand--was 1 conspicuously absent from the joint announcement.   H "We're taking a wait-and-see approach. We don't believe that it's reallyJ lived up to the hype," the company said in a statement. "We're in the campG more with Microsoft and Intel right now. If we start hearing some noise - (from customers), we'll start looking at it."a   </quote>   - bill   ------------------------------  % Date: Mon, 30 Dec 2002 10:37:45 +0000r' From: Andrew Harrison SUNUK Consultancyi: Subject: Re: Of Galaxy, Infiniband and Distributed Caching. Message-ID: <3E1021F9.7080001@nospamn.sun.com>  A Personnaly I think that Infiniband is much more likely to show upl< as an I/O interconnect replacing direct PCI connections into servers.  B Currently most vendors use PCI, PCI-X which all have their issues.  B Bandwidth is one, length is another and there are also significant" issues around fault isolation etc.  A Everyone has their own spin on Infiniband, personally I don't seee> it as a replacement for the big switched interconnects used to9 build large SMP servers because it doesn't have the right  characteristics.  ? We have run RAC on Sun Fire Link which is faster than 30 Gbs IBg; and has a slightly lower latency, even using something likel5 Sun Fire Link does not guarantee that RAC will scale.u  6 On the other hand we have customers with 10 or more FC3 adaptors and 2+ Gigabit cards in each server and in-A this case having a dual Infiniband connection to a Infiniband->FCr9 bridge or a Infiniband->Gigabit bridge or straight into aR3 Infiniband port in a FC/Gigabit switch would vastlys* simplify the I/O subsystem on the servers.  7 Of course people will use IB for clustering and it willf4 be usefull in some environments, however latency and1 bandwidth issues will still defeat people who tryl8 to use if as a wholesale replacement for big backplanes.  8 Incedentally HP don't seem to have much to say about IB.   Regards  Andrew Harrison    Rob Young wrote:a > In article <QRmdnTxQPOVmlJCjXTWc2Q@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:e > : >>"Rob Young" <young_r@encompasserve.org> wrote in message/ >>news:LChUYQzjHNW$@eisner.encompasserve.org...s >>A >>>In article <XbucnYGGuNz05JSjXTWc2Q@metrocast.net>, "Bill Todd"b >>" >><billtodd@metrocast.net> writes: >> >>...s >> >>D >>>>Surely this cannot be the same Rob Young who not so long ago was >>>o >>trumpeting >>I >>>>the inevitable victory of ADMP (an acronym which HP's web site is note >>>r >>able >>L >>>>to find, nor is Google in anything but French and German) over all other >>>>mere MP boxes? >>>> >>> < >>>Well... spelling it correctly would help.  It isn't ADMP. >>A >>So what is it, then?  I *did* get hits in French and German forfC >>'Galaxy/ADMP' in connection with Tru64 (and I think VMS as well).u >> >  >  > 	APMPy > ' > 	Adaptive Partitioned MultiProcessingt >  >  >>...y >> >>I >>>>No matter, since the comment is the same regardless:  Galaxy/ADMP andtK >>>>Infiniband are complementary technologies with virtually no overlap, soS >>>e >>ADMP >>= >>>>is worth exactly as much, or as little, as it always was.n >>> < >>>That was the point of my posting.  Showing advantages and >>>disadvantages.o >>F >>No, you were attempting to show *compensatory* aspects of IB vs. theM >>possible lack of Galaxy support in Itanic systems (at least that's what youiE >>said).  Galaxy is about dynamic reallocation of resources within MPIN >>environments, whereas IB is about interconnecting resources in cluster-styleJ >>environments (as noted, it's not really fast enough for good distributedL >>memory):  they complement each other rather than in any way substitute for
 >>each other.o >> >>H >>>>Something as low-latency and high-bandwidth as Infiniband is, as you >>>o >>note,s >>J >>>>extremely attractive for things like distributed caches (or caching at >>>I >>theg >>H >>>>storage device), but in no way helps a system dynamically reallocate >>>>resources. >>>eA >>>Galaxy in its current incarnation doesn't dynamically allocateaE >>>much at all, other than CPUs.  Sure, you can change things but youlE >>>are at a console prompt when you do it.  There were Galaxy futures D >>>that showed memory being dynamically moved around, but that isn't >>>here yet. >>N >>'Were'?  Are you suggesting that the fast, fine-grained dynamic reassignmentJ >>of CPUs and memory is no longer part of the VMS roadmap (such as it is)? >> >  > 9 > 	Find me a roadmap with that on it.  They are old ones.  >  > D >>>> And IB is not fast enough to support anything but distressinglyL >>>>NUMA distributed shared memory (why you think that 2 - 10 us. latency isD >>>>comparable to EV7's 390 ns. worst-case latency in a 64-processor& >>>>configuration is not clear at all) >>>0 >>>4F >>>Part of what I included was application.  Certainly for HPTC GalaxyF >>>would be a winner, but as Andrew points out that is a small segment5 >>>of the market.  HPTC and VMS?  Very small segment.a >>N >>My impression was that Galaxy was aimed at commercial activity - especially,J >>the ability to divert CPU power to whatever activity in a multi-functionL >>server most needed it, on an instantaneous basis.  Very important segment,L >>in other words - and a very good way to leverage available processor power! >>rather than over-equip systems.  >> >  >  > 	Ok. >  >  >>...  >> >>? >>>Again, XFC would use all free memory.  Galaxy can't/won't in B >>>its current incrarnation so you have more memory available as a' >>>file cache (mentioned that earlier).  >>M >>Huh?  XFC is a distributed cache.  Galaxy is a hardware-level mechanism forpL >>dynamically partitioning resources.  You could *use* some of Galaxy memoryK >>as some kind of central cache (which we've discussed at length long ago),fK >>but once again you're talking about two *complementary* facilities rather $ >>than any kind of either/or choice. >> >  > > > 	Okay.  But what I was thinking here is that XFC in GalacticA > 	Shared memory from an old roadmap.  Maybe it is best XFC staysnA > 	in local memory, maybe not.  If XFC in Galactic Shared memory,i> > 	hard to imagine it larger than 1/2 physical memory in size. >  >  >>  The latency of Infiniband. >>@ >>>is very tolerable for remote reads of file cache (from what I, >>>understand, correct me if I'm off there). >>J >>I agree:  while several-microsecond latency is not really acceptable forN >>main memory these days, it's very acceptable for a cache hit (cache accessesI >>being persumably multiple orders of magnitude less frequent than memory1K >>accesses) - assuming that the cached data is fetched into local memory onnF >>the hit so that subsequent use of it proceeds at main-memory speeds. >> >>D >>>Greatest advantage though is recoup or protecting CPU investment.A >>>Meaning that like CI it will offload IO and messaging to lowera> >>>cost cards.  Querying someone about why they were using theE >>>much slower CI as an interconnect, I was told Memory Channel wouldtA >>>saturate their CPUs and I know of another situation where thatpC >>>happened.  I have no experience with Galaxy SMCI but since it islD >>>memory to memory and no helper chips, it too has to be pretty CPU
 >>>intensive.o >>  >>I have no idea what SMCI is.   >  > 9 > 	SMCI - Shared Memory Cluster Interconnect, i.e. Galaxy 9 > 	instances talking to each other through shared memory.y > K > http://www.itec.suny.edu/scsys/vms/OVMSDOC073/V73/6512/6512pro_index.htmld > 0 > 15.1 Shared Memory Cluster Interconnect (SMCI) > J > The Shared Memory Cluster Interconnect (SMCI) is a System CommunicationsJ > Services (SCS) port for communications between Galaxy instances. When anO > OpenVMS instance is booted as both a Galaxy and as an OpenVMS Cluster member,lQ > the SMCI driver is loaded. This SCS port driver communicates with other clusterrN > instances in the same Galaxy through shared memory. This capability providesF > one of the major performance benefits of the OpenVMS Galaxy SoftwareP > Architecture. The ability to communicate to another clustered instance throughO > shared memory provides dramatic performance benefits over traditional clustert > interconnects. N >  >  > 0 >>However, there's no reason for inter-partitionI >>transfers (though shared memory) within a Galaxy system to be *anywhereeF >>nearly* as CPU-intensive as message-structured transfers over commonK >>interconnects (including FC and, later, IB) are, so if that's what you'reoF >>talking about I strongly suspect that you're reasoning from a flawed
 >>premise. >> >  > > > 	I couldn't find a reference for that, where is a reference?C > 	Also, I discuss this further in the last two or three paragraphso" > 	as it came up again down there. >  > = >>>>By the way, at the moment IB appears to be heading towardm& >>>>low-volume/high-price niche status >>>tB >>>Regarding IB niche status.  There is a lot of mythology out andD >>>about here and you appear to have bought into it.  A lot of folks@ >>>are scared of new things and you have networking guys saying:= >>>"we do IP, Infiniband? ... shiver me timbers, I'm scared."  >>G >>No, what I'm referring to is first the departure of Intel from the IBrM >>enclave ("We're still really enthusiastic about the product, but we'll just0N >>let other people develop the hardware for it..."), followed more recently byL >>IBM IIRC.  No one who appears to know much about IB's current status seemsK >>to expect it to become the true commodity (i.e., including desktop-level)vJ >>interconnect that was once envisioned, but rather a high-end, low-volumeN >>server product - especially since without commodity-level volumes there's noG >>reason to expect its price to drop below that of Fibre Channel (whicheL >>already supports 2 Gbit/sec with comparable host CPU overheads to those IBF >>should offer, and inter-host communication as well as simple storage >>linkage).C >> >  > B > 	Ok.  But FC as an innerconnect is a fallback innerconnect.  TheB > 	performance is really sucky, from a recent session.  That makesC > 	sense, after all.. it is SCSI commands.  SCS over fibre is quiteuE > 	a feat it appears but a great plum for failover and the like, i.e.gD > 	SCS will talk up until you lose the storage innerconnect when SCSA > 	goes over FC.  The cleanup/failover/recovery is then "simpler"c > 	from session statements." >  > M >>The story of the past year has been one of IB startups dropping like flies.iJ >>There may still be enough industry interest to preserve IB as a high-endJ >>niche product, but as of now there's clearly nothing more than that (and< >>still some possibility that it will simply be still-born). >> >  > @ > 	I don't think so.  IBM has a great interest.  Perhaps they doH > 	a Linuxification and make that the innerconnect across all platforms.# > 	Externally, it appears that way.a >  > E >>>Seriously, nothing will be able to compete with IB for price until F >>>about 2006 for high-end interconnect.  IB is certainly cheaper thanJ >>>10 Gbit ethernet at an average of $50000 per port for 10 Gbit ethernet: >>N >>I guess that depends on what you consider 'high-end'.   Gigabit Ethernet hasL >>already become commonplace, with server-quality NICs under $100 (some evenK >>including intelligence to off-load the central processor at that price) -NL >>and 100 MBytes/sec isn't exactly chopped liver.  FC NIC prices continue toM >>drop (IIRC they were starting to flirt with the $300 level well over a yearcF >>ago, so the 2 Gbit versions should be getting down there soon if notM >>already).  So quoting $50K/port for the barely-shipping 10 Gbit Ethernet isrI >>something of a straw man (and of course assuming that its pricing won't'N >>fairly quickly drop to something much closer to commodity levels just as allM >>other Ethernet variants have is also flying in the face of rather extensive N >>precedent), while citing $1000/port prices for IB when it first appears nextL >>year isn't exactly inspiring (especially considering how difficult it will$ >>be to find much to connect it to). >> >  > ? > 	Point taken, but you are stretching this one.  Yes, I am offgA > 	on Gbit pricing.  Yes, I am defining high-end at 10 GBit.  TheeD > 	ComputerWorld articles are legit.  The big whoopty-doowah in that> > 	article is a $30000 per port 10 GBit offering.  The analystB > 	expects $5000 to $6000 per port pricing by 2006.  Your curve inB > 	10 Gbit pricing decline is way out of line with that analyst's. >  >  >>...v >> >>? >>>That fact that Dell is jumping on Infiniband is an indicator  >>>that it is cost effective.- >> >>Reference, please? >> >  > @ > 	Yes, type: "dell infiniband" in Google, the ones towards the	: > 	top are stale but at the bottom of the first page, more" > 	recent ones including this one: > K > http://www.serverworldmagazine.com/newsflash2/2002/12/19_infiniband.shtml  > L > Sun Microsystems, IBM and Dell will outline their commitment to InfiniBandP > today, detail future InfiniBand products, and discuss how this next generationL > of "smart" high speed server I/O will radically change the way servers are$ > configured, operated and designed. > P > The Yankee Group predicts that by 2005, 42 percent of all servers shipped willQ > be InfiniBand-enabled. More than 70 companies worldwide have announced plans tou& > bring InfiniBand products to market. >  > [snip] > Q > Dell believes low latency, high-bandwidth technologies -- such as InfiniBand --1O > will further enable data centers to be built using low-cost, simple-to-deploy P > industry standard systems. Dell's next generation PowerEdge modular blades areL > planned to be InfiniBand-ready enabling customers to take advantage of the$ > technology's performance benefits. >  > 	"built using low-cost", etc.4 > @ > 	It really is a timing issue.  I would grant this.. if 10 GBit@ > 	Ethernet was $3000 or $4000 per port today, IB would probablyA > 	be stillborn.  Again, networking fear of anything not IP wouldi> > 	make sure money for 10 GBit enet shows up.  Today, the only? > 	folks investing in 10 Gbit enet are early adopters with deepH > 	pockets.d >  >  >>...r >> >>C >>>So for the next 3 years+, IB is definitely a better interconnectn6 >>>for CPU offload reasons, latency reasons, and cost! >>F >>Gigabit Ethernet costs less than 10% of the IB costs you're citing.  >  > @ > 	Two different ballparks.  Gbit ethernet has 2 to 10 times theA > 	latency of IB (at 2 to 10 us for IB), a tenth of the bandwidthaF > 	and no offloading capabilities (for the most part, as I acknowledge > 	below it is showing up).v >  >  Its > I >>NICs are starting to incorporate 'offload engines' that reduce host CPU $ >>involvement to FC and IB levels.   >  > ' > 	I see that.  Certainly isn't common.i >  > + >>It can offer one-way latencies in the 10soK >>of microseconds range, which is adequate for most things that IB might betL >>usable for (even remote caching).  So unless a link requires more than 100K >>MBytes/sec of sustained bandwidth, it will remain a *far* more attractivey	 >>option.r >> >  > B > 	Ok.  But surely a bottleneck as channels would frequently burst> > 	above 100 Mbytes with cache transfers, right?  Gbit doesn'tD > 	seem to have enough pipe for cache transfers for serious lifting.% > 	Pretty fluffy nonsense on my part.r >  > N >>2 Gbit Fiber Channel costs less than 1/3 of the IB costs you're citing, alsoK >>offloads host CPUs to about the same extent that IB does, and IIRC offerseK >>more like 10 us. latency, so, again, unless a link requires more than 200:N >>MBytes/sec sustained bandwidth it will be a much more attractive option (andK >>10 Gbit FC is on the near horizon, though I don't know anything about its  >>projected costs).  >> >  > 5 > 	Okay.  Sounds like a competing low-end technology.n >  >  >>...e >> >>  Infiniband shouldp >>I >>>have a superior cost structure for quite some time, have no idea wherehE >>>people (yourself included) get this idea that IB will be at a costcE >>>disadvantage, if nothing else, that certainly isn't the case.  AreiD >>>you comparing to Gbit Ethernet?  Cost the same, IB is much faster >>>(10 Gbit versus Gbit).i >>J >>See above:  your cost figures for Gbit Ethernet appear to be quite a fewK >>years out of date (or perhaps years of DECpaq experience have conditionedl6 >>you to paying 10x the market price for such things). >> >  > = > 	Yes, stale data on my end.  That is what I get for wingingt > 	it. >  >  >>>So ... coming back around...  >>>u? >>>What about Infiniband advantages versus Galaxy?  If you lash F >>>together 16 - 4 CPU servers with Infiniband, would that "do" Oracle4 >>>better than a Galaxied partitioned 64 CPU server? >> >>No:  not nearly as well. >> >>  Wouldn't you >>> >>>get more CPU with IB helping, therefore better performance? >>F >>Not only are you apparently confused about the relative overheads ofJ >>inter-partition communication in Galaxy compared with *any* interconnectI >>(even an efficient one like IB), and not only are you assuming that thedI >>static partitioning into 4-CPU nodes will be as effective as some other B >>division of labor, and not only are you ignoring the latency andJ >>synchronization overheads of using Oracle's data-shipping 'cache fusion'M >>mechanisms rather than one or a small number of larger, centralized caches,xJ >>but you're also ignoring Galaxy's ability to shuffle CPUs dynamically toK >>adjust to instantaneous load variations (assuming, that is, that it's not 7 >>optimal to run all 64 EV7s in a single system image).s >> >  > D > 	I'm still a "bit" skeptical as to the CPUs not being impacted.  IA > 	do know the old crusty CI can be fastpathed, here is reference - > 	to that earlier mention of CPU saturation:c > o > http://groups.google.com/groups?selm=cf15391e.0109260649.40446623%40posting.google.com&oe=UTF-8&output=gplainc > H > "Given that you have 10-CPU SMP boxes, and 4 CI adapters per box, it'sG > quite possible that you are currently using Fast_Path on CI to spreadeF > CI interrupt workload across non-primary CPUs.  Be aware that MemoryB > Channel does not support Fast_Path (and since no new MC hardware? > development is planned, and there's thus no incentive for VMSlF > Engineering to dive back into the driver code, it's unlikely it everE > will support Fast_Path).  I worked at a site where we tried to movedE > from CI to MC for SCS traffic in a large cluster (16 6-CPU GS-140s).G > and our plans failed due to saturation of CPU 0 in interrupt state on=F > lock-master nodes for hot application files.  They had to rip the MCF > hardware back out and go to 6 CIs instead.  As a test, you might tryG > turning off Fast_Path on CI in your current configuration and measure $ > peak CPU 0 interrupt-state usage." > : > 	So to further beat the horse, if SMCI can't or won't be= > 	fastpathed then is IB the answer and we would assume it isa= > 	fastpathed from the outset.  Since SMCI has 94 us for lockw@ > 	latency and MC II 120us, one would hope IB comes in somewhere: > 	less than 200us  (i believe from memory Gbit is 230us). > = > 	If SMCI is or can be fastpathed, Galaxy is a much stronger @ > 	interconnect as you would have less risk of saturating a CPU.D > 	Of course, there is a few other angles here... since it is shared< > 	memory you certainly don't have to build up and tear downB > 	checksummed message packets do you?  Maybe you can run 10 timesE > 	as many lock requests through shared memory on a single CPU.  ThatmF > 	and the fact you wouldn't have 16 CPU partitions, maybe 4 is ideal.D > 	Perhaps Galaxy is far superior all the way around.  That would be
 > 	cool.   > = > 	Disclaimer:  I dawdle.  If you really want or need to knowi= > 	what it is all about, contact HP.  I'm not an HP employee,f > 	just a usenet denizen.d > 	 > 				Rob  >    ------------------------------  % Date: Mon, 30 Dec 2002 04:57:46 -0400b0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>* Subject: Pathworks MAC (printer) debugging/ Message-ID: <3E100A89.60A297AB@vl.videotron.ca>o  K I have pathworks MAC 1.3a on a VAX VMS 7.2  on node BIKE. The queue managerrM and DCPS software run on node VELO with a shared queue manager database. (but M otherwise separate system disks). the PRING and SUBMIT commands from DCL workl fine on both VELO and BIKE.o  2 The file share works fine (albeit are slow speed).  M However, the printing has odd behaviour. On the MAC side, all seems fine, andsK in fact, a file is deposited succesfully into the MSAP$SPOOL directory, buty5 such file is not submitted to any queue for printing.e  < the MSAP$RECEIVERE image issues the follwing OPCOM message:   = MSAP-E-NOSNDJBC, status 98994 on submit file to queue , ref 1u   98994 is "record not found".  I HELP/MESSAGE says it is either a licence issue or a record not found in arK file. I do not have any pathworks licences. If there was a licence problem, L wouldn't this image refuse to even go as far as publishing the printer names to the appletalk clients ?    M I have been able to run the image interactively with SET FILE WATCH to try tonJ see what files it accesses. It accesses SYSUAF.DAT, "ENGLISH.TXT", the PPDH file in the same directory as ENGLISH.TXT, the DCPS$DEVCTL and SYSDECCTL0 libnraries as well as the MSAP$DECVTL.TLB files.  K By the time it tries to submit the file to print, is there a way to providehI better tracing for the process so that I woudl know what file it tries toiQ unseccessfully access ? (and hopefully what key value is used to find a record ?)a   ------------------------------  % Date: Mon, 30 Dec 2002 21:19:53 -0400p0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>. Subject: Re: Pathworks MAC (printer) debugging/ Message-ID: <3E10F0B7.E1E8AFA7@vl.videotron.ca>h   Christoph Gartmann wrote:w= >    $ SHO DEVICE/FILES/OUT=temp.file device_of_MSA_spool_diri/ >    $ SEARCH temp.file pid_of_receiver_processr3 > Try to load the files into an edito or copy them.o  H The receiver process only hjas the file "ENGLISH.TXT" opened during idleM times. While receiving a prnt job from a mac, it accesses the spool directorya and creates the file there.r  N The libraries ( MSAP$DEVCTL.TLB etc) are accesses only during image activation when the receiver begins.r      M This is based on running the receiver interactively with SET WATCH FILE. What J I'd like to know is whether it is possible to trace an image's interaction with the job controller.   ------------------------------    Date: 30 Dec 2002 13:32:25 -08007 From: jones.computer.srv@worldnet.att.net (Daryl Jones)aD Subject: Re: Retrieve RMS Key information at runtime (using Fortran)= Message-ID: <8a646952.0212301332.602150f8@posting.google.com>   p usenet_ihc@hotmail.com (Gert de Boom) wrote in message news:<12ce5972.0212300440.59a4b65f@posting.google.com>...	 > Hi all,l > A > I want to retrieve information about the keys in an RMS file atsF > runtime, i.e. number, size, positions, whether they are segmented or: > not, etc. Currently we are using Fortran (Compaq Fortran0 > V7.4A-1588-46B4K) as our programming language. > G > Using the group search on Google I thought to have found the solutioniB > by using a method described by Steve Lionel (Looping through theG > XAB-records to find the XABKEY information; http://tinyurl.com/3xat).eF > However having tried this, I found out that according to the FortranE > user manual (description of FAB$L_XAB) this only works when the KEY.8 > keyword is used in the open statement, which we don't. > H > Another solution could be to use LIB$SPAWN and then create an FDL fileF > using something like this: $analyze/rms_file /fdl myindexedfile.ind.? > The second step would be to parse this file for the requested C > information. Doing this in a program seems to me a time consumingl > task.. > E > Probably I'm just overlooking the real solution. Any tips, remarks,  > solutions, code snippets ?  	 Dear Sir:   E If you several ISAM files, then you should have the analysis FDL file B generated for each file you are using. Sorry I must ask. Since theE ISAM file properties usually don't change on the fly, why do you want  the info on the fly?   Daryl Jonesa   ------------------------------  % Date: Mon, 30 Dec 2002 17:28:31 -0800r2 From: "Randy Park" <rjpark@mindspring.nospaam.com>D Subject: Re: Retrieve RMS Key information at runtime (using Fortran)2 Message-ID: <auqrs9$m1h$1@slb4.atl.mindspring.net>  6 Gert de Boom <usenet_ihc@hotmail.com> wrote in message7 news:12ce5972.0212300440.59a4b65f@posting.google.com...r	 > Hi all,c >eA > I want to retrieve information about the keys in an RMS file attF > runtime, i.e. number, size, positions, whether they are segmented or: > not, etc. Currently we are using Fortran (Compaq Fortran0 > V7.4A-1588-46B4K) as our programming language. >tG > Using the group search on Google I thought to have found the solutionuB > by using a method described by Steve Lionel (Looping through theG > XAB-records to find the XABKEY information; http://tinyurl.com/3xat).eF > However having tried this, I found out that according to the FortranE > user manual (description of FAB$L_XAB) this only works when the KEYu8 > keyword is used in the open statement, which we don't. > H > Another solution could be to use LIB$SPAWN and then create an FDL fileF > using something like this: $analyze/rms_file /fdl myindexedfile.ind.? > The second step would be to parse this file for the requestedfC > information. Doing this in a program seems to me a time consumingt > task.b >uE > Probably I'm just overlooking the real solution. Any tips, remarks,  > solutions, code snippets ? >h > --- > Thanks in advance and best wishes for 2003,i > Gert >uG > P.S. The tiny URL above was included to prevent wrapping of this fullo > URL: >i >iL http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=7D 1b20542a961847f&seekm=1992Jan16.170352.673%40e2big.mko.dec.com#link2  ; My software has done what you want for over 15 years.  It's 9 fairly old, written in BASIC, but it still works.  It's as8 set of routines that call RMS directly and retrieves key; information at the time of opening a file, and returns thist info to the calling program.  5 To the poster that asks why a program would want thisr= information at run time, the answer is as follows.  Sometimesu9 the software does not know the nature of the file that is 7 to be opened, because the user supplies the name of thee: file.  For example, does the DUMP utility know about every: file on your system?  No, you give it a filename, it opens= it, and then reads data based upon the structure of the file.s   ------------------------------  % Date: Mon, 30 Dec 2002 20:57:27 -0400z0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>D Subject: Re: Retrieve RMS Key information at runtime (using Fortran)/ Message-ID: <3E10EB77.350E0351@vl.videotron.ca>w   Gert de Boom wrote: G > XAB-records to find the XABKEY information; http://tinyurl.com/3xat).aF > However having tried this, I found out that according to the FortranE > user manual (description of FAB$L_XAB) this only works when the KEYR8 > keyword is used in the open statement, which we don't.   Oh you use Fortran IO ?n  N If you use SYS$OPEN and SYS$DISPLAY, you can tak one XAB with a tag of XABSUMMN (summary). In it, you have plenty of information including the number of keys.N You then build a linked array of XABs with XABKEY and incresing key number andG use SYS$DISPLAY to fill that linked list with all the info on each key.n  M If, from fortran, you have access to the FAB block, you should be able to tag-T on the XAMSUM, do a $DISPLAY, then tag on individual XABKEY and do a $DISPLAY again.   ------------------------------  + Date: Mon, 30 Dec 2002 23:30:24 +0000 (UTC)o3 From: "Richard Maher" <maher_rj@hotspamnotmail.com>i Subject: Re: rrd40/ Message-ID: <auqkug$f6n$1@helle.btinternet.com>u   Hi,l  H I own one! I don't know why I'm proud of that but there you go. It is myK only CD drive on my VAX 4000 and for some strange reason can't be seen fromyL the chevron prompt. Sorry, none of this helps you but I'm just glad that I'mI not the only one sad enough to have one of these on their desk! Are you aT7 museum, hobbyist or budget even more pitiful than mine?v   Cheers Richard Maher.d  , mhr <mreilly36@comcast.net> wrote in message* news:qwOdndwCLseGpJOjXTWcoQ@comcast.com...E > looking for a cartridge (cd-rom) holder for a RRd-40 da cdrom for am > vaxstation 3100 76 sfx.o > Thanks > mhra >w >'   ------------------------------    Date: 30 Dec 2002 13:37:15 -0800: From: jonathan@Pescadero.DSG.Stanford.EDU (Jonathan Stone)& Subject: Re: vax6k.openecs.org rebirth5 Message-ID: <auqeab$spj$1@Pescadero.DSG.Stanford.EDU>-  - In article <8765tbimor.fsf@prep.synonet.com>,c. Paul Repacholi  <prep@prep.synonet.com> wrote:7 >Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:l >dD >> VAX interrupt handling was also really "heavy" -- benchmarks withC >> the same I/O device configurations showed that 11/780s could not-A >> handle as many interactive users or SCADA device interrupts asdG >> 11/70s and other I/O was no faster on the 11/780. This situation didb@ >> not get better until terminal servers and LAT were available. >RF >Not quite. All the vaxen except the 780 used direct vectors, and that" >improved things a good bit. [...]  = Nitpick: I'm fairly sure 11/780s, 8600s and 8560s with UBA780lA SBI-to-Unibus adaptors all suffered the indirect-interrupt-vectors lossage for Unibus devices.r  E You seem to've confused the UBA780 with the DWBUA, which (unless I am B horribly mistaken) was the VaxBI-to-Unibus adaptor. ``Curse'' is a pretty apt description, tho.    ) >The biggest problems where the DWUBA andoG >the horrific overhead of the DZ-11 for terminals. All the disadvantgeslD >of a 1 line per controller controller plus all the disadvantages ofH >multiple lines per controller :( A new version of the DH did not happenE >till a lot later, in the DHV, then the DHU after VMS engineering hadu >beaten it up somewhat.e  C Which was why Able sold so many, uh, was it VMZ-32s?  Field Service @ would even put them on DEC maintenance, at least in Australasia.   [...]t   ------------------------------  # Date: Mon, 30 Dec 2002 22:57:24 GMTa5 From: William Robison <william-robison@uiowa.edu.com>s& Subject: Re: vax6k.openecs.org rebirth- Message-ID: <3E10CF54.7CE336F9@uiowa.edu.com>i   Jonathan Stone wrote:c > / > In article <8765tbimor.fsf@prep.synonet.com>, 0 > Paul Repacholi  <prep@prep.synonet.com> wrote:9 > >Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:r > >oF > >> VAX interrupt handling was also really "heavy" -- benchmarks withE > >> the same I/O device configurations showed that 11/780s could not.C > >> handle as many interactive users or SCADA device interrupts aspI > >> 11/70s and other I/O was no faster on the 11/780. This situation didvB > >> not get better until terminal servers and LAT were available. > >iH > >Not quite. All the vaxen except the 780 used direct vectors, and that$ > >improved things a good bit. [...] > ? > Nitpick: I'm fairly sure 11/780s, 8600s and 8560s with UBA780aC > SBI-to-Unibus adaptors all suffered the indirect-interrupt-vectorg > lossage for Unibus devices." > G > You seem to've confused the UBA780 with the DWBUA, which (unless I amnD > horribly mistaken) was the VaxBI-to-Unibus adaptor. ``Curse'' is a > pretty apt description, tho. > + > >The biggest problems where the DWUBA andeI > >the horrific overhead of the DZ-11 for terminals. All the disadvantgesfF > >of a 1 line per controller controller plus all the disadvantages ofJ > >multiple lines per controller :( A new version of the DH did not happenG > >till a lot later, in the DHV, then the DHU after VMS engineering hadr > >beaten it up somewhat.  > E > Which was why Able sold so many, uh, was it VMZ-32s?  Field Service B > would even put them on DEC maintenance, at least in Australasia. >    Heh...@ Field Service would put almost anything under maintenance if yoy@ threw a little extra $$$'s at them and mentioned the word SUN...  A (Actually get 'em to take on a set of Pertec 7 tracks that looked C a lot like TU45's with a 3rd. party TM10 emulation...  By that timeIC field service tracked down 1 head for each drive prior to acceptingI them on the sevice contract...)f :-)o -Willy   ------------------------------   Date: 30 Dec 2002 21:16:04 GMT# From: hoff@hp.nospam (Hoff Hoffman)sG Subject: Re: Volume Shadowing (was: Re: Hello Kieth Parris... pls help)h* Message-ID: <auqd2k$h2e$3@web1.cup.hp.com>  a In article <9M0HHwPwABrq@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:h  > :	Last I checked shadowing dissimilar devices was/is post 7.3.  B   So long as the disks have the same number of blocks, they can be?   shadowed with most any current OpenVMS release configured andnB   licensed for volume shadowing -- the long-standing disk geometryA   restrictions have been lifted in current OpenVMS releases.  See-D   the current OpenVMS release documentation and also see the OpenVMS0   V7.2-*-vintage shadowing ECO kits for details.  B   On-line volume currently expansion targets OpenVMS Alpha V7.3-2.  E   Disk volumes will have to be pre-configured for the largest volume yD   size to be permitted, but the underlying storage can then be grownF   -- clearly this is not the best solution to growing the disk volumesH   over time.  You and I and others would like the volume data structuresG   to provide for dynamic expansion.  This approach is, however, still ai#   workable solution to the problem.e  F   Details on this -- if the capability is incorporated and documented,D   of course -- will be included in the OpenVMS V7.3-2 documentation.  B   As was stated previously, OpenVMS host-based volume shadowing isA   seeing on-going engineering support and on-going development --iE   geometry-related changes, the merge prioritization work, mini-mergee:   and mini-copy, the on-line volume expansion work, etc.    B   There are no plans to discontinue the host-based volume product,@   and no plans to slow the engineering work.  There are plans toA   port shadowing to Itanium, as descrined in the OpenVMS roadmap.v    N  ---------------------------- #include <rtfaq.h> -----------------------------J       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.comN  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.come   ------------------------------  # Date: Tue, 31 Dec 2002 05:01:32 GMT  From: "pfr" <preilly@mail.com>6 Subject: VT220/320 Terminal emulator for Linux client?5 Message-ID: <pan.2002.12.31.05.03.38.207913@mail.com>g  J Can anyone reccomend a good free terminal emulator for a Linux client whenE connecting to a Vax?  TeraTerm has worked well when connecting from abF Windows client to a Vax, but the standard telnet client in Linux seems only able to emulate a VT100.t   Thanks,o   ------------------------------  # Date: Tue, 31 Dec 2002 05:39:23 GMTnL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr"): Subject: Re: VT220/320 Terminal emulator for Linux client?6 Message-ID: <00A193D4.61B840D2@SSRL.SLAC.STANFORD.EDU>  V In article <pan.2002.12.31.05.03.38.207913@mail.com>, "pfr" <preilly@mail.com> writes:  K >Can anyone reccomend a good free terminal emulator for a Linux client when F >connecting to a Vax?  TeraTerm has worked well when connecting from aG >Windows client to a Vax, but the standard telnet client in Linux seemss >only able to emulate a VT100.  J Try Kermit.  (kermit.columbia.edu if it isn't on your Linux distribution.)   -- Alan>  O ===============================================================================o0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056BM  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025wO ===============================================================================    ------------------------------  + Date: Tue, 31 Dec 2002 01:34:07 +0100 (CET)>9 From: Richard Levitte - VMS Whacker <levitte@openssl.org>d* Subject: [ANNOUNCE] OpenSSL 0.9.7 released; Message-ID: <20021231.013407.104029435.levitte@openssl.org>o  " -----BEGIN PGP SIGNED MESSAGE-----        OpenSSL version 0.9.7 released!   ===============================r  /   OpenSSL - The Open Source toolkit for SSL/TLS    http://www.openssl.org/g  @   The OpenSSL project team is pleased to announce the release ofA   version 0.9.7 of our open source toolkit for SSL/TLS.  This newiB   OpenSSL version is a major release and incorporates at least 262>   changes and bugfixes to the toolkit (for a complete list see,   http://www.openssl.org/source/exp/CHANGES.  #   The most significant changes are:   !       o New library section OCSP. &       o Complete rewrite of ASN1 code.8       o CRL checking in verify code and openssl utility.*       o Extension copying in 'ca' utility.1       o Flexible display options in 'ca' utility.aC       o Provisional support for international characters with UTF8.tC       o Support for external crypto devices ('engine') is no longert          a separate distribution.+       o New elliptic curve library section.V+       o New AES (Rijndael) library section.sL       o Support for new platforms: Windows CE, Tandem OSS, A/UX, AIX 64-bit,.         Linux x86_64, Linux 64-bit on Sparc v94       o Extended support for some platforms: VxWorks.       o Enhanced support for shared libraries.J       o Now only builds PIC code when shared library support is requested.       o Support for pkg-config.,       o Lots of new manuals.K       o Makes symbolic links to or copies of manuals to cover all describedn         functions.M       o Change DES API to clean up the namespace (some applications link alsoaI         against libdes providing similar functions having the same name). I         Provide macros for backward compatibility (will be removed in thea         future).H       o Unify handling of cryptographic algorithms (software and engine)N         to be available via EVP routines for asymmetric and symmetric ciphers.3       o NCONF: new configuration handling routines.lJ       o Change API to use more 'const' modifiers to improve error checking         and help optimizers.,       o Finally remove references to RSAref.*       o Reworked parts of the BIGNUM code.G       o Support for new engines: Broadcom ubsec, Accelerated Encryption          Processing, IBM 4758.k2       o A few new engines added in the demos area.=       o Extended and corrected OID (object identifier) table.eN       o PRNG: query at more locations for a random device, automatic query for6         EGD style random sources at several locations.O       o SSL/TLS: allow optional cipher choice according to server's preference.o@       o SSL/TLS: allow server to explicitly set new session ids.:       o SSL/TLS: support Kerberos cipher suites (RFC2712).$ 	Only supports MIT Kerberos for now.K       o SSL/TLS: allow more precise control of renegotiations and sessions.l;       o SSL/TLS: add callback to retrieve SSL/TLS messages. 5       o SSL/TLS: support AES cipher suites (RFC3268).e  G   We consider OpenSSL 0.9.7 to be the best version of OpenSSL availableeC   and we strongly recommend that users of older versions upgrade asUE   soon as possible.  OpenSSL 0.9.7 is available for download via HTTPtG   and FTP from the following master locations (you can find the various ?   FTP mirrors under http://www.openssl.org/source/mirror.html):o  $     o http://www.openssl.org/source/#     o ftp://ftp.openssl.org/source/h  I   OpenSSL 0.9.6 (all patch levels) came in the form of two distributions,oK   a "normal" one and an "engine" variant that included support for external K   crypto devices.  In 0.9.7, the "engine" framework is part of the "normal"e2   distribution, so there are no variants of 0.9.7.      The distribution file name is:  %       o openssl-0.9.7.tar.gz [normal]D6         MD5 checksum: ef376d14205afcfb831cd3720f705d79  :   The checksum was calculated using the following command:  &     openssl md5 < openssl-0.9.7.tar.gz     Yours,   The OpenSSL Project Team...  t  =     Mark J. Cox             Ben Laurie          Andy Polyakovt<     Ralf S. Engelschall     Richard Levitte     Geoff Thorpe'     Dr. Stephen Henson      Bodo Mllere&     Lutz Jnicke            Ulf Mller   -----BEGIN PGP SIGNATURE-----h Version: 2.6.3ia Charset: noconvv  @ iQEVAwUBPhDlY/Ty7ZjgbSyxAQEFlAgAktqLFxipUJnd64x/jShkBmgz+0hhhlfM@ 6bwMmNYYL8kMgsgvTdoqDgVD8gW3DoIv4xXKsamle9KCZY1aA6KFiU8NQMIzmr6U@ e5FUvwkoaw+X2buF7B5oCGLFOrvgrvNiVjGRzOSp0l+CLXC0/DP9tuzJ/0RJZeko@ YqDQVGAu+FhkZ5veIYTbo1vyuL4Vp6ZG+QMsHcEKfItV2rzCB9EPng7qQIU781a7@ 6kmLgMzNPsqWNW3Z6Ie6YpzVWVUxkiRBPCEEXlvc+jNdEbvG76ax8+Wje6PEsy788 KtRLbe9BAbBY0sMYB+0HEOZVeSZgqvLwhYm0aRg0VG/x3mTsSgSzxw== =NTIEe -----END PGP SIGNATURE-----a   ------------------------------   End of INFO-VAX 2002.723 ************************