× 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.