RE: Floating Point Question

That sounds like something very interesting. Do you have some examples
for us mere mortals.

>>> -----Original Message-----
>>> From: Nelson C. Smith [mailto:ncsmith@gate.net]
>>> Sent: Friday, August 13, 1999 4:48 AM
>>> To: MIDRANGE-L@midrange.com
>>> Subject: Re: Floating Point Question
>>> 
>>> 
>>> Yes, I have a big alpha field containing the result of a 
>>> substring out of a
>>> record data structure.  It contains whatever real data was 
>>> in the record at
>>> the field position.  The QADBIATR file tells me the data type, size,
>>> location, etc, of the field, which controls the subst 
>>> parameters.  It is
>>> being used to create Where statements on the fly inside a 
>>> single generic SQL
>>> copy member used for all files. Once I have the actual 
>>> field data in a
>>> generically-named floating point field, I should be able to 
>>> make a key out
>>> of it. i.e. "WHERE pi = 3.14" .  I think the basing pointer 
>>> method will do
>>> just what I need.  Thanks!
>>> 
>>> I didn't use that method or the movel method for packed 
>>> fields because I
>>> didn't want to have to choose between 900 different packed 
>>> field sizes.  For
>>> them, I just counted bits and put the numbers, decimal point, & sign
>>> directly into an alpha field.  Every other type seems to 
>>> work ok with the
>>> Movel (I haven't gotten to blobs yet, but I assume they 
>>> will work like
>>> varchars).
>>> 
>>> I haven't worked with floating point enough to know what 
>>> they really look
>>> like in hex. I don't have any fields I actually need at the 
>>> moment, but I
>>> wanted my generic procedure to be able to handle any field 
>>> that comes at it.
>>> The floating point data types are currently starred-out as 
>>> the only ones it
>>> can't handle.  I think this will fix it.  Thanks again.
>>> 
>>> BTW Barbara, the only reason I got into all this is due to 
>>> your tip of a
>>> month or two ago (about using procedure pointers as a 
>>> system pointer), that
>>> allowed me to build completely dynamic SQL IO modules and 
>>> triggers.  I now
>>> have a single trigger and a single IO module that handle 
>>> any file defined to
>>> them.  They fire up the specific service program containing 
>>> the specific
>>> file-handling procedure, find the procedure's address and 
>>> then call the
>>> procedure for the actual processing.  Pointers to the file 
>>> data and trigger
>>> buffers get passed all up and down the call stack and the 
>>> whole thing works
>>> so smooth I can hardly believe it.  Is this the kind of 
>>> stuff ya'll get to
>>> play with at the lab all the time?
>>> 
>>> I currently have about 40 files in production using them, but I keep
>>> tinkering with them, of course.  I can foresee someday 
>>> eliminating all
>>> external F-specs from my programs.  Of course, they just 
>>> get replaced by
>>> externally-defined data structures, but at least the files 
>>> are out of the
>>> programs.  I've always preached that "programs don't need 
>>> files, programs
>>> need data".  When you eliminate the files, you eliminate 
>>> about 80% of the
>>> maintenance problems. Thanks to you, I'm finally getting 
>>> there.  The last
>>> few frontiers I'm playing with are floats and blobs and 
>>> they aren't holding
>>> back real production, yet. I'm still waiting to see what 
>>> the trigger buffer
>>> looks like with a few blobs in it. Will the whole field be 
>>> there or just
>>> some kind of pointer to it?
>>> 
>>> You've created a monster here....
>>> 
>>> -----Original Message-----
>>> From: bmorris@ca.ibm.com <bmorris@ca.ibm.com>
>>> To: undisclosed-recipients:; <undisclosed-recipients:;>
>>> Date: Thursday, August 12, 1999 9:32 AM
>>> Subject: Re: Floating Point Question
>>> 
>>> >----------------------------- B -----------------------------
>>> >If you mean that you have 8 bytes containing an actual 
>>> floating point
>>> >value, use a based 8F variable, and set its basing pointer 
>>> to the address
>>> >of the char field.
>>> >
>>> >D floatVal        s              8f
>>> >D basedFloat      s              8f   based(pFloat)
>>> >D rec             s           1000a
>>> >
>>> > * Get the floating point value at offset "off" in field "rec"
>>> > * into the float field "floatVal"
>>> >C                   eval     pFloat = %addr(rec) + off
>>> >C                   eval     floatVal = basedFloat
>>> >C                   seton
>>> >
>>> >I'm guessing the second case is correct.  If so, I'd use 
>>> this technique for
>>> >all the types, using a based data structure with a 
>>> subfield starting at
>>> >position 1 for each possible type.  Set your basing 
>>> pointer to the address
>>> >of the record + the offset, then just assign from one of the based
>>> subfields.
>>> >
>>> >Barbara Morris
>>> >
>>> 
>>> +---
>>> | This is the Midrange System Mailing List!
>>> | To submit a new message, send your mail to 
>>> MIDRANGE-L@midrange.com.
>>> | To subscribe to this list send email to 
>>> MIDRANGE-L-SUB@midrange.com.
>>> | To unsubscribe from this list send email to 
>>> MIDRANGE-L-UNSUB@midrange.com.
>>> | Questions should be directed to the list owner/operator: 
>>> david@midrange.com
>>> +---
>>> 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---