MOMI is initially launched via a TACL obey file to start the main $MOMI process. This process starts other processes that support the MOMI environment.
When a user 'logs on' to a MOMI PC Client, a logon server process is launched that assumes given User ID. If it is necessary to perform a sensitive command, such as viewing a Spooler Job, a process is launched from the logon server to perform the sensitive commands under the users authority and not under the authority of the main $MOMI process.
MOMI does NOT contain privileged code so it does NOT require to be licensed via FUP. However, certain Operating System functions require additional levels of authority. MOMI obtains this authority via the object file BWSSG (discussed below). BWSSG is manually created by the System Administrator during installation.
There are three general User ID classifications. Super.Super (i.e. 255,255), Super.Group (i.e. 255,*) and all other "normal" User ID's. You should consider starting MOMI under a "normal" User ID, perhaps one specifically created for MOMI. However, the use of SAFEGUARD or SQL/MP may require that you operate MOMI under a higher level of authority.
Below are the security guidelines:
The BWMOMI executable
Must be secured to allow Execute for all users. For example, a Guardian security string of "UUNU". Additionally, in order to allow the creation of SAVEABEND files (used in troubleshooting), READ access should also be considered for a resulting security string of "NUNU".
The BWMOMI executable Super Group helper
Performs TCP/IP "Ping" or the ICMP Echo command and adjustment of System time (if enabled)
Must be secured to allow Execute for all users and PROGID to a Super.Group user for TNS/R systems and Super.Super for TNS/E systems. For example, a Guardian security string of "UUNU". Additionally, in order to allow the creation of SAVEABEND files (used in troubleshooting), READ access should also be considered for a resulting security string of "NUNU".
This server is not used if MOMI is started under Super.Super.
MOMI creates several work files in the subvolume where the object resides. The User ID MOMI runs under must have read/write/execute/purge/create access in this subvolume. It is suggested that SAFEGUARD is not used for this subvolume.
MOMI must be given read/write/create access to the subvolume(s) specified for the history files.
MOMI makes extensive use of MEASURE . These files must allow read/execute access.
EMS distributor program.
Must allow execute access.
EMS log file subvolume
In order to display EMS messages from $0, the EMS log files must allow read access. Use EMSCINFO $0 to display the current EMS log file settings and EMSCCTRL $0,<command> to alter the settings within $0. Existing EMS log files will need to have their file security altered via FUP.
Virtual memory access utility
MOMI uses this to report on virtual memory usage. The file must allow execute access.
O/S release information (i.e. G06.29.02)
Must allow read access.
SQL/MP compilation utility
The display of SQL/MP information is the result of dynamic SQL statements. This file must allow read/execute access.
MOMI provides SQL/MP information by reading this subsystem's catalogs. MOMI needs read access to all the catalogs on the system, particularly to the Catalog of the System, to provide information on the SQL/MP screens.
EMS HTML cause/effect/recovery information
MOMI makes use of this file to display EMS cause/effect/recovery information. MOMI needs read access to this file.
(This file is not found on pre-S-series systems.)
EMS user defined cause/effect/recovery information
MOMI makes use of this file to display EMS user defined cause/effect/recovery information. MOMI needs read access to this file. Additionally, a user may also logon and if they have proper security edit this file. The location of this file may be overridden with the CONFMOMI keyword EVENTCX.