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.
ckellemsAsked:
Who is Participating?
 
Gary PattersonConnect With a Mentor VP Technology / Senior Consultant Commented:
You basic idea is sound, though.  You'll probably find yourself needing to create multiple versions of common libraries that cannot be merged - usually due to name conflicts.

Merging libs with the same name is the best strategy when possible.

Renaming libs creates all kinds of problems.

Hardcoded library names in programs (and I've occasionally seen library names stored in database files) are the big problem when doing this kind of consolidation.  We use some simple tools we built to scan objects - programs, of course, but also source members, DB2 stored procedures and UDFs, QSH and PASE scripts, Java source, table trigger constraints, and even database table columns that may contain library names used dynamically to execute programs of find files.  Journals, journal receivers, and logical files can be linked to physical files in specific named, and depending on the rename and move process, these links can get broken.

Similar issues sometimes exist in the non-QSYS parts of the IFS.

Programs that construct library names (or IFS names) based on a naming convention are even trickier to track down.

You'll also have to deal with potential device and user name conflicts, too.

Of course, a lot depends on the systems that you are merging, and now much overlap you have in library names and objects in shared libs.

And of course, test, test, test.
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
I'm not sure exactly what you are trying to accomplish, or why, but QUSRSYS, as you've noted is part of the default system library list.

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.
0
 
ckellemsAuthor Commented:
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?
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
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:  http://www.experts-exchange.com/M_4382324.html
0
 
ckellemsAuthor Commented:
Gary....Sage advice which I will follow.  Thanks!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.