ACCEPT Abuse By Carolyn I. Conner The concept of the SMPE ACCEPT process is often misunderstood. It is often viewed as an optional clean-up step of SMPE to be done after a function or maintenance install. ACCEPT processing is not an optional task to be done when it is convenient, but is an integral part of system maintenance. Timing is the key to ACCEPT processing. The question is not if a system function or product maintenance should be ACCEPTed, but when to ACCEPT it. ACCEPT processing is generally done after an SMPE APPLY. There are, however, some instances when the APPLY is skipped or done after the ACCEPT processing is complete. These special SMPE methods are used for the installation of functions. An example of one method is RECEIVE-ACCEPT-STAGE 1 GENERATION-JCLIN-SMPE GENERATE, which is used by IBMþs Custom-Built Installation Process Offering (CBIPO) to create a new system or replace an existing system. This method bypasses the APPLY process entirely with the use of BYPASS (APPLYCHECK) on the ACCEPT command. The sysmods are placed directly in the SMPE distribution data sets without updating any target data sets. The target data sets are updated during the STAGE 1 GENERATE and SMPE GENERATE steps of the process. Whenever one of these special SMPE methods is required, the function installation documentation will guide the user through the process. The most commonly used SMPE method of function and product maintenance installation is RECEIVE-APPLY-ACCEPT processing. This method is used when the installation is straightforward and does not require a system generation [i.e., the IBM Custom-Built Product Delivery Offering (CBPDO), which is used to add new functions and maintenance to an existing system]. It is during this SMPE method that the ACCEPT process can be misused. ACCEPT processing permanently updates the distribution data sets to reflect what exists in the target libraries. SMPE then can use the distribution data sets as a backup for the target data sets to be used in SMPE RESTORE processing. ACCEPT also does some clean up by deleting the RELFILEs (temporary storage containing the function sysmods) that are created during a function install, deleting the MCS (the sysmod that is RECEIVEd from the SMPPTFIN data set) from the PTS data set and deleting the sysmod entries from the SMPE global zone. It is important to remember that when an ACCEPT is done, there is no SMPE method to back out this update from the distribution data sets. If the changes cannot be backed out after an ACCEPT, why do it at all? There are several very good reasons to ACCEPT functions and maintenance. It is a good practice to test and ACCEPT a function before APPLYing maintenance in case some of the maintenance may have to be backed out using RESTORE. Also, since RESTORE will not back out sysmods that have been ACCEPTed, the number of sysmods that must be RESTOREd to remove a specific sysmod may be smaller. This is especially true if the chain of dependent sysmods connected to the problem sysmod is very long. Another reason to ACCEPT is that some functions and sysmods must be ACCEPTed before testing (i.e., AOC/MVS sample data bases are only installed in the distribution data sets that are updated only after ACCEPT processing). These special circumstances are usually documented in the installation materials or by ++HOLD requirements. Before a system generation, all sysmods must be ACCEPTed or they will be lost and must be reinstalled. Last, ACCEPT does clean up the RELFILEs, the PTS data set and the SMPE global zone. There are some cases when ACCEPT processing should not be done. Maintenance should not be ACCEPTed before it has been thoroughly tested, because once ACCEPTed, there is no SMPE method to back out the changes if there is a problem. Also, maintenance should not be ACCEPTed unless the most up-to-date HOLDDATA is available to avoid ACCEPTing maintenance that may be in error. Since ACCEPT processing cannot be reversed by SMPE, it requires the same special treatment given the APPLY. Following are the six steps that should be followed during an ACCEPT: 1) A backup should be made of all of the data sets updated by the APPLY. 2) All of the system modifications should be tested and a reasonable amount of time should be spent in production mode to detect any problems left undiscovered during the test phase. A good practice is to only ACCEPT maintenance that is at least one level behind the currently released maintenance tape. This will allow for the discovery of problems by other customers and give the vendor time to correct these problems. 3) The latest HOLDDATA should be requested from the vendor and RECEIVEd, so that any sysmod that has been found to be in error since the APPLY will not be ACCEPTed. 5) If additional sysmods not yet in APPLY status are required by the ACCEPT, then the entire APPLY process should be redone for these sysmods before attempting the ACCEPT. 6) Do the same special processing that was required in the APPLY process as indicated by the installation documentation or any ++HOLD requirements. ACCEPT processing creates some conditions that require special handling. One is removing a function that has been APPLYed and ACCEPTed but is no longer needed on a system. First, the user must determine that no other functions depend on this function. Then the user must code up a dummy function (DELFUNC) as shown in Figure 1. The commands to RECEIVE, APPLY and ACCEPT the dummy function (DELFUNC) are shown in Figure 2. Last, the old product data sets must be manually deleted. Another special condition created by the ACCEPT occurs when APPLYing maintenance from a cumulative maintenance tape. Since the ACCEPT deletes the MCS entries from the PTS and the sysmod entries from the global zone, sysmods may be RECEIVEd that are already APPLYed and ACCEPTed on the system. Since these sysmods are not needed, there is a way using SMPE to delete them from the PTS and global zone. The commands needed to accomplish this clean up task are shown in Figure 3. ACCEPT processing is an important part of the SMPE process. It should never have been done carelessly, but with the same care that is used during APPLY processing. When done correctly, ACCEPT processing is a very necessary part of system maintenance; when done haphazardly, ACCEPT processing can cause problems that are not easily or quickly correctable. /* Was this article of value to you? If so, please let us know by circling Reader Service No. 81.   Figure 2: The Commands To RECEIVE, APPLY and ACCEPT DELFUNC //SMPCNTL DD * SET BOUNDARY (global) . /* Set to global zone */ REJECT S(DELFUNC) /* REJECT function if */ . /* not successfully */ /* deleted last time */ SET BOUNDARY (global) . /* Set to global zone */ RESETRC . /* Reset return code */ RECEIVE S(DELFUNC) /* RECEIVE function */ . SET BOUNDARY (target) . /* Set to target zone */ APPLY S(DELFUNC) CHECK . /* APPLY to delete old */ APPLY S(DELFUNC) RC(APPLY=04) /* function from target */ . SET BOUNDARY (dlib) . /* Set to dlib zone */ ACCEPT S(DELFUNC) CHECK . /* ACCEPT to delete old */ ACCEPT S(DELFUNC) RC(APPLY=04) /* function from dlibs */ . SET BOUNDARY (target) . /* Set to target zone */ UCLIN . DEL SYSMOD(DELFUNC) . /* Delete sysmod entries */ DEL SYSMOD(old fmid) . /* for dummy and old */ ENDUCL /* functions from target */ . SET BOUNDARY (dlib) . /* Set to dlib zone */ UCLIN . DEL SYSMOD(DELFUNC) . /* Delete sysmod entries */ DEL SYSMOD(old fmid) . /* for dummy and old */ ENDUCL /* functions from dlib */ .   Figure 3: Commands for Clean Up SET BOUNDARY (global) . /* Set to global zone */ REJECT /* Deletes sysmods from */ PURGE ( dlib) /* PTS that have been */ . /* APPLYed and ACCEPTed */