1 INFO-VAX	Wed, 12 Jul 2006	Volume 2006 : Issue 385       Contents: Re: 64K limit for socket send  Re: 64K limit for socket send  Re: 64K limit for socket send  Re: 64K limit for socket send  Re: 64K limit for socket send  Re: 64K limit for socket send  Re: 64K limit for socket send  Re: 64K limit for socket send  RE: Alpha remembrance day  RE: Alpha remembrance day  RE: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day & Re: An entirely Digital OSF/1 question@ Re: Any Way to Validate Username & Password from an Application? File Conversion Problem  Re: File Conversion Problem  Re: Floating point questions Re: Floating point questionsC How to create a new user account: Request Example Of How To Do This P Re: How to create a new user account: Request Example Of How To Do This ThisThis9 Is There A VMS User Manual Online With Information On CMS = Re: Is There A VMS User Manual Online With Information On CMS = Re: Is There A VMS User Manual Online With Information On CMS = Re: Is There A VMS User Manual Online With Information On CMS + Re: Making LIB$*_VM_PAGE Caller's-mode safe  OpenVMS V8.3 is in sight Re: OpenVMS V8.3 is in sight Re: OpenVMS V8.3 is in sight Re: OpenVMS V8.3 is in sight' Re: OT: Intel quad core X64 benchmarked  Re: scsi to ide brdige on a VAX & Re: The possibility of vms opening up?& Re: The possibility of vms opening up?& Re: The possibility of vms opening up?& Re: The possibility of vms opening up? There is a good photo website  VAX 66x0 & CHARON VAX  Re: VAX 66x0 & CHARON VAX   Where Are The System Directories$ Re: Where Are The System Directories  F ----------------------------------------------------------------------  % Date: Wed, 12 Jul 2006 11:14:35 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de>& Subject: Re: 64K limit for socket send/ Message-ID: <e92eh3$80q$02$1@news.t-online.com>    Keith A. Lewis schrieb: N > I'm running up against an apparant 64K limit for socket writes.  What I want > to do is increase the limit. > 
 > I tried: > 6 > $ TCPIP SET PROTO TCP/QUOTA=(SEND:130000,REC:130000) >  > and also:  > B > setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &bufsize, sizeof(int))); > (with privileges turned on)  > L > But I still get "%system-f-ivbuflen, invalid buffer length" from writev(). > F > What do I need to do to increase the buffer size so I can send large > messages?  >  > I'm running this: 5 >   HP TCP/IP Services for OpenVMS Alpha Version V5.4 @ >   on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V7.3-1 >   E Funny, this is probably the same flaw I mentioned in the "straw poll" * post when asked about reasons to drop VMS.8 Walking through my source archives I found the CMS entry  H 17-AUG-1992 11:14:15 KRAEMER "special rcv for VAX to overcome 64k limit"  < which suggests that it hasn't been fixed in nearly 15 years. Back then I used something like    #if defined(VAX)           while( nBytes > 0 ) { C              nChunk = nBytes; if ( nChunk > 32768 ) nChunk = 32768; H              if ( ( iRC = recv( *iSocket, pBytes, nChunk, 0 ) ) <= 0 ) {                 ...               }*              nBytes -= iRC; pBytes += iRC;           }  #else  /* all other platforms OK */           while( nBytes > 0 ) { H              if ( ( iRC = recv( *iSocket, pBytes, nBytes, 0 ) ) <= 0 ) {                 ...               }*              nBytes -= iRC; pBytes += iRC;           }  #endif   as a workaround.   ------------------------------    Date: 12 Jul 2006 06:55:49 -0500 From: briggs@encompasserve.org& Subject: Re: 64K limit for socket send3 Message-ID: <A0slHopR$LMl@eisner.encompasserve.org>   _ In article <e915lj$4r7$1@newslocal.mitre.org>, klewis@LUMINA.MITRE.ORG (Keith A. Lewis) writes: } > Rick Jones <rick.jones2@hp.com> writes in article <bhUsg.349$co6.104@news.cpqcorp.net> dated Tue, 11 Jul 2006 20:57:43 GMT: H >>When one does split the > 64KB of data to send into multiple sends, itF >>would probably be best to split it such that none of the sends - theE >>last send in particular - are less than the MSS for the connection.  > L > That sounds reasonable, but it leads to another question -- how can I find > the MSS for my socket?  A You don't have to.  If you're chunking up your data to fit within A some buffer size limit (e.g. 64K) then simply work your algorithm A so that you send a small chunk first and a full sized chunk last.   : i.e. If you have 80K to send, send 16K first and then 64K.   ------------------------------    Date: 12 Jul 2006 07:39:09 -0500 From: briggs@encompasserve.org& Subject: Re: 64K limit for socket send3 Message-ID: <2TuJjphA3PCJ@eisner.encompasserve.org>   \ In article <44B46D3C.8F59FAC0@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Rick Jones wrote: I >> 1) Is this user's _send_, plus any queued, unsent data > MSS?  If yes, 3 >>    send immeidately, otherwise go to question 2.  > H > If I have a 1500 MTU (server side) and some remote dialup user has 150H > MTU,  isn't it better for the server to send 1500 size packets and letI > the last router befofe the dialup link split the packets versus sending  > 150 packets from the server ?  > G > (Or does the TCP stack limit those packets to 150 right at the server 	 > side ?)   D What's better?  I'm not sure I'm competent to comment.  In the usualE case, it won't matter enough to be worth arguing about.  Depending on C IP fragmentation rather than TCP segmentation would certainly limit C the usefulness of selective ACKs, so I'd suspect that fragmentation + at the last-hop router would be a bad idea.     A What actually happens?  You didn't ask that, but I can offer some  information.  D Yes, if the sending stack knows that the connection MSS is 110 bytesA (IP/TCP header overhead is 40 bytes, btw) then the TCP layer will H be sending 110 byte segments inside 150 byte packets.  All the splitting< of the data into tiny packets will take place at the server.    D If PMTU discovery is enabled (as it almost always is) and the serverB does not already know the MSS available on the connection, it willA send out a packet that is too big.  Typically this will be a 1500 E byte IP packet carrying a 1460 byte TCP segment.  With PMTU discovery B enabled, this packet will have the DF (don't fragment) bit set andB the last-hop router will be forbidden to fragment it.  Instead, itF will send an ICMP datagram (fragmentation required and DF set) back toA the server.  The PMTU discovery algorithm calls for the server to @ update its connection MTU information with information from that	 datagram.   G Now the server knows the connection MSS and again, all splitting of the 5 data into tiny packets will take place at the server.     ? If PMTU discovery is not enabled, the server will send out that D large 1500 byte packet but without the DF bit set.  Now the last-hopD router is free to fragment that 1500 byte packet into some number of@ 150 byte IP fragments.  (Though I seem to remember a granularityC restriction on the fragment size.  They might be 144 or 148 bytes). E The client will then reassemble those fragments into an IP packet and ? extract the 1460 byte TCP segment from that reassembled packet.   J > (sorry for using MTU here, i forget the actual number of byte difference > between MTU and MSS)   As above, 40 bytes.    ------------------------------  % Date: Wed, 12 Jul 2006 10:56:42 -0400 ' From: Dave Froble <davef@tsoft-inc.com> & Subject: Re: 64K limit for socket send9 Message-ID: <0IGdnaW3TunzkSjZnZ2dnUVZ_rWdnZ2d@libcom.com>    briggs@encompasserve.org wrote: a > In article <e915lj$4r7$1@newslocal.mitre.org>, klewis@LUMINA.MITRE.ORG (Keith A. Lewis) writes: ~ >> Rick Jones <rick.jones2@hp.com> writes in article <bhUsg.349$co6.104@news.cpqcorp.net> dated Tue, 11 Jul 2006 20:57:43 GMT:J >>> When one does split the > 64KB of data to send into multiple sends, itH >>> would probably be best to split it such that none of the sends - theG >>> last send in particular - are less than the MSS for the connection. M >> That sounds reasonable, but it leads to another question -- how can I find  >> the MSS for my socket?  > C > You don't have to.  If you're chunking up your data to fit within C > some buffer size limit (e.g. 64K) then simply work your algorithm C > so that you send a small chunk first and a full sized chunk last.  > < > i.e. If you have 80K to send, send 16K first and then 64K.  E I've never heard of doing this before this thread.  Why would one do  H this instead of just sending chunks of the message until it's all sent, 1 with the last chunk being whatever size required?    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  # Date: Wed, 12 Jul 2006 15:09:44 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>& Subject: Re: 64K limit for socket send0 Message-ID: <Yg8tg.391$eB6.302@news.cpqcorp.net>   Dave Froble wrote:! > briggs@encompasserve.org wrote:   = >> i.e. If you have 80K to send, send 16K first and then 64K.  > G > I've never heard of doing this before this thread.  Why would one do  J > this instead of just sending chunks of the message until it's all sent, 3 > with the last chunk being whatever size required?   F    There are no "messages" with TCP, the receiver can get one or more G bytes, up to the number of bytes requested -- TCP is a stream of data,  @ and not a datagram service.  The application is responsible for > buffering the incoming data up to the required length, if the 9 application is looking to pass datagrams over a TCP link.   F    You can encounter something akin to the following message arrival, 
 for instance:   ,    [TC][P i][s a stre][am][ ][proto][col][.]  G    This is probably bizarre to most folks (and I've seen gazillions of  E applications that don't realize this, and can derail when they don't  E check the length of the arriving data and end up with part of an old  = message, for instance), but it's how TCP is supposed to work.    ------------------------------  % Date: Wed, 12 Jul 2006 16:06:16 +0100 * From: "Richard Brodie" <R.Brodie@rl.ac.uk>& Subject: Re: 64K limit for socket send2 Message-ID: <e93358$fmi$1@blackmamba.itd.rl.ac.uk>  5 "Dave Froble" <davef@tsoft-inc.com> wrote in message  3 news:0IGdnaW3TunzkSjZnZ2dnUVZ_rWdnZ2d@libcom.com...   = >> i.e. If you have 80K to send, send 16K first and then 64K.  > W > I've never heard of doing this before this thread.  Why would one do this instead of  T > just sending chunks of the message until it's all sent, with the last chunk being  > whatever size required?   I If you dribble data at a TCP socket, it will usually try to coalesce your A sends to reduce overhead. Standard sockets don't have an easy way E to flush the data out, although no doubt some folks have experimented D with such. See also: http://en.wikipedia.org/wiki/Nagle's_algorithm    ------------------------------  + Date: Wed, 12 Jul 2006 16:36:50 +0000 (UTC) . From: klewis@LUMINA.MITRE.ORG (Keith A. Lewis)& Subject: Re: 64K limit for socket send. Message-ID: <e938f2$bq3$1@newslocal.mitre.org>  z Rick Jones <rick.jones2@hp.com> writes in article <0VVsg.361$co6.60@news.cpqcorp.net> dated Tue, 11 Jul 2006 22:48:28 GMT:0 >Keith A. Lewis <klewis@lumina.mitre.org> wrote:M >> That sounds reasonable, but it leads to another question -- how can I find  >> the MSS for my socket?  > A >I don't know if OpenVMS supports it, but elsewhere, you can do a F >getsockopt() against TCP_MAXSEG - after the connection is established* >- to retrieve the MSS for the connection.  F HP's Sockets API doc lists it as a settable socket option, at least.    G >1) Is this user's _send_, plus any queued, unsent data > MSS?  If yes, 1 >   send immeidately, otherwise go to question 2.  > G >2) Is the connection otherwise idle (ie no outstanding, unACKed data)? 6 >   If yes, send immediately, otherwise, go to step 3.  : Presumably on the tail of a multi-send, we'd end up at 3a.  G >3) Queue the data and wait.  One of at least three things will happen:  > B >   a) The remote will ACK the unacked data, making the connection> >      "idle" and allowing the send of this sub-MSS remainder.  F >That ACK in 3.a will arrive within the remote's standalone ACK timer,G >which is typically somewhere between 50 and 200 milliseconds depending  >on the stack.  J And the latency of the connection, which I haven't stated but for the timeJ being this data is going over a pretty nice LAN -- fastFD switched subnets connected by fiber.   0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Wed, 12 Jul 2006 16:59:30 GMT % From: Rick Jones <rick.jones2@hp.com> & Subject: Re: 64K limit for socket send/ Message-ID: <ST9tg.393$kP6.40@news.cpqcorp.net>   . JF Mezei <jfmezei.spamnot@teksavvy.com> wrote: > Rick Jones wrote: I >> 1) Is this user's _send_, plus any queued, unsent data > MSS?  If yes, 3 >>    send immeidately, otherwise go to question 2.   D > If I have a 1500 MTU (server side) and some remote dialup user hasC > 150 MTU, isn't it better for the server to send 1500 size packets B > and let the last router befofe the dialup link split the packets. > versus sending 150 packets from the server ?  @ > (Or does the TCP stack limit those packets to 150 right at the > server side ?)  F The TCP stact at the dial-up user will have exchanged an MSS option ofF 150-40 or 110 in the SYNchronize segment and that will be used for the connection in each direction.   D At the risk of repeating what others will say, one wants to avoid IPB fragmentation when possible.  All fragments of an IP datagram mustE arrive at the receiver for the datagram to be reassembled.  If any of ; the fragments are lost, the entire datagram is toast.  This C "amplifies" the packet loss rate into a rather higher datagram loss F rate, and the entire datagram must be retransmitted by something above IP.   ? > (sorry for using MTU here, i forget the actual number of byte ! > difference between MTU and MSS)   F _Typically_ it will be the MTU less 20 bytes of IP header and 20 bytes? of TCP header.  For IPv6 that IP header is larger, and when TCP F Timestamps are enabled on a connection, the TCP header is typically 32 bytes.   --  B No need to believe in either side, or any side. There is no cause.E There's only yourself. The belief is in your own precision.  - Jobert F these opinions are mine, all mine; HP might not want them anyway... :)D feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   ------------------------------  % Date: Wed, 12 Jul 2006 07:55:58 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> " Subject: RE: Alpha remembrance dayT Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401722B24@tayexc19.americas.cpqcorp.net>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20  > Sent: July 11, 2006 11:39 PM > To: Info-VAX@Mvb.Saic.Com $ > Subject: Re: Alpha remembrance day >=20 > "Main, Kerry" wrote:; > > Perhaps someone could quote what the actual emulator=20  > product list priceD > > is for a VAX 6600 quad CPU system running on a X86 of some type? >=20A > Often, when prices are not published, it is because they are=20  > adapted to< > each customer's needs. Consider budgets which may allow=20 > certain types ofF > expenditures but not others (think capital cost vs leasing costs,=20 > service vs purchase etc.). >=20= > I have no idea if that is the case with the specific VAX=20  > emulators. AndD > the price structure may also vary from country to country and fromF > distributor to distributor. So it makes it hard to publish anything. >=20  F Distributors typically have a base dealer price that they have to dealA with. How much margin they add is dependent on the scenario's you 
 mentioned.  < Point is that these can be 5-6 figure license costs + annualH re-occurring support costs depending on the VAX model being emulated, soE Customers need to understand this before automatically jumping to any H conclusion that moving to emulation on a x86 might be cheaper than otherG alternatives. It may be cheaper, but they need to thoroughly review all ( options with associated pro's and con's.   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Wed, 12 Jul 2006 08:22:23 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>" Subject: RE: Alpha remembrance day: Message-ID: <44B4B13F.6868.9A18353@squayle.insight.rr.com>  * On 12 Jul 2006 at 7:55, Main, Kerry wrote:G > Customers need to understand this before automatically jumping to any D > conclusion that moving to emulation on a x86 might be cheaper thanD > other alternatives. It may be cheaper, but they need to thoroughly6 > review all options with associated pro's and con's.   D Another place where a value-added reseller adds value.  I've turned B down business because the benefits don't match the expenses.  But ! this is true about all decisions.   D The only thing that makes me sad is that most of these cases result ( in a move away from VMS, not to Itanium.   
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA < stan-at-stanq-dot-com   http://www.stanq.com/charon-vax.html) "OpenVMS, when downtime is not an option"    ------------------------------  % Date: Wed, 12 Jul 2006 09:18:40 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> " Subject: RE: Alpha remembrance dayT Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401722B82@tayexc19.americas.cpqcorp.net>   > -----Original Message-----< > From: Stanley F. Quayle [mailto:squayle@insight.rr.com]=20 > Sent: July 12, 2006 8:22 AM  > To: Info-VAX@Mvb.Saic.Com $ > Subject: RE: Alpha remembrance day >=20, > On 12 Jul 2006 at 7:55, Main, Kerry wrote:= > > Customers need to understand this before automatically=20  > jumping to anyF > > conclusion that moving to emulation on a x86 might be cheaper thanF > > other alternatives. It may be cheaper, but they need to thoroughly: > > review all options with associated pro's and con's.=20 >=20H > Another place where a value-added reseller adds value.  I've turned=20F > down business because the benefits don't match the expenses.  But=20# > this is true about all decisions.  >=20H > The only thing that makes me sad is that most of these cases result=20* > in a move away from VMS, not to Itanium. > =20  > --Stan Quayle  > Quayle Consulting Inc. >=20  E In a few cases I was involved with, the large emulator licensing (5-6 G figures) and annual support costs made the Customer decide to stay with D OpenVMS (migration to another platform is an exponential increase inH cost and effort compared to simply changing the HW only) but not use the@ emulator option (which technically would have been much easier).   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------    Date: 12 Jul 2006 08:05:40 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) " Subject: Re: Alpha remembrance day3 Message-ID: <jBfLv+dla5bN@eisner.encompasserve.org>   o In article <44B3AC11.3108.5A547E1@squayle.insight.rr.com>, "Stanley F. Quayle" <squayle@insight.rr.com> writes: 1 > On 11 Jul 2006 at 16:34, Bill Gunshannon wrote: J >> I would love to see one example of commercial software whose commercialJ >> life extended beyond the life of the hardware it was designed to run on >> by using an emulator..  > B > Doing it every day with CHARON-VAX [Shameless Plug Alert(tm)].  E > Ancient database software, ancient applications (MASS-11, for one).  > H >> Do you honestly think that once Itanium gets relegated to the crapperL >> that HP is going to continue to develop/support VMS for use on emulators? > H > No, but the software support path for Alpha is set through 2011 now.  / > And there's a CHARON product line for that...   E    I think the OP's issue would be addressed if you had HP commiting  E    continued support for OpenVMS VAX or OpenVMS Alpha just because of @    CHARON customers.  I haven't heard that from HP; they've beenI    promising support for those products based on VAX and Alpha customers.   B    I suspect HP's continued support for that software beyond theirH    current promises depends on how many customers will pay support fees,4    not which hardware is really behind the instance.   ------------------------------    Date: 12 Jul 2006 08:08:10 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) " Subject: Re: Alpha remembrance day3 Message-ID: <s6jSdr9KbvmP@eisner.encompasserve.org>   \ In article <44B467FD.40BC43E7@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Bill Gunshannon wrote:H >> Do you honestly think that once Itanium gets relegated to the crapperL >> that HP is going to continue to develop/support VMS for use on emulators? > B > HP has already stopped development of VMS for emulators, despite8 > promises for and 8.* release for the VAX architecture.  C    HP is continuing to provide development for OpenVMS Alpha, which     runs on Charon-Alpha.  A    What HP is not doing is living up to earlier plans to continue ,    OpenVMS VAX development, on any platform.   ------------------------------    Date: 12 Jul 2006 06:12:30 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayA Message-ID: <1152709950.323934.41500@35g2000cwc.googlegroups.com>    Dave Weatherall wrote:E > On Mon, 10 Jul 2006 17:14:09 UTC, David Mathog <mathog@caltech.edu>  > wrote: >  > > Andrew wrote:  > > M > > > Trying to re-write history by claiming that Alpha did not suffer from a N > > > shortage of applications is rubbish, it was in fact a key contributor inM > > > the decline even if the blame for the lack of software could be laid at % > > > Digital and then Compaqs doors.  > > L > > Andrew is right on this one, the lack of native software was the primaryJ > > reason we eventually abandoned VMS.  This was true even though most ofK > > the software we used came as source - it just didn't make sense to have L > > to port every program we needed from Unix -> VMS.  OS and hardware costsI > > were also factors, and I'd argue that these continued high costs were L > > mostly to blame for the lack of software.  It was a vicious circle: highD > > OS and hardware cost -> small market -> repeat.  Not exactly the; > > ecosystem that software developers wanted to invest in.  > G > The only trouble with the theory, and it may well be correct, is that C > the same situation, a dearth of applications, was always going to  > apply to Itaniuim too.  G In hindsite yes, but when Intel/HP and their other partners embarked on > the Itanium project they clearly felt that having an "IndustryD Standard" platform would guarantee that ISV's flocked to their door.G The reality however has been that most of the ISV's have adopted a wait A an see strategy for Itanium pors which has hindered its adoption.    Regards  Andrew Harrison    ------------------------------    Date: 12 Jul 2006 06:17:12 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayA Message-ID: <1152710232.566166.71820@35g2000cwc.googlegroups.com>    David Mathog wrote:  > etmsreec@yahoo.co.uk wrote:  > >  > > Bill Gunshannon wrote:D > >> In article <DTiotGxQ0bj6-pn2-W7L6joy8WjGC@dave2_os2.home.ours>,: > >> 	"Dave Weatherall" <djw-nothere@nospam.nohow> writes:K > >>> The only trouble with the theory, and it may well be correct, is that G > >>> the same situation, a dearth of applications, was always going to  > >>> apply to Itaniuim too.H > >> But that is pretty much what people have been saying all along.  IfI > >> the same logic that killed Alpha were applied to the Itanium, it too H > >> would be dead meat.  So, how comfortable does that make people feel" > >> betting their business on it? > >>5 > > Not very, but it's the only game in town I guess?  > @ > It's also possible to run VMS on the emulator on x86 hardware.  F It is but this does not solve the ISV support issue because most majorF ISV's will not support VMS running on an emulator on x86,any more thanF they would support FX!32 when it attempted to solve a similar problem.  B Taking that approach would relegate OpenVMS to the museum exhibit,' hobby, home and to the truly despirate.    regards  Andrew Harrison    ------------------------------    Date: 12 Jul 2006 06:41:18 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1152711678.824209.142300@h48g2000cwc.googlegroups.com>    Bill Todd wrote: > etmsreec@yahoo.co.uk wrote: H > > Likewise Bill, the fact that you've been around for a while gives no > > excuse for your rudeness.  > H > Correct:  it's persistent incompetence by those who should know better > that justifies the rudeness. > ' > >  you have one view, I have another.  > H > Some people believe men never landed on the moon, too.  I accord theirH > 'view' a similar level of respect:  not all 'views' are created equal,I > though people with a sufficiently fuzzy understanding of both logic and 2 > democracy often seem to get confused about that. >   F Oddly the general concensus on this thread is that your views at leastG about the contribution that Alphas small software portfolio made to the B demise of Alpha fall into the "moon landing actually happened in a- large hanger in the Arizona desert" category.    Regards  Andrew     > - bill   ------------------------------    Date: 12 Jul 2006 07:55:51 -0700$ From: "Ed Wilts" <ewilts@ewilts.org>" Subject: Re: Alpha remembrance dayC Message-ID: <1152716151.893722.152140@p79g2000cwp.googlegroups.com>    david20@alpha2.mdx.ac.uk wrote:   N > At the time of the Compaq purchase of Digital, Alpha supported a respectable  > number of Operating Systems :- > 	 > Windows   > Linux (multiple distributions) > NetBSD	 > OpenBSD 	 > FreeBSD  > VMS  > and  > TRU64  > N > (I even saw Linux on Alpha distributions for sale in a number of high streetE > shops - which was pretty unusual for most non-intel distributions).   B At Decus Cincinnati 1992, I saw a Galaxy system with VMS and Linux- running at the same time.  Now that was cool!   	    .../Ed    ------------------------------  % Date: Wed, 12 Jul 2006 11:02:10 -0400 ' From: Dave Froble <davef@tsoft-inc.com> " Subject: Re: Alpha remembrance day9 Message-ID: <RYadnUwqJfwqkCjZnZ2dnUVZ_qmdnZ2d@libcom.com>    Bob Koehler wrote:^ > In article <44B467FD.40BC43E7@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >> Bill Gunshannon wrote: I >>> Do you honestly think that once Itanium gets relegated to the crapper M >>> that HP is going to continue to develop/support VMS for use on emulators? C >> HP has already stopped development of VMS for emulators, despite 9 >> promises for and 8.* release for the VAX architecture.  > E >    HP is continuing to provide development for OpenVMS Alpha, which  >    runs on Charon-Alpha. > C >    What HP is not doing is living up to earlier plans to continue . >    OpenVMS VAX development, on any platform. >   F It's that decision that leads one to wonder how long after the end of 1 Alpha sales that Alpha development will continue.   I Ok, the above isn't quite fair.  The two major reasons for not including  @ new features in VAX/VMS are the non-common code base and 64 bit B capability.  The non-common code base means that some part of the C development is separate work, and separate testing.  As for 64 bit  H requirements, VAX just doesn't qualify.  Can't be done, at least easily.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 12 Jul 2006 08:12:28 -0700 From: etmsreec@yahoo.co.uk" Subject: Re: Alpha remembrance dayC Message-ID: <1152717148.508520.112820@m79g2000cwm.googlegroups.com>   E >From what I've heard, there's nothing saying "we'll never do VMS 8.x B for VAX".  It's more a case of there isn't the call for it becauseF those sites that still have VAX hardware are just fine and dandy whereD they are and don't want to upgrade, not even to VMS VAX v7.3.  (ThisA was from a senior member of the support staff for VMS in the UK).   G The cost justifications for releasing 8.x on VAX are such that it isn't C commercially viable.  If you've got deep pockets, I'm sure HP would F consider it and, if they're deep enough, oblige.  They've probably got to be pretty deep though!    Steve    Dave Froble wrote: > Bob Koehler wrote:` > > In article <44B467FD.40BC43E7@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > >> Bill Gunshannon wrote: K > >>> Do you honestly think that once Itanium gets relegated to the crapper O > >>> that HP is going to continue to develop/support VMS for use on emulators? E > >> HP has already stopped development of VMS for emulators, despite ; > >> promises for and 8.* release for the VAX architecture.  > > G > >    HP is continuing to provide development for OpenVMS Alpha, which  > >    runs on Charon-Alpha. > > E > >    What HP is not doing is living up to earlier plans to continue 0 > >    OpenVMS VAX development, on any platform. > >  > G > It's that decision that leads one to wonder how long after the end of 3 > Alpha sales that Alpha development will continue.  > J > Ok, the above isn't quite fair.  The two major reasons for not includingA > new features in VAX/VMS are the non-common code base and 64 bit C > capability.  The non-common code base means that some part of the D > development is separate work, and separate testing.  As for 64 bitJ > requirements, VAX just doesn't qualify.  Can't be done, at least easily. >  > --6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486    ------------------------------  + Date: Wed, 12 Jul 2006 15:12:53 +0000 (UTC) ( From: m.kraemer@gsi.de (Michael Kraemer)" Subject: Re: Alpha remembrance day5 Message-ID: <e933hl$64t$1@lnx107.hrz.tu-darmstadt.de>   N In article <1152716151.893722.152140@p79g2000cwp.googlegroups.com>, "Ed Wilts" <ewilts@ewilts.org> writes: D > At Decus Cincinnati 1992, I saw a Galaxy system with VMS and Linux/ > running at the same time.  Now that was cool!    huh ? galaxy in 1992 ?8 And Linux ? Was barely usable on intel, let alone alpha.   ------------------------------  % Date: Wed, 12 Jul 2006 08:56:43 -0700 ' From: David Mathog <mathog@caltech.edu> " Subject: Re: Alpha remembrance day+ Message-ID: <e9363r$sca$1@naig.caltech.edu>    Main, Kerry wrote: >> -----Original Message----- 2 >> From: David Mathog [mailto:mathog@caltech.edu] @ >> Conversely there is a compelling reason to move off of prettyE >> much all of the HP OS's since they are all slowly sinking into the D >> sunset while tied to the Itanic.  Migrating to commodity hardware1 >> and software offers a better, cheaper future.   > I > The HW platform is one of the smallest parts of an IT budget. IT staff, B > training, business logic compatibility, new functionality QA andH > regulatory testing, application licenses and support, DC costs etc areI > the biggies. Changing the underlying HW is one thing, but also changing 0 > the OS as well is a 800lb gorilla to address.   E You're overstating the difficulty of migration to another OS/platform H versus the problems of not being able to obtain software for the current platform at all.   > A > And by commodity hardware and software, do you mean adopting OS < > platforms that *average* 7-20 security patches per month?   D Presumably you mean windows? Actually I was thinking more along the G lines of the x86 variants of Solaris or Linux.  These too have security D patches of course, whether or not they actually need to be installedE depends a lot on what the server in question is being used for.  That A is, a hole in libjpeg is not a serious security hole if there are F no interactive users.  My experience with these two OS's has been thatG I can generally install all security changes (via RPM) on Linux without H requiring a reboot.  The cumulative patches for Solaris often do require	 a reboot.   E However the argument is irrelevant since the OS which doesn't require B these patches (VMS) typically no longer has the required software E available and so is not an option in any case.  Or to put it another  I way, a steel strongbox will keep your secrets safe but you can't run SAP   on it.     > How would you F > price the cost associated with QA ing and testing all these securityC > patches each month with all of the Customer apps running on these  > platforms?    F Insignificant compared to not being able to run the apps at all.  You D are of course talking about customer developed apps and I am talking! about commercially supplied ones.   I > Most Customers are concerned about their apps and as long as there is a I > support plan in place for them, the HW costs are usually a much smaller  > consideration.  H By "most" you mean "customers with very special needs and deep pockets" D whereas by "most" I mean "customers who use off the shelf software".   > E > Case in point - why are Solaris Customers not migrating en masse to  > Solaris on x86?   D There is no compelling reason to do so since the software they need F exists on Sparc/Solaris and so the migration cost isn't justified.  InH that instance all they would be doing would be changing hardware withoutC any significant change in any other costs.  That isn't the case for C getting the heck off of the Itanic, where software availability is   extremely limited.  ? (FYI we recently looked into migrating one Oracle Sparc/Solaris C server to Oracle Opteron/Linux when the application that ran on top > of Oracle finally was supported on Linux.  The deciding factor@ against the move was that the trade in value on the Sparc serverD wasn't enough to buy a comparable Linux system.  Had we been settingG up the system now, with $$$ to buy new hardware, it would have been on  E Linux.  Of course this is for Biology research and not banking, so we A don't have either the security or up time requirements you assume / are typical.  Definitely not the deep pockets.)    Regards,   David Mathog   ------------------------------  % Date: Wed, 12 Jul 2006 22:37:38 +1200 1 From: Tux Wonder-Dog <wes.parish@paradise.net.nz> / Subject: Re: An entirely Digital OSF/1 question # Message-ID: <44b4d18c@clear.net.nz>    Michael Kraemer wrote:  4 > In article <44b391f9@clear.net.nz>, Tux Wonder-Dog& > <wes.parish@paradise.net.nz> writes:@ >> Well, if it helps anyone ... I'd be glad to be of service! ;) >>  9 > well, there are bigger enthusiasts on this one than me,  > you might check out: > ! > http://www.xanthos.se/~joachim/ K Thanks.  I agree with his assessment that it's "almost archaelogical" - the K problem we found with Linux and the *BSD is that people don't keep track of > what was once common knowledge, and then someone tries to takeB advantage ... a la the BSD lawsuit and the current 'The SCO Group'
 kerfuffle.  F Far better to keep track of it and keep at least some of the knowledge current.  
 Wesley Parish  --  O "Good, late in to more rewarding well."  "Well, you tonight.  And I was U lookintelligent woman of Ming home.  I trust you with a tender silence."  I C get a word into my hands, a different and unbelike, probably - 'she D fortunate fat woman', wrong word.  I think to me, I justupid.G Let not emacs meta-X dissociate-press write your romantic dialogs...!!!    ------------------------------  % Date: Wed, 12 Jul 2006 06:10:18 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> I Subject: Re: Any Way to Validate Username & Password from an Application? : Message-ID: <44b4c9db$0$989$9a6e19ea@news.newshosting.com>  - <VAXman- @SendSpamHere.ORG> wrote in message  * news:00A58857.58525BD0@SendSpamHere.ORG...L > In article <1152623876.244916.275180@35g2000cwc.googlegroups.com>, "Craig % > Dedo" <Dedo.Craig@mayo.edu> writes:  [...snip...] > B > SYS$GETUAI (SALT and Algorithm and encrypted password value) andC > SYS$HASH_PASSWORD toe generate the encrypted password value using B > the SALT and algorithm with the password text you query for when > wanting to validate the user.  > E Here is some demo software (written in OpenVMS BASIC) showing how to  J interface with SYS$HASH_PASSWORD and SYS$GETUAI etc. Any programmer worth J his SALT (pun intended) should be able to easily convert these demos into  any other programming language.   C http://www3.sympatico.ca/n.rieck/demo_vms/basic-password-search.zip A http://www3.sympatico.ca/n.rieck/demo_vms/basic-web-pw-change.zip   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html9 http://www3.sympatico.ca/n.rieck/links/openvms_demos.html    ------------------------------    Date: 12 Jul 2006 09:40:13 -0700A From: "Tim ffrench-Lynch" <tim.newsgroups.account@googlemail.com>   Subject: File Conversion ProblemC Message-ID: <1152722413.364010.157440@h48g2000cwc.googlegroups.com>   A A colleague has a file that is supposed to be an ordinary fortran C source code file as produced by edit/edt with variable line length. D However at some point in the past the file has been put through someD sort of archiving process that has brought it back as 512 byte fixedA length records with CR LF characters within the 512 byte records.   E Using Convert/FDL I can convert the file to variable length with line > breaks in place of each CR LF, but the line breaks at 512 byte7 intervals are preserved leading to odd breaks in lines.    Any ideas how to fix the file?   Tim    ------------------------------  + Date: Wed, 12 Jul 2006 12:14:48 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)$ Subject: Re: File Conversion Problem2 Message-ID: <06071212144873_20200291@antinode.org>  A From: "Tim ffrench-Lynch" <tim.newsgroups.account@googlemail.com>   C > A colleague has a file that is supposed to be an ordinary fortran E > source code file as produced by edit/edt with variable line length. F > However at some point in the past the file has been put through someF > sort of archiving process that has brought it back as 512 byte fixedC > length records with CR LF characters within the 512 byte records.  > G > Using Convert/FDL I can convert the file to variable length with line @ > breaks in place of each CR LF, but the line breaks at 512 byte9 > intervals are preserved leading to odd breaks in lines.   C    CR-LF?  I'd (copy the file, and on the copy) try something like:   4       SET FILE /ATTRIBUTES = RFM:STM  file_to_change  . Then, if I wanted a more common record format:  =       CONVERT file_to_change file_to_change /FDL = SYS$INPUT:        RECORD               FORMAT stream_lf       <CTRL/Z>  $ or some other format of your choice.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------    Date: 12 Jul 2006 07:13:07 -0500 From: briggs@encompasserve.org% Subject: Re: Floating point questions 3 Message-ID: <wqfNPjGjOjDv@eisner.encompasserve.org>   O In article <op.tcj06rfxzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes: G > On Tue, 11 Jul 2006 12:03:22 -0700, <briggs@encompasserve.org> wrote: 8 >> 	05 YTD-PAY PICTURE S9(9)V99 USAGE IS PACKED-DECIMAL. >>H >> where the compiler automatically keeps track of the scaling factor of >> 100 for you.  > / [quoted-printable damage (line wraps) repaired] E > In PL/I Picture data types are not packed decimal but are stored as  > character strings. > H > PL/I supports both Picture and scaled fixed decimal, the latter storedA > as packed decimal, i.e., BCD.  So how many bytes of storage are + > required for the above Cobol declaration?   F 6 bytes.  The "USAGE IS" clause dictates the storage encoding.  PackedD decimal is two digits per byte and the sign takes a digit's worth of6 space.  11 digits + 1 sign = 12 nibbles / 2 = 6 bytes.  B You always try for pictures with an odd number of digits if you're4 using packed decimal and you know what you're doing.  G Cobol supports 32 bit two's complement and one-digit-per byte "display" B format also.  Both come with built in support for decimal scaling.   ------------------------------    Date: 12 Jul 2006 07:57:24 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: Re: Floating point questions 3 Message-ID: <SWLajn4S6jsP@eisner.encompasserve.org>   T In article <tvOcQDsFqz$C@eisner.encompasserve.org>, briggs@encompasserve.org writes:K > As a practical matter, this means that packed decimal is the clear choice I > for financial applications in languages that support it.  And languages B > that support it are the clear choice for financial applications. > D > It is possible to use scaled double-precision floating point as an > alternative. > L > In my younger days I did precisely this because what I had was VAX FortranD > and D-floating and what I needed were 9 and 10 digit dollar valuesF > accurate to the penny.  There was no 64 bit integer language support0 > or I'd have gone with scaled integers instead.  F    We used the lib$ functions to do extended integer arithmetic in ourH    early VAX-11 Fortran IV+ days, but would have written in VAX-11 MacroF    to access those instructions if they didn't already show up in lib$C    (we had several such Macro routines for instructions that didn't *    get lib$ accesss routines until later).  F    With those instructions (EMUL, ADWC, ...) and a little work you can,    get much more than 64 bits in an integer.  E    We also had a routine which almost worked right converting D_float B    calculations to 36 bit fixed point; all we had to do was changeD    INTEGER*8 to INTEGER*16 (H_float) to fix the rounding errors.  WeC    didn't care whether the MV II did H_float in hardware, there was E    little enough use of it that all we required was the right answer.    ------------------------------    Date: 12 Jul 2006 09:33:46 -0700$ From: "Chris L" <clusardi2k@aol.com>L Subject: How to create a new user account: Request Example Of How To Do ThisC Message-ID: <1152722026.268891.146890@m73g2000cwd.googlegroups.com>   G Can you give me all the steps that I would have to go through to create  a new user account.   
 Thank you, Christopher Lusardi    ------------------------------  % Date: Wed, 12 Jul 2006 12:44:08 -0400 # From: sol gongola <sol@adldata.com> Y Subject: Re: How to create a new user account: Request Example Of How To Do This ThisThis 0 Message-ID: <1152722716.793923@nntp.acecape.com>   Chris L wrote:I > Can you give me all the steps that I would have to go through to create  > a new user account.  >  > Thank you, > Christopher Lusardi  >   ) SYS$COMMON:[SYSHLP.EXAMPLES]ADDUSER.COM;1    ------------------------------    Date: 12 Jul 2006 05:59:05 -0700$ From: "Chris L" <clusardi2k@aol.com>B Subject: Is There A VMS User Manual Online With Information On CMSC Message-ID: <1152709145.370452.247230@b28g2000cwb.googlegroups.com>   E CMS is an acronym for configuration management. Is there one of these  user manual's online?   
 Thank you, Christopher Lusardi    ------------------------------  # Date: Wed, 12 Jul 2006 14:11:00 GMT & From: John Reagan <john.reagan@hp.com>F Subject: Re: Is There A VMS User Manual Online With Information On CMS/ Message-ID: <Up7tg.387$Li6.36@news.cpqcorp.net>    Chris L wrote:G > CMS is an acronym for configuration management. Is there one of these  > user manual's online?  >  > Thank you, > Christopher Lusardi  >   = http://h71000.www7.hp.com/commercial/decset/decset_index.html    --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------    Date: 12 Jul 2006 07:05:36 -0700  From: "Ian Miller" <ijm@uk2.net>F Subject: Re: Is There A VMS User Manual Online With Information On CMSA Message-ID: <1152713136.053906.60860@75g2000cwc.googlegroups.com>   E If you mean the CMS that is part of DECset you can find documentation  at) http://h71000.www7.hp.com/doc/decset.html    ------------------------------    Date: 12 Jul 2006 07:05:23 -0700  From: "Ian Miller" <ijm@uk2.net>F Subject: Re: Is There A VMS User Manual Online With Information On CMSB Message-ID: <1152713123.877804.80580@m79g2000cwm.googlegroups.com>  E If you mean the CMS that is part of DECnet you can find documentation  at) http://h71000.www7.hp.com/doc/decset.html    ------------------------------  % Date: Wed, 12 Jul 2006 20:33:04 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 4 Subject: Re: Making LIB$*_VM_PAGE Caller's-mode safe1 Message-ID: <e92q1r$d1v$1@news-02.connect.com.au>    Hi Ian,   A > If you have your own zone then you can have your own alloc/free 
 > routines  0 There are several problems with this strategy: -  K 1) It achieves nothing :-( The Default_Zone, String_Zone and Zone_Zone Heap I Inventory databases would remain vulnerable in user-mode writable memory. J I'm now open to the argument for just two heaps (inner/outer) but, even ifG we persist with the idea of 1:Access_Mode, we need to create a seperate L version of each of these database for each heap. That is, if I create a zoneH in Exec_Mode then that Zone_Configuration and Inventory must go into theK Zone_Zone owned by Exec_Mode. Lib$Find_vm_zone and lib$*vm* must all now to / check the PSL and use the appropriate database.   G 2) The *WHOLE* point of wanting to use lib$*vm* is that they are *VERY* F clever! Do shit loads of work! And no one wants to reinvent the bloodyH wheel! Just start thinking about writing lib$*_vm_page in any detail andL then you'll see why so many want this functionality. "OK so you're asking inI Pagelets and I'm $expregING in Pages, I have to keep a list of free and a E list of used, and then know if the pages are contiguous, but at least J setting the protection up and down should be ok, but should I $deltva, and' what about reentrancy and and and. . ."   L ) I did have a "3" the other day but I forgot about it :-) [Look! The Pound sign - Nostalgia]   C I think it was something about why you couldn't just pass a call to L MY_GET_PAGE on to lib$get_vm_page and then set the protection 'cos of (among  other things) the pageLET issue.  I > I wonder if the overhead of calling a memory allocation routine that is > > a system service rather than a mode-of-caller rtl routine is > significant.  E I did a quick test (that wouldn't stand up in court) and this is what 
 happend: -  & I did a simple loop of 100K iterations' It was a vanilla lib$get_vm (512 bytes) " Followed by a matching lib$free_vm (No pool growth, extending etc) : One test was performed in user-mode with the calls in-line The other call sys$cmexec   L The results were that the inner-mode calls version took twenty times longer.J Now 20x almost nothing is still almost nothing and that sort of allocationG pattern is hardly typical of your average application, but whether it's L goodness or badness is not up to me. But compound this with the fact that ifK you went the UWSS route then the additional PROBEing and sanity checking of H user-mode writeable pages would increase the o/head, then maybe that 20x would extend considerably? OTY.   J The simplicity and transparency of caller's-mode tolerance still has a lot going for it IMHO.  F There was also some discussion at www.jcc.com Rdb listserver about howI RMU/UNLOAD lets you read "N" rows per access-mode transition and how this E achieves quite favourable CPU consumption when contrasted with a user , application that does a fetch/row in a loop.  J I'm not suffering from conviction on the issues and am open to persuasion.I The vast majority of System Services (and RMS and Rdb) do this so how bad L can it be? (If only we could lose that bullshit semaphore check (that no one uses) it would fly :-)   Cheers Richard Maher  + "Ian Miller" <ijm@uk2.net> wrote in message = news:1152529086.628755.253160@m73g2000cwd.googlegroups.com... A > If you have your own zone then you can have your own alloc/free 
 > routines >   > (see LIB$CREATE_USER_VM_ZONE ) > 2 > which could then call UWSS routines or whatever. >    ------------------------------    Date: 12 Jul 2006 03:23:04 -0700  From: "Ian Miller" <ijm@uk2.net>! Subject: OpenVMS V8.3 is in sight B Message-ID: <1152699784.564119.148510@35g2000cwc.googlegroups.com>  + New features and benefits page has appeared   < http://h71000.www7.hp.com/openvms/integrity/v83features.html  F with a description of some of the lovely new things in V8.3. This willE be the third version of VMS that has been released in two years (2005 G had V8.2 and V8.2-1) - not bad for an alegedy dead operating system :-)   ? When was the most recent version of Microsoft Windows released?   D (advert - picture of stressed looking people rebooting their windowsG server yet again. "Fed up with waiting for the next version of windows? @ Why not move from stagnant, buggy, insecure Microsoft Windows toF actively developed, properly designed, secure hp OpenVMS!". Picture of0 happy person next to new hp Integrity Server :-)  7 Steve Hoffman is writing about the VMS release end game  http://www.hp.com/blogs/hoffman    ------------------------------  % Date: Wed, 12 Jul 2006 19:45:14 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> % Subject: Re: OpenVMS V8.3 is in sight 1 Message-ID: <e92n89$980$1@news-02.connect.com.au>    Hi Ian,   > The Programming/Development enhancements section blew me away!   Regards Richard Maher   + "Ian Miller" <ijm@uk2.net> wrote in message < news:1152699784.564119.148510@35g2000cwc.googlegroups.com...- > New features and benefits page has appeared  > > > http://h71000.www7.hp.com/openvms/integrity/v83features.html > H > with a description of some of the lovely new things in V8.3. This willG > be the third version of VMS that has been released in two years (2005 I > had V8.2 and V8.2-1) - not bad for an alegedy dead operating system :-)  > A > When was the most recent version of Microsoft Windows released?  > F > (advert - picture of stressed looking people rebooting their windowsI > server yet again. "Fed up with waiting for the next version of windows? B > Why not move from stagnant, buggy, insecure Microsoft Windows toH > actively developed, properly designed, secure hp OpenVMS!". Picture of2 > happy person next to new hp Integrity Server :-) > 9 > Steve Hoffman is writing about the VMS release end game ! > http://www.hp.com/blogs/hoffman  >    ------------------------------    Date: 12 Jul 2006 08:23:49 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: Re: OpenVMS V8.3 is in sight 3 Message-ID: <s+DC+7vEQ2h+@eisner.encompasserve.org>   e In article <1152699784.564119.148510@35g2000cwc.googlegroups.com>, "Ian Miller" <ijm@uk2.net> writes: - > New features and benefits page has appeared  > > > http://h71000.www7.hp.com/openvms/integrity/v83features.html > H > with a description of some of the lovely new things in V8.3. This willG > be the third version of VMS that has been released in two years (2005 I > had V8.2 and V8.2-1) - not bad for an alegedy dead operating system :-)  > A > When was the most recent version of Microsoft Windows released?  >   C    Now that's hardly a fair comparison.  VMS 8.3 will have security /    features Windows can only claim don't exist.    ------------------------------    Date: 12 Jul 2006 06:59:50 -0700  From: "Ian Miller" <ijm@uk2.net>% Subject: Re: OpenVMS V8.3 is in sight B Message-ID: <1152712790.343017.45010@m79g2000cwm.googlegroups.com>  F there is no comparision in terms of features but I just wondered about2 how often new versions of MS Windows are released.   ------------------------------    Date: 12 Jul 2006 06:29:43 -0700- From: "Andrew" <andrew_harrison@symantec.com> 0 Subject: Re: OT: Intel quad core X64 benchmarkedC Message-ID: <1152710983.765325.201720@m79g2000cwm.googlegroups.com>    JF Mezei wrote:  > Andrew wrote: J > > fundamentally different because it is basically 2 Madison (Itanium II)K > > cores packaged on to a single die. It uses the same FSB interface (400, K > > 533 and 667 Mhz) it also cloclks at the same speed as Madison (1.6 Ghz)  > E > Question:  in terms of access to the outside world, does having two I > single core CPUs make any difference relative to a single dual core CPU  > ?  > F Dual core modules normally share one connection to the system bus whatG ever it may be so a single core module generally has more bandwidth per C core than a dual core module assuming that they use the same system G interconnect as they will with Montecito which is replacing single core F Madison processors in SX2000 base HP servers. Same interconnect 2x the cores.  G > In other words, does each chip have its own separate FSB, or is there  > just one FSB per system ?  >   A Currently with Madison and Montecito they share an FSB with other  modules.C Woodcrest has a FSB per module, but when Clovertown (Quad core ish) G Xeon 51XX comes out you will in essence have 2 modules sharing the same B FSB because Clovertown is in fact 2 Woodcrest modules packaged up.  I > IF there is one FSB per chip, then it is fair to state that a dual core H > chip with a 400Mh< FSB is at a disadvantage versus 2 single core chips > each with a 400mhz FSB ?  E If that was the case then yes. Or rather sort of, the cache coherancy E traffic for the dual core module will remain within the module itself @ while for the 2 single core modules cache coherancy traffic will travers the two FSB's.   Regards  Andrew Harrison    ------------------------------    Date: 12 Jul 2006 08:40:38 -0700 From: etmsreec@yahoo.co.uk( Subject: Re: scsi to ide brdige on a VAXB Message-ID: <1152718838.892690.272270@75g2000cwc.googlegroups.com>  D Interesting that this has come up now.  I was about to ask a similar# though slightly different question: D I know that there are PCI IDE controllers out there with and withoutF BIOS support.  Would any of these run with VMS and, ideally, would any= of them provide booting on an IDE CD-ROM or DVD-ROM with VMS?   
 Ta muchly.   Steve    tomarsin2015@comcast.net wrote:  > Hello I > Has anyone tried a scsi to ide bridge on a VAX (4000-10X or 4000-90) or  > even on a E > Alpha? Will VMS 7.3 (VAX) and 8.2 (Alpha) had any problems with the 	 > bridge. B > According to the docs the bridge  will work with "any os" (which > usually means WinXX/Unix) I > I'm wondering how would the bridge work with a CMD 22X qbus controller.  > Would @ > MSCP had problems with the ide drives??  Thanks for any input.   ------------------------------  % Date: Wed, 12 Jul 2006 22:21:00 +1200 1 From: Tux Wonder-Dog <wes.parish@paradise.net.nz> / Subject: Re: The possibility of vms opening up? # Message-ID: <44b4cda7@clear.net.nz>    Dave Froble wrote:   > geletine wrote:  >> Dave Froble wrote:  <snip>  H >> Lets not forget most of solaris is open source, are Sun closing their >> buisness? > G > That's an experiment they were forced into, and how well it will work  > out is not yet known.   @ From what I know, it's increased their visibility in the market. > , >> why not vms open at least some of the Os? > G > Cheap or free sources, yeah I'll go along with that.  Usage of the OS J > however, I'd tend to stick with some type of license fee.  You don't seeG > Microsoft giving away free usage of windows, do you?  I would like to J > see more competition in price at the low end.  However, the license feesI > on itanic based systems are getting pretty good.  The system prices are  > another matter.  >  <snip>  F > The source code is available now.  There are no/few secrets.  It mayJ > have a cost associated with it, but it IS AVAILABLE!  Usage of the OS is- > another matter.  See above about Microsoft.  > D >> I believe there will be a time in the future where not being open8 >> source will kill a buisness, apart from a select few. >  > Believe what you will. > B > It's not the cost that's hurting VMS the most.  It's visibility. > J And that's partly why I believe HP should open the source tree, under someK suitable Open Source license.  Even if it was for a tree as old as VMS 2.0, 3 we might see a change from "VMS is dead" headlines.   
 Wesley Parish  --  O "Good, late in to more rewarding well."  "Well, you tonight.  And I was U lookintelligent woman of Ming home.  I trust you with a tender silence."  I C get a word into my hands, a different and unbelike, probably - 'she D fortunate fat woman', wrong word.  I think to me, I justupid.G Let not emacs meta-X dissociate-press write your romantic dialogs...!!!    ------------------------------  + Date: Wed, 12 Jul 2006 10:59:37 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk/ Subject: Re: The possibility of vms opening up? ( Message-ID: <e92kmp$5p$1@news.mdx.ac.uk>  c In article <g56dndIYyOCJci7ZnZ2dnUVZ_vKdnZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:  >Dave Froble wrote:  > J >>> Hp surely can profit from support and selling more hardware and giving
 >>> away vms.  >>  J >> Well, most commercial VMS sites won't go without support.  The support E >> is an ongoing money maker, vs a one-time amount for selling an OS  : >> license.  I'd agree that support is where the money is. >>  J >> In the past, systems came with a 3-year warranty, which included basic L >> support.  If the money wasn't made with the OS license cost, it wouldn't  >> be made at all. >>  I >> I'd think that support should be the prime target, but, for those who  H >> won't purchase support, why should HP give away free something which  >> costs them money? >>  I >> Keep in mind that VMS has always been a high margin product, and that  A >> doesn't bother those who need it.  Doesn't bother them at all.  > F >After thinking about this a bit more, it occurs to me that companies J >such as RedHat require a support contract.  At least I've read things to H >that effect.  I also think I've read that the RedHat contract requires H >discontinuing use of the OS when support ends.  At least a VMS license  >is perpetual. >   M Redhat Enterprise Linux ES and WS can be purchased with Basic edition service J which provides patches, security updates etc for a year but only provides % a 30 day installation period support.   5 See http://www.europe.redhat.com/software/rhel/faq/#9    ( N Though it appears that you have to purchase at least standard edition support N for Redhat Enterprise Linux AS - their top of the line solution. I'm not sure N how the courts would view such an artificial restriction if someone wanted to ? use the AS version but wanted to get support from someone else.  )     L However Redhat is selling all these versions as a software subscription and F does require you to continue paying this subscription year on year to  continue using the product.   H Users who don't want support and to pay subscription fees also have the < option of using Redhat's alternative Linux product - Fedora.    
 David Webb Security team leader CCSS Middlesex University      H >So just by changing symantics a bit, it would be rather easy for HP to H >declare that a license for VMS would be free, but a minimum of ? years H >basic support must be purchased in order to get the license.  Wouldn't I >matter whether they sold hardware, or just the support.  There would be  C >some differences from today's pricing, but, keeping a customer on  H >support may be easier than selling them support.  Doing this would get # >that foot in the door immediately.  > H >So yeah, the VMS license should be free.  Support should be mandatory, H >and would be the method of obtaining the right to use new versions, as  >it does today.  >            >-- 5 >David Froble                       Tel: 724-529-0450 ? >Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com  >DFE Ultralights, Inc. >170 Grimplin Road >Vanderbilt, PA  15486   ------------------------------    Date: 12 Jul 2006 08:16:45 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: The possibility of vms opening up? 3 Message-ID: <tGTRKgInaShz@eisner.encompasserve.org>   W In article <44b4cda7@clear.net.nz>, Tux Wonder-Dog <wes.parish@paradise.net.nz> writes:   L > And that's partly why I believe HP should open the source tree, under someM > suitable Open Source license.  Even if it was for a tree as old as VMS 2.0, 5 > we might see a change from "VMS is dead" headlines.   H    I'm not sure HP has a copy of the VMS 2.0 source tree.  And I'm quiteD    sure I wouldn't want anything earlier than 3.0 as a souce tree inE    general use.  There was still a lot of basic effort going into VMS     prior to 3.0.   ------------------------------    Date: 12 Jul 2006 08:14:47 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: The possibility of vms opening up? 3 Message-ID: <huNgjyhwxUfi@eisner.encompasserve.org>   \ In article <44B46245.21600B5C@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > J > Deployment of thrust reversers is fatal while in the air (and there haveH > been such crashes) and since then, there are many "locks" that prevent> > that from happening until the plane is firmly on the ground.  G    Side note:  the Gulfstream used by NASA to practice shuttle landings E    is the only instance of that model certified for flight with fully G    deployed thrust reverse.  Only by deploying thrust reverse in flight ?    can they simulate the shuttle's 45 degree glide slope with a     production aircraft.    ------------------------------    Date: 12 Jul 2006 02:15:42 -0700* From: "Part Pic" <mydream.666@hotmail.com>& Subject: There is a good photo websiteC Message-ID: <1152695742.545705.270530@s13g2000cwa.googlegroups.com>   : hello,everyone,I am the newcomer.I hope you can go to this: website:www.flickr.com/photos/partpic/.I am sure it is NOTC spam.Then,you can feel that it is a professional photograph website G about the computer.there are o lot of picture of some kinds of computer > ,include IBM,SUN,HP,EMC,HDS and others.I wanna to exchange the! experience and the idea with you.    ------------------------------  % Date: Wed, 12 Jul 2006 08:44:07 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: VAX 66x0 & CHARON VAX) Message-ID: <op.tck1ztqczgicya@hyrrokkin>   8 Following a recent thread on CHARON VAX I was curious if= any such systems still running.  I can't imagine SRI actually ? going through the effort without adequate market opportunities.    Tom    ------------------------------  % Date: Wed, 12 Jul 2006 12:17:34 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>" Subject: Re: VAX 66x0 & CHARON VAX: Message-ID: <44B4E85E.1589.A78D6FB@squayle.insight.rr.com>  ) On 12 Jul 2006 at 8:44, Tom Linden wrote: : > Following a recent thread on CHARON VAX I was curious if? > any such systems still running.  I can't imagine SRI actually A > going through the effort without adequate market opportunities.   E I'm waiting on a purchase order for a 6620 for production and a 6610  ? for test at a site that's running a 7420 (and no test system!).   E There aren't as many 7xxx or 6xxx systems as 3100's, but they're out  - there.  My biggest problem is finding them...       
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA < stan-at-stanq-dot-com   http://www.stanq.com/charon-vax.html) "OpenVMS, when downtime is not an option"    ------------------------------    Date: 12 Jul 2006 09:32:08 -0700$ From: "Chris L" <clusardi2k@aol.com>) Subject: Where Are The System Directories C Message-ID: <1152721928.456102.137640@m73g2000cwd.googlegroups.com>   F What is the standard file directory system? For example, where are the password files kept?   Thanks,  Christopher Lusardi    ------------------------------  % Date: Wed, 12 Jul 2006 12:56:25 -0400 # From: sol gongola <sol@adldata.com> - Subject: Re: Where Are The System Directories 0 Message-ID: <1152723453.607871@nntp.acecape.com>   Chris L wrote:H > What is the standard file directory system? For example, where are the > password files kept? > 	 > Thanks,  > Christopher Lusardi  >  sys$system:  sys$system:sysuaf.dat     No. It is not user viewable    No. It is not user editable   ------------------------------   End of INFO-VAX 2006.385 ************************