IBM Mainframe Forum

Hi,
I have problem with REXX runing under USS. The REXX is part:

and

Under TSO everything is OK, but in USS I get an error:

and:


Any necessary libraries i include in DD statements.

Sorry, I do not know much USS, but you should use lookat: http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/
to search for the 338 abend. Knowing what the abend means may suggest a course of action.

Pedro is correct. S338 ABENDs are most unusual, so I did the lookup for you.

Explanation: An unauthorized task attempted to use authorized options of the ENQ macro instruction during the processing of global resource serialization.

The message showed a decimal reason code, which didn't seem to make much sense. On a hunch I converted it to hexadecimal: 37289985 = 2390001. This seemed to make more sense. Going to the manual I found -

xxxx0001
An unauthorized requester attempted to ENQ an authorized resource.

This doesn't mean much to a beginner, so I will attempt to explain it.

Programmers use the ENQ Assembler macro to control a resource that can be modified by one task at a time. A resource is identified by two names: the "queue" name (or QNAME) and the "resource" name (or RNAME). For example, when you use a data set resource, say SYS1.COBLIB, you are implicitly using QNAME SYSDSN and RNAME SYS1.COBLIB. The system obtains this resource for you; your program does not have to do anything. A number of QNAMEs can only be used by authorized programs; your program appears to be one of them.

Now, I can't do any more since I don't know anything about your environment. Your program could have lost authorization for several reasons. You can figure this out and make sure your program really is authorized, or you can update your program so it does not attempt to use a restricted QNAME. I can't tell you any more.

Good luck.

Under TSO everything is OK, but in USS I get an error:

Because it works in TSO and not in USS, I suspect that something in USS makes it a 'dirty' environment. The system considers it risky to call an authorized program from there, so it loses its authorization for that instance. Instead of using LINKPGM, I recommend that you use ATTCHPGM instead.

The program will be called differently. The use of ATTACH creates a separate TCB just for EQQYCOM, and this new TCB should be 'clean' and allow the APF authorization to be allowed.

I had to google for EQQYCOM... it is part of Tivoli Workload Scheduler. This cannot be the first time someone tried to call it from USS... how has it worked for others? Perhaps ask your question in a Tivoli forum.