1 INFO-VAX	Thu, 20 Jun 2002	Volume 2002 : Issue 339       Contents:@ Re: "We stay with VMS because we have forgotten that we have it" Re: A PL/I question ...  Re: A PL/I question ...  Re: A PL/I question ...  RE: A PL/I question ... ) Re: A Proposal for All C.O.V. to Consider # Re: A [departure from] VMS Disaster # Re: A [departure from] VMS Disaster # Re: A [departure from] VMS Disaster # Re: A [departure from] VMS Disaster - Re: Another C and PL/I question - Descriptors 9 Re: Call or email hp ... they will answer your questions! 9 Re: Call or email hp ... they will answer your questions! 9 Re: Call or email hp ... they will answer your questions! 9 Re: Call or email hp ... they will answer your questions! $ Re: CONNECT:Direct wildcard transfer  Re: Console hang solved (almost) Re: Could linux become VMS? 8 Re: Disaster Tolerant advertising using Fortune magazine8 Re: Disaster Tolerant advertising using Fortune magazine8 Re: Disaster Tolerant advertising using Fortune magazine8 Re: Disaster Tolerant advertising using Fortune magazine+ Re: howto create self-extracting zip files? + RE: howto create self-extracting zip files? > HP Lan Console for who doesnt know it .... x 3 (the real link)* HP RoadShow in France these days: a report. Re: HP RoadShow in France these days: a report& Re: http osu web server open vms 7.2-2! Re: install image /write/resident ! Re: install image /write/resident 5 Mac keboard mapping - was Re: Could linux become VMS? " McKinley die smaller than expected& Re: McKinley die smaller than expected$ Re: Middle European DST change rules, Re: My conversation with Linus about VMS ..., Re: My conversation with Linus about VMS ..., Re: My conversation with Linus about VMS ...< Re: NSA: Security in current mainstream operating systems vs< Re: NSA: Security in current mainstream operating systems vs< RE: NSA: Security in current mainstream operating systems vs< RE: NSA: Security in current mainstream operating systems vs) Re: Obsoleting entries in a symbol vector  Re: OpenVMS Mailing Lists?' Re: PWS500au PowerStorm 3D30 DECWindows " Re: rooted devices and /TRANS=CONC! Storage directions for The New HP % Re: Storage directions for The New HP % Re: Storage directions for The New HP ! Re: Sun/Slowaris future in doubt!  timeout restriction  Re: timeout restriction  Re: timeout restriction  Re: timeout restriction  Re: timeout restriction = Re: Urgent help required( Link command getting struck in vax) = Re: Urgent help required( Link command getting struck in vax) P Re: VMS MARKETING VOLUNTEERS, LTD. Biz Card Example ( was Re: A Proposal for AllP Re: VMS MARKETING VOLUNTEERS, LTD. Biz Card Example ( was Re: A Proposal for AllP Re: VMS MARKETING VOLUNTEERS, LTD. Biz Card Example ( was Re: A Proposal for All< Re: Why porting apps to VMS isn't very helpful in most cases< Re: Why porting apps to VMS isn't very helpful in most cases< Re: Why porting apps to VMS isn't very helpful in most cases" Re: [OT] Why Software is So Bad..." Re: [OT] Why Software is So Bad..." Re: [OT] Why Software is So Bad..." Re: [OT] Why Software is So Bad...  F ----------------------------------------------------------------------  # Date: Wed, 19 Jun 2002 18:00:02 GMT 2 From: "Sue Skonetski" <susan.skonetski@compaq.com>I Subject: Re: "We stay with VMS because we have forgotten that we have it" 2 Message-ID: <CE3Q8.30$MX1.599188@news.cpqcorp.net>   with both of course : "Didier Morandi" <Didier.Morandi@Free.fr> wrote in message! news:3D0A3546.E1ACA03B@Free.fr... > > So that everyone knows that I'm kidding, I'll reply in here: > & > With me, Sue? (or still with DEC :-) >  > D. >  > Sue Skonetski wrote: > > = > > I have never met this customer, but I think I am in love.  > >  > > Thanks Didier,   ------------------------------    Date: 19 Jun 2002 11:28:22 -0700, From: bubbapig@hotmail.com (Jeffrey Cameron)  Subject: Re: A PL/I question ...= Message-ID: <b22333b7.0206191028.758956d8@posting.google.com>    Actually ...  E I have found the answer to the problem, I know the difference between E a char and a char var in PL/I, in C/C++ I can work around it by using D pointers. The real problem was in the way C passes the parameters toE PL/I or the way PL/I expects its parameters to be passed. If there is E a return value, PL/I expects it to be passed as the first parameter.  C This is why if I reversed the order of the parameters it would work @ (i.e. would match up the value of indx properly). C must do thisE differently underneath or at least expects it in a different pattern. B So to vole this anyways in the C code I declare my get_filename as such:   ) void get_filename(void *, void *, void*);    rather then   # char *get_filename(void *, void *);   C the extra parameter in the above example holds the return value, in  general the example is:   8 void func_name(void *retval, void *param1, void *param2)  ) Hope this can help someone in the future.   d "Tom Linden" <tom@kednos.com> wrote in message news:<CIEJLCMNHNNDLLOOGNJIGEFDFDAA.tom@kednos.com>...C > get_filename is not a char, it is a char var, you need to declare % > it with a descriptor in you C code.  >  > >-----Original Message----- 6 > >From: Jeffrey Cameron [mailto:bubbapig@hotmail.com]' > >Sent: Tuesday, June 18, 2002 7:42 AM  > >To: Info-VAX@Mvb.Saic.Com > >Subject: A PL/I question ...  > >  > > - > >I have two procedures which I call from C:  > > 1 > >/************ C CODE ************************/  > >  > >#include <descrip.h>  > > 1 > >extern "C" char *get_filename(void *, void *); . > >extern "C" void *print_out(void *, void *); > > > > >/* where I use the void * pointers rather then arguments as > >declarators */  > >  > >..  > >..  > >..  > >  > >int num = 12; > >short val = 1; " > >struct dsc$descriptor_ubs desc;C > >/* there are three other fields which i fill in correctly for an 9 > >unaligned bit string but do not have right on me :) */ # > >desc.dsc$a_base = (char*)(&val);  > >desc.dsc$l_pos = 0L;  > >  > >print_out(&num, &desc);* > >char *temp = get_filename(&num, &desc); > > 8 > >/****************** PL/I Code **********************/ > > @ > >get_filename: proc (indx, in_temparg) returns (char(80) var); > > " > >dcl indx         fixed bin(31); > >dcl in_temparg   bit(1); ! > >dcl filename     char(80) var;  > >  > >put skip list (indx); > >put skip list (in_temparg); > >  > >return (filename) > >  > >end get_filename; > > 1 > >/*------------------------------------------*/  > > $ > >print_out: proc (param1, param2); > > " > >dcl param1       fixed bin(31); > >dcl param2       bit(1);  > >  > >put skip list (param1); > >put skip list (param2); > >  > >end print_out;  > > G > >/***************************** END CODE ***************************/  > > E > >The problem is this, the print_out procedure is a test stub I made E > >which works fine, it prints out both the bit and the integer value H > >correctly which are passed into it. You'll notice I do NOT modify the > >structure in any way. > > I > >When I call the get_filename procedure though the addresses and values F > >for both parameters are screwed and lead to access violation when I > >try to print. > > G > >THEY ARE THE EXACT SAME PARAMETER LISTS!!! The only difference is in H > >the names and the fact that one procedure returns something while theD > >other does not. What the heck is going on here guys? Is this someH > >obscure bug? Or a piece of the calling standard I am unfamiliar with? > >How do I get around this? > > F > >p.s. I am compiling the C with all the compiler options for sharingH > >code with other psects /EXTERN=COMMOM/nomember_alignment/noopt ... et > >al. IF that helps at all? > >  > >Thanks again in advance!  > >Jeff Cameron  > >  > >---) > >Incoming mail is certified Virus Free. = > >Checked by AVG anti-virus system (http://www.grisoft.com). B > >Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002 > >  > --- ( > Outgoing mail is certified Virus Free.< > Checked by AVG anti-virus system (http://www.grisoft.com).A > Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002    ------------------------------    Date: 19 Jun 2002 13:36:23 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)   Subject: Re: A PL/I question ...3 Message-ID: <7Bc28ghidvPR@eisner.encompasserve.org>   l In article <b22333b7.0206191028.758956d8@posting.google.com>, bubbapig@hotmail.com (Jeffrey Cameron) writes: > Actually ... > G > I have found the answer to the problem, I know the difference between G > a char and a char var in PL/I, in C/C++ I can work around it by using F > pointers. The real problem was in the way C passes the parameters toG > PL/I or the way PL/I expects its parameters to be passed. If there is G > a return value, PL/I expects it to be passed as the first parameter.    - Which is the way Ada and Pascal work as well.   E I believe the problem is that C is specified at such a low level that A it has its own requirements for a calling convention (besides the @ notorious use of null-terminated strings).  It is possible in C,> for example, to pass a 16-byte array into a routine _by_value_& (split amongst the machine registers).   ------------------------------  % Date: Wed, 19 Jun 2002 18:39:16 +0000 2 From: John Eisenschmidt <jweisen@eisenschmidt.org>  Subject: Re: A PL/I question ...4 Message-ID: <20020619183916.C31710@eisenschmidt.org>  1 This (to some degree for me anyway) makes sense.    It's been a while, but I recall that Pascal lets you pass parameters in both directions through a procedure name, but their was either a keyword or order was important. Though I've never worked with it, I remember being told that FORTRAN let you do something similar. In C/C++ a function is only supposed to return one value through the function name, unless you use a pointer or pass by reference. So PL/I wanting the parameters in a particular position doesn't seem "out there", at least to me.  6 In any event, congratulations on solving the mystery.   M Unless the Voices are Mistaken, Jeffrey Cameron (bubbapig@hotmail.com) Wrote:  > Actually ... > G > I have found the answer to the problem, I know the difference between G > a char and a char var in PL/I, in C/C++ I can work around it by using F > pointers. The real problem was in the way C passes the parameters toG > PL/I or the way PL/I expects its parameters to be passed. If there is G > a return value, PL/I expects it to be passed as the first parameter.  E > This is why if I reversed the order of the parameters it would work B > (i.e. would match up the value of indx properly). C must do thisG > differently underneath or at least expects it in a different pattern. D > So to vole this anyways in the C code I declare my get_filename as > such:  > + > void get_filename(void *, void *, void*);  >  > rather then  > % > char *get_filename(void *, void *);  > E > the extra parameter in the above example holds the return value, in  > general the example is:  > : > void func_name(void *retval, void *param1, void *param2) > + > Hope this can help someone in the future.  > f > "Tom Linden" <tom@kednos.com> wrote in message news:<CIEJLCMNHNNDLLOOGNJIGEFDFDAA.tom@kednos.com>...E > > get_filename is not a char, it is a char var, you need to declare ' > > it with a descriptor in you C code.  > >  > > >-----Original Message----- 8 > > >From: Jeffrey Cameron [mailto:bubbapig@hotmail.com]) > > >Sent: Tuesday, June 18, 2002 7:42 AM  > > >To: Info-VAX@Mvb.Saic.Com! > > >Subject: A PL/I question ...  > > >  > > > / > > >I have two procedures which I call from C:  > > > 3 > > >/************ C CODE ************************/  > > >  > > >#include <descrip.h>  > > > 3 > > >extern "C" char *get_filename(void *, void *); 0 > > >extern "C" void *print_out(void *, void *); > > > @ > > >/* where I use the void * pointers rather then arguments as > > >declarators */  > > >  > > >..  > > >..  > > >..  > > >  > > >int num = 12; > > >short val = 1; $ > > >struct dsc$descriptor_ubs desc;E > > >/* there are three other fields which i fill in correctly for an ; > > >unaligned bit string but do not have right on me :) */ % > > >desc.dsc$a_base = (char*)(&val);  > > >desc.dsc$l_pos = 0L;  > > >  > > >print_out(&num, &desc);, > > >char *temp = get_filename(&num, &desc); > > > : > > >/****************** PL/I Code **********************/ > > > B > > >get_filename: proc (indx, in_temparg) returns (char(80) var); > > > $ > > >dcl indx         fixed bin(31); > > >dcl in_temparg   bit(1); # > > >dcl filename     char(80) var;  > > >  > > >put skip list (indx);  > > >put skip list (in_temparg); > > >  > > >return (filename) > > >  > > >end get_filename; > > > 3 > > >/*------------------------------------------*/  > > > & > > >print_out: proc (param1, param2); > > > $ > > >dcl param1       fixed bin(31); > > >dcl param2       bit(1);  > > >  > > >put skip list (param1); > > >put skip list (param2); > > >  > > >end print_out;  > > > I > > >/***************************** END CODE ***************************/  > > > G > > >The problem is this, the print_out procedure is a test stub I made G > > >which works fine, it prints out both the bit and the integer value J > > >correctly which are passed into it. You'll notice I do NOT modify the > > >structure in any way. > > > K > > >When I call the get_filename procedure though the addresses and values H > > >for both parameters are screwed and lead to access violation when I > > >try to print. > > > I > > >THEY ARE THE EXACT SAME PARAMETER LISTS!!! The only difference is in J > > >the names and the fact that one procedure returns something while theF > > >other does not. What the heck is going on here guys? Is this someJ > > >obscure bug? Or a piece of the calling standard I am unfamiliar with? > > >How do I get around this? > > > H > > >p.s. I am compiling the C with all the compiler options for sharingJ > > >code with other psects /EXTERN=COMMOM/nomember_alignment/noopt ... et > > >al. IF that helps at all? > > >  > > >Thanks again in advance!  > > >Jeff Cameron  > > >  > > >---+ > > >Incoming mail is certified Virus Free. ? > > >Checked by AVG anti-virus system (http://www.grisoft.com). D > > >Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002 > > >  > > --- * > > Outgoing mail is certified Virus Free.> > > Checked by AVG anti-virus system (http://www.grisoft.com).C > > Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002    --  / John W. Eisenschmidt <jweisen@eisenschmidt.org> 6  Homepage URL    | http://www.eisenschmidt.org/jweisenM  GPG Public Key  | http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.asc D  GPG Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2  M  Problems Reading this Email? http://www.jensbenecke.de/misc/outlook+pgp.html    ------------------------------  % Date: Wed, 19 Jun 2002 16:28:11 -0700 # From: "Tom Linden" <tom@kednos.com>   Subject: RE: A PL/I question ...9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOEIBFDAA.tom@kednos.com>   > So it wasn't a reversal of paramters but prepending the return value as the first parameter?   C Once upon a time Digital used to have a uniform stack frames across H languages.  I wonder if this solutions works with all recent versions ofH C.  Where does C put the return value?  Even though you have solved yourF problem, it is not the right solution.  You shouldn't have to know theK internals of the passing mechanism, because if you do, it could change, and  itH certainly isn't portable.  But maybe there is no  other way to do on VMSD at this stage.  Again I would urge you to use SDL for cross-language implemetation.   Tom        >-----Original Message----- 4 >From: Jeffrey Cameron [mailto:bubbapig@hotmail.com]( >Sent: Wednesday, June 19, 2002 11:28 AM >To: Info-VAX@Mvb.Saic.Com! >Subject: Re: A PL/I question ...  >  > 
 >Actually ...  > F >I have found the answer to the problem, I know the difference betweenF >a char and a char var in PL/I, in C/C++ I can work around it by usingE >pointers. The real problem was in the way C passes the parameters to F >PL/I or the way PL/I expects its parameters to be passed. If there isE >a return value, PL/I expects it to be passed as the first parameter. D >This is why if I reversed the order of the parameters it would workA >(i.e. would match up the value of indx properly). C must do this F >differently underneath or at least expects it in a different pattern.C >So to vole this anyways in the C code I declare my get_filename as  >such: >o* >void get_filename(void *, void *, void*); >e >rather then >u$ >char *get_filename(void *, void *); >fD >the extra parameter in the above example holds the return value, in >general the example is: > 9 >void func_name(void *retval, void *param1, void *param2)i >p* >Hope this can help someone in the future. >l/ >"Tom Linden" <tom@kednos.com> wrote in message 6 >news:<CIEJLCMNHNNDLLOOGNJIGEFDFDAA.tom@kednos.com>...D >> get_filename is not a char, it is a char var, you need to declare& >> it with a descriptor in you C code. >> >> >-----Original Message-----7 >> >From: Jeffrey Cameron [mailto:bubbapig@hotmail.com]s( >> >Sent: Tuesday, June 18, 2002 7:42 AM >> >To: Info-VAX@Mvb.Saic.Coma  >> >Subject: A PL/I question ... >> > >> >. >> >I have two procedures which I call from C: >> >2 >> >/************ C CODE ************************/ >> > >> >#include <descrip.h> >> >2 >> >extern "C" char *get_filename(void *, void *);/ >> >extern "C" void *print_out(void *, void *);n >> >? >> >/* where I use the void * pointers rather then arguments ase >> >declarators */ >> > >> >.. >> >.. >> >.. >> > >> >int num = 12;d >> >short val = 1;# >> >struct dsc$descriptor_ubs desc;pD >> >/* there are three other fields which i fill in correctly for an: >> >unaligned bit string but do not have right on me :) */$ >> >desc.dsc$a_base = (char*)(&val); >> >desc.dsc$l_pos = 0L; >> > >> >print_out(&num, &desc);s+ >> >char *temp = get_filename(&num, &desc);s >> >9 >> >/****************** PL/I Code **********************/  >> >A >> >get_filename: proc (indx, in_temparg) returns (char(80) var);  >> ># >> >dcl indx         fixed bin(31);r >> >dcl in_temparg   bit(1);" >> >dcl filename     char(80) var; >> > >> >put skip list (indx);i >> >put skip list (in_temparg);M >> > >> >return (filename)u >> > >> >end get_filename;  >> >2 >> >/*------------------------------------------*/ >> >% >> >print_out: proc (param1, param2);N >> ># >> >dcl param1       fixed bin(31);H >> >dcl param2       bit(1); >> > >> >put skip list (param1);  >> >put skip list (param2);e >> > >> >end print_out; >> >H >> >/***************************** END CODE ***************************/ >> >F >> >The problem is this, the print_out procedure is a test stub I madeF >> >which works fine, it prints out both the bit and the integer valueI >> >correctly which are passed into it. You'll notice I do NOT modify the  >> >structure in any way.l >> >J >> >When I call the get_filename procedure though the addresses and valuesG >> >for both parameters are screwed and lead to access violation when Io >> >try to print.s >> >H >> >THEY ARE THE EXACT SAME PARAMETER LISTS!!! The only difference is inI >> >the names and the fact that one procedure returns something while theSE >> >other does not. What the heck is going on here guys? Is this someSI >> >obscure bug? Or a piece of the calling standard I am unfamiliar with?- >> >How do I get around this?2 >> >G >> >p.s. I am compiling the C with all the compiler options for sharing:I >> >code with other psects /EXTERN=COMMOM/nomember_alignment/noopt ... et  >> >al. IF that helps at all?r >> > >> >Thanks again in advance! >> >Jeff Cameron >> > >> >---.* >> >Incoming mail is certified Virus Free.> >> >Checked by AVG anti-virus system (http://www.grisoft.com).C >> >Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002  >> > >> ---) >> Outgoing mail is certified Virus Free. = >> Checked by AVG anti-virus system (http://www.grisoft.com). B >> Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002 >r >---' >Incoming mail is certified Virus Free.j; >Checked by AVG anti-virus system (http://www.grisoft.com).8@ >Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002 >s ---o& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002s   ------------------------------    Date: 19 Jun 2002 13:16:51 -0700- From: jodonnell@hrblock.com (Jason O'Donnell)p2 Subject: Re: A Proposal for All C.O.V. to Consider< Message-ID: <9059bf6b.0206191216.d8310a9@posting.google.com>  j "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message news:<aenrl3$abp$1@fizban.pprd.abbott.com>...J > Maybe we should throw in a "can you hear me now" for good measure.  I do > like the PRICELESS thing btw.  > N > I tuned in to the server web cast today and VMS was mentioned several times,I > but when I asked an on-line question about its absense in the first few I > slides, I got the "VMS is strategic, but not a growth platform" answer.pM > What would make it a growth platform you might ask?  Lots of sales followede  > by more of the same I'd guess. > --	 > Dave...H > 5 > More than one cigar at a time is excessive smoking.o > -----Mark Twainh   ARGH!o  B You have to spend money to make money (so a saying goes).  If theyD would market the technical merits of OVMS, then it would be a growth	 platform.   ! ^&*%$#^&%$#$@^%$&*(_()* IDIOTS!!!A  ( Sorry, thier response just blew my fuse.   ------------------------------  % Date: Wed, 19 Jun 2002 14:11:22 -0400r; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>*, Subject: Re: A [departure from] VMS Disaster$ Message-ID: <3d10c93a$1@news.si.com>  G >It's the mime encoding. Which application would you like to blame? :-)  >s, >John's software for posting mime to Usenet. > / >Or yours for not showing Usenet as plain text.   K I use OE, so can see both MIME and plain text.  Others' plain text shows up H fine.  Others' MIME postings show up fine.  It's just Mr. Eisenschmidt's that don't.r --A Brian Tillman                   Internet: tillman_brian at si.comaA Smiths Aerospace                          tillman at swdev.si.com = 3290 Patterson Ave. SE, MS      Addresses modified to prevent*< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Wed, 19 Jun 2002 18:18:16 +0000l2 From: John Eisenschmidt <jweisen@eisenschmidt.org>, Subject: Re: A [departure from] VMS Disaster4 Message-ID: <20020619181816.E10647@eisenschmidt.org>  C The problem is with Outlook and OE - it does not conform to RFC2015   / http://www.jensbenecke.de/misc/outlook+pgp.htmli  Z Unless the Voices are Mistaken, Brian Tillman (tillman_brian@notnoone.notnohow.com) Wrote:I > >It's the mime encoding. Which application would you like to blame? :-)* > > . > >John's software for posting mime to Usenet. > >l1 > >Or yours for not showing Usenet as plain text.I > M > I use OE, so can see both MIME and plain text.  Others' plain text shows upcJ > fine.  Others' MIME postings show up fine.  It's just Mr. Eisenschmidt's
 > that don't.a > --C > Brian Tillman                   Internet: tillman_brian at si.comdC > Smiths Aerospace                          tillman at swdev.si.comt? > 3290 Patterson Ave. SE, MS      Addresses modified to preventR> > Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@": >        This opinion doesn't represent that of my company >    -- ./ John W. Eisenschmidt <jweisen@eisenschmidt.org>e6  Homepage URL    | http://www.eisenschmidt.org/jweisenM  PGP Public Key  | http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.asctD  PGP Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2  O FOO MANE PADME HUM: "Our first obligation is to keep the FOO counters turning."    ------------------------------  % Date: Wed, 19 Jun 2002 18:32:35 +0000n2 From: John Eisenschmidt <jweisen@eisenschmidt.org>, Subject: Re: A [departure from] VMS Disaster4 Message-ID: <20020619183235.B31710@eisenschmidt.org>  & Actually, two addition things on this:  1.) I pgp/gpg sign all my messages that go to other mailing lists that gateway to Usenet without any problems (except for people who read their mail with Outlook or OE). The Info-VAX gateway doesn't seem to have a problem digesting it, and interesting enough the message looks fine by the time it makes it to Google. What magic the elves perform behind the scene to make that happen is a mystery, but when my posts make it back to me the signature is still in tact (when it was there).    2.) I appreciate the formality, but really you can call me John. My family is informal and from very common stock. It has been pointed out that some of you have uptimes longer than I've been alive.a  If it makes you feel any better, even my sainted mother reads her mail with OE and until last week (when I stopped signing my messages to COV) I was signing messages to her, so she had to detach and open my email separately. I just want to insure that the inane, insane, inept, annoying, aggravating, misspelled, misunderstood writings that you get in your inbox are none other than mine. =)d  Z Unless the Voices are Mistaken, Brian Tillman (tillman_brian@notnoone.notnohow.com) Wrote:I > >It's the mime encoding. Which application would you like to blame? :-)- > >a. > >John's software for posting mime to Usenet. > >n1 > >Or yours for not showing Usenet as plain text.P > M > I use OE, so can see both MIME and plain text.  Others' plain text shows upsJ > fine.  Others' MIME postings show up fine.  It's just Mr. Eisenschmidt's
 > that don't.s > --C > Brian Tillman                   Internet: tillman_brian at si.com C > Smiths Aerospace                          tillman at swdev.si.com ? > 3290 Patterson Ave. SE, MS      Addresses modified to prevents> > Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@": >        This opinion doesn't represent that of my company >    -- c/ John W. Eisenschmidt <jweisen@eisenschmidt.org> 6  Homepage URL    | http://www.eisenschmidt.org/jweisenM  GPG Public Key  | http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.asciD  GPG Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2  M  Problems Reading this Email? http://www.jensbenecke.de/misc/outlook+pgp.html    ------------------------------  # Date: Wed, 19 Jun 2002 22:07:00 GMT # From: "John Smith" <a@nonymous.com> , Subject: Re: A [departure from] VMS DisasterH Message-ID: <8g7Q8.84488$831.17987@news01.bloor.is.net.cable.rogers.com>  @ It's probably the gpg/pgp signing that's doing it. I had similarF 'attachment' issues when first using PGP's client plug-in with OE. The; plug-in's can be flaky. Switched to Eudora..problem solved.       ? "John Eisenschmidt" <jweisen@eisenschmidt.org> wrote in message . news:20020619183235.B31710@eisenschmidt.org...( > Actually, two addition things on this: >tH > 1.) I pgp/gpg sign all my messages that go to other mailing lists thatH gateway to Usenet without any problems (except for people who read theirE mail with Outlook or OE). The Info-VAX gateway doesn't seem to have a_J problem digesting it, and interesting enough the message looks fine by theL time it makes it to Google. What magic the elves perform behind the scene toG make that happen is a mystery, but when my posts make it back to me theo/ signature is still in tact (when it was there).  > L > 2.) I appreciate the formality, but really you can call me John. My familyL is informal and from very common stock. It has been pointed out that some of- you have uptimes longer than I've been alive.a >CH > If it makes you feel any better, even my sainted mother reads her mailI with OE and until last week (when I stopped signing my messages to COV) I*C was signing messages to her, so she had to detach and open my emailtJ separately. I just want to insure that the inane, insane, inept, annoying,J aggravating, misspelled, misunderstood writings that you get in your inbox are none other than mine. =) >s/ > Unless the Voices are Mistaken, Brian Tillman , (tillman_brian@notnoone.notnohow.com) Wrote:K > > >It's the mime encoding. Which application would you like to blame? :-)h > > > 0 > > >John's software for posting mime to Usenet. > > >t3 > > >Or yours for not showing Usenet as plain text.r > >aL > > I use OE, so can see both MIME and plain text.  Others' plain text shows upL > > fine.  Others' MIME postings show up fine.  It's just Mr. Eisenschmidt's > > that don't.* > > --E > > Brian Tillman                   Internet: tillman_brian at si.comrE > > Smiths Aerospace                          tillman at swdev.si.com A > > 3290 Patterson Ave. SE, MS      Addresses modified to preventi@ > > Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"< > >        This opinion doesn't represent that of my company > >- >- > --1 > John W. Eisenschmidt <jweisen@eisenschmidt.org>o8 >  Homepage URL    | http://www.eisenschmidt.org/jweisen >  GPG Public Key  |: http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.ascF >  GPG Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2 >  >  Problems Reading this Email?N/ http://www.jensbenecke.de/misc/outlook+pgp.html    ------------------------------    Date: 19 Jun 2002 11:34:49 -0700, From: bubbapig@hotmail.com (Jeffrey Cameron)6 Subject: Re: Another C and PL/I question - Descriptors< Message-ID: <b22333b7.0206191034.e54e57c@posting.google.com>  < Thanks for your reply, however I have solved it on my own :)    E PL/I passes ALL parameters by reference (which can be a bugger with ad> language like C where everything is passed by value, excepting	 pointers)   B The problem is that PL/I expects the first parameter of a functionC that returns a value to be the address of the return value, so when F passing from C the first parameter is actuall the return value and the5 second parameter is the first parameter and so forth.    I declared my get_filename as:  5 extern "C" void get_filename(void *, void *, void *);t  @ where the first parameter is the return value, and so on. you'llE notice this function doesnt return a value anymore is avoid function.aE the value which is return from PL/I is placed in the first parameter.   F As for bits, I have played around with and discovered that in C on theE VMS you can create an unsigned bit string descriptor and pass that in7F which works like a charm, PL/I thinks it is aPL/I bit variable and youE can even work it such that the bit you pass in is in a short variabley? or something which you can check the value of later because theb< descriptor allows you to specify which bits will be changed.    Thansk again for your replies :)    c lewis@spyder.mitre.org (Keith A. Lewis) wrote in message news:<aendes$567$1@newslocal.mitre.org>...n > "Jeffrey Cameron" <bubbapig@hotmail.com> writes in article <XStP8.1484$Rf7.529909@news20.bellglobal.com> dated Mon, 17 Jun 2002 19:01:08 -0400:cN > >1. My C++ modules must interact with certain PL/I code and quite often thseI > >PL/I modules either return or take as a parameter a bit (usually as an:) > >unaligned bit string), for example ...H > >O5 > >/***************** PL/I CODE ********************/a: > >get_filename: proc (indx, in_temparg) returns (bit(1)); > >m > >dcl in_temparg bit(1);D > >dcl indx fixed bin(15); > >c > >/* ... snip ... */a > >  > >end get_filename; > >w > >wO > >But how do I declare this in C so that it knows to pass in and return a bit,oO > >there are obviously no atomic data types for this operation in C/C++. I have M > >found a lot of litaerature on passing by descriptor and have tried passingeN > >in the address of an unaligned bit string descriptor to the PL/I program to > >no avail. e.g.: > L > I would *guess* that PL/I passes the bit(1) parameter by reference and theJ > return value by value.  You could experiment to determine if my guess is( > right or if somebody else's is, but... > L > I'm assuming you can't modify the existing PL/I code for some reason.  CanK > you write more?  Write a wrapper function which uses parameter types thatf( > integrate easily with C.  For example: > B > get_filename_c: proc (indx, in_temparg) returns (fixed bin (7)); >  > dcl indx fixed bin(15);a% > dcl in_temparg fixed bin (7) value;e >  > dcl final_temparg	bit; > dcl result		bit; > # > final_temparg = (in_temparg = 1); - > result = get_filename(indx, final_temparg);e > if result then h >     return (1);l > else ( >     return (0);  >  > end; > 4 > /***************** C CODE ***********************/. > extern "C" char get_filename(short *, char); > - > --Keith Lewis              klewis$mitre.org @ > The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Wed, 19 Jun 2002 22:03:01 GMTt# From: "John Smith" <a@nonymous.com>lB Subject: Re: Call or email hp ... they will answer your questions!J Message-ID: <pc7Q8.403805$t8_.169152@news01.bloor.is.net.cable.rogers.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:do3Q8.29$hW1.537734@news.cpqcorp.net... >@C > David J. Dachtera wrote in message <3D0E5626.EBF15498@fsi.net>...n >  > >cJ > >Gee - now if we could get Rich in the loop on our sales cycle, maybe HEJ > >could explain the so-called "dead end" Alpha to our prospects who throw > >that back in our face...  > >o >nF > Please contact Sue Skonetski.  If you need help closing the deal and believeoF > that Mark, or even Rich is what you need to do it...  all things are > possible.* >/     Fred,>  L With all due respect, David wouldn't have had to call Rich or Mark to try toH rescue a sale with his customer (if that's even now possible) had Compaq  been smart about last June 25th.  H Irrespective of the fact that many businesses lease their hardware for 3J years (2002 + 3 = 2005), and that at the end of that period will allegedlyI see a VMS/Itanic, the perception in the marketplace is that Alpha is deadg today.  J HP can huff and puff all it wants to but you're not going to convince veryL many *new* (oh my god...there's that word that's banned in Palo Alto) to VMSJ customers that they should buy an Alpha today. They'll look you in the eyeJ and say, "Digital lied to its customers, Compaq lied to its customers, andF HP is not doing anything visible to make us believe that they have anyK commitment to it either. Lots of the same people are still in charge and welJ don't see any of them standing up to their bosses making a case for VMS. IJ guess a lot of them are just getting close to retirement and don't want to rock the boat.">  H $5 says that even if David can get Rich or Mark to call on his customer, they won't make the sale.    Sorry.   ------------------------------  # Date: Thu, 20 Jun 2002 02:44:18 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>*B Subject: Re: Call or email hp ... they will answer your questions!' Message-ID: <3D114560.FE61307C@fsi.net>e   Fred Kleinsorge wrote: > C > David J. Dachtera wrote in message <3D0E5626.EBF15498@fsi.net>...l >  > >rJ > >Gee - now if we could get Rich in the loop on our sales cycle, maybe HEJ > >could explain the so-called "dead end" Alpha to our prospects who throw > >that back in our face...m > >  > N > Please contact Sue Skonetski.  If you need help closing the deal and believeF > that Mark, or even Rich is what you need to do it...  all things are > possible.h   *HEARTFELT SIGH*  B As much as I'd like to believe that, I suspect it might be a touchF difficult to get folks of their stature to co-ordinate their schedules. around the trampings of a travelling salesman.  D See - and this is the part we keep trying to hammer into, well, justH about everyone - *EVERY* sales call these days needs that. The prospectsG have all read WSJ, InfoWorld, ComputerWeek and heaven knows what else.    H They're hip, guy. They're onto it. They know Alpha hits the wall at someH point where the "Q" have "driven a stake in the ground". That makes it aD dead-end proposition in their eyes, and no amount of "commitment" is going counter act that.>  ? HP has *GOT* to stand up, step up to the plate and state, in no D uncertain terms, that the Alphacide was mistake and that Alphas willF continue to be developed and will continue to be available until IntelG FINALLY manages to put forth a viable, ready-for-prime-time 64-bit CPU..  B Anything short of that is just so much more zero-credibility sales fluff.  F Sorry to have to state it so bluntly, but that is the bottom line from the front-line perspective.o   -- . David J. Dachtera/ dba DJE Systems2 http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------  # Date: Thu, 20 Jun 2002 03:25:58 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>9B Subject: Re: Call or email hp ... they will answer your questions!. Message-ID: <aXbQ8.253734$352.21290@sccrnsc02>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3D114560.FE61307C@fsi.net...  > Fred Kleinsorge wrote: > >bE > > David J. Dachtera wrote in message <3D0E5626.EBF15498@fsi.net>...e > >e > > >eL > > >Gee - now if we could get Rich in the loop on our sales cycle, maybe HEL > > >could explain the so-called "dead end" Alpha to our prospects who throw > > >that back in our face...l > > >y > >gH > > Please contact Sue Skonetski.  If you need help closing the deal and believeHH > > that Mark, or even Rich is what you need to do it...  all things are
 > > possible.o >  > *HEARTFELT SIGH* > D > As much as I'd like to believe that, I suspect it might be a touchH > difficult to get folks of their stature to co-ordinate their schedules0 > around the trampings of a travelling salesman. > F > See - and this is the part we keep trying to hammer into, well, justJ > about everyone - *EVERY* sales call these days needs that. The prospectsH > have all read WSJ, InfoWorld, ComputerWeek and heaven knows what else.  E Which is why, for the last decade, I have been telling DEC and CPQ tobH PROACTIVELY engage the trade press organs. Perhaps I would have had moreA luck if I wore an Armani Suit (Probability Factor: slim to none).t   >EJ > They're hip, guy. They're onto it. They know Alpha hits the wall at someJ > point where the "Q" have "driven a stake in the ground". That makes it aF > dead-end proposition in their eyes, and no amount of "commitment" is > going counter act that.i >aA > HP has *GOT* to stand up, step up to the plate and state, in noiF > uncertain terms, that the Alphacide was mistake and that Alphas willH > continue to be developed and will continue to be available until IntelI > FINALLY manages to put forth a viable, ready-for-prime-time 64-bit CPU.n >sD > Anything short of that is just so much more zero-credibility sales > fluff.  F Having lost a year of Alpha development, not to mention the developersL themselves, what is the liklihood that HPQ could pull this off if they chose	 to do so?o   ------------------------------  # Date: Thu, 20 Jun 2002 03:56:35 GMTn* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Call or email hp ... they will answer your questions!A Message-ID: <TncQ8.34439$8i1.2110917@bin2.nnrp.aus1.giganews.com>   < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3D114560.FE61307C@fsi.net...    ...   A > HP has *GOT* to stand up, step up to the plate and state, in notF > uncertain terms, that the Alphacide was mistake and that Alphas willH > continue to be developed and will continue to be available until IntelI > FINALLY manages to put forth a viable, ready-for-prime-time 64-bit CPU.   ) Ain't gonna happen - wouldn't be prudent.i  K The problem is, they're already committed (really, not just verbally).  I'd'H heard before that the HP engineers gave up on Itanic a while ago but gotG overridden by management.  Makes sense that it might have been when EV6nK started demonstrating that OoO was real and worked well, as was just stateds
 elsewhere.  L If so, guess who was in charge of that managerial decision.  Guess who neverJ admits her mistakes but just continues plunging along in the direction she? has chosen to define as 'ahead', regardless of new information.   H If Itanic had truly sunk without a trace, there might be some hope.  ButK while McKinley and its followers won't be any world-beaters, they'll likely H be marginally adequate (unlike Merced).  Having (she says intentionally)J burned her other bridges, it's not clear at all that frantically trying toK rebuild them now would offer better prospects than just toughing it out andtJ hoping that Intel's dominating presence in the industry will prevail where its technology can't.t  J Since Itanic is still right down to the gunwales in heavy seas, announcingK even just a strategic withdrawal to Alpha and PA-RISC until it's 'ready fornJ prime time' could well cause it to go under.  As could Intel support for aK direct Hammer competitor, which may well be why they just announced that nooG Yamhill is planned (though that also suggests that Yamhill may not havenG stacked up very well against Hammer either, so better to back the horsetJ that's already run half the race, albeit unimpressively, than a completely0 new entry with nothing particular going for it).  H As long as there's any hope at all for Itanic to survive, Carly won't doC anything that might jeopardize that - including commit to any AlphaoH development beyond that already defined.  Compaq had a relatively narrowL window of opportunity to reverse its Alpha decision fairly soon after havingF made it, but that window closed long ago and it would take an absoluteJ catastrophe (though that may yet occur) to make opening it up again appearK attractive.  In other words, unless Itanic sinks beyond any hope of rescue,eL count on it (and the already-defined limited Alpha development) as being the% future for VMS, and plan accordingly.   J Unless an already-dubious world passionately clasps McKinley to its breastJ (for reasons which I cannot even begin to imagine, but equally nonsensicalI things have happened over the years), cHumPaq's enterprise business (savedK possibly in storage, if they don't screw that up too) will be only a shadow J of its pre-Alphacide self two years from now.  Since Carly appears to loveG high-stakes poker even, or perhaps especially, when her hand is alreadywJ beaten by the cards showing on the table, expect her to take HP right down with her if Itanic sinks.s   - bill   ------------------------------  # Date: Wed, 19 Jun 2002 21:51:26 GMTm( From: "Tom Simpson" <simpsont@attbi.com>- Subject: Re: CONNECT:Direct wildcard transfer-- Message-ID: <y17Q8.81717$nZ3.34638@rwcrnsc53>0   Xavier,m  K Your chances of getting a working script that does exactly what you want it  toH are slim to none, especially without providing more details.  It is very simple, buthI VMS environments vary wildly using different file names, directory names,f1 node names, etc.  You have to fill in the blanks.i   Regards, Tom   E "Xavier Nicolovici" <xavier.nicolovici@citicorp.com> wrote in messagee6 news:e033a250.0206190414.fcfb27b@posting.google.com...
 > Thanks Tom,m >.B > That's the kind of information I need. I was just expecting that" > someone has a working script ;-) > H > I do not have access to the VMS platform and did wanted to provide theG > script to our engineers. Now, as it seems to be very simple, it shoudt# > not be a problem to implement it.t >n. > The choice of CONNECT:Direct wasn't mine ;-) >  >e5 > "Tom Simpson" <simpsont@attbi.com> wrote in messageh$ news:<RuOP8.435$EP.340@sccrnsc03>...= > > How about something like this?     This is from memory...  > >i
 > > $LOOP:: > > $     cur_file = f$search("DISK$USER:[TEST]FUBAR.*",1)2 > > $     if cur_file .eqs. "" Then Goto loop_exit > > $!+ > > $     COPY 'cur_file'   <to where ever>u > > $! > > $     Goto loopm > > $! > > $LOOP_EXIT:a
 > > $ exit > >i6 > > My condolences on your choice of Connect:Direct... > >  > > Regards, > > Tom  > >wI > > "Xavier Nicolovici" <xavier.nicolovici@citicorp.com> wrote in message ; > > news:e033a250.0206180656.768a3fc0@posting.google.com...u	 > > > Hi,i > > >hK > > > I'm currently trying to set up a file transfer between a VMS platformdF > > > and an NT one. We have concluded to use, for various reason, the1 > > > CONNECT:Direct tool from Sterling Commerce.t > > >bJ > > > I would like to transfer a set of file from this VMS platform to theJ > > > NT one, but the only information I have about those file is the fileJ > > > name pattern. A random generated number is added to the filename, inI > > > order to avoid file overwritting (the file are created from time toi > > > time). > > > K > > > Now, CONNECT:Direct can not perform wildcard file transfer, and I was I > > > wondering, for this simple task, if someone has already developed a_K > > > small script that loops in a particular VMS area, and search for eachd@ > > > existing file to perform a call to the CONNECT:Dircet API. > > >v > > > Many thanks in advance,2 > > >  > > > Xavier Nicolovicih   ------------------------------   Date: 19 Jun 02 20:58:12 +0200) From: p_sture@elias.decus.ch (Paul Sture)i) Subject: Re: Console hang solved (almost)|) Message-ID: <UxMbgIoMNzbD@elias.decus.ch>G  b In article <d56d1c2d.0206190933.6dc128e4@posting.google.com>, cstranslations@msn.com (Joe) writes:= > Thanks for all replies both to the news group and off line.e > E > I've tracked down the nightly disappearance of the console login to-D > the nightly running of a batch job someone put together to stop/idE > most INTERACTIVE users every night at 23:45. DTLOGIN is the hint...  > A > Still have problems with the logon screen not reappearing aftergF > logging off from the console. While playing around with this part of > the problem this morning...e > C > If I (telnet) in and DELETE [.DT...]*.*;* I can then logon on thevG > console and get the logon screen back when logging off. At that point G > any subsequent console logons I attempt leave me with the gray baskete> > weave (until I remove [.dt...]*.*;* as above). Seems to be a9 > protection thing. If I enable BYPASS by default (UAF =>pD > modify/defpriv=bypass) the logout runs all the way through and the( > console redisplays the logon screen... > @ > I'm not seeing anything in the protection settings on the "dt"F > directory tree (for as long as I've been staring at it it would have% > to jump off the screen and hit me).c > < > Is there something afoul in the below protection settings?A > Is there something I'm not think of (or not aware of) - defaultMB > settings for decwindows, default protection setting a la SYSGEN? >h  I Yes. This is a known bug. Notice that the CURRENT.DIR has no Owner Deleten access.s  M I'll have to look it up, as IIRC there was another subdirectory (SESSIONS.DIRcL ?) concerned, but my quick and dirty workaround at the time involved settingE  the protection of specified subdirectories under [.DT] to OW:WRED ind SYLOGIN.COM.   See the thread at g http://groups.google.ch/groups?q=comp.os.vms+wred+.dt&hl=de&lr=&selm=355070CE.5B936986%40ubs.com&rnum=1   E > I wouldn't think one would have to have bypass on by default to logn > off of the console...  >  > joem > $ > Directory __DKB500:[IAC.FOOBAR.DT] > % > APPMANAGER.DIR;1     (RWE,RWE,RWE,)h# > DESKTOP.DIR;1        (RWE,RWED,,)t( > ERRORLOG.;1          (RWED,RWED,RWED,)( > ERRORLOG.OLD;1       (RWED,RWED,RWED,)% > HELP.DIR;1           (RWE,RWE,RWE,) % > ICONS.DIR;1          (RWE,RWE,RWE,))% > SESSIONS.DIR;1       (RWE,RWE,RWE,)p% > TMP.DIR;1            (RWE,RWE,RWE,);+ > TRASH.DIR;1          (RWE,RWED,RWED,RWED)g% > TYPES.DIR;1          (RWE,RWE,RWE,)  >  > Total of 10 files. > - > Directory __DKB500:[IAC.FOOBAR.DT.SESSIONS]a > % > CURRENT.DIR;1        (RWE,RWE,RWE,)o( > DTWMFP.SESSION;1     (RWED,RWED,RWED,) >  >  > Total of 2 files.  > 5 > Directory __DKB500:[IAC.FOOBAR.DT.SESSIONS.CURRENT]  > ( > DT.RESOURCES;1       (RWED,RWED,RWED,)( > DT.SESSION;1         (RWED,RWED,RWED,)( > DT.SETTINGS;1        (RWED,RWED,RWED,)% > DT089913.;1          (RWD,RWD,RWD,)l >  > Total of 4 files.x > * > Directory __DKB500:[IAC.FOOBAR.DT.TRASH] > % > .TRASHINFO;1         (RWD,RWD,RWD,)s >  > Total of 1 file. > * > Directory __DKB500:[IAC.FOOBAR.DT.TYPES] > ' > FP_DYNAMIC.DIR;1     (RWE,RWED,RE,RE)c >  > Total of 1 file. > ) > Grand total of 5 directories, 18 files.  --   __
 Paul Sture Switzerlandn   ------------------------------  % Date: Wed, 19 Jun 2002 16:22:16 -0400n, From: "Frank Sapienza" <sapienza@noesys.com>$ Subject: Re: Could linux become VMS?, Message-ID: <aeqp10017tl@enews2.newsguy.com>  > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:aeps6e$5pt$1@info.cs.uofs.edu...c1 > I don;t know about you, but I don't use a mono-y > case natural languagei  C Really?  Does your dictionary show different meanings for the words - "Dictionary", "DICTIONARY", and "dictionary"?i  D All natural languages are mono-case.  Just because we may format ourI sentences using upper- and lower-case letters for appearance doesn't makey the language case-sensitive.   ------------------------------  % Date: Wed, 19 Jun 2002 19:07:50 +0000e2 From: John Eisenschmidt <jweisen@eisenschmidt.org>A Subject: Re: Disaster Tolerant advertising using Fortune magazinev4 Message-ID: <20020619190750.F31710@eisenschmidt.org>  I Unless the Voices are Mistaken, Bill Todd (billtodd@metrocast.net) Wrote:e > A > "John Eisenschmidt" <jweisen@eisenschmidt.org> wrote in messaget0 > news:20020618194306.E30373@eisenschmidt.org...L > > I can't imagine that rolling HP-UX and Tru64 would be remotely easy. MayL > make sense to keep HP-UX for PA-RISC and Itanic, Tru for Alphas, bring the5 > best of Tru64 into HP-UX over the next couple yearsh > L > Making HP-UX anything like a proper functional superset of Tru64 - or evenN > the more limited objective of incorporating AdvFS and clustering - will takeM > a good deal longer than two years (unless you don't think any field-testingi > will be necessary...).   Don't forget, there are some people who think Tru64 is the broken one, not HP-UX. But yeah I think we're on the same page here.c  ( >  and add a binary compatability layer. > G > Binary compatibility between little-endian and a big-endian platformstN > running on completely different hardware is something I won't hold my breath > waiting for - ever.t  7 Uhh - FX32! Hello? Or do you not consider that working?    > - bill >    -- e/ John W. Eisenschmidt <jweisen@eisenschmidt.org>r6  Homepage URL    | http://www.eisenschmidt.org/jweisenM  GPG Public Key  | http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.asc D  GPG Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2   ------------------------------  # Date: Wed, 19 Jun 2002 20:14:57 GMTi* From: "Bill Todd" <billtodd@metrocast.net>A Subject: Re: Disaster Tolerant advertising using Fortune magazineeC Message-ID: <5D5Q8.328557$Oa1.25780008@bin8.nnrp.aus1.giganews.com>   ? "John Eisenschmidt" <jweisen@eisenschmidt.org> wrote in messages. news:20020619190750.F31710@eisenschmidt.org...K > Unless the Voices are Mistaken, Bill Todd (billtodd@metrocast.net) Wrote:o > >oC > > "John Eisenschmidt" <jweisen@eisenschmidt.org> wrote in message.2 > > news:20020618194306.E30373@eisenschmidt.org...   ...e  * > >  and add a binary compatability layer. > >nI > > Binary compatibility between little-endian and a big-endian platforms I > > running on completely different hardware is something I won't hold myl breath > > waiting for - ever.t >m9 > Uhh - FX32! Hello? Or do you not consider that working?e  K I'm afraid I don't consider a software interpreter (as distinct from, e.g.,PI a VMS system interface layer on Alpha that could run Alpha Linux binariesfK natively, which could be fairly interesting) as being an effective solutionEF unless it can run code with near-native performance and in native-likeH surroundings.  FX!32 was a very significant accomplishment, but it stillE only had to translate from a register-poor hardware architecture to a E register-rich (and at least originally significantly faster) hardware F architecture of the same little-endianness running *the same operatingE system and environment* (NT).  By contrast, a Tru64 Alpha interpreteriJ running on HP-UX would have to convert from one register-rich architectureK to another (but slower) one of opposite endianness (I guess you could use aoC cache-resident table to reverse the bits in each byte:  it might be G preferable to add support to HP-UX to run some processes using Itanic's H little-endian facilities, but that's no small job), while simultaneouslyF converting between the Tru64 process execution environment and HP-UX'sI non-trivially different one (there's a reason knowledgeable people guffawe= when Unix is called an 'industry standard', and part of it iseK subtly-differing APIs that can only partially be masked by language runtimesH systems).  Oh, and the environment also has to handle any differences inK process structure (e.g., in use of and linkage to sharable libraries).  AndcK let a Tru64 process fork a child in its own image.  And probably a bunch of J other things that, as I'm not a Unix user, don't immediately come to mind.   - bill   ------------------------------    Date: 19 Jun 2002 13:28:16 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)bA Subject: Re: Disaster Tolerant advertising using Fortune magazinei= Message-ID: <cf15391e.0206191228.4d830a25@posting.google.com>f  t "Bill Todd" <billtodd@metrocast.net> wrote in message news:<XuOP8.301404$Gs.23902216@bin5.nnrp.aus1.giganews.com>...G > Binary compatibility between little-endian and a big-endian platformsoN > running on completely different hardware is something I won't hold my breath > waiting for - ever.   F While still not "binary compatibility" in the strictest sense, of muchD more applicability than FX!32 to this discussion is FreePort ExpressB (see http://www.support.compaq.com/amt/freeport/index.html), whichA does binary translation of big-endian SPARC code to little-endianf Alpha code.n: ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------  # Date: Wed, 19 Jun 2002 20:54:33 GMTU* From: "Bill Todd" <billtodd@metrocast.net>A Subject: Re: Disaster Tolerant advertising using Fortune magazinerB Message-ID: <dc6Q8.311063$Gs.24603057@bin5.nnrp.aus1.giganews.com>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0206191228.4d830a25@posting.google.com... 7 > "Bill Todd" <billtodd@metrocast.net> wrote in messagei> news:<XuOP8.301404$Gs.23902216@bin5.nnrp.aus1.giganews.com>...I > > Binary compatibility between little-endian and a big-endian platforms?I > > running on completely different hardware is something I won't hold myD breath > > waiting for - ever.l > H > While still not "binary compatibility" in the strictest sense, of muchF > more applicability than FX!32 to this discussion is FreePort ExpressD > (see http://www.support.compaq.com/amt/freeport/index.html), whichC > does binary translation of big-endian SPARC code to little-endian.
 > Alpha code.&  G Now something like that I can believe might be feasible, though I stilleL suspect there would be a lot of API nooks and crannies that would have to be investigated thoroughly.  E And when it comes to things like translating third-party libraries, IE0 suspect there might be licensing issues as well.   - bill   ------------------------------  % Date: Wed, 19 Jun 2002 14:46:18 -0400 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> 4 Subject: Re: howto create self-extracting zip files?$ Message-ID: <3d10d16b$1@news.si.com>  I >The above is generally applicable to CDSA on OpenVMS as well, with a few  minor 	 >changes:. > ( >  o CDSA is a supported part of OpenVMS9 >  o CDSA ships as a required component of OpenVMS V7.3-1P  J Is this another one of those, "well, everyone but the Luddites using VAXes get it" items?  If so, why?S --A Brian Tillman                   Internet: tillman_brian at si.comIA Smiths Aerospace                          tillman at swdev.si.comW= 3290 Patterson Ave. SE, MS      Addresses modified to preventf< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Wed, 19 Jun 2002 17:48:57 -0400 * From: WILLIAM WEBB <WWEBB1@email.usps.gov>4 Subject: RE: howto create self-extracting zip files?- Message-ID: <0033000068762586000002L062*@MHS>-  4 =0ALuddites, being technophobes, wouldn't use VAXen.  - They'd use fingers, small stones or the like.    WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNETl& Sent: Wednesday, June 19, 2002 2:49 PMB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET4 Subject: RE: howto create self-extracting zip files?    H >The above is generally applicable to CDSA on OpenVMS as well, with a f= ew minor 	 >changes:i >.( >  o CDSA is a supported part of OpenVMS9 >  o CDSA ships as a required component of OpenVMS V7.3-1-  H Is this another one of those, "well, everyone but the Luddites using VA= Xes  get it" items?  If so, why?  --A Brian Tillman                   Internet: tillman_brian at si.com1A Smiths Aerospace                          tillman at swdev.si.comn= 3290 Patterson Ave. SE, MS      Addresses modified to prevent7< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"9        This opinion doesn't represent that of my company=i   ------------------------------  % Date: Wed, 19 Jun 2002 11:25:24 -0300a% From: <fabio_compaq@petrobras.com.br>rG Subject: HP Lan Console for who doesnt know it .... x 3 (the real link)nL Message-ID: <OF698AC75D.4223A854-ON03256BDD.004E5FBF@ep-bc.petrobras.com.br>   Clickv  H http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x0fe5d211e18ad5118ff100= 90279cd0f9,00.html  + Better link to see the online documentationh  H http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=3D/hpux/onlined=H ocs/A5201-10006/A5201-10006_top.html&con=3D/hpux/onlinedocs/A5201-10006=H /00/00/62-con.html&toc=3D/hpux/onlinedocs/A5201-10006/00/00/62-toc.html=, &searchterms=3DGSP&queryid=3D20020619-072800 Regards   
 Fabio Cardoso     H  ----------------------------------------------------------------------= ----=20fH  "Toda informa=E7=E3o gerada ou adquirida no desenvolvimento das ativid= ades da =20 H  Bacia de Campos =E9 de propriedade da Petrobras e deve ser compartilha=	 da de =20 H  modo seguro e exclusivamente em benef=EDcio do resultado do neg=F3cio,=         =20dH  respeitando a Pol=EDtica de seguran=E7a da Informa=E7=E3o, requisitos = legais e    =20aH  princ=EDpios =E9ticos vigentes."                                      =         =20 H                                                                        =     =20fH  O descumprimento da Pol=EDtica de Seguran=E7a da Informa=E7=E3o implic= ar=E1 em      =20tH  processo investigat=F3rio, sujeitando o infrator a processo legal e   =	       =20eH  administrativo, podendo ocasionar em san=E7=F5es disciplinares previst= as no   =20 H  regimento disciplinar da Petrobras e nas puni=E7=F5es previstas em lei=
        =20H                                                                        =     =20KH  This message contains confidential and proprietary information to     =     =20eH  Petrobras.                                                            =     =20 H                                                                        =     =20wH  If it has been delivered in error, please notify the sender and destro= y   =20eH  the message.                                                          =     =20 H  ----------------------------------------------------------------------= ----=20o   =e   ------------------------------  % Date: Wed, 19 Jun 2002 22:26:07 +0200t- From: Didier Morandi <Didier.Morandi@Free.fr>t3 Subject: HP RoadShow in France these days: a reporti& Message-ID: <3D10E8DE.3952A30@Free.fr>  ( We had an HP RoadShow in Toulouse today.   I summarize:  S TNHP is Nr 1 everywhere but in services, where 1 is IBM GS, 2 is EDS and 3 is TNHP. K Two hours to say that "you should not consider to move to another platform"a/ The presentation on the printers was very good.a  ' The cake on the cherry was this phrase:d  ! VMS sales in France : +3% in 2001o  # I think that I am in love again :-)c   D. --  2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  # Date: Thu, 20 Jun 2002 02:52:04 GMTe1 From: "David J. Dachtera" <djesys.nospam@fsi.net>h7 Subject: Re: HP RoadShow in France these days: a reportb& Message-ID: <3D114735.8D0A0F2@fsi.net>   Didier Morandi wrote:p > * > We had an HP RoadShow in Toulouse today. >  > I summarize: > U > TNHP is Nr 1 everywhere but in services, where 1 is IBM GS, 2 is EDS and 3 is TNHP.aM > Two hours to say that "you should not consider to move to another platform"i1 > The presentation on the printers was very good.> > ) > The cake on the cherry was this phrase:  > # > VMS sales in France : +3% in 2001f > % > I think that I am in love again :-)   A If *ANY* region can manage 30%, and sustain it for at least sevene1 consecutive quarters, I'll marry *ALL OF 'EM* !!!    -- l David J. Dachterac dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/.   ------------------------------  % Date: Wed, 19 Jun 2002 14:48:03 -0400n; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> / Subject: Re: http osu web server open vms 7.2-2e" Message-ID: <3d10d1d4@news.si.com>  3 >Any ideas running the OSU web server on vms 7.2-2.e  J Please ask this question in the VMS-WEB-DAEMON mailing list, where it will- be answered by others who use the OSU server.l --A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.comt= 3290 Patterson Ave. SE, MS      Addresses modified to preventk< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------   Date: 19 Jun 02 20:35:41 +0200) From: p_sture@elias.decus.ch (Paul Sture)i* Subject: Re: install image /write/resident) Message-ID: <dJGumf8uOMMY@elias.decus.ch>a  Z In article <3D0E8CA3.9000908@qsl.network>, "John E. Malmberg" <wb8tyw@qsl.network> writes: > Jakob Erber wrote:	 >> Hello,o >> nF >> according to compaq engineering, one of our sharable images must beK >> installed with the qualifiers above, in order to be able to link symbols M >> dynamicly via dlsym. I would be glad if somebody could give me hints about 4 >> possible negativ side effects of this qualifiers. >  > How about a cookbook?y > A > http://www.openvms.compaq.com/wizard/swdev/ovms-shexe-cook.htmlu > K > A shared image must be installed as writable if it has a data psect that n' > is writable by more than one process.v > G > This has implications in a VMSCLUSTER, as each member of the cluster o4 > must have their own private version of this image. >   O Also note that unless the image is deinstalled before backups, BACKUP needs ther1 /INGORE=INTERLOCK qualifier to back the file up. s  -K > It is much better if you can design your shared image to not require the e > /write qualifier.i > J > Frequently this is caused by process private data being marked as being ? > shared between processes.  See the cookbook referenced above.t > K > Otherwise, you can code the image to create a dynamic global section for dI > the shared data, and then your shared image will not need the writable o > attribute.  M A dynamic global section will not preserve the data across reboots, whereas ae writeable shared image will. __
 Paul Sture Switzerlandn   ------------------------------   Date: 19 Jun 2002 22:38:30 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)* Subject: Re: install image /write/resident* Message-ID: <aer156$or8$3@web1.cup.hp.com>  U In article <dJGumf8uOMMY@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:oM :A dynamic global section will not preserve the data across reboots, whereas i :a writeable shared image will.i  G   Um, the mechanism used to implement the (position-dependent) writable J   shareable image on OpenVMS is the (position-independent) global section H   mechanism of OpenVMS -- a global section can most certainly flush its %   contents to disk, in other words.  )  E   The "real fun" with shared memory is not the backing storage, it iseF   SMP synchronization, granularity of reference, and memory caching.  F   Ask The Wizard topics (1661), (2486), (2681), (6984), and (7383) -- G   among others -- can be of interest here.  There are some discussions tE   of addressing granularity of reference in the OpenVMS FAQ, as well.   J   I prefer to avoid the writable shareable image, if for no other reasons E   than for its position-dependence, its fixed sizing, and the need tonG   install what is in effect the backing storage file.  Global sections eE   are rather more flexible in these regards.  (Position independence  F   will typically require use of pointers within an application that is(   utilizing global sections, of course.)    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 19 Jun 02 20:24:08 +0200) From: p_sture@elias.decus.ch (Paul Sture)t> Subject: Mac keboard mapping - was Re: Could linux become VMS?) Message-ID: <J8odd6$0SR3j@elias.decus.ch>i  c In article <3D0DDBE3.3E69F050@mindspring.com>, Atlant Schmidt <atlantnospam@mindspring.com> writes:w > Paul Sture wrote:a > R >> I'm currently trying to come to grips with a Mac iBook. OS X may be a wonderfulN >> thing, but a unix based system without a pipe character on the keyboad (norL >> square nor curly brackets for that matter) does present certain problems. > / > Is that a "national" keyboard (e.g., French?)t) > that doesn't have the "pipe" character?m >    <snip>  c- > When you've done the deed, a small national'0 > flag will appear in the right-hand part of the/ > menu bar. That's a pull-down menu and it will / > quickly let you select keyboard mappings. Thew- > "US" mapping should certainly have the pipet% > character in the usual US position.P > M Thanks. Clicking on the flag symbol gave me a choice of German, Swiss German,eN or customize. Customize allows selection from a host of layouts, amongst which& is US. Now set to Swiss German and US.  ' Here are the elusive []{}|# characters.e  M Further to that, alt-apple-space toggles the setting, so no mousing required.  __
 Paul Sture Switzerland.   ------------------------------    Date: 19 Jun 2002 11:05:09 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)1+ Subject: McKinley die smaller than expectede= Message-ID: <cf15391e.0206191005.68430b1e@posting.google.com>o  E According to ZDnet, the McKinley die size turned out to be 421 squaregE millimeters instead of 464 as previously predicted back in February. aB A smaller die size typically results in increased yields and lowerC costs in two ways: fitting more chips on a wafer of silicon, and bym2 decreasing the odds of a defect in any given chip.  D McKinley is manufactured in a .18 micron process, and is expected toD debut at 1 Ghz.  Madison, due in 2003, will be a .13 micron shrink. = Montecito is slated for 2004, followed by Chivano in 2005-6. eE (Montecito and Chivano are reported to have designs influenced by theo Alpha team.)  K http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2870642,00.htmln   ------------------------------  # Date: Wed, 19 Jun 2002 19:38:46 GMTn* From: "Bill Todd" <billtodd@metrocast.net>/ Subject: Re: McKinley die smaller than expectedhB Message-ID: <a55Q8.310599$Gs.24556328@bin5.nnrp.aus1.giganews.com>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0206191005.68430b1e@posting.google.com...BG > According to ZDnet, the McKinley die size turned out to be 421 squarenF > millimeters instead of 464 as previously predicted back in February.D > A smaller die size typically results in increased yields and lowerE > costs in two ways: fitting more chips on a wafer of silicon, and byr4 > decreasing the odds of a defect in any given chip.  I Not exactly new information, however, since it has been known for months.i   >tF > McKinley is manufactured in a .18 micron process, and is expected toE > debut at 1 Ghz.  Madison, due in 2003, will be a .13 micron shrink. > > Montecito is slated for 2004, followed by Chivano in 2005-6.G > (Montecito and Chivano are reported to have designs influenced by them > Alpha team.)  F Perhaps reported by ZDnet, but not by either Intel (which has recently? announced Montecito's differences from Madison as being 'little6I enhancements', though a quite a while ago had been reported as suggestinghG that both Montecito and Chivano would contain Alpha benefits) nor by atiF least one member of the former Alpha team (who laughed derisively fourG months ago at the suggestion that any significant Alpha influence woulde appear as early as 2004).g  K Another question that has recently arisen w.r.t. Madison is how much fastermE than McKinley it will likely be.  Paul DeMone projected in his latest.L realworldtech.com article on the subject that it would run at 1.8 GHz, whichL seemed so unlikely an increase (for a mere process-shrink plus the migrationH to Cu technology) over McKinley's 1.0 Ghz (if indeed McKinley can indeedJ wheeze its way up to that lofty figure) that I questioned it publicly in aL realworldtech forum - but have yet to receive any response.  I did, however,I recently stumble over some extensive industry roadmaps at Mike's HardwarelG which stated that Madison was projected to run in the 1.2 GHz - 1.6 GHz-L range next year (one might guess that the higher speeds would be the longestE in arriving, if they actually arrive at all) - numbers in much closereI agreement to those expected to result from EV78's shrink to EV79 (1.2 GHz>D for EV78 in a 180 nm process, 1.6 GHz for EV79 in a 130 nm process).   - bill   ------------------------------   Date: 19 Jun 2002 18:53:49 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)- Subject: Re: Middle European DST change ruleso* Message-ID: <aeqjvt$lth$1@web1.cup.hp.com>  e In article <9a924482.0206182210.5cafb23b@posting.google.com>, bart.zorn@xs4all.nl (Bart Zorn) writes:m   ..B :Maybe the solution is to document (and I mean really document andE :not the sorry excuse for documentation that is taken over from Un*x) C :the procedure to implement one's own time zone rules! Part of this"> :documentaion should include the way to install this new rule.9 :I have managed to compile one, but failed to install it.. ..    K   Is the documentation on creating a timezone rule for "WhereEverLand" thateL   is included in the current OpenVMS FAQ insufficient?  (If I have not addedK   sufficient detail on this topic into the FAQ, I'd like to hear about it.)t    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 19 Jun 2002 16:10:12 -0400e, From: "Frank Sapienza" <sapienza@noesys.com>5 Subject: Re: My conversation with Linus about VMS ...w, Message-ID: <aeqoac016lg@enews2.newsguy.com>  > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:aeq5l1$a9s$1@info.cs.uofs.edu...iG > And the experience here is and has been the exact opposite.  We still H > have an OpenVMS/Alpha available for general faculty/staff/student use.H > It is usually idle.  On the other hand, as long as I have been the SysI > Admin here in the CS Dept.  I have had to handle requests from faculty,vD > staff and students from outside the department for accounts on ourD > machines because they don't want to use the VMS machine.  And thisB > with the VMS machine having a history of use pre-dating any UnixH > system here.  (I set up the first Unix system upon my arrival about 153 > years ago, prior to that there was no Unix here.)L >*  I Can you attribute this to a distaste for the VMS user interface or simplyfG because there aren't enough applications running on the VMS system that-J people want/need to use?  If, once the Unix systems were introduced, folksL started developing to the Unix systems (or installing applications that onlyJ run under Unix) and slowly started leaving the VMS systems behind, then itF could be understandable that the VMS box is idle.  I'd find it hard toE believe that once the Unix boxes showed up everybody just cold-turkeyhL dropped the VMS systems and said, "wow, this Unix system is *so* much easierA to use".  I'd suspect the transition happened because more of the I applications needed were available under Unix and not VMS, as well as thetH likelihood that Unix was/is a more recognizable O/S name and that's were& people wanted to do their development.  H Putting Unix on your resume is likely of more value to a larger audience than is VMS.   ------------------------------   Date: 19 Jun 2002 23:29 CDT-' From: carl@gerg.tamu.edu (Carl Perkins)15 Subject: Re: My conversation with Linus about VMS ...a- Message-ID: <19JUN200223295413@gerg.tamu.edu>s   bill@cs.scranton.edu writes...+ } carl@gerg.tamu.edu (Carl Perkins) writes:D }|> E }|> Most computer professionals could use a CLI that only made use ofQE }|> four keys ("-", ".", <space>, and <return>) which required you torE }|> enter everything in morse code spelling out grammatically correctnC }|> English language statements and questions. It would be a simple0G }|> matter of spending the effort to learn it. Anybody who already knew/? }|> morse code would not find this very difficult. .... --- .--P> }|> ... .- .-. -..  -.-. --- ..- .-.. -..  .. -  -... . ..--.. } $ }"How sard would it be?"   Hmmmm....K }Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesd  A 1) Somewhere along the line a dot went away. It is still there ind@ my original file that was sent. Your news client may strip a dotA if it is the first character on a line (some do, as I recall), oro4 it could have happened somewhere else along the way.  " There are 4 dots on the next line: ...s2 They may, or may not, all make it through to you.   D Clearly, this stuff was not designed for transmission of morse code.? (Which I don't actually know, other than SOS - I looked it up.)s  1 2) That is "could" not "would". C = -.-., W = .--7   --- Carl   ------------------------------   Date: 20 Jun 2002 00:11 CDTf' From: carl@gerg.tamu.edu (Carl Perkins) 5 Subject: Re: My conversation with Linus about VMS ...p- Message-ID: <20JUN200200111913@gerg.tamu.edu>i  , bob@instantwhip.com (Bob Ceculski) writes...] }carl@gerg.tamu.edu (Carl Perkins) wrote in message news:<19JUN200202142683@gerg.tamu.edu>... K }> We used to have a VAXcluster (later a VMScluster) here at Texas A&M that K }> was accessable to all students, faculty, and staff. Every year thousands G }> of new students of all majors would learn how to use it. They did so I }> mainly via a rather brief handout, and a few minutes of explanation innI }> any class that actually required its use, and were supported by a help H }> desk staffed almost entirely by part-time student workers. There wereH }> also various public Unix systems - these were avoided like the plague }> by most non-CS majors.  }> e }> --- Carl2 } F }since you said "used to" have a vms cluster, now that you don't, does0 }that mean no non CIS majors use the system now?  H It means that PCs drove it out of the public access business completely,J along with the Unix systems (I think there may still be one general accessE Unix system that anybody can get an account on with shell access, butsD I'm not sure - the main e-mail servers are Unix, but that is managedH via a web interface and the users can't log in, and likewise for variousD other services; various departments do their own thing for their ownG people, as always). The cluster does still exist (two nodes, I seem to aE recall that they were dual processor 4100 series Alphas - at one timeoC the biggest system in the cluster was a VAX 9000 which, unlike somenF people here, I found to be quite spiffy but I only used it a few timesA and didn't manage it) and are doing something but I think it is aeA captive login that does nothing but connect you to other services.A (via telnet) such as various things that have always lived on therA "mainframe" system running MVS - I doubt that the people using itoB know they are doing it via a VMS system. No DCL prompt availabe to the general public.r   --- Carl   ------------------------------    Date: 19 Jun 2002 12:58:11 -0700- From: jodonnell@hrblock.com (Jason O'Donnell)oE Subject: Re: NSA: Security in current mainstream operating systems vso= Message-ID: <9059bf6b.0206191158.755b208b@posting.google.com>   | Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KJ4CII230O96WTPR@sysdev.deutsche-boerse.com>...- > > d|i|g|i|t|a|l had a bolt-on called SEVMS.r > >L= > > Properly configured, it moved things up to the "B" level.t > >w< > > One of the many things that HP ought to resurrect, IMHO. > D > I think Hoff mentioned here a while back that VERY few folks were G > interested in buying this.  Lack of marketing?  Maybe.  On the other tH > hand, how many folks need SEVMS instead of VMS and are willing to pay  > the premium?  E It is my understanding that the DOD COE version 7.2-???? would be the  same thing.t  D It is also my understanding that the plan is to merge those security' enhancements back into mainstream OVMS.-  D Your friendly neighborhood OVMS Representative should be able to get that information for you.    JMOD   ------------------------------    Date: 19 Jun 2002 16:21:46 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)1E Subject: Re: NSA: Security in current mainstream operating systems vss3 Message-ID: <LEnBUnAlzQ8B@eisner.encompasserve.org>-  m In article <9059bf6b.0206191158.755b208b@posting.google.com>, jodonnell@hrblock.com (Jason O'Donnell) writes:t~ > Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KJ4CII230O96WTPR@sysdev.deutsche-boerse.com>.... >> > d|i|g|i|t|a|l had a bolt-on called SEVMS. >> >> >> > Properly configured, it moved things up to the "B" level. >> >= >> > One of the many things that HP ought to resurrect, IMHO.e >>  E >> I think Hoff mentioned here a while back that VERY few folks were oH >> interested in buying this.  Lack of marketing?  Maybe.  On the other I >> hand, how many folks need SEVMS instead of VMS and are willing to pay a >> the premium?x > G > It is my understanding that the DOD COE version 7.2-???? would be thed
 > same thing.n  = If you mean "technically equivalent to SEVMS", you are wrong.a; If you mean "just as popular as SEVMS", you might be wrong.t  F > It is also my understanding that the plan is to merge those security) > enhancements back into mainstream OVMS.B  F I don't know what antecedent you intended for "security enhancements",4 but I do not feel it applies to the DII-COE support.   ------------------------------  % Date: Wed, 19 Jun 2002 17:35:38 -0400e* From: WILLIAM WEBB <WWEBB1@email.usps.gov>E Subject: RE: NSA: Security in current mainstream operating systems vs - Message-ID: <0033000068760864000002L042*@MHS>t  B =0ADII-COE involved more of the POSIX interface stuff, as I recall than the security enhancements.b  7 It's common knowledge that some of the folks who boughts4 SEVMS (and a lot of it, too) were in the business of% "killing people and breaking things."e  9 I'm willing to bet that those folks in Maryoland with the " great big basement bought it, too.   WWWebb,a7 who'll probably look askance at his telephone tomorrow.e (just kidding)   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNETt& Sent: Wednesday, June 19, 2002 5:21 PMB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNETE Subject: RE: NSA: Security in current mainstream operating systems vss    = In article <9059bf6b.0206191158.755b208b@posting.google.com>,g@ jodonnell@hrblock.com (Jason O'Donnell) writes: > Phillip Helbig5 <HELBPHI@sysdev.deutsche-boerse.com> wrote in message H news:<01KJ4CII230O96WTPR@sysdev.deutsche-boerse.com>... >> > d|i|g|i|t|=	 a|l had am bolt-on called SEVMS.s >> >> >> > Properly configured, it moved things up to the "B" level. >> >= >> > One of the many things that HP ought to resurrect, IMHO.8 >>D >> I think Hoff mentioned here a while back that VERY few folks wereH >> interested in buying this.  Lack of marketing?  Maybe.  On the other=  H >> hand, how many folks need SEVMS instead of VMS and are willing to pa= y  >> the premium?  >nH > It is my understanding that the DOD COE version 7.2-???? would be the=  
 > same thing.c  = If you mean "technically equivalent to SEVMS", you are wrong. ; If you mean "just as popular as SEVMS", you might be wrong.t  F > It is also my understanding that the plan is to merge those security) > enhancements back into mainstream OVMS.-  F I don't know what antecedent you intended for "security enhancements",5 but I do not feel it applies to the DII-COE support.=p   ------------------------------    Date: 19 Jun 2002 17:24:54 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)nE Subject: RE: NSA: Security in current mainstream operating systems vs-3 Message-ID: <V0aRxGl9L4u1@eisner.encompasserve.org>2  Z In article <0033000068760864000002L042*@MHS>, WILLIAM WEBB <WWEBB1@email.usps.gov> writes:D > =0ADII-COE involved more of the POSIX interface stuff, as I recall! > than the security enhancements.c > 9 > It's common knowledge that some of the folks who boughta6 > SEVMS (and a lot of it, too) were in the business of' > "killing people and breaking things."n > ; > I'm willing to bet that those folks in Maryoland with ther$ > great big basement bought it, too.  @ Don't be too sure.  The DEC SVS project was cancelled just as it> went into Field Test.  It did provide an A1 security kernel on< VAX, but it turned out there was no market for it.  The NCSC; portion of the NSA thought all the military out to use suchh: software, but the actual military agencies with the budget9 were not particularly interested, preferring to go with a  "system high" approach.t   ------------------------------   Date: 19 Jun 2002 23:57:21 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)2 Subject: Re: Obsoleting entries in a symbol vector* Message-ID: <aer5p1$qoi$1@web1.cup.hp.com>  c In article <ae5pea$4bbn4$1@ID-46415.news.dfncis.de>, "James Gessling" <jgessling@yahoo.com> writes: I :I have a shareable image (alpha) built with an options file with entries  :like: :  :abc=PROCEDURE, -- :ABC/abc=PROCEDURE, -- : F :to allow upper and lowercase calls to "abc".   When I want to remove ? :a procedure, but keep the vector consistent, I know how to do:s :- :abc=PRIVATE_PROCEDURE, -4  9   PRIVATE_PROCEDURE does reserve the entry in the vector.y  G :but I'm not sure what to do with the alias.  Linker doesn't like this:o :y9 :ABC/abc=PRIVATE_PROCEDURE, -   (if abc already private).y :s! :Should I just delet this line?     @   No.  You either need to use PROCEDURE if you want the externalC   symbol to be visible, or (if not) you don't need the alias entry.aA   (There's no reason to have an alias symbol if you're not gonna G@   have the alias entry symbol in the symbol table -- this is theC   symbol table, as distinct from the transfer symbol vector.  Thus dB   the linker permits alias entries only for =DATA and =PROCEDURE.)   :Any suggestions appreciated./  C   Please see the shareable image cookbook for details; the cookbook-D   is referenced in the OpenVMS FAQ, and is available via the OpenVMSB   Ask The Wizard website: <http://www.openvms.compaq.com/wizard/>.  D   The cookbook suggests you jump to a dummy routine; a routine whichE   returns an appropriate (success or failure) condition status and/oreB   error message, etc.  You would obviously use =PROCEDURE for thisB   routine.  You will want to increment the minor value of GSMATCH ?   appropriately -- this could be a case where you increment the C   major value, but that forces everybody to relink.  This change is D   arguably upward-compatible -- because only callers of this routineC   get the bogus routine -- and thus could be implemented using the  >   GSMATCH minor value and without forcing a relink.  Code thatA   handles return values correctly should continue to work fine...p  E   If you completely remove the entry from the symbol vector, then allhG   callers get to relink.  (If this is possible for you, it's certainly  K   an option.  Just remember to adjust the GSMATCH major value accordingly.)h    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 19 Jun 2002 21:35:02 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)# Subject: Re: OpenVMS Mailing Lists?t* Message-ID: <aeqte6$or8$1@web1.cup.hp.com>  h In article <VXqN8.217$yK6.51156@news1.iquest.net>, skidmore@alternate-venue.org (Barry Skidmore) writes:L :I am looking for a general OpenVMS mailing list.  A Google search turned upL :info-vax-request@mvb.saic.com with a mailing list called 'VMS'.  However, aM :subscription request resulted in an automated return message that no list byw :that name exists.  L   Please acquire (download) and read the OpenVMS Frequently Asked Questions G   (FAQ) document.  You will find pointers to the various mailing lists nJ   included in the FAQ, including details on Info-VAX.  You will also find =   the answers to various other (common) questions in the FAQ.m    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 19 Jun 2002 22:48:55 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)0 Subject: Re: PWS500au PowerStorm 3D30 DECWindows* Message-ID: <aer1on$or8$4@web1.cup.hp.com>  H In article <B92C3106.1432E%edl@euronet.nl>, EdL <edl@euronet.nl> writes:  C :I have the following configuration a PWS500au with PowerStorm 3D30e  :card and a 14" digital monitor.  A   Which specific monitor?  How is the PowerStorm 3D30 configured?iC   (See the OpenVMS FAQ for some suggestions on connecting graphics  A   widgets and monitors, and please see Ask The Wizard (2041) for t/   the PowerStorm 3D30 secret selector decoder.)   G :Now having troubles with DECWindows, the screens are corrupt and greenr :lines appears over the text.   E   Looks like the controller and the "mystery monitor" are mismatched, E   or (potentially, but less likely) that there is a hardware problem.t  B :In OPA0: console mode (without DECWindows) I cannot use edit/edt.  E   EDT can operate in this environment.  You can configure the console-E   as a VT52 "glass TTY", or you can use EDT in non-screen mode.  (EDT 5   works quite nicely in the raw console environment.)c      Some of the core EDT commands:   T We 1e +1 -u i;text to insert de  H   See the help text or EDT documentation for details and for additional    commands.b  F :The screen updates verys slow and line for line. And I cannot use the2 :keypad. Trying to set term/vt100 was no solution.  H   VT52 support is available in the console "glass TTY" mode.  VT100 and F   later terminal emulation support requires DECterm, and a functional H   DECwindows environment.  As an alternative, connect in via the serial H   console support -- please see the FAQ -- and use an external terminal F   emulator or (if you have one) a real serial terminal as the console.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 20 Jun 2002 02:06:41 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> + Subject: Re: rooted devices and /TRANS=CONCn' Message-ID: <3D113C90.CC04D04A@fsi.net>s   "Alan E. Feldman" wrote: > A > Comments interspersed below with a new example included! (well,  > slightly new)a > b > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3D0FEFBC.3DF012C9@fsi.net>...
 > > [snip]( > > Let me highlight the key item there: > >jI > > "If the leftmost component ends with a colon, space, comma, or a lineiL > > terminator (for example, Return), the system attempts to translate it asL > > a logical name. If the leftmost component ends with any other character,C > > the system does not attempt to translate it as a logical name."t > > H > > Now applying that iteratively, "BBB" (the translation of your "AAA")J > > ends with "B", not a colon (":"); likewise, "DKA0" (the translation ofL > > my "DJD") ends with "0", not a colon. So, this (what you're seeing) *IS* > > the documented behavior. >  > Well, yes and no.    Mostly, yes though.-   > You forgot this part:.   No I didn't. Observe:a  - > "Logical name translation can be iterative:r  0 Check that: "can be" != "must be" != "is always"   > after the system > translatesD > a logical name, it repeats the translation process for any logical: > names it finds contained within the first logical name." > D > Is BBB not "contained withing the first logical name", AAA? It is.  C *BUT* - and this is a big one: apply the rule of terminators as youw quoted in an earlier posting:e  I > > "If the leftmost component ends with a colon, space, comma, or a line-L > > terminator (for example, Return), the system attempts to translate it asL > > a logical name. If the leftmost component ends with any other character,C > > the system does not attempt to translate it as a logical name."d  G Again: "BBB" ends with a "B", *NOT*, repeat __N_O_T__ a colon (":") !!!s  @ So, according to the documentation: *MUST* the system attempt to9 translate it? According to the quote, the answer is "no".    > SoG > it should get translated. And it *DOES* get translated AS LONG AS YOU = > DON'T INCLUDE /TRANS=CONC IN YOUR "DEFINE AAA BBB" command.e  F O.k. You keep harping on that, so let's explore it in a little greater detail:   " Which of the following make sense:   $ DEFINE AAA BBB/TRAN=CONC  A Does this make sense? Well, I can see what you might be trying to.A achieve. However, according to the rules as documented as well asbG observed behavior, it does not reliably produce the desired result. So,n no, it doesn't make sense.  & $ DEFINE BBB DKA0:[FELDMAN.]/TRAN=CONC  D Does this make sense? Sure. Another example would be SYS$SPECIFIC orG even SYS$SYSROOT (just because its a search list, doesn't mean that thes- /TRANSLATION_ATTRIBUTES can't vary by index)..  / $ DEFINE SYSUAF SYS$SYSTEM:SYSUAF.DAT/TRAN=CONCa  @ Does this make sense? (The answer is left as an exercise for the reader.)   > [snip]E > I claim that the documentation is ***not clear*** about whether you E > should include a trailing colon in the equivalence name in a DEFINEp@ > statement ***WHEN THE EQUIVALENCE NAME IS ALSO ANOTHER LOGICAL
 > NAME***.  $ Dunno - it seems plain enough to me.  ? > Experience proves that you should include it when the logical  > name will be a file-spec.h   Dunno. Let's go ask VMS...    DJAS01::DDACHTERA$ sh log sysuaf8    "SYSUAF" = "SYS$SYSTEM:SYSUAF.DAT" (LNM$JOB_80D13C40)( DJAS01::DDACHTERA$ define vmsuaf sysuaf: DJAS01::DDACHTERA$ dir vmsuafl   Directory SYS$COMMON:[SYSEXE]e  > SYSUAF.DAT;1              36/36       22-MAY-2000 14:48:51.75 
 (RWED,RWED,,)m   Total of 1 file, 36/36 blocks.- DJAS01::DDACHTERA$ open/read/share uaf vmsuafr DJAS01::DDACHTERA$ close uaf" DJAS01::DDACHTERA$ copy vmsuaf nl:1 %COPY-E-WRITEERR, error writing NL:[]SYSUAF.DAT;1e= -RMS-F-IOP, operation invalid for file organization or deviceoG %COPY-W-NOTCMPLT, SYS$COMMON:[SYSEXE]SYSUAF.DAT;1 not completely copiedo DJAS01::DDACHTERA$ i  H Well, the copy failed, but not because the translation was bogus. In theG case of a complete (or even partial) filespec. (remember SYS$SYLOGIN?),r< I'd say the colon is meaningless in the second-layer DEFINE.  * > When the LNM will be a queue name, it isG > actually better to *NOT* include a trailing colon, as a previous postf > of mine made clear.S  $ Well, again, that's what I'd expect.  H Where we seem to get balled up is in the discussion of /TRAN=CONC. WhereG it makes sense to use it, it would also make sense to observe the rules2 associated with it, no?    -- l David J. Dachteran dba DJE Systemsj http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/7   ------------------------------    Date: 19 Jun 2002 14:51:03 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)W* Subject: Storage directions for The New HP= Message-ID: <cf15391e.0206191351.6d72f2c4@posting.google.com>i  B Ken Farmer pointed out on tru64.org an excellent ZDnet(UK) article@ with an interview with Howard Elias about storage in The New HP:>   http://techupdate.zdnet.co.uk/story/0,,t481-s2110483,00.html: ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------  # Date: Wed, 19 Jun 2002 23:47:17 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>i. Subject: Re: Storage directions for The New HP. Message-ID: <9K8Q8.261141$cQ3.11994@sccrnsc01>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0206191351.6d72f2c4@posting.google.com...-D > Ken Farmer pointed out on tru64.org an excellent ZDnet(UK) articleB > with an interview with Howard Elias about storage in The New HP:@ >   http://techupdate.zdnet.co.uk/story/0,,t481-s2110483,00.html< > ----------------------------------------------------------< > Keith Parris | parris <at> DECUServe <dot> decus <dot> org  A Word has it that there are some storage defections afoot as well.o   ------------------------------  # Date: Thu, 20 Jun 2002 00:59:05 GMTe* From: "Bill Todd" <billtodd@metrocast.net>. Subject: Re: Storage directions for The New HPA Message-ID: <tN9Q8.32323$8i1.1972249@bin2.nnrp.aus1.giganews.com>g  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0206191351.6d72f2c4@posting.google.com...rD > Ken Farmer pointed out on tru64.org an excellent ZDnet(UK) articleB > with an interview with Howard Elias about storage in The New HP:@ >   http://techupdate.zdnet.co.uk/story/0,,t481-s2110483,00.html  E While there's nothing particularly alarming in Elias's comments aboutlI storage, he seemed to feel he had to sneak in the corporate bullshit thatEJ "Alpha couldn't do what Compaq wanted in the broad Unix market" as opposedE to admitting that the dolts running Compaq had no fucking clue how to   leverage that significant asset.   - bill   ------------------------------    Date: 20 Jun 2002 06:00:17 +0800, From: Paul Repacholi <prep@prep.synonet.com>* Subject: Re: Sun/Slowaris future in doubt!0 Message-ID: <878z5bkjym.fsf@k9.prep.synonet.com>  * bob@instantwhip.com (Bob Ceculski) writes:  D > Since everyone here is so quick to speculate that Itanium/VMS willA > fail, why are saying that Sun/Hammer will not?  Makes no sense,nE > esp. when pitting Alpha/VMS engineers againset Sun/AMD engineers, IfC > would expect Itanium VMS chances of survival to be a heck of alotf< > better than Sun/AMD!  We all know that Sparky chip is deadD > ... unless they can keep adding on more chips ... 512, 1024, 2048,D > to get the thing to look like it can run fast ... so Alpha is deadC > after EV7, and sparc is dead now ... EV7 will outperform sparc byRE > years, the question is, why buy Sun/Slowaris?  Hammer One right nowM > looks like Itanic one ...,  E Well, after Dave's comment, how could I resist :) All this is IMO, sor apply salt to taste! :)s  @ The EPIC was built around the AXIOM that an OoO CPU would not beA practical, and that the odds of the compiler folk getting the bigiB break in auto parelising was a better bet. Note, this is HP in theA late 80s, a very different outlook than now. IE, 180 deg from thet EV6 design.m   What has changed is:  D 1) Power from leakage is FAR more of a worry, though Intel have doneA some very good work in ameliating this. And, it will get worse as8 processes shrink.f  C 2) Latency to cache and memory are worse. No magic bullet here, andn@ none on the horizon. Bandwidth still surcomes to enough money in the right place, like always!s  ? 3) OoO has become a proven and very workable design tool. It isiF extensible into SMT with a very small area penalty, and with the addedD cost in the Ins decode/despatch part of the chip, not in the ALU andD register file(s). This hooks back into (1), as the power/mm of PARTSC of the chip is hitting the limit. The ALU-regtisters are bad enoughu for wire and power already.o   What has not changed:o  B 1) It is still a 10 year research problem to be compilers over the `may alias' hump.a  C 2) The known Itanic performance is as expected from the clasic VLIWaB machines. It is very strong on vectorizable codes, and dies in theC arse on branchy codes. x86 emulation is nominal at best. The toutedgC 2-3 times the Alpha at release is somthing Intel are trying to have  everyone forget!  A 3) The speculative execution add to the pain in power, and on pine= bandwidth of current chips. Enough RDRAM added would ease the E bandwidth squeeze, but at the moment, the SPECfp number indicate thatgE memory bandwidth is not yet a big problem. Mind, the underperformancer all round helps here.    Now, what is in the future?   C If the compiler miracle happens, then *everyone* will be on it. TherF EPIC machines MUST have it, but all of the chips will benefit by about5 the same amount, given time to re-shuffle the design.t  B Power density becomes a bigger and bigger worry, so CMP type stuff> becomes more important. Thus increased emphisis on W/Gflop andE inter-chip signalling. Fast timming domain crossing will be absolutlynC essentaial, rather than just very nice. Itanic is probably near the D hairy edge with wire density in parts of the chip already, and as itF is scaled smaller and denser, the slower scaling of the wire, plus theB increase in power density will become a bigger and bigger limit on performance.  A Board traces are not scaling at all. So the delay as we go out toeD memory, and back will cost more and more latency and bandwidth.  AddB in speculative execution consuming memory for no good, and it getsE worse. In 1990, this made sense, now it does not, not one littel bit, E and won't until memory systems undergo a complete revolution like theuB core-mos change in the 70s. Very just like it come to think of it!  @ Hpaq are about to rediscover why DEC got into the chipset biz...? And why having all the dusks under your control is a good idea.k  E HP's enginers wanted to drop Merced once they saw that EV6 works, anddD worked well. Intel wouldn't hear of it, and insisted on flogging the@ dead donkey. If the PA9000 apears, then hp have bailed. SGI have: already, Sun, and IBM never bought the bull to start with.  @ The critical factor will be the cost of porting VMS to PA9Ks, or= POWERns or what ever, or the cost of getting Alpha revived :(   > A lower performance, low cost EV7 would make a lot of sense at
 the moment...p   -- a< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.b@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Wed, 19 Jun 2002 12:52:18 -0500r+ From: Chuck Aaron <caaron@ceris.purdue.edu>d Subject: timeout restriction0 Message-ID: <3D10C4D2.9ED98348@ceris.purdue.edu>  E Does anyone know how to remove a timeout restriction for a particulart% user from being timed off the system?n   chuckh   ------------------------------  % Date: Wed, 19 Jun 2002 16:55:47 -0400 1 From: Michael Austin <maustin@firstdbasource.com>o  Subject: Re: timeout restriction2 Message-ID: <3D10EFD3.55B94296@firstdbasource.com>   Chuck Aaron wrote: > G > Does anyone know how to remove a timeout restriction for a particularh' > user from being timed off the system?u >  > chucke  H Depends on what is used to create the "timeout". Inactive? Active? ThereH are many ways to accomplish this. Contact your system administrator.  He5 is the only one who can fix it.  Lowly users can't :)    More info required.- --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.com-E                           http://www.firstdbasource.com/donation.htmln/ 704-947-1089 (Office)     704-236-4377 (Mobile)-   ------------------------------   Date: 19 Jun 2002 22:24:15 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)  Subject: Re: timeout restriction* Message-ID: <aer0af$or8$2@web1.cup.hp.com>  ^ In article <3D10C4D2.9ED98348@ceris.purdue.edu>, Chuck Aaron <caaron@ceris.purdue.edu> writes:F :Does anyone know how to remove a timeout restriction for a particular& :user from being timed off the system?  D   Terse questions beget terse answers -- and answers quite possibly D   not to a question that you had intended to have answered.  Please D   consider providing problem details, error messages, versions, etc.D   A one- or two-line question can be ambiguous surprisingly often...  E   If you are not the system manager responsible for the configurationlI   in question, please contact the system manager directly for assistance.m  F   If this is the job controller restriction on permitted login hours, G   or the CPU time restriction, this is established on a per-user basis mF   within the specific user's SYSUAF entry.  Use the AUTHORIZE utility.  F   If this tine restriction is arising from a terminal timeout program C   (an "idle process killer") that is running on OpenVMS, or from a eE   terminal or network server, or otherwise, details on the particularo   widget will be required.  B   You will need to identify exactly what mechanism is "timing off")   the particular user(s), in other words.t    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 19 Jun 2002 19:07:00 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)  Subject: Re: timeout restriction= Message-ID: <b096a4ee.0206191807.796efbac@posting.google.com>   c Chuck Aaron <caaron@ceris.purdue.edu> wrote in message news:<3D10C4D2.9ED98348@ceris.purdue.edu>...eG > Does anyone know how to remove a timeout restriction for a particulari' > user from being timed off the system?o >  > chucka    % Could you be a little more vague? ;-)s   ------------------------------  # Date: Thu, 20 Jun 2002 03:00:52 GMTy1 From: "David J. Dachtera" <djesys.nospam@fsi.net>   Subject: Re: timeout restriction& Message-ID: <3D114945.FEF4BA4@fsi.net>   "Alan E. Feldman" wrote: > e > Chuck Aaron <caaron@ceris.purdue.edu> wrote in message news:<3D10C4D2.9ED98348@ceris.purdue.edu>... I > > Does anyone know how to remove a timeout restriction for a particular2) > > user from being timed off the system?  > >m	 > > chuck  > ' > Could you be a little more vague? ;-)i  : Sure! How 'bout: "My system crashed. What went wrong?" :-)   -- r David J. Dachterav dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Wed, 19 Jun 2002 22:49:41 -0400   From: John Santos <JOHN@egh.com>F Subject: Re: Urgent help required( Link command getting struck in vax)4 Message-ID: <1020619224406.452A-100000@Ives.egh.com>  + On Mon, 17 Jun 2002, De vernufteling wrote:-   >  > All, > N > Sometimes I also have a link command which hangs. Strange enough when you doF > the same commands in a batch job the linker tells you whan is wrong. >  > Evert van Dijken.f > > > "Mahesh V S Jetti" <mvsjetti@hss.hns.com> schreef in bericht9 > news:adb15ffe.0206112042.66cd76a0@posting.google.com...  > > Hi,nH > >   My system is having different units. When i am trying to build one > > unit theF > >  link command is getting struck. Its giving no response. The exact > > command is > >  as follows. > >e1 > >  CM BUILD LINKFILE NOI NOIHAND NOIHAND.OPL ""hH > >  LINK/FULL/NOCROSS/TRACEBACK/MAP=NOI_LST:NOIHAND/EXE=NOI_EXE:NOIHAND, > > NOI$OBJ:NOIHAND, NOI$COM:NOIHAND.OPW/OPT > >o  G Are you sure one of these logical names (most likely noi$com:) doesn't n? point to sys$command: instead of a disk directory?  It could bei9 waiting for user input to type in the /options file, etc.v  F What happens if you type a ctrl/z or two?  (EOF on sys$command:, whichF will act like an empty options file, if the above conjecture is true.)  E This would account for the difference in behavior between interactiveh use and submitting a batch job.   I > >  This command is not giving any repsonse.It waits there indefintely.I  > > hadc* > >  to do ^c to come out of this command. > >hG > >  can u give me some pointers as to why linker waits indefinitely att
 > > the above 9 > >  command? or how to proceed in this kind of scenario? / > >              Any help is higly appreciated.  > >  Thanks in advance," > >  Maheshh   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 20 Jun 2002 03:20:15 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)F Subject: Re: Urgent help required( Link command getting struck in vax)) Message-ID: <aerhlf$9n$1@web1.cup.hp.com>o  ? "Mahesh V S Jetti" <mvsjetti@hss.hns.com> apparently wrote the ,D following in news:adb15ffe.0206112042.66cd76a0@posting.google.com...  D : My system is having different units. When i am trying to build oneG : unit the link command is getting struck. Its giving no response. The   : exact command is as follows. :e. : CM BUILD LINKFILE NOI NOIHAND NOIHAND.OPL ""E : LINK/FULL/NOCROSS/TRACEBACK/MAP=NOI_LST:NOIHAND/EXE=NOI_EXE:NOIHANDD* : NOI$OBJ:NOIHAND, NOI$COM:NOIHAND.OPW/OPT  C   This is NOT an OpenVMS linker command, there is other stuff here.g@   (There are also some odd file extensions used, but I digress.)  B   This could potentially be the classic stickiness problem -- the ?   looping linker behaviour.  When working with searchlists and oC   incomplete specifications, the linker can take a looonnnggg time  C   to complete; to finish the link or to find and return an error.  DF   These searchlists can involve the default directory, or any logical 6   names referenced by the particular linker operation.  G   Please visit <http://askq.compaq.com/>, and enter a search something a   like "Linker Looping?".S  F   On current OpenVMS versions, you can disable the filename stickinessE   within the linker options file.  Or you can provide complete (full)tE   file specifications in the linker command and in the options files.e%   Either will avoid the stickiness...m  D   If you want to watch the file accesses underneath the linker, the I   undocumented SET WATCH command -- see any of the undocumented features eJ   sites referenced in the OpenVMS FAQ -- can monitor XQP-level (low-level .   file system) activity underneath the linker.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 19 Jun 2002 22:01:46 +0100C/ From: "Adam Price" <adam+usenet@pappnase.co.uk>rY Subject: Re: VMS MARKETING VOLUNTEERS, LTD. Biz Card Example ( was Re: A Proposal for AllC5 Message-ID: <aeqrfg$97kh3$1@ID-138239.news.dfncis.de>p  S I think I read somewhere that Terry C. Shannon <terryshannon@attbi.com> wrote ... :s >i? > I have a hastily-shot 325KB JPEG of my original VMS MARKETINGeD > VOLUNTEERS, LTD. biz card that I'd be glad to send to anyone who'dG > like to take a look (a professional photographer I am not, but you'lluF > get the idea). VISTAPRINT.COM will print you up 250 of these puppies6 > for about ten-twelve bucks. Money well spent, sez I. > 9 > Drop me a line if you'd like me to mail you the JPEG...R@ Why not see if Ken Farmer will put a copy up on www.openvms.org?
 Adam Price   ------------------------------  # Date: Wed, 19 Jun 2002 23:48:07 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>rY Subject: Re: VMS MARKETING VOLUNTEERS, LTD. Biz Card Example ( was Re: A Proposal for All-* Message-ID: <XK8Q8.13047$EP.644@sccrnsc03>  : "Adam Price" <adam+usenet@pappnase.co.uk> wrote in message/ news:aeqrfg$97kh3$1@ID-138239.news.dfncis.de....I > I think I read somewhere that Terry C. Shannon <terryshannon@attbi.com>. wrote ... :e > >nA > > I have a hastily-shot 325KB JPEG of my original VMS MARKETINGnF > > VOLUNTEERS, LTD. biz card that I'd be glad to send to anyone who'dI > > like to take a look (a professional photographer I am not, but you'llrH > > get the idea). VISTAPRINT.COM will print you up 250 of these puppies8 > > for about ten-twelve bucks. Money well spent, sez I. > >C; > > Drop me a line if you'd like me to mail you the JPEG...rB > Why not see if Ken Farmer will put a copy up on www.openvms.org? > Adam Price  @ I could have him do that, but he's on vaction for the next week!   ------------------------------  % Date: Wed, 19 Jun 2002 22:41:49 -0400r1 From: Michael Austin <maustin@firstdbasource.com>nY Subject: Re: VMS MARKETING VOLUNTEERS, LTD. Biz Card Example ( was Re: A Proposal for Allt2 Message-ID: <3D1140ED.DF1BEA58@firstdbasource.com>   "Terry C. Shannon" wrote:- > < > "Adam Price" <adam+usenet@pappnase.co.uk> wrote in message1 > news:aeqrfg$97kh3$1@ID-138239.news.dfncis.de...eK > > I think I read somewhere that Terry C. Shannon <terryshannon@attbi.com> 
 > wrote ... :M > > >mC > > > I have a hastily-shot 325KB JPEG of my original VMS MARKETINGnH > > > VOLUNTEERS, LTD. biz card that I'd be glad to send to anyone who'dK > > > like to take a look (a professional photographer I am not, but you'll J > > > get the idea). VISTAPRINT.COM will print you up 250 of these puppies: > > > for about ten-twelve bucks. Money well spent, sez I. > > >v= > > > Drop me a line if you'd like me to mail you the JPEG...tD > > Why not see if Ken Farmer will put a copy up on www.openvms.org? > > Adam Price > B > I could have him do that, but he's on vaction for the next week!  H send it to me and I will put it on my site. I can always use the traffic :) e   -- e Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163c7 Sr. Consultant            http://www.firstdbasource.com E                           http://www.firstdbasource.com/donation.htmle/ 704-947-1089 (Office)     704-236-4377 (Mobile)!   ------------------------------  # Date: Thu, 20 Jun 2002 01:43:36 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>sE Subject: Re: Why porting apps to VMS isn't very helpful in most cases ' Message-ID: <3D113727.37B02A52@fsi.net>    r eclipse wrote: > L > Do you know of any group that may be willing to buy out VMS os from HP andQ > try to revive and grow it themseleves? HP says it will support VMS but my guessk, > is they may wanna dump it sooner or later.  E I seriously doubt that between all of us we could raise the $4billiontE (US) that some have estimated it would require. Personally, I've been.; looking in the Yellow Pages under both "angel" and "shark".h  E Too bad, though. Some bunch with a little business savvy and titanium @ gonads could probably make Bill Gates wish he'd bought it first.   --   David J. Dachtera! dba DJE Systemsw http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/f   ------------------------------  # Date: Thu, 20 Jun 2002 03:22:11 GMTi1 From: "Terry C. Shannon" <terryshannon@attbi.com>tE Subject: Re: Why porting apps to VMS isn't very helpful in most cases . Message-ID: <DTbQ8.262316$cQ3.11915@sccrnsc01>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3D113727.37B02A52@fsi.net...  > r eclipse wrote: > > J > > Do you know of any group that may be willing to buy out VMS os from HP andwJ > > try to revive and grow it themseleves? HP says it will support VMS but my guess. > > is they may wanna dump it sooner or later. >iG > I seriously doubt that between all of us we could raise the $4billion G > (US) that some have estimated it would require. Personally, I've beeni= > looking in the Yellow Pages under both "angel" and "shark".S  H Remember DEC sold Rdb to ORCL? The sale price was, I dunno, about $135M.( Less than one year of Rdb gross revenue.  ? VMS gross revenue actually amounts to no more than 10 times ther aforementioned $135M figute.  F Still, raising a billion and a quarter bucks is easier said than done!   ------------------------------  # Date: Thu, 20 Jun 2002 03:52:54 GMTo* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: Why porting apps to VMS isn't very helpful in most caseseA Message-ID: <qkcQ8.34414$8i1.2107707@bin2.nnrp.aus1.giganews.com>a  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:DTbQ8.262316$cQ3.11915@sccrnsc01...   ...q  A > VMS gross revenue actually amounts to no more than 10 times then > aforementioned $135M figute.  J It would be interesting to know exactly what is included in that estimate:L since it's only 1/3 of what VMS system revenue was stated as being two yearsJ ago, if it includes the same elements that is more than somewhat alarming.   - bill   ------------------------------   Date: 19 Jun 2002 18:51:55 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)e+ Subject: Re: [OT] Why Software is So Bad...W+ Message-ID: <aeqjsb$gnn$1@info.cs.uofs.edu>n  8 In article <3d10bb69.925162212@proxy.news.easynews.com>,3  prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:  |> w |> iA |> The engineering technology exists to produce reliable softwareeF |> systems.  But it's so expensive and tedious to apply that it's onlyB |> used on critical projects such as the control computers for the |> Space Shuttle.t   Your joking, right??  = Did you forget what one of the astronauts (John Glenn) had tol say about "the lowest bidder"??e   :-)e   bill   -- uJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Wed, 19 Jun 2002 19:21:44 GMT. From: system@SendSpamHere.ORGu+ Subject: Re: [OT] Why Software is So Bad...g0 Message-ID: <00A0FB2D.7BEA724A@SendSpamHere.ORG>  k In article <3d10bb69.925162212@proxy.news.easynews.com>, prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:a {...snip...} >vD >One of these days, the general public is going to be computer-savvyA >enough that we in the industry won't be able to get away with itPE >anymore.  Some day, some lawyer is going to file a class-action suit   E Lawyers are sleazy, immoral, cantankerous vermon but they are not, inoE general terms, intelligent enough to understand the software businessnD and the issues of shoddy software to bring such a suit to a meaning- ful conclusion.     F >that'll be heard by a comuter-savvy judge who will rule that whateverE >the license agreement might say, standard consumer product liabilitya? >law applies to computer software.  The result won't be pretty.   D Ne'er happen.  Judges tyically aren't bright enough to know the dif-D ference between a computer and a toaster over.  Most don't appear toB have the common sense to wear under-garments beneath their frocks.  D Stop watching Perry Mason reruns and Law and Order episodes.  Court-D rooms and the law are nothing like what you've seen on any TV shows.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMe            15   "Well my son, life is like a beanstalk, isn't it?" :   ------------------------------    Date: 19 Jun 2002 16:17:49 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)m+ Subject: Re: [OT] Why Software is So Bad...o3 Message-ID: <r3Qg6Z2c$0tj@eisner.encompasserve.org>a  _ In article <aeqjsb$gnn$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes: : > In article <3d10bb69.925162212@proxy.news.easynews.com>,5 >  prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:  > |> i > |>  C > |> The engineering technology exists to produce reliable software H > |> systems.  But it's so expensive and tedious to apply that it's onlyD > |> used on critical projects such as the control computers for the > |> Space Shuttle.- >  > Your joking, right??  4 http://www.fastcompany.com/online/06/writestuff.html   ------------------------------  # Date: Wed, 19 Jun 2002 21:59:17 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>4+ Subject: Re: [OT] Why Software is So Bad...a* Message-ID: <V87Q8.12439$EP.540@sccrnsc03>  = "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote in message 2 news:3d10bb69.925162212@proxy.news.easynews.com...6 > On Tue, 18 Jun 2002 20:13:16 GMT, "Terry C. Shannon"! > <terryshannon@attbi.com> wrote:n > I > >Software is bad because people will pay for the squatulent, bug-riddens	 > >dreck.o >  > Ain't it the truth.i >qF > For what other consumer good would people accept a license agreementC > that says "if it doesn't work as advertised and documented, we'resH > under no obligation to fix it, and if you or your business get damagedF > by it, we won't pay for your losses."  Contrast consumer response toD > Firestone's tire debacle with the response to Melissa, Nimbda, and > other such software glitches.s >hE > One of these days, the general public is going to be computer-savvyrB > enough that we in the industry won't be able to get away with itF > anymore.  Some day, some lawyer is going to file a class-action suitG > that'll be heard by a comuter-savvy judge who will rule that whateveroF > the license agreement might say, standard consumer product liability@ > law applies to computer software.  The result won't be pretty. >a >>@ > The engineering technology exists to produce reliable softwareE > systems.  But it's so expensive and tedious to apply that it's only-A > used on critical projects such as the control computers for theh > Space Shuttle. > F > As long as the marketplace is willing to tolerate buggy systems thatC > crash, malfunction, and have security holes you can drive a truck(0 > through, the situation isn't going to improve.  B I am not optimistic. Look at all the crap the public sucks up from$ politicians and Armani Analysts. ;-}   ------------------------------   End of INFO-VAX 2002.339 ************************