Possible Issues When SGI* User Profiles MAXSTG Set Too Low
Product: Strategi
Modified Date:

When iSeries 400 user profiles are created, they usually have their MAXSTG (Maximum Storage Allowed) parameter set to *NOMAX. Some iSeries 400 administrators have a policy of setting this to some specific level for certain user profiles. If the SGICUSSPT, SGIHSMSVR, SGIJOBCTL, or SGIOBJOWN profiles, or profiles used to administer Strategi, have a MAXSTG set too low, certain problems may arise.

Problems when MAXSTG set too low for SGIHSMSVR
If SGIHSMSVR has a MAXSTG limit set, it is possible that not all HSM Servers will start properly, but instead will go into a status of MSGW with a joblog similar to the following: 

>> CALL PGM(SGI131) PARM('SOMESVR')
   Authority *ALL or *AUTL revoked from *PUBLIC.
   Authority given to user *PUBLIC for object ABLUSRINF in QTEMP object 
   type *DTAARA.
   Cannot resolve to object HSSOMESVR. Type and Subtype X'0A02' Authority X'0000'.
   Function check. MCH3401 unmonitored by QC2UTIL1 at statement 0000000035, 
   instruction X'0000'.
   The call to HSMRCVRQS ended in error (C G D F).
This happens because as the HSM server initializes its context with the HSM service program, it must create a USRQ object. This USRQ will be owned by the user profile under which the HSM server job is running, usually SGIHSMSVR. If enough other HSM servers are running that the amount of storage taken by their USRQs exceeds the MAXSTG limit for the SGIHSMSVR user profile, the server will not be able create the USRQ. It seems that this failure to create is a silent failure-- OS/400 does not send an error to the service program. But when the service program attempts to use that USRQ, the "Cannot resolve..." error results. To resolve this problem, one of two things can be done. Either SGIHSMSVR can be set with a MAXSTG limit of *NOMAX, or its MAXSTG limit can be increased until the server is able to start. When the USRQ is created for an HSM server, it is usually 1,056,768 bytes in size. However, this can increase as the HSM server is used, to as high as possibly 16 megabytes. Thus, it may be necessary to up the MAXSTG by at least 16 megs.

Problems when MAXSTG set too low for SGICUSSPT
If SGICUSSPT or any other profile used interactively has a MAXSTG limit set too low, they may not be able to run commands such as ENDHSMSVR and CHKHSMSVR. Such commands act as a client to the HSM servers they are run against, and in order to make HSM requests to stop or ping the HSM server, they must create a temporary USRQ. Similarly to the problems starting HSM servers, this command will fail with messages similar to the following: 

>> CHKHSMSVR *SYSTEM
   Cannot resolve to object HS00000133. Type and Subtype X'0A02' 
   Authority X'0000'.
   Function check. MCH3401 unmonitored by QC2UTIL1 at statement 0000000035, 
   instruction X'0000'.
   Function check. MCH3401 unmonitored by QC2UTIL1 at statement 0000000035, 
   instruction X'0000'.
As with SGIHSMSVR, to resolve this problem, SGICUSSPT or the user profile in question should have MAXSTG set to either *NOMAX, or increased by at least 16 megs.

Problems when MAXSTG set too low for SGIJOBCTL or SGIOBJOWN
If SGIJOBCTL or SGIOBJOWN have MAXSTG limits set too low, Strategi as a whole may not run properly or may not run at all. It is highly recommended that these profiles be set with a MAXSTG of *NOMAX. It would be very difficult to determine in advance how much storage is needed by the profiles, as usage of the system, creation of Strategi users, websites, zones, and other entities within Strategi, may all increase the requirements for each profile.

** End of Technical Support Bulletin **