×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 24 Oct 2012 14:10, Vinay Gavankar wrote:
I want to use Query or SEQUEL (cannot run SQL on production box), to
identify any records in a file, that have fields with non-printable
characters.
Without having to define every printable character I see in the
EBCDIC table in my query, what would be the best way to do this?
Define "cannot run SQL on production box". Does that mean STRSQL is
not available? If that is what is presumed to be preventive for running
SQL, then that is a false inference. There are many ways to use\run SQL
besides via STRSQL. Anyhow...
Create a translate table which maps all of the decidedly "printable
characters" to the same weight, to a blank [i.e. x'40']. What that list
of characters is unknown or at least ill-defined to us, the readers;
i.e. outside whatever are your thoughts [not yet] expressed on the
matter. With Query/400 specify that conversion\translation table in the
Define Collating Sequence [4=xlate table], and be sure the processing
option is set to apply the collating sequence generally to the
comparison against the string of one blank. In this manner, a
comparison to the single blank is padded with blanks for comparison with
either blanks or non-printable characters; request records where the
string is not equal to the blank... because all printable characters
were mapped to blank. Of course an inverse translate table with a
negative of that predicate is just as workable.
There are other means to do similar, but that all depends on what the
real goal is. While the task described is fairly specific, that task
might not closely reflect the actual overall intent. For example one
might intend to prevent "non-printable" characters from being spooled,
so as to prevent printer issues. However in that case, probably better
to use the RPLUNPRT [Replace Unprintable characters] feature of the
printer file rather than the database. Other specifics of the scenario
including how many fields and records may influence what might be
considered as perhaps /better/ means to accomplish the desired goal, if
indeed the specific task may not reflect the exact goal.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.