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



IMO the PRTTXT seems inappropriate to use in that manner. The print text setting would seem more appropriately classified as an effect, not as an indication, of the application environment that was established. Its use requires that there is prevention of any CHGJOB JOB(*) PRTTXT(another_value) activity within any existing or new [future additions to] invocations made by the application, when not used explicitly for changing the environment. Preventing the use of that command to change the print text is more difficult to ensure, or to predict its [mis]use, as compared to just changing some storage owned only by the application. IMO the application environment should be stored elsewhere, precluding any need to have the print text value retrieved.

Regardless, if the QUSRJOBI API [or the equivalent in keyed API, either Retrieve Current Attributes (QWCRTVCA) or Retrieve Thread Attribute (QWTRTVTA) API retrieves), or RTVJOBA] is not desirable for retrieval of the app environment then, again, why not just store the environment detail in another place? In so doing, the value would still be stored only once IMO, considering the PRTTXT as an effect. Choose the alternate [or /additional/] location that would enable a\the most preferable method of retrieval of the active application environment details. My preference is an input parameter when possible [tell the application what to do rather than the application inferring\divining what to do], but there are others such as an environment variable, a data area, a row of a database file, a held lock, etc..

Regards, Chuck

James H. H. Lampert wrote:
Last month, I had a question about a keyed union of enrollment files for multiple separate environment libraries of an application.

It turned out to be much easier to accomplish the goal by switching to a single enrollment file in the application library, with the environment added as a leading key to it and all its logicals.

But that opens another can of worms: now I have programs that need to know which environment they're running in. Easy enough if the program opens a file in the environment library, but not so easy if it doesn't.

But for a variety of other reasons, the application already sets the Print Text of every one of its jobs to the environment library and TCP port it's using. (Among other things, it makes it easy to find the server jobs using a particular environment, so they can be held, serviced, or terminated.)

Obviously, I can get the print text from a call to QUSRJOBI, format JOBI0400, but is there another way to get it?

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.