Re: Using the contents of a filed for selection of the file

Avoid the limitation of the layout matching, statement length, and number of UNION clauses in the Procedure, by using the single dynamic SELECT in a UDF [User Defined Function] which outputs the selection to a report. For example, starting with CREATE FUNCTION PrtSSN(Lib Char(10), File Char(10), Fld Char(10), SSN VarChar(9)).
Or maybe [since I infer the request is to run successive reports for each file that meets the criteria,] just generate a script of SELECT statements that can then be copy/paste into the Run SQL Scripts window, from the output/results of the following SELECT statement:

select
case
when dbiitp='A'
then 'select * from ' concat dbilib concat '.' concat dbifil
concat ' where ' concat dbifld concat ' = ''123456789'';'
when dbiitp in ('B' ,'P' ,'S')
then 'select * from ' concat dbilib concat '.' concat dbifil
concat ' where ' concat dbifld concat ' = 123456789;'
else '/* ' concat dbilib concat '.' concat dbifil concat ' '
concat dbifld concat ' is neither Alpha nor Numeric */'
end
from qsys.QADBIFLD
where dbitxt like '%SSN%'
and dbilib = 'MYLIBRARY'

A decision could be made to eliminate any statements that are known by visual inspection to be redundant [versus having tried to code the query to eliminate them]. Coding a comment in the generated SELECT to include the field length could be valuable. Or code the query to eliminate rows which did not have a known-as-compatible SSN field length -- but then some hits for '%SSN%' do not appear in the list.
With implicit cast, the CASE across numeric and character should be optional, allowing just one long concatenation. Or since the script output is just character data with no column separators, the duplicated portion of the generated statement could be the first field, and only the comparison and end of statement character [and comment for ELSE] could be the second field.

Regards, Chuck