RACROUTE is an Assembler macro used to interface with the security system for a wide variety of functions such as verifying that a user can access some system resource such as a dataset. The macro itself is quite complex and difficult for a inexperienced Assembler programmer to use. For better or worse, I believe all RACROUTE functions require the caller to be APF authorized.
Both a weakness and a strength of RACROUTE is it very oriented in its definition to the capabilities of the RACF security product. Non RACF system products must translate RACROUTE calls to their security system primitives, which does not always work smoothly. Security products that have primitives that cannot be translated to RACF terms are left out in RACROUTE.
Still, almost all primitive security system interfaces that reasonable programs require can be expressed in RACROUTE, though if my memory is correct RACROUTE cannot be used for tasks like defining a user or system resource for the security system.
Back in the days when I did product support we had a customer that was trying to use RACROUTE in a well defined exit in the product I supported. This customer screwed it up big time; the exit was getting an S0C4 and the customer could not figure out his problem. I rewrote their exit to implement their use of RACROUTE correctly; a major effort which went far beyond something support should do for a customer.
Long before that a shop where I worked was doing ICHINTxx calls (these are RACF primitive macros) in the JES2 main task, which is supposed to be a no no. Once or twice a year this junk locked up the entire JES2 MAS. It was always a major effort to determine the system to IPL to clear the problem. I translated the ICHINTxx calls to RACROUTE and did the actual RACROUTE call in a JES2 subtask, the way it is supposed to be done, and that solved that problem, though I cannot recall if that code was removed as part of a major cleanup demanded by a security consultant.