1 INFO-VAX	Wed, 12 Jul 2006	Volume 2006 : Issue 384       Contents: 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: 64K limit for socket send B Re: A consistent, even playing field - That's all I ask! (Was: Re: Re: Alpha remembrance day  RE: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day @ Re: Any Way to Validate Username & Password from an Application?@ Re: Any Way to Validate Username & Password from an Application?@ Re: Any Way to Validate Username & Password from an Application?@ Re: Any Way to Validate Username & Password from an Application?@ Re: Any Way to Validate Username & Password from an Application? Re: Floating point questions Re: Floating point questions6 Re: No Oracle Standard Edition planned for VMS on IA64 Re: Oracle10g on IA64 8.2-1  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?  F ----------------------------------------------------------------------  + Date: Tue, 11 Jul 2006 20:07:50 +0000 (UTC) . From: klewis@LUMINA.MITRE.ORG (Keith A. Lewis)" Subject: 64K limit for socket send. Message-ID: <e910em$2ke$1@newslocal.mitre.org>  L I'm running up against an apparant 64K limit for socket writes.  What I want to do is increase the limit.   I tried:  4 $ TCPIP SET PROTO TCP/QUOTA=(SEND:130000,REC:130000)  	 and also:   @ setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &bufsize, sizeof(int))); (with privileges turned on)   J But I still get "%system-f-ivbuflen, invalid buffer length" from writev().  D What do I need to do to increase the buffer size so I can send large	 messages?    I'm running this: 3   HP TCP/IP Services for OpenVMS Alpha Version V5.4 >   on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V7.3-1  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Tue, 11 Jul 2006 20:26:14 GMT + From: Ryan Moore <rmoore@rmoore.dyndns.org> & Subject: Re: 64K limit for socket send< Message-ID: <Pine.LNX.4.64.0607111324020.29300@jaipur.local>  J Just write a looop that takes your buffer and makes a series of TCP write I calls, each 64K bytes long.  TCP is a stream protocol anyway.  You can't  J write a TCP 'message'.  Regardless of how you send the data, the receiver G may get the data in as many chunks as the Operating System sees fit to  # give it.  That's the way TCP works.     * On Tue, 11 Jul 2006, Keith A. Lewis wrote: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: 4 >  HP TCP/IP Services for OpenVMS Alpha Version V5.4? >  on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V7.3-1    ------------------------------  # Date: Tue, 11 Jul 2006 20:57:43 GMT % From: Rick Jones <rick.jones2@hp.com> & Subject: Re: 64K limit for socket send0 Message-ID: <bhUsg.349$co6.104@news.cpqcorp.net>  , Ryan Moore <rmoore@rmoore.dyndns.org> wrote:E > Just write a looop that takes your buffer and makes a series of TCP E > write calls, each 64K bytes long.  TCP is a stream protocol anyway. # > You can't write a TCP 'message'.    > It might be more explicit to say that TCP will not preserve an! application's message boundaries.   D > Regardless of how you send the data, the receiver may get the data@ > in as many chunks as the Operating System sees fit to give it.  + Well, the TCP stack on either end anyway :)    > That's the way TCP works.   F And just for the record, if one ever happened to be using UDP, ~64K isB the hard limit for a UDP datagram so one couldn't send larger than that either.  ? While other stacks allow one to make sends > 64KB against a TCP B socket, by the time one is making 64KB sends, one is well into the- realm of diminishing returns for CPU savings.   F When one does split the > 64KB of data to send into multiple sends, itD would probably be best to split it such that none of the sends - theC last send in particular - are less than the MSS for the connection. E At least if this is a request/response sort of application.  If it is D just bulk streaming, it likely doesn't matter since the subsequent >E 64KB send would flush the previous trailing sub-MSS send if it hadn't E already been sent.  (Nagle algorithm as applied to sub-MSS sends by a  user).  
 rick jones --  = portable adj, code that compiles under more than one compiler 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: Tue, 11 Jul 2006 21:36:51 +0000 (UTC) . From: klewis@LUMINA.MITRE.ORG (Keith A. Lewis)& Subject: Re: 64K limit for socket send. Message-ID: <e915lj$4r7$1@newslocal.mitre.org>  { 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: - >Ryan Moore <rmoore@rmoore.dyndns.org> wrote: F >> Just write a looop that takes your buffer and makes a series of TCPF >> write calls, each 64K bytes long.  TCP is a stream protocol anyway.$ >> You can't write a TCP 'message'.   E Thanks for the tip, Ryan.  I tried that and it's working fine so far.   G >When one does split the > 64KB of data to send into multiple sends, it E >would probably be best to split it such that none of the sends - the D >last send in particular - are less than the MSS for the connection.  J That sounds reasonable, but it leads to another question -- how can I find the MSS for my socket?  E These messages don't come constantly, and I don't want the end of one 7 waiting around on my end for the beginning of the next.   0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------    Date: 11 Jul 2006 15:05:51 -0700) From: "Bob Gezelter" <gezelter@rlgsc.com> & Subject: Re: 64K limit for socket sendB Message-ID: <1152655551.108068.95790@p79g2000cwp.googlegroups.com>   Keith,  D I concur with Ryan. I have written quite a few socket level (and QIO> level) uses of TCP streams, and the reality is that TCP is, byE definition, a STREAM connection. You can check the applicable RFC (at F http://www.ietf.org). Unlike DECnet, where the underlying concept is a= "message", there is no equivalent in TCP. Each application is A responsible for the processing necessary to break the stream into  actual messages.  G If you are using 64K writes, you are well into the diminishing overhead  curve.  $ - Bob Gezelter, http://www.rlgsc.com   ------------------------------  # Date: Tue, 11 Jul 2006 22:48:28 GMT % From: Rick Jones <rick.jones2@hp.com> & Subject: Re: 64K limit for socket send/ Message-ID: <0VVsg.361$co6.60@news.cpqcorp.net>   / Keith A. Lewis <klewis@lumina.mitre.org> wrote: L > That sounds reasonable, but it leads to another question -- how can I find > the MSS for my socket?  @ I don't know if OpenVMS supports it, but elsewhere, you can do aE getsockopt() against TCP_MAXSEG - after the connection is established ) - to retrieve the MSS for the connection.   G > These messages don't come constantly, and I don't want the end of one 9 > waiting around on my end for the beginning of the next.   F Well, it won't wait around for _very_ long.  In broad handwaving termsC a proper implementation of the Nagle algorithm works something like  this:   F 1) Is this user's _send_, plus any queued, unsent data > MSS?  If yes,0    send immeidately, otherwise go to question 2.  F 2) Is the connection otherwise idle (ie no outstanding, unACKed data)?5    If yes, send immediately, otherwise, go to step 3.   F 3) Queue the data and wait.  One of at least three things will happen:  A    a) The remote will ACK the unacked data, making the connection =       "idle" and allowing the send of this sub-MSS remainder.   ;    b) The local TCP retransmission timer will fire for some C       outstanding data and this queue data may be bundled with that F       retransmission (assumes the data to be retransmitted is within 1E       MSS of the queued data in the TCP sequence space) TCP will only <       retransmit one segment (1 MSS worth of data) at a time       (basically).     A    c) The local application will make another send() and take the        quantity of data >= MSS.  E That ACK in 3.a will arrive within the remote's standalone ACK timer, F which is typically somewhere between 50 and 200 milliseconds depending
 on the stack.   
 rick jones --  B firebug n, the idiot who tosses a lit cigarette out his car windowF 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: Tue, 11 Jul 2006 23:32:26 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: 64K limit for socket send, Message-ID: <44B46D3C.8F59FAC0@teksavvy.com>   Rick Jones wrote: H > 1) Is this user's _send_, plus any queued, unsent data > MSS?  If yes,2 >    send immeidately, otherwise go to question 2.  F If I have a 1500 MTU (server side) and some remote dialup user has 150F MTU,  isn't it better for the server to send 1500 size packets and letG the last router befofe the dialup link split the packets versus sending  150 packets from the server ?   E (Or does the TCP stack limit those packets to 150 right at the server  side ?)       H (sorry for using MTU here, i forget the actual number of byte difference between MTU and MSS)   ------------------------------  % Date: Tue, 11 Jul 2006 21:52:11 -0700 = From: "John Gemignani, Jr." <john@nfw-invalid.cibtrikker.com> & Subject: Re: 64K limit for socket send6 Message-ID: <PsadndguRINg4inZnZ2dnUVZ_vKdnZ2d@dls.net>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:44B46D3C.8F59FAC0@teksavvy.com... > 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 ?)  >  >  > J > (sorry for using MTU here, i forget the actual number of byte difference > between MTU and MSS)  M Depends. Many routers can accept the larger packets and then refragment them  L down to the appropriate size. Once that occurs, they are never defragmented D until they reach the destination where they are pulled together and J sequenced for delivery up to the receiving socket. Some routers will push H back on the sender and not allow them through unless they are the right  size.    John     ------------------------------  % Date: Tue, 11 Jul 2006 21:55:30 -0700 = From: "John Gemignani, Jr." <john@nfw-invalid.cibtrikker.com> & Subject: Re: 64K limit for socket send6 Message-ID: <Er-dnYOcWN9ZHSnZnZ2dnUVZ_vWdnZ2d@dls.net>  5 "Bob Gezelter" <gezelter@rlgsc.com> wrote in message  < news:1152655551.108068.95790@p79g2000cwp.googlegroups.com... > Keith, > F > I concur with Ryan. I have written quite a few socket level (and QIO@ > level) uses of TCP streams, and the reality is that TCP is, byG > definition, a STREAM connection. You can check the applicable RFC (at H > http://www.ietf.org). Unlike DECnet, where the underlying concept is a? > "message", there is no equivalent in TCP. Each application is C > responsible for the processing necessary to break the stream into  > actual messages. > I > If you are using 64K writes, you are well into the diminishing overhead  > curve. > & > - Bob Gezelter, http://www.rlgsc.com >   L If you're going to send huge blobs of data, be sure that you up your socket B quotas and such. It may also cost you process quota in some cases.   John     ------------------------------    Date: 11 Jul 2006 14:56:44 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) K Subject: Re: A consistent, even playing field - That's all I ask! (Was: Re: 3 Message-ID: <0gwyyMKCjAzq@eisner.encompasserve.org>   Y In article <xFNsg.310$686.160@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes:  > Richard Maher wrote: >  >>   >> For example:  >>  
 >> $GETUAI >>   >>   >> REQUIRED ACCESS MODE  >>  $ >> Cannot be called from Kernel Mode >>   > I > $GETUAI/$SETUAI uses RMS to access SYSUAF.DAT.  That is the reason for  6 > the restriction about calling them from kernel mode.  F For the $GETUAI case only from kernel mode, a lot of the same features  can be obtained by calling $ACM.   ------------------------------  % Date: Tue, 11 Jul 2006 14:29:48 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>" Subject: Re: Alpha remembrance day: Message-ID: <44B3B5DC.7513.5CB87FF@squayle.insight.rr.com>  * On 11 Jul 2006 at 10:46, Tom Linden wrote: > I was looking at that, on @ > http://h71000.www7.hp.com/openvms/sri-charon-vax-emulator.html' > $5,995 for 1200 lmf units on VAX 66x0   B That's only required if you consolidate a bunch of, say VAX 4000, C systems into one VAX 66x0 emulation.  Most conversions are one-for- F one, and incur the $2,000 charge for license transfer without needing  any new licenses.   = > Also I note that support is available only on HP hardware.    @ Yeah, but clients without VMS software support don't care.  And @ telling clients who need support that they have to buy ProLiant ' instead of Dell isn't too a big battle.   2 > AFAIK, HP does not offer a 4 cpu Opteron system   > I think the DL585 can be ordered in a 2-processor, dual-core,  configuration.  
 --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: Tue, 11 Jul 2006 19:29:04 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> " Subject: RE: Alpha remembrance dayT Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401722AA7@tayexc19.americas.cpqcorp.net>   > -----Original Message-----< > From: Stanley F. Quayle [mailto:squayle@insight.rr.com]=20 > Sent: July 11, 2006 2:30 PM  > To: Info-VAX@Mvb.Saic.Com $ > Subject: Re: Alpha remembrance day >=20, > On 11 Jul 2006 at 10:46, Tom Linden wrote: > > I was looking at that, on B > > http://h71000.www7.hp.com/openvms/sri-charon-vax-emulator.html) > > $5,995 for 1200 lmf units on VAX 66x0  >=20F > That's only required if you consolidate a bunch of, say VAX 4000,=20E > systems into one VAX 66x0 emulation.  Most conversions are one-for- J > one, and incur the $2,000 charge for license transfer without needing=20 > any new licenses.  >=20  F It also is for the OpenVMS component only. That price does not include! the cost of the emulator product.   G Perhaps someone could quote what the actual emulator product list price @ is for a VAX 6600 quad CPU system running on a X86 of some type?  A > > Also I note that support is available only on HP hardware.=20  >=20D > Yeah, but clients without VMS software support don't care.  And=20D > telling clients who need support that they have to buy ProLiant=20) > instead of Dell isn't too a big battle.  >=206 > > AFAIK, HP does not offer a 4 cpu Opteron system=20 >=20B > I think the DL585 can be ordered in a 2-processor, dual-core,=20 > configuration. >=20  
 Reference:H http://h10010.www1.hp.com/wwpc/us/en/ss/WF05a/15351-241434-241475-241475 -f80-398220.html=20 " DL585 is quad AMD Opteron CPU x 4.   Snip ..   
 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: Tue, 11 Jul 2006 23:10:01 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> " Subject: Re: Alpha remembrance day, Message-ID: <44B467FD.40BC43E7@teksavvy.com>   Bill Gunshannon wrote:G > Do you honestly think that once Itanium gets relegated to the crapper K > that HP is going to continue to develop/support VMS for use on emulators?   @ HP has already stopped development of VMS for emulators, despite6 promises for and 8.* release for the VAX architecture.  B The problem with HP is that VMS is there to help sales of IA64. It1 should be the hardware platform helping OS sales.   C When Intel/HP finally announce the end of that IA64 thing, the true H nature of HP will be revealed because it is then that we will know if HPH intents to continue VMS on industry standard platform (aka 8086)  or let it die.    ------------------------------  % Date: Tue, 11 Jul 2006 23:39:29 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> " Subject: Re: Alpha remembrance day, Message-ID: <44B46EE3.14D3D3E0@teksavvy.com>   "Main, Kerry" wrote:I > Perhaps someone could quote what the actual emulator product list price B > is for a VAX 6600 quad CPU system running on a X86 of some type?  G Often, when prices are not published, it is because they are adapted to H each customer's needs. Consider budgets which may allow certain types ofB expenditures but not others (think capital cost vs leasing costs,  service vs purchase etc.).  G I have no idea if that is the case with the specific VAX emulators. And B the price structure may also vary from country to country and fromD distributor to distributor. So it makes it hard to publish anything.   ------------------------------    Date: 11 Jul 2006 14:52:28 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) I Subject: Re: Any Way to Validate Username & Password from an Application? 3 Message-ID: <GcwMvsKi1OWp@eisner.encompasserve.org>   g In article <e90fam$s0i$1$8300dec7@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes:   I > If you really want the entry of a password, it is doable, but you need  K > to use all the right services, and make sure you do proper vms intrusion  # > detection, evasion, auditing etc. E > See $getuai, $hash_password, $audit_event, $scan_intrusion (from a  H > module originally written in '92, so perhaps not entirely current - I - > think it's probably got easier since then).   F That is the reason to use $ACM - it includes the necessary calls to doF all of that.  But it does not currently work on VAX.  It could but the? monetary rationale for creating it was Microsoft compatibility.   C Note that third party vendors (or ambitious individuals) can create G their own backends if you require alternative authentication technology  like Vulcan Mind Meld.   ------------------------------    Date: 11 Jul 2006 14:53:45 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) I Subject: Re: Any Way to Validate Username & Password from an Application? 3 Message-ID: <G5JZT7bra1D7@eisner.encompasserve.org>   g In article <e90fam$s0i$1$8300dec7@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes:  > Craig Dedo wrote:  >> Everyone:C >>     Is there any way to validate a username and password from an I >> application?  We need to have this functionality in one of our OpenVMS  >> applications. >>  C >>     The application program has a variety of application-defined I >> advanced privileges, e.g., granting certain kinds of exceptions to the I >> usual business rules.  At the time such privileges need to be used, it J >> is necessary to validate the username and password for several reasons. > I > VMS identifiers (rights) granted to users are ideal for this - you can  K > set real protections using them, as well as program behaviours, security   > audits and alarms, etc. H > We use rights (both positive and negative), and find them at run-time # > with $find_held (system service).   G Rights are good for determining attributes of the person who logged on, E but reauthentication is what is needed for authorizing a particularly G high value transaction -- making sure the person at the keyboard is the ! same one who initially logged on.    ------------------------------    Date: 11 Jul 2006 17:17:44 -0700 From: dooleys@snowy.net.auI Subject: Re: Any Way to Validate Username & Password from an Application? C Message-ID: <1152663464.566441.206440@m73g2000cwd.googlegroups.com>   . There is a freeware utility called "term_lock"1 this locks the terminal and requires the password   of the current user to continue.5 I don't know if this utility is up to date as regards  vms password encryption 8 You may be able to incorporate it into your application,8 or you could just read the source to give you some ideas (you DO read fortran don't you)  Phil   ------------------------------  % Date: Tue, 11 Jul 2006 22:59:21 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> I Subject: Re: Any Way to Validate Username & Password from an Application? , Message-ID: <44B4657E.D2AC8F45@teksavvy.com>  ! VAXman-, @SendSpamHere.ORG wrote: 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.   H How does one ensure that if you enter the wrong password, this gets sent> to the appropriate "authority" that logs this invalid passwordD (generating alarm and intrusion attempt increment), and how does one? check that the username is not considered an intruder already ?   G This is another example where having open source would have allowed VAX F users to port the SYS$ACM services to VAX because some paper pusher at2 Digital/Compaq/HP decided not to assign resources.   ------------------------------  % Date: Tue, 11 Jul 2006 23:04:42 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> I Subject: Re: Any Way to Validate Username & Password from an Application? , Message-ID: <44B466BE.880E6CC9@teksavvy.com>   Chris Sharman wrote:> > VMS identifiers (rights) granted to users are ideal for this  H If you are writing a TCPIP service, you need to authenticate a user with? username/password. The user is not yet logged in and it is your G software's responsability to do it properly. (consider an SMTP receiver E which would allow a remote user to authenticate itself against SYSUAF G and this be granted "local" privileges to relay to the world and bypass , any blocks on an IP block he might be using.      D > See $getuai, $hash_password, $audit_event, $scan_intrusion (from aG > module originally written in '92, so perhaps not entirely current - I - > think it's probably got easier since then).   E Thanks for the pointers. It would be nice to have such code posted so H that we don't have to re-invent the wheel.  Since SYS$ACM does not existL in all VMS platforms, one cannot really use it for widely deployed software.   ------------------------------    Date: 11 Jul 2006 14:03:22 -0500 From: briggs@encompasserve.org% Subject: Re: Floating point questions 3 Message-ID: <tvOcQDsFqz$C@eisner.encompasserve.org>   z In article <890539d90607110905y144c0140kbcc400a7a0b20c4a@mail.gmail.com>, "Carl Friedberg" <frida.fried@gmail.com> writes:9 > From deepest, darkest memory niches (failing cells too)  > N > The way that packed decimal interfaces to other formats is very interesting. > M > Packed decimal is definitely of IBM origin, but was fully supported on VAXn J > of the 780/750 era. Beginning with MicroVAX II, the concept of partiallyH > supported architectures was introduced, and packed decimal was allowedN > to be migrated off the hardware. Various flavors of VAXen had various levelsI > of hardware support, but I believe that if you did Cobol benchmarks, in C > many cases the results were dismal when Packed Decimal arithmetic  > was at issue.  > N > A funny thing: IIRC to convert from integer to floating, IBM first convertedJ > from integer to Packed, and then from packed to floating, as it was much > faster that way.   Strange, if true.   G IBM floating point has (had?) a binary fraction and a base 16 exponent. H The fraction was typically normalized so that the high order 4 bits wereC not all zero.  This is memory from circa 1974, I don't know whether - denormalized fractions were actually allowed.   7 IBM integers are 32 bit two's complement binary values.   H Converting from integer to floating point is mainly a matter of decidingA what exponent to use and masking the appropriate set of bits from F the integer value into the fraction field in the floating point value.  J Unless bit string operations are horrendously expensive and packed decimalA instructions are very well microcoded, the notion that converting H from binary to decimal and back is the most efficient way to change fromD binary fixed point to binary floating point does not seem plausible.  N > For banking applications, there was no alternative to packed decimal becauseM > there were no rounding errors (it wasn't floating point) and no issues with  > handling pennies correctly...   G Packed decimal is not immune to rounding errors (divide by 3 sometime). I Binary floating point need not have rounding errors (add 2 + 2 sometime).   C What _is_ true is that packed decimal deals quite conveniently with E fractions that are powers of ten, that packed decimal implementations H typically include language support for decimal-scaled packed decimal (*)J and that packed decimal implementations typically support more significant, digits than double precision floating point.  I As a practical matter, this means that packed decimal is the clear choice G for financial applications in languages that support it.  And languages @ that support it are the clear choice for financial applications.  B It is possible to use scaled double-precision floating point as an alternative.  J In my younger days I did precisely this because what I had was VAX FortranB and D-floating and what I needed were 9 and 10 digit dollar valuesD accurate to the penny.  There was no 64 bit integer language support. or I'd have gone with scaled integers instead.  H With a scaling factor of 100, floating point addition and subtraction inD pennies are not subject to round-off error as long as all the values? involved fall within the range of exactly expressible integers.   B Multiplication by an integer is similarly not subject to round-off@ errors as long as the product is an exactly expressible integer.  ? Division and multiplication by a decimal fraction won't usually G be exact.  But in the usual case, those results don't need to be exact. B They'll be rounded off anyway.  [In some applications such as, forJ instance, currency exchange or the stock market, details of that round-off  may be very carefully specified]    I * By language support for decimal-scaled packed decimal I mean constructs  like  5 	05 YTD-PAY PICTURE S9(9)V99 USAGE IS PACKED-DECIMAL.   I where the compiler automatically keeps track of the scaling factor of 100  for you.   ------------------------------  % Date: Tue, 11 Jul 2006 19:29:05 -0700 # From: "Tom Linden" <tom@kednos.com> % Subject: Re: Floating point questions ) Message-ID: <op.tcj06rfxzgicya@hyrrokkin>   E On Tue, 11 Jul 2006 12:03:22 -0700, <briggs@encompasserve.org> wrote:    > In article  =   I > <890539d90607110905y144c0140kbcc400a7a0b20c4a@mail.gmail.com>, "Carl  =   , > Friedberg" <frida.fried@gmail.com> writes:: >> From deepest, darkest memory niches (failing cells too) >>E >> The way that packed decimal interfaces to other formats is very  =    >> interesting.  >>I >> Packed decimal is definitely of IBM origin, but was fully supported o=  n  =   >> VAXn I >> of the 780/750 era. Beginning with MicroVAX II, the concept of partia=  lly I >> supported architectures was introduced, and packed decimal was allowe=  d I >> to be migrated off the hardware. Various flavors of VAXen had various=    =   	 >> levels I >> of hardware support, but I believe that if you did Cobol benchmarks, =  inD >> many cases the results were dismal when Packed Decimal arithmetic >> was at issue. >>H >> A funny thing: IIRC to convert from integer to floating, IBM first  =   >> convertedI >> from integer to Packed, and then from packed to floating, as it was m=  uch  >> faster that way.  >  > Strange, if true.  > I > IBM floating point has (had?) a binary fraction and a base 16 exponent=  . I > The fraction was typically normalized so that the high order 4 bits we=  reE > not all zero.  This is memory from circa 1974, I don't know whether / > denormalized fractions were actually allowed.  > 9 > IBM integers are 32 bit two's complement binary values.  > I > Converting from integer to floating point is mainly a matter of decidi=  ngC > what exponent to use and masking the appropriate set of bits from I > the integer value into the fraction field in the floating point value.=    > G > Unless bit string operations are horrendously expensive and packed  =   	 > decimal C > instructions are very well microcoded, the notion that converting I > from binary to decimal and back is the most efficient way to change fr=  omF > binary fixed point to binary floating point does not seem plausible. > I >> For banking applications, there was no alternative to packed decimal =   =  
 >> becauseI >> there were no rounding errors (it wasn't floating point) and no issue=  s  =   >> with   >> handling pennies correctly... > I > Packed decimal is not immune to rounding errors (divide by 3 sometime)=  . I > Binary floating point need not have rounding errors (add 2 + 2 sometim=  e).  > E > What _is_ true is that packed decimal deals quite conveniently with G > fractions that are powers of ten, that packed decimal implementations I > typically include language support for decimal-scaled packed decimal (=  *)C > and that packed decimal implementations typically support more  =   
 > significant . > digits than double precision floating point. > I > As a practical matter, this means that packed decimal is the clear cho=  ice I > for financial applications in languages that support it.  And language=  s 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. > G > In my younger days I did precisely this because what I had was VAX  =   	 > Fortran D > 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. > I > With a scaling factor of 100, floating point addition and subtraction =  inF > pennies are not subject to round-off error as long as all the valuesA > involved fall within the range of exactly expressible integers.  > D > Multiplication by an integer is similarly not subject to round-offB > errors as long as the product is an exactly expressible integer. > A > Division and multiplication by a decimal fraction won't usually I > be exact.  But in the usual case, those results don't need to be exact=  . D > They'll be rounded off anyway.  [In some applications such as, forE > instance, currency exchange or the stock market, details of that  =    > round-off " > may be very carefully specified] >  > I > * By language support for decimal-scaled packed decimal I mean constru=  cts  > like > 7 > 	05 YTD-PAY PICTURE S9(9)V99 USAGE IS PACKED-DECIMAL.  > I > where the compiler automatically keeps track of the scaling factor of =  100 
 > for you.  F In PL/I Picture data types are not packed decimal but are stored as  =   character strings.I PL/I supports both Picture and scaled fixed decimal, the latter stored a=  s I packed decimal, i.e., BCD.  So how many bytes of storage are required fo=  r  =  	 the above  Cobol declaration?   ------------------------------    Date: 11 Jul 2006 13:46:41 -0700/ From: "jgar the jorrible" <joel-garry@home.com> ? Subject: Re: No Oracle Standard Edition planned for VMS on IA64 C Message-ID: <1152650801.411658.323740@p79g2000cwp.googlegroups.com>    Larry Kilgallen wrote:n > In article <1152310054.695221.93970@35g2000cwc.googlegroups.com>, "joel garry" <joel-garry@home.com> writes: > J > > Isn't it about 8 years since Compaq sent out the 10-year sunset noticeF > > for VMS?  (0r was that Alpha?)  Since I haven't touched VMS for 10& > > years, it's just nostalgia for me. > " > You need to read more carefully. > F > The notices have been N-year "guarantees" of support, not statements1 > that support would stop after that time period.    Thanks.   E It's not so much reading comprehension, as remembering 8 years later!  :-)   0 Say, didn't we meet at a DECUS around 1986?  :-)   jg --   @home.com is bogus.  www.oneredpaperclip.com    ------------------------------    Date: 11 Jul 2006 19:57:16 -02006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)$ Subject: Re: Oracle10g on IA64 8.2-1, Message-ID: <44b4029c$1@news.langstoeger.at>  d In article <1152601484.410383.162330@h48g2000cwc.googlegroups.com>, "Joerg" <spi@equicon.de> writes:> >I want test Oracle10g on IA64. How can I donwload a Oracle10g >installation kit?  O To download 10GR1 for OpenVMS Alpha you use (after accepting the license terms)   ] http://www.oracle.com/technology/software/products/database/oracle10g/htdocs/openvmssoft.html   B NOTE: You need an OTN (Oracle Technology Network) account for this  I But to download 10G for OpenVMS I64 (which will be only 10GR2 and up) you L have to wait for 10GR2 for OpenVMS (Alpha&I64) => a couple of months longer.  O Too bad, that Oracle for OpenVMS comes many months/years after other platforms. @ I remember of an (not so long ago) Oracle promise ("90 days")...  	 Good luck    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   Date: 11 Jul 2006 19:48:40 GMT From: healyzh@aracnet.com ( Subject: Re: scsi to ide brdige on a VAX, Message-ID: <e90vao02amq@enews2.newsguy.com>   tomarsin2015@comcast.net wrote: I > Has anyone tried a scsi to ide bridge on a VAX (4000-10X or 4000-90) or K > even on a Alpha? Will VMS 7.3 (VAX) and 8.2 (Alpha) had any problems with F > the bridge. According to the docs the bridge will work with "any os"J > (which usually means WinXX/Unix) I'm wondering how would the bridge workF > with a CMD 22X qbus controller. Would MSCP had problems with the ide! > drives??  Thanks for any input.   H I'm aware of people using the Acard bridges on Alpha's under OpenVMS (asH well as SGI/IRIX and Sun Solaris).  Under OpenVMS I believe there is oneF problem, which is, I've heard you can't do Volume Shadowing with them.  K It should work on the VAXstation 4000-90.  I'm a little concerned about the G CMD 22X Q-Bus controller, and would be very interested in knowing if it G would work there or not.  Based on my experience with Viking Q-Bus SCSI I cards, I'd recommend ensuring the CMD board has as new of firmware as you G can get on it.  Does anyone know how well these SCSI controllers handle  *LARGE* disks?   			Zane    ------------------------------  % Date: Tue, 11 Jul 2006 14:39:12 -0400 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: The possibility of vms opening up? 9 Message-ID: <g56dndIYyOCJci7ZnZ2dnUVZ_vKdnZ2d@libcom.com>    Dave Froble wrote:  I >> Hp surely can profit from support and selling more hardware and giving  >> away vms. > I > Well, most commercial VMS sites won't go without support.  The support  D > is an ongoing money maker, vs a one-time amount for selling an OS 9 > license.  I'd agree that support is where the money is.  > I > In the past, systems came with a 3-year warranty, which included basic  K > support.  If the money wasn't made with the OS license cost, it wouldn't   > be made at all.  > H > I'd think that support should be the prime target, but, for those who G > won't purchase support, why should HP give away free something which   > costs them money?  > H > Keep in mind that VMS has always been a high margin product, and that @ > doesn't bother those who need it.  Doesn't bother them at all.  E After thinking about this a bit more, it occurs to me that companies  I such as RedHat require a support contract.  At least I've read things to  G that effect.  I also think I've read that the RedHat contract requires  G discontinuing use of the OS when support ends.  At least a VMS license  
 is perpetual.   G So just by changing symantics a bit, it would be rather easy for HP to  G declare that a license for VMS would be free, but a minimum of ? years  G basic support must be purchased in order to get the license.  Wouldn't  H matter whether they sold hardware, or just the support.  There would be B some differences from today's pricing, but, keeping a customer on G support may be easier than selling them support.  Doing this would get  " that foot in the door immediately.  G So yeah, the VMS license should be free.  Support should be mandatory,  G and would be the method of obtaining the right to use new versions, as   it does today.   --  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: 11 Jul 2006 20:39:00 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)/ Subject: Re: The possibility of vms opening up? , Message-ID: <4higj4F1r7f35U1@individual.net>  9 In article <p7CdnYRSsK0GcS7ZnZ2dnUVZ_t2dnZ2d@libcom.com>, * 	Dave Froble <davef@tsoft-inc.com> writes: > Bill Gunshannon wrote:/ >> In article <44B3014B.B9FEDDFD@teksavvy.com>, 3 >> 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>> Bob Koehler wrote:G >>>>    That gets to the point.  He requested thrust at what would have M >>>>    otherwise been an appropriate point, but the FBW setup added delay to C >>>>    the thrust increase, causing a delay in the speed increase. L >>> Do you have any evidence that the FBW system delayed increasing thurst ?: >>>  There is no reasonf or it to delay increasing thurst. >>> F >>> All the stuff I had read was that the pilot put the aircraft in anL >>> unrecoverable situation without enough energy to start climbing and thatK >>> the pilot did not increase thrust soon enough before the need to climb.  >>  I >> I am not an aviation expert and should probably just stay out of this, I >> but as a point of reference, I have seen at least on story that stated L >> the initial findings of the NTSB into the December Chicago incident foundK >> that there was a measurable delay from when the pilot requested that the H >> thrust reversers deploy and when they actually deployed.  Sounds like >> software to me!!  >>   > 6 > Software tends to do the same thing every time used. > I > Hardware is much more tempermental.  There could be various mechanical  , > reasons for failures, partial or complete.   C Slip of the tongue (OK, actually, the fingers) I didn't really mean E sodtware as much as the overall system.  This kind of flaw can appear D in FW but somehow I doubt it would occur in a mechanical system thatF did the same job.  Sometimes we have technology for technology's sake.; A computer is not always the right answer to every problem.    bill   --  J 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: Tue, 11 Jul 2006 22:45:36 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> / Subject: Re: The possibility of vms opening up? , Message-ID: <44B46245.21600B5C@teksavvy.com>   Bill Gunshannon wrote:K > the initial findings of the NTSB into the December Chicago incident found J > that there was a measurable delay from when the pilot requested that theG > thrust reversers deploy and when they actually deployed.  Sounds like  > software to me!!  A If you are refering to the Southwest landing that killed a kid at H Chicago during snowstorm, it was a 737 so very little "software" becauseG the 737 is not FBW. However, there are switches that prevent deployment > of thrust reversers prior to wheels touching down OR turning.   F The initial software on the Airbus 320 had an "AND" instead of OR, andH it did cause an incident because aircraft didn't deploy thrust reversersF and brakes because the wheels were hydroplanning on wet runway and notB spinning. They changed it to an "OR" after that incident. That wasF software because it is a computer on the 320 that handles it. Not on aH 737 which is essentially 1960s technology. But this was during the firstD 2 years of the 320's life. Since about 1990, the aircraft has become? much better and now ranks right up there in terms of safety and 
 reliability.      H Deployment of thrust reversers is fatal while in the air (and there haveF been such crashes) and since then, there are many "locks" that prevent< that from happening until the plane is firmly on the ground.  G Note that the NTSB has not yet released an investigative report of this G Southwest incident, just factual info confirming the accident.  So what - you may have heard is just media speculation.     D Qantas had a policy of not using thurst reversers on its big 747s toH save on fuel costs and focused on brakes and spoilers. A pilot landed atF Bangkok during very bad rain weather and overshot the runway and endedH up in the golf course at end of runway.  Thrust reversers do not do thatC much braking, but in a tight squeeze, every bit helps.  That Qantas F pilot had not even selected the most agressive auto braking because heF was overconfindent this would be a normal landing.  Had the pilot beenH less confident and heeded warning from other pilots who had just landed,G he would have forgotten his routine and applied full braking as well as H pushed the button for auto deployment of thrust reversers as soon as the wheels touch down.  H In VMS terms, this is like doing a BACKUP/IMAGE/IGNORE=INTERLOCK of yourC system disk. Normally you do it and it works because you do it on a G quiet iddle system. But the day you must do it on a very active system, > you forget that this is dangerous and suffer the consequences.    E If you heard that in the Southwest case, the thrust reversers did not @ deploy immediatly,  it is more likely that the pilot was late inF requesting their deployment. (and there may be many reasons for that).H And the real story isn't out yet, so speculating is wrong.  The NTSB hasD to do the equivalent of a crash dump analysis of not only the flight9 recorders, but also the wreckage to determine the causes.    ------------------------------   End of INFO-VAX 2006.384 ************************