Just one way, but you can avoid needing an override most of the time. <BR>
Unless your shop explicitly excludes changing IBM shipped objects...

Sure, CHGPRTF would be a lesser hassle if one could come up with a width that would satisfy everybody. Another possible workaround would be an application wrapper around STRQMQRY command to make the system submit a batch job with a printer file override issued immediately before starting the query. I have written such a thing to bundle STRQMQRY with an MMAIL e-mail generator and Gary Guthrie's output queue monitor with a DREAM Writer front end (we are a JD Edwards shop). A processing option instructs the server to override the printer file to the specified width. It's all good, but I was wondering if I was actually overlooking a system provided solution. Apparently not...

I use Query Manager queries as a quick and very convenient SQL and reporting tool. One slight issue I am having with the product is the lack of an option to dynamically change the width of printed form (the capability Query/400 provides). I have not found a better work around than to issue an override to printer file QPQXPRTF before running the query either interactively or from a CL program. That still does not solve my problem when I am to run my query with a specified form width in batch. As a result, the output comes sliced into two or more parts vertically once its width exceeds 80 characters (the default page width of file QPQXPRTF). I still feel I may be missing something since the problem is so obvious it could not have been overlooked by QM product designers. I will appreciate your tips.