×
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.
Brian,
Actually ,this is a perfect scenario for "Group jobs" ... :-)
That's exactly what "group jobs" was invented for, back on S/38 CPF ... ;-)
Each job in a "group job" has its own library list, etc. -- even it's own set of Activation Groups ... because they are real, independent jobs, but the OS manages them as a "group" and allows an interactive user to quickly and easily jump between them.
Contact me "off-list" and I can supply sample code that you can use to "wrapper" any set of programs and carve it up into "group jobs." ;-)
All the best,
Mark S. Waterbury
On Thursday, May 6, 2021, 11:27:24 AM EDT, Brian Garland via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
Jon,
I understand and agree with the DAG issue. I'm eating the proverbial
elephant here.
You are correct regarding the reason for putting service programs in a
named group - it was to prevent them from going away.
Most users never switch their library lists so that was working. We have a
few users jumping between environments and want to make this work without
signing off. And, even those that jump between environments will run
multiple commands in each environment so I think having the service
programs in one activation group still makes sense.
I'll have to work on getting our CLLE into a named activation group
(instead of *NEW) and converting our CLP to CLLE. A bit of a long-term
project.
--
Brian J. Garland
Vermont Information Processing, Inc.
brian.garland@xxxxxxxxxx
midrange.com
