Question & Answer
Question
Customer was unsure of the usage of common global variable AOFSMARTMAT, and also wanted clarification of SMP/E ++HOLDDATA regarding how to refresh SA z/OS message automation table after various PTFs mentioning AOFSMARTMAT are installed.
Answer
The essence of the AOFSMARTMAT variable is whether the SA EMM (Easy Message Management) feature is enabled.
There are 4 possible settings for SA z/OS variable AOFSMARTMAT:
AOFSMARTMAT Value | EMM Status | Message Table Refresh | MRT (Msg Revision) Activation/Status |
0 | off | disabled | off |
1 | on | enabled | off |
2 | on | enabled | off |
3 | on | enabled | on |
To query current AOFSMARTMAT variable setting enter NetView command and review the output:
QRYGLOBL VARS=AOFSMARTMAT.
The AOFSMARTMAT default setting is 2.
To expand on SA z/OS operational characteristics, following is:
1) a description of the different settings
2) why this variable may be mentioned in a PTF ++HOLDDATA
AOFSMARTMAT Settings
The answer to (1) is related to whether customers employ EMM or whether they manually create their own message table from SA z/OS samples.
Most customers will use the default AOFSMARTMAT setting of '2', which means SA is building a message table when the SA TSO/ISPF dialog 'build' process is invoked, and the output message table will be a member named "ACF*99**" in the build output file. This message table will contain all of the built in SA requirements and all MESSAGES entries in locally defined in the customer SA PDB policy.
For customers who do not use EMM then they have created their own table and the local table would be named INGMSG02. Clients would use a one-time SA PDB build to create an SA message table as above and rename that to INGMSG02.
At the appropriate point in SA z/OS master message table INGMSG01 when SA sees the statement '%INCLUDE INGMSG02' it then determines whether EMM is used or not, and if yes, then in loads the PDB-built table, whereas it loads the manually created INGMSG02 if EMM is not used.
And to add one more part to this, there is interaction between AOFSMARTMAT and INGAMS REFRESH. This relates to message table refresh, the item (2) which was mentioned above (what is the relationship between AOFSMARTMAT and certain PTFs).
With AOFSMARTMAT set to either 1 or 2 or 3, then SA will automatically refresh INGMSG01 and any other msg tables you define in the policy for each system when INGAMS REFRESH is performed. The net is that INGAMS REFRESH can then allow activation of any message table changes and PDB changes at the same time, which does not happen if you use AOFSMARTMAT = 0. In that case you must manually refresh the message table(s) (which are defined in the SA system entry of the PDB) using ACF ATLOAD for example.
With AOFSMARTMAT set to 3, then all of the above detail regarding message table usage and refresh is still the same, with the added function of MRT activation as well. With '3' for AOFSMARTMAT, then SA will attempt to activate the MRT table that it builds as part of the build process. This file will be named ACFRZ9nn in the customer SA PDB build output file and contain appropriate MRT statements.
The last information to add here is how customers can set the variable AOFSMARTMAT (or any of the allowed SA common globals) if they do not want the default, or if they want to ensure it is set to '2' locally.
One can either use the sample SA z/OS AOFEXDEF startup exit, or the style method to set them.
Option A: AOFEXDEF
AOFEXDEF is copied from SINGSAMP to a local DSICLD dataset and one can use the NetView rexx "GLOBALV PUTC" command to save the desired value of AOFSMARTMAT during initialization if that approach is preferred.
Option B: Style Definition
COMMON.AOFSMARTMAT = n (n = 0,1,2,3)
The expression "COMMON.varname = value" is used in the style method, and in that scenario, any CxxSTYLE member or one of its %INCLUDE files can contain these 'COMMON' definitions, such as the INGSTGEN sample member provided in the SINGSAMP dataset. INGSTGEN is typically copied from SINGSAMP and added as a %INCLUDE file in the local style sheet so users can put their specific SA z/OS style customizations in this member.
Either method (exit or style) is fine and is completely acceptable, should there be any SA common global variables that one needs to set in this fashion. However customers should take care to ensure that there is no conflict or overlap between common global values that may be defined in both places erroneously.
AOFSMARTMAT/INGMSG01 in SMP/E ++HOLDDATA
The last point here is that any advice or PTF ++HOLDDATA where AOFSMARTMAT is quoted, is merely indicating that the SA sample message table entries are updated, and that you need to refresh the INGMSG01 and/or INGMSGSA tables to activate the changes. The ++HOLDDATA is cautioning you that the actions needed locally to do so will differ depending on the specific setting of AOFSMARTMAT, in relation to EMM (is it on or off) and therefore whether INGAMS REFRESH will refresh the message tables for you.
The net of using the default AOFSMARTMAT=2 (or the setting '3') means that to activate SA z/OS supplied message table changes then all one needs to do after such a PTF is installed is perform a SA ISPF dialog "BUILD" followed by INGAMS REFRESH. By taking these steps the new SA message table changes introduced via the PTF would now be activated.
For customers using AOFSMARTMAT=0/1 then they need to perform command ACF ATLOAD to initiate the message table refresh, after reviewing the changes introduced to determine if they may need to update their local 'INGMSG02' table in some fashion.
Related Information
[{"Product":{"code":"SSWRCJ","label":"IBM Tivoli System Automation for z\/OS"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"--","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Historical Number
65764;422;000
Product Synonym
SA SAz SAzOS SAfzOS
Was this topic helpful?
Document Information
Modified date:
08 August 2018
UID
swg21329642