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
+---