Re: Storing Numeric Values in the Database

Yet I was contrasting the two tools [DSPPFM vs RUNQRY QRY(*NONE)] for their ability to present data as RRNs, which is likely very relevant to most users with regard to displaying the data in a member.

The point in mentioning "no ORDER BY" is of course, to emphasize that the order of rows returned by a RUNQRY QRY(*NONE) is undefined and thus unpredictable. That remains factual, no matter that most will have falsely inferred the results will always be in "arrival sequence". Very many times I had to explain to a customer that the "defect" they were reporting for a change in order of rows was instead a usage-error, because their query request did not include ordering; a query which [at least seemed] to have long given arrival sequence results, suddenly would no longer. As long as the user of RUNQRY QRY(*NONE) for the purpose of displaying physical data understands that [and other nuances], then I agree that the RUNQRY can be a great tool for them, either along with or instead of DSPPFM.

With DSPPFM the order is defined-as and thus known to be in "arrival sequence". That the data returned from RUNQRY may not reflect the physical-order conflicts with the typical expectation for viewing the physical data. Without physical order, identifying a particular row requires tracking to a primary or unique key. And while DSPPFM has its own issue for not representing the deleted rows relative to the active rows, at least there is feedback for which active row remains presented at the top of the displayed data. And with DSPPFM the relative or direct positioning input field can be used to request that the specific, previous, or next RRN be presented as the first row of the displayed data; the actual RRN that was found is then shown in the feedback above the data\rows.

FWiW RUNQRY [using CQE] does honor the select\omit [both of the index and dynamic] of the access path for the LFM named on the QRYFILE [or in the *QRYDFN], but again, order is undefined both for RUNQRY QRY(*NONE) and for a *QRYDFN with no sort field specifications [aka "no ORDER BY"].

Regards, Chuck

On 02-Sep-2011 16:41 , Vern Hamberg wrote:

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!

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.