Chuck, Bravo and Amen!
Paul Nelson
Office 512-392-2577
Cell 708-670-6978
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, July 10, 2008 7:23 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Search OS/400 Physical Files
Dave Odom wrote:
Seems like the native OS "find" capabilities are WAYYY outdated and
not anything like the Windoz Search function. And it also sounds
like one must depend on utilities created for other OS's or some
other vendor's tools to accomplish a simple global function like
search global for a string which is native in most other OS's. If
true, it doesn't bode well for the IBM i. How sad.
Out from under the Norse bridge, more snide commentary instead of any
useful input on how to solve the issue presented by the OP. How sad.
<sarcasm> Way outdated.... So, so true. People are asking week after
week for such a function. This forum, USENET, and elsewhere; they are
just deluged with such requests over the years. </sarcasm>
If it were such a /simple/ function there would have been plenty of
offers for resolution already, by the many who have needed it and coded
up the correspondingly /simple/ solution. The issue is extremely
complex because the requirements from one individual to another are
always wildly different, and as an object-based system instead of the
typical /everything is a file/ architecture, the complexity grows in
defining the scope.
Even if i5/OS provided some basic function that was thought to be
generally acceptable, the same concern would occasionally recur, but
with variations on the original theme. Most notably would be all the
whining about how the search is honoring CCSIDs or not, that it is
identifying numeric data as a match to a character string that was
provided as input, that it did or did not find both numeric and
character for the hex string provided as input, that it was searching
exclusively one of only externally described, program described, or
source files, that it was searching encapsulated data but not text
attributes of the objects, that it was only searching external objects,
or that it was not searching QTEMP of other jobs -- but the list goes on
ad infinitum. So really it is probably best left to vendor tools that
can cater to some more specific desires, rather than the OS development
trying to create something to appease the majority; only to find that it
is a generally derided feature because it is so slow & cumbersome
because it is too generic in its capabilities, or just that it is not
exactly what they wanted [so they had to build or buy what they wanted
anyhow].
I am sure if someone came up with a real solid idea of what was
considered generally desirable, and there was significant support from
something like COMMON with regard to that explicit design concept, then
IBM would be willing to provide it. At least then the development would
have an idea of what goal to achieve for the customers instead of having
to decide what they think they should give to the customers; there is no
end to the complaints that all software development is guilty of the
latter. But as can be inferred from my sarcasm above, there has in my
experience, never been much of a calling for any such function, because
what few requests are published have typically been easily solved by an
existing [and yes, often non-native client-based] features.
Perhaps someone could start by diagramming what might be a
representative command interface to do what might be considered the most
commonly required function. I am sure it would soon become obvious just
how /simple/ it is when more than one person provides input.
Regards, Chuck
midrange.com
