Re: Help Systems Robot Schedule...

If you don't use Help System's Robot Schedule - just delete this email....

Below is my attempt at setting up Robot security. It appears to be good for 
keeping people out, but not detailed enough to let people in. If a person is 
given authority to one job to do one thing, and then need to be given authority 
to another job to do another thing, they now have authority to do both things 
on both jobs.

(Sorry about the formatting - it looks WAY better in Word...) If you want the 
Word doc, send me an email...

I have also created an Excel sheet that has the Robot menus in hierarchical 
order...

Email: dturnidge [at] oldrepublictitle [dot] com...

How to Set Up Robot/SCHEDULE Security
The iSeries provides a security system that restricts the rights to system 
objects. Robot/SCHEDULE also provides an optional security system that can 
restrict the rights to change various Robot/SCHEDULE functions or job data. You 
must select to use the Robot/SCHEDULE security system on the General System 
Defaults dialog. This is our current standard.
Robot/SCHEDULE security uses a hierarchical system. For example, you can secure 
each menu. When a user profile is restricted at the menu level, it 
automatically restricts each option under that menu.
Sometimes there can be situations involving several objects, each of which may 
have different security restrictions. In this case, whatever set of 
restrictions is the most restrictive is used.
Whoever originally sets up a job is automatically granted all authority to the 
job. Your security officer can edit this authority at a later time.
To set up Robot/SCHEDULE security, follow the steps below:
1.      First, we need to clean all security as it now stands. This is a 
multi-step process.
a.      Remove all authority lists that may be applied to the menus. Run this 
command inside of Robot using F21 to get a command line:
RBTGRTAUT SECOBJ(*ALL)              
          AUTL(*NONE) 
          RVKUSRAUT(*ALL)           
b.      Remove all authority lists from individual jobs.
RBTGRTAUT SECOBJ(*JOB)              
          JOB(*ALL)      
          AUTL(*NONE) 
          RVKUSRAUT(*ALL)           
c.      Remove all "special" authority from jobs, that has built up over the 
years:
RBTGRTAUT SECOBJ(*JOB)             
          JOB(*ALL)      
          USER(*PUBLIC)            
          AUT(*CHANGE *ADD *DELETE)
          AUTL(*SAME)              
          RVKUSRAUT(*ALL)          
This will still grant all authority to *PUBLIC while you are preparing to shut 
things down, which is the correct status for the development machine.
d.      On previous releases of Robot, a user could start a job, and then 
cancel out before assigning a job name. This would create an orphan record that 
needs to be deleted.
To determine whether we have this problem or not, it is good to run a print 
program:
CALL RBT400
This listing will show the current status of security at all levels of Robot. 
So far, most systems have shown these bogus records. These can be identified 
because the job name will be blank, and the User Name will be a regular user 
profile name.
These records do not get cleared out by the commands above. In order to do 
this, we need to run two (actually 4) SQL statements to accomplish this. The 
first of the two will print the records that will be deleted, and the second 
actually does the deleting:
The following statement will display all the records that you will potentially 
be deleting:
SELECT substr(QRVKEY,1,12) FROM robotlib/rbtqr a WHERE substr(qrvkey,1,12) NOT 
IN (select kytime from robotlib/rbtrob b)
This should display the same records that were on the report without job names. 
If so, then follow it up with the following DELETE statement:
DELETE FROM robotlib/rbtqr a WHERE substr(qrvkey,1,12) NOT IN (select kytime 
from robotlib/rbtrob b)
After running the above commands for the RBTQR file, run the same commands, 
except for the RBTQU file as follows:
SELECT substr(QUVKEY,1,12) FROM robotlib/rbtqu a WHERE substr(quvkey,1,12) NOT 
IN (select kytime from robotlib/rbtrob b) and quojnm = 'JOBREC ' and quvkey <> 
' '
This should display the same records that were on the report without job names. 
If so, then follow it up with the following DELETE statement:
DELETE FROM robotlib/rbtqu a WHERE substr(quvkey,1,12) NOT IN (select kytime 
from robotlib/rbtrob b) and quojnm = 'JOBREC ' and quvkey <> ' '
This leaves us with *PUBLIC (that's everybody) having all authority to 
everything (if they can get to a command line to call Robot in the first 
place). Now we can assign the desired specific authorities.
2.      From the ROBOT Main Menu, select option 4. System Setup Menu.
3.      From the System Setup Menu, select option 3. Maintain Secured Objects. 
This is a list of all the secured objects from a menu level. 
4.      To start locking Robot down, from the Maintain Secured Objects go to 
Main Menu. Enter a "1" under the Opt column. This will bring you to the Edit 
Profiles for Object Authority dialog. At this point, we are not dealing with 
authorization lists, so that can be ignored.
Change *PUBLIC by putting an "X" under the Exclude column, and clear the "X" 
under the Use column. This prevents ANYONE other than those with *ALLOBJ 
authority from any access to Robot.
However, that is not our purpose. So, add DEVELOPER and SUPPORTCTR to the list 
and put an "X" under the Use column. This gives these two groups all rights to 
Robot at this level.

All instructions from this point on apply to Production systems only!

From this point on, we need to apply security to cover two scenarios:

First, SUPPORTCTR and DEVELOPER need to have Display authority to everything 
that displays information, and DO authority to all jobs.
Second, a specific user (or users) in SUPPORTCTR or DEVELOPER needs authority 
to JSL-3 and/or JSL-5 and/or JSL-9 on a specific job.
In order to do this in as efficient manner as possible, we need to start by 
setting *PUBLIC to Display Only on all menu options and jobs. Unfortunately, 
the default for options that don't have a Display authority gets set to Use. We 
will have to go back and restore the changes made previously as well as change 
inappropriate "Use" authority to "Exclude" authority.
5.      Remove all authority from *PUBLIC:
RBTGRTAUT SECOBJ(*ALL)             
          USER(*PUBLIC)            
          AUT(*DISPLAY)
RBTGRTAUT SECOBJ(*JOB)             
          JOB(*ALL)      
          USER(*PUBLIC)            
          AUT(*DISPLAY)
Change *PUBLIC Main Menu authority back to Exclude.
6.      Return to the Maintain Secured Objects dialog, and place a "1" in front 
of Secured Object item Main 1. *PUBLIC, from this point on, applies to 
SUPPORTCTR and DEVELOPER. So, we want to change *PUBLIC to have Change rights 
and not Display Only.
We need to add any profiles of users that do not have *ALLOBJ authority in 
their profiles, and need to get into these menu items. In our case, we would 
have to give the GERDES profile *Add, *Change and *Delete rights in any place 
that *PUBLIC does not have sufficient rights. The easiest way to do this is to 
use the RBTGRTAUT command to give this profile all rights to everything. Then 
we can remove those rights in menus where *PUBLIC has sufficient rights.
This change is going to have to be handled on a user by user basis. If someone 
needs to be able to change ONE job, they need to be given authority at this 
level. The rest of the jobs will have to be secured individually.
7.      So far, the easiest way to set up the security is by doing as many mass 
changes as possible, that is, defaulting *PUBLIC to Display Only, and *Add, 
*Change and *Delete rights to those that need them.
Next, starting at the top of the Maintain Secured Objects dialog, process the 
security options one screen load at a time. That is, type the number "1" in 
front of each menu item, and then press Enter and compare the security allowed 
for that item to the Excel spreadsheet titled, "Robot Menu Security," file 
name, "Robot Menus.xls," that shows the recommendations.
If the *PUBLIC authority is the same as what is given to individuals, remove 
the individuals. If it is greater than it should be, set *PUBLIC authority to 
what is should be, and leave the individual authority.

From here on down, we are presenting scenario 2.

8.      Notice that at the top of the Maintain Secured Objects dialog you have 
two options listed: 1=User Authorities and 8=Job Authorities. Option 8 works 
only with Secured Object: Specific jobs. For now, place a "1" under Opt and 
press enter. This is the Edit Profiles for Object Authority dialog. Now we want 
to allow DEVELOPER and SUPPORTCTR to have Display Only authority. We also have 
to add any individual profiles that are supposed to have authority to all 
jobs... That would be giving them Add, Change and Delete authority.
This is the only place where the "top-down" logic doesn't carry through. All 
"Specific Jobs" now give DEVELOPER and SUPPORTCTR Display Only authority. 
However, if you go to the specific job, you can give authority to anyone to 
have authority to that job. This is taken care of in the next step.
9.      If you place an "8" under Opt next to Specific jobs and press enter, 
you will see a listing of all jobs in Robot on the Secured ROBOT Jobs dialog. 
This is where individual profiles can be given authority to a job. Add the 
profile with the appropriate authority as needed. These profiles will need to 
be in either the SUPPORTCTR or DEVELOPER groups, otherwise they would have been 
prevented from getting this far in the first place.
Under Scenario2 the logic is somewhat complex. Example 1: Allow anyone on 
Support Center staff to be able to change commands in Robot job STRPRTWTR. Take 
the following steps:
1.      On Job Schedule List: Command Entry (JSL 3) give SUPPORTCTR Change 
rights.
2.      Enter an "8" on Specific jobs, and then go to job STRPRTWTR. Give 
SUPPORTCTR Change rights to that job.
Gotchas:
Ø       If SUPPORTCTR is granted rights to another job, for another purpose 
(that is, access to a different JSL option), they still have JSL 3 rights to 
that new job.
Example 2: Allow user BWELLER, who is in the SUPPORTCTR group, to set up report 
distribution for a job.
1.      On JSL 4, 9 and 12, give BWELLER Change rights.
2.      Under Specific jobs, give BWELLER Change rights to that specific job.
Gotchas:
Ø       Because of Example 1, BWELLER also has rights to JSL 3.
Ø       Again, if BWELLER is given rights to any other Robot job, she already 
has JSL 3, 4, 9 and 12 rights to that job.
Unintended Example 3: Give ALL DEVELOPER and SUPPORTCTR users rights to DO a 
Robot job.
1.      On JSL-DO, give *PUBLIC Use rights. At this level, this should give 
SUPPORTCTR and DEVELOPER rights to the DO command. 
2.      Give SUPPORTCTR and DEVELOPER Change rights at the "Specific Jobs" 
level.
Gotchas:
Ø       ALL users in the SUPPORTCTR and DEVELOPER groups have JSL-DO rights to 
all jobs AND SUPPORTCTR has JSL 3 rights to ALL jobs, and BWELLER has, in 
addition, JSL 4, 9 and 12 rights to ALL jobs.
Bottom Line:
Ø       I don't believe we can give authority to a group profile. We need to 
authorize individuals to the functions they need to do.
Ø       We need to give individual authority to individual jobs with full 
knowledge of the authority this person has to other options (JSL). 
Ø       Sheesh...