ckellems
asked on
QUSRSYS QUESTION on system i
I would like to create a multiple QUSRSYS libraries (QUSRSYSA, QUSRSYSB....) and defined each to specific groups of users (possibly via the JOBD) . Currently QUSRSYS is part of the system library list.
My question (concern) is are there any caveats to removing QUSRSYS from the system library list or concerns with creating multiple QUSRSYS Libraries?
The reasoning is to segregate the outq within each QUSRSYS.
My question (concern) is are there any caveats to removing QUSRSYS from the system library list or concerns with creating multiple QUSRSYS Libraries?
The reasoning is to segregate the outq within each QUSRSYS.
ASKER
Gary, Thanks...I guess I was asking if there are any "unintended consequences" for removing the QUSRSYS from the QSYSLIBL list.
I can see your point with creating non-OS "Q" objects. Yet I am looking for a simplified method to keep the existing outq (currently stored in QUSRSYS) when I migrate multiple systems (servers) to a single server. I was thinking of naming the QUSRSYS from machine A to QUSRSYSA on the consolidating server (as there will be about 20 different servers being moved to this consolidating server.)
Any caveats?
I can see your point with creating non-OS "Q" objects. Yet I am looking for a simplified method to keep the existing outq (currently stored in QUSRSYS) when I migrate multiple systems (servers) to a single server. I was thinking of naming the QUSRSYS from machine A to QUSRSYSA on the consolidating server (as there will be about 20 different servers being moved to this consolidating server.)
Any caveats?
Ah, server consolidation.
That's a big topic. Let me stick to the topic at hand: No, don't take QUSRSYS out of the system libl. It is the default library for creation of certain new objects, and needs to be in the system portion of the libl.
Do a WRKLIB and take a look at all the stuff in QUSRSYS (besides outqs and jobqs) - you'll see journal receivers, journals, data queues, user queues, user indexes, job schedules, validation lists, and files that are used by various system facilities, and need to be findable.
Instead, I suggest locating any user objects in QSYS, QHLPSYS, QUSRSYS, and QSYS2 on each system and getting them moved into user libraries. Then you can add the appropriate user libraries to each group.
By convention, suggest you avoid "Q" names, for user libraries.
I've done quite a few system consolidations and mergers over the years - don't hesitate to post back if you need help.
- Gary
Check out my EE profile: https://www.experts-exchange.com/M_4382324.html
That's a big topic. Let me stick to the topic at hand: No, don't take QUSRSYS out of the system libl. It is the default library for creation of certain new objects, and needs to be in the system portion of the libl.
Do a WRKLIB and take a look at all the stuff in QUSRSYS (besides outqs and jobqs) - you'll see journal receivers, journals, data queues, user queues, user indexes, job schedules, validation lists, and files that are used by various system facilities, and need to be findable.
Instead, I suggest locating any user objects in QSYS, QHLPSYS, QUSRSYS, and QSYS2 on each system and getting them moved into user libraries. Then you can add the appropriate user libraries to each group.
By convention, suggest you avoid "Q" names, for user libraries.
I've done quite a few system consolidations and mergers over the years - don't hesitate to post back if you need help.
- Gary
Check out my EE profile: https://www.experts-exchange.com/M_4382324.html
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Gary....Sage advice which I will follow. Thanks!
You can create as many OUTQs as you like, and put them in any library you like.
For example, you could have:
QUSRSYS/GROUP1 *OUTQ
QUSRSYS/GROUP2 *OUTQ
QUSRSYS/GROUP3 *OUTQ
all in QUSRSYS.
And in the various jobd's just point them to the appropriate outq.
Also "Q" library names are generally reserved for IBM use, so I'd suggest picking a different name if you do need to create dedicated libraries for each group for some reason.
Maybe if you provided a better explanation of your requirements, we can help you figure out the best practice for handling the issue.