But it is authorised!!! A quick guide to diagnosing unexpected S047 abends.

But it is authorised!!! A quick guide to diagnosing unexpected S047 abends.

Many of us will have come across the S047 abend ("An unauthorized program issued a restricted Supervisor Call (SVC) instruction") that we cannot immediately explain.  We know that our executable library is authorised (or authorized, for those reading in North America).  We have double checked member PROGxx in SYS1.PARMLIB or re-issued our ‘SETPROG APF’ command but this has failed to explain the problem.  Therefore there must be something seriously and fundamentally wrong with the application or the execution environment, yes? 

Well, no.  Usually not, at least.  However, where do we start investigating potential causes of the abend?  Here is a quick checklist to set the wheels in motion.

1.  SYS1.PARMLIB(PROGxx) or SETPROG APF command

Well, obviously enough, we start with the possibilities listed above.  Are you absolutely sure that your libraries have been authorised?  That your IPL was executed with the correct LOADPARM setting and, in turn, the expected PROGxx member was selected?  Or that your SETPROG commands have been successfully executed?

To check and follow through the PROGxx aspect of this a user can issue the ‘D IPLINFO’ MVS operator command.  This will provide pointers to the parms and datasets used to IPL the system and this aspect of the problem can be tracked from there.

However, as this is being written in 2015 most, if not all, customers rely on dynamic APF lists for the vast majority of their authorisation needs.  The ‘D PROG,APF’ command can be used to display the current contents of the dynamic APF list:

2015196 02:50:21.56 SNEVIN   00000280  D PROG,APF                                        
2015196 02:50:21.64 SNEVIN   00000080  CSV450I 02.50.21 PROG,APF DISPLAY 398             
                         398 00000080  FORMAT=DYNAMIC                                    
                         398 00000080  ENTRY VOLUME DSNAME                               
                         398 00000080     1  Z13SX1 SYS1.LINKLIB                         
                         398 00000080     2  Z13SX1 SYS1.SVCLIB                          
...
                         398 00000080   623  *SMS*  CMNSUP.CMN710S.SPTDPE.VPROM2.LINKLIB   
                         398 00000080   624  *SMS*  CMNSUP.CMN710S.SPTDPE.CPROM.LINKLIB    
                         398 00000080   625  *SMS*  CMNSUP.CMN710S.SPTDPE.VPROM1.LINKLIB   

Is your library returned?  If not, it can be added using something similar to the following command:

SETPROG APF,ADD,DSNAME=your.executable.library,SMS   

It is very likely that some or all of these operator commands will be restricted to specific users in your environment.  If you are unsure or unauthorised to issue these commands then ask your Systems Programmers or Systems Support staff to issue them on your behalf.

2.  Are you running on the expected LPAR?

Having verified that our library is definitely authorised on LPARA. the next thing we need to ensure is that our abending job is actually executing on LPARA!  It sounds obvious, but in these days of IBM Workload Manager it is far from a given that just because we submitted our job on LPARA it definitely ran there.  It could easily have been routed to LPARB, C, D, etc., for execution.  As the APF list is managed on an LPAR-by-LPAR basis, you will need to ensure that your execution library is authorised on all LPARs on which the job can execute.

3.  Are all the libraries in my JOBLIB or STEPLIB authorised?

In order to retain authorisation for any library or program within a JOBLIB or STEPLIB concatenation, all libraries within that concatenation must be authorised.  For example, let’s take a look at this:

//STEPLIB   DD DISP=SHR,DSN=CMNSUP.INTL.CMN713.EXITS   
//          DD DISP=SHR,DSN=CMNSUP.INTL.SER713.LOAD            
//          DD DISP=SHR,DSN=CMNSUP.INTL.CMN713.LOAD            
//          DD DISP=SHR,DSN=CMNSUP.INTL.CMN713.NONAPF.LOAD     

Even though all programs that issue authorised instructions exist in the top three, authorised libraries in this STEPLIB, the inclusion of the unauthorised ‘CMNSUP.INTL.CMN713.NONAPF.LOAD’ in this concatenation means that no programs will be authorised at execution time.  Therefore any request to execute an authorised instruction from any program within this job step will fail with a S047 abend.

4.  Is the ‘top level’ program linked AC=1?

This is arguably the most obscure potential cause of unexpected S047 abends. 

We all know that to issue an authorised instruction a program must be linked AC=1, right?  Well, no, that is not completely correct.  Maybe surprisingly, and regardless of the module that is issuing the authorised command/function/service, it is the task/TCB/EXEC PGM= level program that must be linked with an authorisation code of 1 and not the program that actually requests the restricted function.

So, let’s take a situation where PGM1 loads and dynamically calls PGM2.  PGM2 uses the restricted MODESET macro to switch the task into supervisor mode.  The JCL EXEC statement for this routine is:

//STEP1 EXEC PGM=PGM1 
//STEPLIB DD...

In this situation it is actually PGM1 that must be linked or bound with AC=1, not PGM2.  If PGM1 is linked with AC=0 a S047 abend will occur.  PGM2’s AC value will have no impact at all in this situation.  All relies on PGM1’s AC value.     

This has caused problems in the past where, for example, third party security systems have attempted to execute authorised functions from within job steps executing Serena-supplied programs.  In order for this to work, Serena have had to re-bind/re-link specific modules with AC=1 to overcome this restriction.  One such example can be found here:

http://knowledgebase.serena.com/InfoCenter/index?page=content&id=D20603&actp=search&viewlocale=en_US&searchid=1436800109838

Conclusion

As a final ‘gotcha’, please remember that even if a program is linked AC=1 this will only ever be exercised if a protected function is executed.  For example, SERCOPY may be bound with AC=1 and operate normally 99%+ of the time.  However, that one time it needs to switch to supervisor mode to access protected storage or execute any other authorised function is the only time that it will abend with a S047 if the host library and calling module are not correctly authorised.  This is another common explanation for the apparent 'intermittent' S047 abends that we sometimes see reported. 

Hopefully you will never encounter unexplained S047 abends or, if you do, the answer will lie somewhere in this article.  Personally I have yet to come across a S047 that cannot be explained by one of the points covered in this article.  However, if you believe that you have one, or if you are struggling to diagnose a S047 related to a Serena product, then please feel free to contact Serena Support who will be happy to assist.

Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Comments

Comment removed by moderator pending clarification.

Top Contributors
Version history
Revision #:
3 of 3
Last update:
‎2020-01-16 19:57
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.