Sounds like a case for dynamic SQL to me. No file definition at all. Each routine (Rtn37) builds the sql it needs to get to the file. All keyfield sizes, etc are abstracted away into the dynamic select or insert.
Still, I'd make it modular. Compile each Rtn as it's own NOMAIN module. Then maintenance on one routine requires only re-compiling that module and rebinding the service program. Yes, I'd make PgmB a service program. Export all the routine names.
All those routines will need protypes in PgmA. Great use for /COPY. Use the same prototype within the module file in each routine that will be in PgmB in the source for PgmA.
I think I'd look for a way to gather some of those files into a smaller set of files where records have similar characteristics. You can sparsely load columns in the file if needed (null when a particular type of record doesn't have a 5.3 keyfield for
example). Let the database do a lot of the work for you. Include a "type" column. So your selects look like:
SELECT templateField from FileA where type='Rtn37' and decimalColumn = 5.7 and stringColumn='Some Value'
SELECT templateField from FileA where type='Rtn38' and integerColumn = 22 and stringColumn='Hello'
Receive the SQL results into a data area you can differentiate for the result sets from the query. Each module has its own data area. Keep the size of the PASA down by ALLOC'ing the memory for the data area before the call and deleting it after.
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact