|
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:Using RUNQRY of a file ["default queries" as we called them]
Instead, I use RUNQRY - it, also, is always there, and itBut you missed a big advantage DSPPFM has over RUNQRY, which Joe
displays everything as their value, not their hex
representation.
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>>
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.