Hi Jim,
I agree that would be the correct approach and if I could do that I would have it implemented today.
Unfortunately, this is not an option for me. One of the reasons is money. Our environment is hosted externally and having a second partition would mean we are gonna have to pay more. Besides the cost of the partition itself, I believe there was also extra license costs if we used more partitions.
A second concern was making sure all communications and version control that we currently have in place between the different environments would still work when it was on two partitions. I know all of this is technically possible and not that hard to implement, but some people in my organisation are afraid of any form of change. Maybe one day I will be able to convince them, but I don’t see that happening any time soon.
So besides creating a second partition, would there be any way to implement what I was trying to do?
Erwin Donker
Van: Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
Verzonden: dinsdag 15 oktober 2019 16:09
Aan: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
CC: Erwin Donker <erwin.donker@xxxxxxxxxx>
Onderwerp: Re: Limiting QSYSOPR access to own jobs
Maybe the correct approach would be to separate the test/production environments into separate partitions?
IBM i can host IBM i quite easily. You can set up the DEV partition to be the size you need it to be and then you'll achieve your goal.
It's a matter of creating the partition definition.
Create virtual devices for disk hosting on primary partition
Create virtual disk units
Attach them
Create an Ethernet Bridge on primary
build new partition
Save/Restore the development libraries onto DEV
Done.
Complete separation. If your interested I can post the CL program to create most of it.
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
On Tue, Oct 15, 2019 at 7:53 AM Erwin Donker via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>> wrote:
Hi,
On our (V7R3) system we have the production and development environments on the same partition using different libraries. When there is an error in a job that requires a reply, the message is sent to the QSYSOPR message queue. When a developer is testing a change or reproducing a reported incident, there will be messages in QSYSOPR from this test that the developer has to be able to answer himself. Since our end-users don't have a command line, giving *PUBLIC authority to answer messages in QSYSOPR gave the developers the authorization they needed.
However, this also means they have access to answering production jobs and other messages in QSYSOPR. I don't want them to have this access, so i am looking for a way to revoke their access to QSYSOPR message queue, but at the same time be able to answer any messages that appear in jobs they have started themselves.
The only information I found so far is
https://www.ibm.com/support/pages/restricting-users-qsysopr-message-queue but that also blocks their ability to answer their own jobs. Is there any way to accomplish what I want? Or, alternatively, is there a way to have certain messages go to another MSQG (for instance based on the user, jobq, jobd, library, etc.)? The only thing I was able to find in this regard was
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzahb/rzahbqueuesman.htm .
Thanks in advance for your replies.
Kind regards,
Erwin Donker
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op:
http://www.denhaag.nl/disclaimer
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx<mailto:support@xxxxxxxxxxxx> for any subscription related questions.
Help support midrange.com<
http://midrange.com> by shopping at amazon.com<
http://amazon.com> with our affiliate link:
https://amazon.midrange.com
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op:
http://www.denhaag.nl/disclaimer
midrange.com
