|
Hi JamesI don't know exactly what circumstances your program is intended to be used in, but doing a blind ADDLIBLE like this is one of my pet hates (don't take it personally :) ).
To my way of thinking if you do an ADDLIBLE then you ought to add a corresponding RMVLIBLE to ensure that the job is left in the same state it was when your program was called.
Further, you also need to know whether the ADDLIBLE failed because the library was in the list already so that you can condition the RMVLIBLE operation to only be executed of the library was added by your program. If it was already in the list then you don't want to remove it.
It may well be that this is totally inapplicable in your case, but I have seen quite a few weird failures over the years where programs meddled with library lists without considering the impact on any subsequent programs calls later on in the job.
Regards Evan Harris At 02:26 p.m. 25/11/2006, you wrote:
The USROPN route seems to have solved the problem. And as to calling ADDLIBLE, after a bit of experimentation, I found that prototyping and calling the C "system()" function was better suited to the problems at hand than calling "QCMDEXC," since "system()" doesn't blow up if the command fails (and since, barring an authority problem that likely would have blown things up already, it could only fail if the library were already ON the *LIBL, we don't give a rodent's defecatory orifice about whether it succeeds or fails). Thanks to all. Have a nice weekend. -- JHHL --
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
