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...
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.