Re: Storing Numeric Values in the Database

Chuck

All true enough and good points. The OP, however, was speaking of DSPPFM, and that also has no ORDER BY. Using RUNQRY on an LF seems never to use the access path - well, I've not tried it, actually.

And you can't run DSPPFM against a select-omit - HMMMM!

As I replied to John, I did say "almost completely" to describe my use of RUNQRY over DSPPFM. I'm usually more often interested in seeing the real-world value than in the hex value underneath. But I do like seeing the over-under - I once got a glimpse at the S/36 tools - was it called POP?

So again we use the tool we need to get our job done.

Regards and hope y'all have a good Labor Day - no working allowed here in the States, please!

Vern

On 9/2/2011 4:32 PM, CRPence wrote:

On 02-Sep-2011 08:12 , John Yeung wrote:

On Fri, Sep 2, 2011 at 10:40 AM, Vern Hamberg wrote:

Instead, I use RUNQRY - it, also, is always there, and it displays
everything as their value, not their hex representation.

But you missed a big advantage DSPPFM has over RUNQRY, which Joe
already pointed out: DSPPFM is very, very fast, and will show you
ANY record you choose (by RRN) almost instantly. RUNQRY has to load
all the records sequentially and cannot "jump" to a record. For
some files, RUNQRY is not a practical option.<<SNIP>>

Using RUNQRY of a file ["default queries" as we called them] enables
no means to include an ORDER BY clause so no specific collation can be
assumed. While arrival sequence is the most probable outcome [even if
the file named is a keyed logical file member over just one physical
member.data], the order of rows presented can not be predicted.

And while RUNQRY can assist to identify which key has a field with an
error, there is no means to see what is the actual origin for an error
such as decimal data errors whether blanks or something else in NUMERIC
type data; seeing RRN possibly only by review of some logged database
messages which may remain only when running in debug. But of course
DSPPFM is similarly worthless for reviewing the date\time types with
errors, because of the design which matches the layout to the DSPFFD
instead of the actual internal storage. Somewhat silly, since a primary
purpose of BRWPFM was to enable reviewing the hex code points that make
up the internal representation of the data in any particular RRN,
typically in response to an error that had identified that RRN.

Regards, Chuck