Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Shmuel Metz (Seymour J.)]

In <012501cc8d4e$0f098770$2d1c9650$@net>, on 10/18/2011
   at 12:26 AM, Micheal Butz  said:

>SRB was the only way to go,

Why wouldn't an IRB work?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Shmuel Metz (Seymour J.)]

In <011b01cc8d43$10639a30$312ace90$@net>, on 10/17/2011
   at 11:07 PM, Micheal Butz  said:

>I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't
>abended on a SVC I abended whitin STM of the SETFRR inst  

No. You got the ABEND on the breakpoint that TESTAUTH inserted in
place of the STM.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Chris Craddock]

On Tue, Oct 18, 2011 at 10:20 AM, Micheal Butz wrote:

> Is all that's required for setting a recovery routine for the SRB is
> setting
> a address in SRBFRRA ?
> 
>


At the risk of sending you off on another tangent, "yes".

But, what would you *DO* with an FRR if you managed to set one? They serve
two purposes;
1. Diagnosis: Collect error diagnostic data for subsequent analysis
2. Recovery: Choose to percolate or set up the registers for a retry

both of those things are complex and delicate (think of walking on
eggshells). If you don't have a very detailed understanding of the recovery
environment, you're likely to do more harm than good. If you're going to
play with fire, it is best to let your SRB crash and burn, rather than risk
doing more harm.

Oh and BTW> I assume you are aware that (for normal human beings) you CANNOT
debug any SRB or FRR under TSO right?


-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Micheal Butz]

Is all that's required for setting a recovery routine for the SRB is setting
a address in SRBFRRA ? 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Tom Harper
Sent: Tuesday, October 18, 2011 8:48 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

Michael,

It sounds like you are issuing the SETFRR under your TCB which is going to
SCHEDULE your SRB. This is not necessary and will almost certainly cause you
problems, such as the 0F8 abend, and this FRR will not protect your SRB.

FRR's can be used to establish a recovery environment for a TCB, but I don't
think you really need one here. If you do need such an environment, I would
use an ESTAEX.

You can choose to use an FRR with your SRB, or, you can just let it
percolate back to your TCB, as Chris mentioned. If you do want an FRR for
your SRB, you can just set its address in the SRBFRRA field or you can issue
your own SETFRR rearly in the SRB code. I would also suggest issuing an
SRBTIMER macro to catch any loops you might have.

Like the Binjamin and Chris, I wonder what you're trying to accomplish here.
It sounds like this is your first foray into this sort of coding, but it
also appears that you haven't read all of the background material in the
z/OS Authorized Programming Guide, which I suggest you should do. In there
are the answers to all of the questions you've been asking here.

If you are determined to push ahead, I'm hoping you are testing on a sandbox
system. 

Please be more communicative with your objectives here.

Tom

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Binyamin Dissen
Sent: Tuesday, October 18, 2011 3:10 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH

On Tue, 18 Oct 2011 00:26:08 -0400 Micheal Butz 
wrote:

:>I am trying to issue a branch entry form of  a macro in a other address
:>space since the specifications say PASN=HASN=SASN

Which macro?

:>SRB was the only way to go, the branch entry form of the macro was the
only :>code in the SRB I figured I would set up a FRR 

:>So that if anything goes wrong RTM would give control to the FRR I could
:>examine the SDWA for any problems

Have you done FRR's before? ESTAEs? If not, you might be biting off more
than you can chew with testing a FRR and SRB's at the same time.

Under which conditions will you recover?

You might want to set it up so that the SRB will abend your issuing task. 

Also, I don't get the connection between what you are doing and a
non-reentrent TSO command.

Try to give details on WHAT you are trying to accomplish - not how you are
trying to do it.

:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf :>Of Chris Craddock
:>Sent: Tuesday, October 18, 2011 12:05 AM
:>To: IBM-MAIN@bama.ua.edu
:>Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH :>
:>No, you werent where you thought you were in the code. The system doesn't
:>lie about what happened.  You can't issue any SVC instructions while you
:>have an FRR on the stack, regardless of what kind of FRR you have. And
don't :>forget you may be calling other system services whether you're aware
of it :>or not. 
:>
:>Leaving aside the general undesirability of testing SRB code  by trial and
:>error, If you did manage to get the SRB scheduled then two interesting
:>things are happening to you. First you have another independent unit of
work :>running (the SRB) which will muddy the waters because any error that
befalls :>the SRB will be reflected back on the TCB you're running under so
your :>debugging information is going to be quite confusing. 
:>
:>Frankly you're kind of stumbling around in a coal mine with a flashlight
:>even trying this. I would usually give a little sermon about all the
things :>that can go horribly wrong. I will spare you that but here's the
rub -- :>there's not a lot of chance you're going to suddenly converge on a
solution :>that works. Tell us what problem you're trying to solve and maybe
we can :>help you without trashing your system. 
:>
:>Sent from my iPad
:>
:>On Oct 17, 2011, at 10:07 PM, Micheal Butz 
:>wrote:
:>
:>> I didn't issue any SVC
:>>
:>> The code blew up under TESTAUTH at the fifth instruction after the :>>
expansion of the SETFRR macro :>> :>> I normally get 0F8 when I am in XMEM
mode and issue a SVC I didn't abended
:>> on a SVC I abended whitin STM of the SETFRR inst    
:>>
:>> -Original Message-
:>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>Behalf :>> Of Li

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Tom Harper]

Michael,

It sounds like you are issuing the SETFRR under your TCB which is going to 
SCHEDULE your SRB. This is not necessary and will almost certainly cause you 
problems, such as the 0F8 abend, and this FRR will not protect your SRB.

FRR's can be used to establish a recovery environment for a TCB, but I don't 
think you really need one here. If you do need such an environment, I would use 
an ESTAEX.

You can choose to use an FRR with your SRB, or, you can just let it percolate 
back to your TCB, as Chris mentioned. If you do want an FRR for your SRB, you 
can just set its address in the SRBFRRA field or you can issue your own SETFRR 
rearly in the SRB code. I would also suggest issuing an SRBTIMER macro to catch 
any loops you might have.

Like the Binjamin and Chris, I wonder what you're trying to accomplish here. It 
sounds like this is your first foray into this sort of coding, but it also 
appears that you haven't read all of the background material in the z/OS 
Authorized Programming Guide, which I suggest you should do. In there are the 
answers to all of the questions you've been asking here.

If you are determined to push ahead, I'm hoping you are testing on a sandbox 
system. 

Please be more communicative with your objectives here.

Tom

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Binyamin Dissen
Sent: Tuesday, October 18, 2011 3:10 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH

On Tue, 18 Oct 2011 00:26:08 -0400 Micheal Butz 
wrote:

:>I am trying to issue a branch entry form of  a macro in a other address 
:>space since the specifications say PASN=HASN=SASN

Which macro?

:>SRB was the only way to go, the branch entry form of the macro was the only 
:>code in the SRB I figured I would set up a FRR 

:>So that if anything goes wrong RTM would give control to the FRR I could 
:>examine the SDWA for any problems

Have you done FRR's before? ESTAEs? If not, you might be biting off more than 
you can chew with testing a FRR and SRB's at the same time.

Under which conditions will you recover?

You might want to set it up so that the SRB will abend your issuing task. 

Also, I don't get the connection between what you are doing and a non-reentrent 
TSO command.

Try to give details on WHAT you are trying to accomplish - not how you are 
trying to do it.

:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
:>Of Chris Craddock
:>Sent: Tuesday, October 18, 2011 12:05 AM
:>To: IBM-MAIN@bama.ua.edu
:>Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH :> 
:>No, you werent where you thought you were in the code. The system doesn't 
:>lie about what happened.  You can't issue any SVC instructions while you 
:>have an FRR on the stack, regardless of what kind of FRR you have. And don't 
:>forget you may be calling other system services whether you're aware of it 
:>or not. 
:>
:>Leaving aside the general undesirability of testing SRB code  by trial and 
:>error, If you did manage to get the SRB scheduled then two interesting 
:>things are happening to you. First you have another independent unit of work 
:>running (the SRB) which will muddy the waters because any error that befalls 
:>the SRB will be reflected back on the TCB you're running under so your 
:>debugging information is going to be quite confusing. 
:>
:>Frankly you're kind of stumbling around in a coal mine with a flashlight 
:>even trying this. I would usually give a little sermon about all the things 
:>that can go horribly wrong. I will spare you that but here's the rub -- 
:>there's not a lot of chance you're going to suddenly converge on a solution 
:>that works. Tell us what problem you're trying to solve and maybe we can 
:>help you without trashing your system. 
:>
:>Sent from my iPad
:>
:>On Oct 17, 2011, at 10:07 PM, Micheal Butz 
:>wrote:
:>
:>> I didn't issue any SVC
:>>
:>> The code blew up under TESTAUTH at the fifth instruction after the :>> 
expansion of the SETFRR macro :>> :>> I normally get 0F8 when I am in XMEM mode 
and issue a SVC I didn't abended
:>> on a SVC I abended whitin STM of the SETFRR inst
:>>
:>> -Original Message-
:>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
:>Behalf :>> Of Lizette Koehler :>> Sent: Monday, October 17, 2011 10:54 PM :>> 
To: IBM-MAIN@bama.ua.edu :>> Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 
0014 under TESTAUTH :>> :>>> Hi, :>>> :>>> :>>> :>>> I am trying to 
establish a FRR in a TSO command pro

Re: Assember Newsgroup ( Was SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH)

[Lizette Koehler]

> >
> > Lizette
> 
> But, at times, the people over on ASSEMBLER-LIST will refer people back
here for
> system-specific problems. Something about ASSEMBLER-LIST being for
problems and
> questions about the assembler itself, not about assembler coding to a
system API
> function for a specific environment (z/VM vs. z/VSE vs. z/OS vs. z/TPF vs.
z/Linux).
> 
> --
> John McKown
> Systems Engineer IV
> IT


John, thanks for letting me know that.  I had thought that they would also
be interested in discussing deep level coding techniques like FRR and SRB as
well.  This is good to know.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler
> Sent: Monday, October 17, 2011 9:54 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH
> 

> 
> Are you a member of the assembler language newsgroup?  You 
> might have better
> response there or better assistance.   assembler-l...@listserv.uga.edu
> 
> 
> 
> Lizette

But, at times, the people over on ASSEMBLER-LIST will refer people back here 
for system-specific problems. Something about ASSEMBLER-LIST being for problems 
and questions about the assembler itself, not about assembler coding to a 
system API function for a specific environment (z/VM vs. z/VSE vs. z/OS vs. 
z/TPF vs. z/Linux).

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Binyamin Dissen]

On Tue, 18 Oct 2011 00:26:08 -0400 Micheal Butz 
wrote:

:>I am trying to issue a branch entry form of  a macro in a other address
:>space since the specifications say PASN=HASN=SASN

Which macro?

:>SRB was the only way to go, the branch entry form of the macro was the only
:>code in the SRB I figured I would set up a FRR 

:>So that if anything goes wrong RTM would give control to the FRR I could
:>examine the SDWA for any problems

Have you done FRR's before? ESTAEs? If not, you might be biting off more than
you can chew with testing a FRR and SRB's at the same time.

Under which conditions will you recover?

You might want to set it up so that the SRB will abend your issuing task. 

Also, I don't get the connection between what you are doing and a
non-reentrent TSO command.

Try to give details on WHAT you are trying to accomplish - not how you are
trying to do it.

:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
:>Of Chris Craddock
:>Sent: Tuesday, October 18, 2011 12:05 AM
:>To: IBM-MAIN@bama.ua.edu
:>Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH
:>
:>No, you werent where you thought you were in the code. The system doesn't
:>lie about what happened.  You can't issue any SVC instructions while you
:>have an FRR on the stack, regardless of what kind of FRR you have. And don't
:>forget you may be calling other system services whether you're aware of it
:>or not. 
:>
:>Leaving aside the general undesirability of testing SRB code  by trial and
:>error, If you did manage to get the SRB scheduled then two interesting
:>things are happening to you. First you have another independent unit of work
:>running (the SRB) which will muddy the waters because any error that befalls
:>the SRB will be reflected back on the TCB you're running under so your
:>debugging information is going to be quite confusing. 
:>
:>Frankly you're kind of stumbling around in a coal mine with a flashlight
:>even trying this. I would usually give a little sermon about all the things
:>that can go horribly wrong. I will spare you that but here's the rub --
:>there's not a lot of chance you're going to suddenly converge on a solution
:>that works. Tell us what problem you're trying to solve and maybe we can
:>help you without trashing your system. 
:>
:>Sent from my iPad
:>
:>On Oct 17, 2011, at 10:07 PM, Micheal Butz 
:>wrote:
:>
:>> I didn't issue any SVC 
:>> 
:>> The code blew up under TESTAUTH at the fifth instruction after the
:>> expansion of the SETFRR macro
:>> 
:>> I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended
:>> on a SVC I abended whitin STM of the SETFRR inst
:>> 
:>> -Original Message-
:>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>Behalf
:>> Of Lizette Koehler
:>> Sent: Monday, October 17, 2011 10:54 PM
:>> To: IBM-MAIN@bama.ua.edu
:>> Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH
:>> 
:>>> Hi,
:>>> 
:>>> 
:>>> 
:>>> I am trying to establish a FRR in a TSO command processor program that is
:>> not re-
:>>> entrant this is because
:>> 
:>>> 
:>>> Later I schedule a SRB and I want to use the routine I established as a
:>> FRR, as  input
:>>> to the SRBFRRA parameter
:>>> 
:>> 
:>> Did you review the abend and code?
:>> S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR.   
:>>IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO.
:>> 
:>> Did it help?
:>> 
:>> Are you a member of the assembler language newsgroup?  You might have
:>better
:>> response there or better assistance.   assembler-l...@listserv.uga.edu
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
:>Search the archives at http://bama.ua.edu/archives/ibm-main.html
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
:>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Micheal Butz]

I am trying to issue a branch entry form of  a macro in a other address
space since the specifications say PASN=HASN=SASN

SRB was the only way to go, the branch entry form of the macro was the only
code in the SRB I figured I would set up a FRR 

So that if anything goes wrong RTM would give control to the FRR I could
examine the SDWA for any problems

 

   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Chris Craddock
Sent: Tuesday, October 18, 2011 12:05 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH

No, you werent where you thought you were in the code. The system doesn't
lie about what happened.  You can't issue any SVC instructions while you
have an FRR on the stack, regardless of what kind of FRR you have. And don't
forget you may be calling other system services whether you're aware of it
or not. 

Leaving aside the general undesirability of testing SRB code  by trial and
error, If you did manage to get the SRB scheduled then two interesting
things are happening to you. First you have another independent unit of work
running (the SRB) which will muddy the waters because any error that befalls
the SRB will be reflected back on the TCB you're running under so your
debugging information is going to be quite confusing. 

Frankly you're kind of stumbling around in a coal mine with a flashlight
even trying this. I would usually give a little sermon about all the things
that can go horribly wrong. I will spare you that but here's the rub --
there's not a lot of chance you're going to suddenly converge on a solution
that works. Tell us what problem you're trying to solve and maybe we can
help you without trashing your system. 

Sent from my iPad

On Oct 17, 2011, at 10:07 PM, Micheal Butz 
wrote:

> I didn't issue any SVC 
> 
> The code blew up under TESTAUTH at the fifth instruction after the
> expansion of the SETFRR macro
> 
> I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended
> on a SVC I abended whitin STM of the SETFRR inst
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf
> Of Lizette Koehler
> Sent: Monday, October 17, 2011 10:54 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH
> 
>> Hi,
>> 
>> 
>> 
>> I am trying to establish a FRR in a TSO command processor program that is
> not re-
>> entrant this is because
> 
>> 
>> Later I schedule a SRB and I want to use the routine I established as a
> FRR, as  input
>> to the SRBFRRA parameter
>> 
> 
> Did you review the abend and code?
> S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR.   
>IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO.
> 
> Did it help?
> 
> Are you a member of the assembler language newsgroup?  You might have
better
> response there or better assistance.   assembler-l...@listserv.uga.edu

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Chris Craddock]

No, you werent where you thought you were in the code. The system doesn't lie 
about what happened.  You can't issue any SVC instructions while you have an 
FRR on the stack, regardless of what kind of FRR you have. And don't forget you 
may be calling other system services whether you're aware of it or not. 

Leaving aside the general undesirability of testing SRB code  by trial and 
error, If you did manage to get the SRB scheduled then two interesting things 
are happening to you. First you have another independent unit of work running 
(the SRB) which will muddy the waters because any error that befalls the SRB 
will be reflected back on the TCB you're running under so your debugging 
information is going to be quite confusing. 

Frankly you're kind of stumbling around in a coal mine with a flashlight even 
trying this. I would usually give a little sermon about all the things that can 
go horribly wrong. I will spare you that but here's the rub -- there's not a 
lot of chance you're going to suddenly converge on a solution that works. Tell 
us what problem you're trying to solve and maybe we can help you without 
trashing your system. 

Sent from my iPad

On Oct 17, 2011, at 10:07 PM, Micheal Butz  wrote:

> I didn't issue any SVC 
> 
> The code blew up under TESTAUTH at the fifth instruction after the
> expansion of the SETFRR macro
> 
> I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended
> on a SVC I abended whitin STM of the SETFRR inst
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of Lizette Koehler
> Sent: Monday, October 17, 2011 10:54 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH
> 
>> Hi,
>> 
>> 
>> 
>> I am trying to establish a FRR in a TSO command processor program that is
> not re-
>> entrant this is because
> 
>> 
>> Later I schedule a SRB and I want to use the routine I established as a
> FRR, as  input
>> to the SRBFRRA parameter
>> 
> 
> Did you review the abend and code?
> S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR.   
>IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO.
> 
> Did it help?
> 
> Are you a member of the assembler language newsgroup?  You might have better
> response there or better assistance.   assembler-l...@listserv.uga.edu

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Wayne Driscoll]

When you set a breakpoint in TSO TEST (or TESTAUTH), the TEST processor 
copies the current instruction off, and then inserts an SVC 97 instruction 
(0A61).  Because you have an EUT FRR established, you are prohibited from 
issuing SVC instructions (other than 13).  Because of this, when the TEST 
SVC is executed, the SVCFLIH issues the 0F8 abend.

===
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
===



From:
Micheal Butz 
To:
IBM-MAIN@bama.ua.edu
Date:
10/17/2011 08:19 PM
Subject:
SYSTEM ABEND CODE 0F8   REASON CODE 0014 under TESTAUTH
Sent by:
IBM Mainframe Discussion List 



Hi,

 

I am trying to establish a FRR in a TSO command processor program that is
not re-entrant this is because

 

Later I schedule a SRB and I want to use the routine I established as a 
FRR,
as  input to the SRBFRRA parameter

 

While tracing thru TESTAUTH 

 

After establishing a breakpoint at the STM inst  I get the following abend

 

 SETFRR A,FRRAD=SWAPFRR,WRKREGS=(7,8),EUT=YES 

*MACDATE03/23/2006 

 L 7,PSACSTK-PSA(0,0)ADDR OF CURRENT 

 CL7,PSANSTK-PSA(0,0)IS CURRENT STACK

*NORMAL STACK 

 JNE   *+8   NO, BRANCH 

 OIPSAMFLGS-PSA(0),X'80' IND EUT TYPE FRR

 STM   14,3,16(7)SAVE REGS 14-3 

 

SYSTEM ABEND CODE 0F8   REASON CODE 0014 under TESTAUTH


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Micheal Butz]

I didn't issue any SVC 

 The code blew up under TESTAUTH at the fifth instruction after the
expansion of the SETFRR macro

I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended
on a SVC I abended whitin STM of the SETFRR inst

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Lizette Koehler
Sent: Monday, October 17, 2011 10:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH

> Hi,
> 
> 
> 
> I am trying to establish a FRR in a TSO command processor program that is
not re-
> entrant this is because

> 
> Later I schedule a SRB and I want to use the routine I established as a
FRR, as  input
> to the SRBFRRA parameter
>  

Did you review the abend and code?
S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR.   
IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO.

Did it help?

Are you a member of the assembler language newsgroup?  You might have better
response there or better assistance.   assembler-l...@listserv.uga.edu



Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Lizette Koehler]

> Hi,
> 
> 
> 
> I am trying to establish a FRR in a TSO command processor program that is
not re-
> entrant this is because

> 
> Later I schedule a SRB and I want to use the routine I established as a
FRR, as  input
> to the SRBFRRA parameter
>  

Did you review the abend and code?
S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR.   
IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO.

Did it help?

Are you a member of the assembler language newsgroup?  You might have better
response there or better assistance.   assembler-l...@listserv.uga.edu



Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH

[Micheal Butz]

Hi,

 

I am trying to establish a FRR in a TSO command processor program that is
not re-entrant this is because

 

Later I schedule a SRB and I want to use the routine I established as a FRR,
as  input to the SRBFRRA parameter

 

While tracing thru TESTAUTH 

 

After establishing a breakpoint at the STM inst  I get the following abend

 

 SETFRR A,FRRAD=SWAPFRR,WRKREGS=(7,8),EUT=YES

*MACDATE03/23/2006   

 L 7,PSACSTK-PSA(0,0)ADDR OF CURRENT 

 CL7,PSANSTK-PSA(0,0)IS CURRENT STACK

*NORMAL STACK

 JNE   *+8   NO, BRANCH  

 OIPSAMFLGS-PSA(0),X'80' IND EUT TYPE FRR

 STM   14,3,16(7)SAVE REGS 14-3  

 

SYSTEM ABEND CODE 0F8   REASON CODE 0014 under TESTAUTH


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html