If his code is running in key 0, then he can also set the appropriate bit in the DEB and thus avoid the S306 ABEND. Or at least get past the S306 ABEND and advance through system code until the next type of ABEND is uncovered.
Bill Fairchild ----- Original Message ----- From: "John McKown" <[email protected]> To: [email protected] Sent: Monday, July 7, 2014 7:25:38 AM Subject: Re: SVC 99 APF Authorized Library On Sun, Jul 6, 2014 at 10:45 PM, MichealButz <[email protected]> wrote: > Hi, > > I am getting 306 ABEND because my APF concatenation contains a NON > authorized Library. IS it possible to remedy this (as I have a recovery > routine) > > By Dynamic allocation of the dataset ? _IF_ I understand what you want to do, then the answer is an unqualified NO. Let me restate the problem in my own words. You are running some code which running APF authorized (loaded from APF library & AC=1 on PGM=). You now want to access/run some code which resides in an non-APF authorized library. This is _impossible_. Even if you dynamically allocate a new DD to point to the non-APF library; OPEN it; then do a LINK/LOAD/XCTL/ATTACHX with the DCB operand. You will get the S306 abend in all cases. As I understand it, what happens is this: One: to run APF authorized basically means that the APF bit is set "on" in the JSCB. When you (or the initiator in the case of STEPLIB/JOBLIB) does an OPEN, the code in OPEN will look at each (or only) library concatenated to the DD being OPEN'ed. If _every_ DSN in the concatenation is marked as APF authorized, then OPEN will set a bit in the DEB for the open DD which says "this DD is APF authorized". Now, when you do a program fetch (LOAD/LINK/...), the z/OS code responsible for doing that will basically do: "IF JSCBAPF IS TRUE AND DEBAPF IS FALSE THEN ABEND S306". You are blowing up in program fetch. So, to bypass the abend, you would need to bypass program fetch. Good luck with that. What are you basically trying to do? Because what you are _trying_ to do would comprise system reliability and security. Now, since you are APF authorized, you can do "weird and wonderful" things. The first is to act like the initiator. That is, set up a _new_ JSCB which does not have the JSCBAPF bit on. Now, allocate your DD to the non-APF library (or libraries). OPEN it. Now, critically, use the ATTACHX macro with DCB= and JSCB= (and maybe even TASKLIB=) to point to the newly opened DCB and your new JSCB. Alternate method. SVC 99 allocate DD to non-APF library. OPEN it. Switch to key 0. Reset APF bit in JSCB. Do a LOAD on the module you want, using the newly OPENed DCB (saving the EP, of course). You won't abend because your code is not APF authorized at this point. Set APF bit on in JSCB. switch back to TCBKEY. Use SYNCH to invoke the non-APF authorized module using the address you saved from the LOAD. !!!!! This can seriously compromise system reliability and security !!! If you are a vendor, I do _not_ want to run your product! No kidding. No way. No how. This shows a complete contempt for reliability. Use Windows instead. They don't care about security or reliability either. Yes, I am deliberately being nasty. This method is an abomination. I likely should not have mentioned it. Better method: I don't know why you want to run non-APF code or what you want it to do. But, being APF authorized, you can run it in a separate address space. You could use the ASCRE macro to do an internal START command of a procedure in PROCLIB which will run the required program with the appropriate STEPLIB. You can even parameterize the PROC to accept the name of the program and the DSN of the library. ASCRE can also set up a cross memory environment so that the started program (if it is your own) can access the APF authorized program's address space. I consider this to be a bad idea and a security threat, unless it is done _exactly_ right. If you need to pass data back and forth using DD statements in the STARTed program, remember the existence of UNIX pipes. Now, the "problem" would be if the target program needs to access the memory of the parent program directly, not using ALETs in a cross memory environment. This, again, leads to "badness" in my opinion. Well, I've rambled on long enough. Hope this was of some help. I sincerely hope you don't use the key 0 method. It is nasty in a nasty way. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
