We are looking at implementing security in our Glovia install. If I use $SECFN to set a functions security level it only seems to stick until that function is regened. Then it reverts back to 1 or blank. If the level is changed in function maintenance it keeps that level. What use is $SECFN if it only last until the function is regened? Is this how $SECFN is supposed to work? Thanks

$SECFN
Started by
Gregg Barr
, Apr 25 2002 04:37 PM
7 replies to this topic
#2
Posted 25 April 2002 - 04:44 PM
Hi,
Superlayer 'rebuilds' the function everytime you gen a superlayer function. It first removes the function in native and then recreates it.
This means that it will overwrite any settings in $SECFN when you gen the superlayer function.
I dont know if there is an equivalent function to $SECFN in superlayer (I dont use it), maybe someone else knows.
Rob D
Superlayer 'rebuilds' the function everytime you gen a superlayer function. It first removes the function in native and then recreates it.
This means that it will overwrite any settings in $SECFN when you gen the superlayer function.
I dont know if there is an equivalent function to $SECFN in superlayer (I dont use it), maybe someone else knows.
Rob D
#5
Posted 26 April 2002 - 01:14 PM
On our system when I type $SECFN it does run SLSECFNS. Changes made here only change the Native. If you make a change in SLSECFNS and then look at the function in SLM the level does not reflect the change made in SLSECFNS. As we are just beginning to implement security I really don't like the idea of going into each function, changing the security level and regening. I don't like the fact the change date will be reset on the glovia function when nothing really changed. What do most Glovia users do? Use SLSECFNS to change the native level and then document the change so if that function is ever regened go back into SLSECFNS and change it back?
#6
Posted 26 April 2002 - 01:42 PM
Gregg,
I never tested out the level of security... and you are correct, when you change the level, only native is changed. However, when you change the category, it changes both SL and Native. Keeping this in mind, you could define categories that represent different levels such as: APHIGH, APMED, APLOW. This technique can get a little messy because you will end up with a s**t load of categories, but it is another option.
I am also just implementing security and would like to know the purpose of operator groups. You can define a group and assign a group to an operator, but nowhere can you define what categories apply to groups??? Maybe I am missing something... do you know?
George
I never tested out the level of security... and you are correct, when you change the level, only native is changed. However, when you change the category, it changes both SL and Native. Keeping this in mind, you could define categories that represent different levels such as: APHIGH, APMED, APLOW. This technique can get a little messy because you will end up with a s**t load of categories, but it is another option.
I am also just implementing security and would like to know the purpose of operator groups. You can define a group and assign a group to an operator, but nowhere can you define what categories apply to groups??? Maybe I am missing something... do you know?
George
#7
Posted 26 April 2002 - 03:41 PM
I'm not sure if its available in Glovia but in Chess v3.20
the function XUFNSAVS can be used to save spooler, security and production flags for all functions at the Pro-IV level.
The function XUFNRSTS can be used to restore. Both of these functions are on the XUTIL menu. I would think there is something similar in Glovia!
the function XUFNSAVS can be used to save spooler, security and production flags for all functions at the Pro-IV level.
The function XUFNRSTS can be used to restore. Both of these functions are on the XUTIL menu. I would think there is something similar in Glovia!
#8
Posted 28 April 2005 - 04:12 PM
Groups are used to maintain operator categories en-masse. If you have "ACCT" group, and add a new function/file security, you can apply it via SLOPRACS (either enable or disable) to them all at once.
Or, if you use * instead of a group name, you will apply to all operator IDs in the system.
Its a pain to maintain, and after time it seems users get cross-overs into other categories that dont fit the group profile, but.. that's another topic.
Or, if you use * instead of a group name, you will apply to all operator IDs in the system.
Its a pain to maintain, and after time it seems users get cross-overs into other categories that dont fit the group profile, but.. that's another topic.
Reply to this topic

0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users