Hi
I know system 23E is for invalid TCB it seems to me that TCB is valid could
any confirm that the following is the correct sequence of step to terminate
a TASK
I have 4 tasks I do an ATTACH with ECB =, SYSECB is the ECB, I am using
END_ECB I use to tell the subtask to return via BR 14
2:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S23E
Hi
I know system 23E is for invalid TCB it seems to me that TCB is valid could any
confirm that the following is the correct sequence of step to terminate a TASK
I have 4 tasks I do an ATTACH with ECB =, SYSECB is the ECB, I am using
END
> From: IBM Mainframe Discussion List On Behalf Of
> Joseph Reichman
> Sent: Wednesday, October 31, 2018 2:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S23E
>
> Hi
>
>
>
> I know system 23E is for invalid TCB it seems to me that TCB is valid coul
Please provide all the relevant information in a post like this. The
IBM-Main community is very helpful but should not be wasting time trying
to guess about things that could easily have been supplied. This would
include the 23E reason code, the ATTACH (and how you saved the result) and
the dat
Peter
END_ECB is the address, it is DSECTed off R7
So is TASK_ADDR, END_ECB and SYS_ECB they are unique to the 4 subtasks as for
the reason code as you so helpfully suggested yesterday the registers I got in
my dump were from IGC062 i know with what I provided it would be close to
impossible t
Is DETACH self valid?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Rob
Scott
Sent: Wednesday, October 31, 2018 7:01 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S23E
I would suggest
gt; To: IBM-MAIN@listserv.ua.edu
> Subject: Re: S23E
>
> I would suggest performing the DETACH from an "end of task exit routine"
> whose address is passed on the ETXR keyword of ATTACH(X).
>
> Rob Scott
> Rocket Software
>
> -Original Message
Metz
Sent: Wednesday, October 31, 2018 5:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S23E
Is DETACH self valid?
--
Shmuel (Seymour J.) Metz
https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C2c2c0176f7044c1b36
ssued to remove the subtask from the system
> after the subtask terminates."
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Seymour J Metz
> Sent: Wednesday, October 31, 2018 5:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S
Is END_ECB and EB or the address of an ECB?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Joseph Reichman
Sent: Tuesday, October 30, 2018 10:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: S23E
://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf of
> Joseph Reichman
> Sent: Tuesday, October 30, 2018 10:20 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: S23E
>
> Hi
>
>
>
> I know system 23E is for invalid TCB it seems
frame Discussion List on behalf of
Joseph Reichman
Sent: Wednesday, October 31, 2018 1:56 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S23E
I still think I am going to need a ECB or actually 4 to say I’m done or else
the main task might finish first looking at the registers
None have any info
: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Wednesday, October 31, 2018 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S23E
I still think I am going to need a ECB or actually 4 to say I’m done or else
the main task might finish first looking at the registers None have any
own.
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Joseph Reichman
> Sent: Wednesday, October 31, 2018 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S23E
>
> I still think I am going to need a ECB or actually 4 to say I’m done
n (1).
Mother can always supervise daughters thru the list of structures it maintains
in (1).
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Wednesday, October 31, 2018 5:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S23E
I still think I am
gt;
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Joseph Reichman
> Sent: Wednesday, October 31, 2018 5:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S23E
>
> I still think I am going to need a ECB or actually 4 to say I’m do
h case it is destroyed when the DETACH is issued.
Looking up the S23E
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieah700/m015090.htm
During processing of a DETACH macro, the system found an error in the
input parameters.
Register 15 contains a hexadecimal reason code that
stroyed when the DETACH is issued.
>
> Looking up the S23E
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieah700/m015090.htm
>
> During processing of a DETACH macro, the system found an error in the
> input parameters.
>
> Register 1
Hello
One of our online application started task got abended with S23E with
reason code 0.
Recently we swapped our production site with our DR site.
The person who supports that product believes that the system swap could be
a reason
But during swap all we did was upgrading our DR machine
On Mon, 22 Aug 2022 10:23:01 +0400 Peter wrote:
:>One of our online application started task got abended with S23E with
:>reason code 0.
:>Recently we swapped our production site with our DR site.
:>The person who supports that product believes that the system swap could b
started task got abended with S23E with
> :>reason code 0.
>
> :>Recently we swapped our production site with our DR site.
>
> :>The person who supports that product believes that the system swap could
> be
> :>a reason
>
> :>But during swap all we did
>
:>This is what I see in dump
:>On Mon, Aug 22, 2022, 11:57 AM Binyamin Dissen
:>wrote:
:>> On Mon, 22 Aug 2022 10:23:01 +0400 Peter wrote:
:>> :>One of our online application started task got abended with S23E with
:>> :>reason code 0.
:>> :>
t;
> :>On Mon, Aug 22, 2022, 11:57 AM Binyamin Dissen <
> bdis...@dissensoftware.com>
> :>wrote:
>
> :>> On Mon, 22 Aug 2022 10:23:01 +0400 Peter wrote:
>
> :>> :>One of our online application started task got abended with S23E with
> :>> :&g
400 Peter wrote:
:>>
:>> :>1B10A920 E6C1D7C1 D9D47A6C C8F84040 40404040D7D3C9E2 E37A6CC8
:>> F8404040
:>> :>40404040 *WAPARM:%H8 PLIST:%H8
:>> :>
:>> :>This is what I see in dump
:>>
:>> :>On Mon, Aug 22, 2022, 11:57 A
ent: Monday, August 22, 2022 5:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S23E abend
Look at the SVC 3E trace entry in the dump. It shows R1 and the PSW at the
time.
Look at the key of R1 storage.
The minidump indicates that the DETACH was issued in key8.
Not clear to me why DETACH requires
pering, amendment or viruses or any consequence thereof.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, August 22, 2022 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S23E abend
Since this is a DR test, I would be willing to bet that someone made an error
in the PROGxx member and you have at lest one and probably several datasets
that are not authorized correctly. It could be that someone forgot a comma or
they specified the wrong volume (i.e it's on Z24RES on the prim
If was an APF issue then the started wouldn't have started at all
This online application has 7 region with X1 until X9
only X2 and X2 are having this issue
On Tue, Aug 23, 2022, 9:03 AM Brian Westerman
wrote:
> Since this is a DR test, I would be willing to bet that someone made an
> error in
The application "got abended" because something running under that task
mis-issued DETACH.
The doc for completion code 23E reason 0 seems pretty clear.
The entry requirement for DETACH is:
R1 contains the address of a word which contains the address of the TCB of the
task to be detached.
If you
The "normal" reason this happens (at least to me) is because the task isn't
authorized to issue the detach. It has nothing to do with whether or not the
task was able to start, because the task may not have needed to be authorized
when it started, but needs it to perform a specific function and
Reason code 00 is a storage key mismatch.
Joe
On Wed, Aug 24, 2022 at 3:19 PM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:
> The "normal" reason this happens (at least to me) is because the task
> isn't authorized to issue the detach. It has nothing to do with whether or
> not the ta
on the ETXR keyword of ATTACH(X).
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Joseph Reichman
> Sent: Wednesday, October 31, 2018 2:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S23E
>
> H
How grown application written in ASM and C. Works fine since years, except for
some "out of socket descriptor" problems every now and them. I was asked to
help finding the cause of S23E or S53E (both DETCH) abends since the developer
tries to fix the above "ourt of socket desc
On Mon, Mar 27, 2017 at 9:33 AM, Peter Hunkeler wrote:
> How grown application written in ASM and C. Works fine since years, except
> for some "out of socket descriptor" problems every now and them. I was
> asked to help finding the cause of S23E or S53E (both DETCH) abends si
On Mon, Mar 27, 2017 at 12:06 PM, Peter Hunkeler wrote:
>
>
> >> How grown application written in ASM and C. Works fine since years,
> except
> >> for some "out of socket descriptor" problems every now and them. I was
> >> asked to help finding
I'm not really sure why IBM service would help someone debug an
application error, aside from on a for-fee basis, unless there is reason
to believe there could be a system problem.
23E reason 0: you have an error in the input to detach. The system
program-checked referencing the data that you
>>a) I see a couple of FREEMAIN (SSRV 78) trace entries pointing to a TCB in
>>read/write nucleus (TCB address is 00FDD4F8). Do these hold some useful
>>information for me?
>The only tcb I know of that actually, really is located in the R/W nucleus is
>the first tcb in the *master* address spac
On Tue, Mar 28, 2017 at 7:06 AM, Peter Hunkeler wrote:
>
>
> This is complex, multitasking code that has run for years without problem.
> The developer tried to change a tiny bit of code, and the errors startet do
> appear. The problem is that the code change has been backed out, but the
> pro
or the 0C4-11
-- RCVY FRR when POST's FRR is entered. The 0C4-11 is changed to an S202-00,
then percolation occurs
-- RCVY FRR when DETACH's FRR is entered. The S202-00 is changed to S23E-00,
then percolation occurs again
-- RCVY PERC, when the S23E-0 is percolated to RTM2.
-- SVC D, when RTM
>> How grown application written in ASM and C. Works fine since years, except
>> for some "out of socket descriptor" problems every now and them. I was
>> asked to help finding the cause of S23E or S53E (both DETCH) abends since
>> the developer trie
>I'm not really sure why IBM service would help someone debug an
application error, aside from on a for-fee basis, unless there is reason
to believe there could be a system problem.
I agree. But when all else fails, we might even try going down that route.
>23E reason 0: you have an error in
>a) I see a couple of FREEMAIN (SSRV 78) trace entries pointing to a TCB in
>read/write nucleus (TCB address is 00FDD4F8). Do these hold some useful
>information for me?
The only tcb I know of that actually, really is located in the R/W nucleus is
the first tcb in the *master* address space. Eve
> >a) I see a couple of FREEMAIN (SSRV 78) trace entries pointing to a
> TCB in read/write nucleus (TCB address is 00FDD4F8). Do these hold
> some useful information for me?
> The only tcb I know of that actually, really is located in the R/W
> nucleus is the first tcb in the *master* address spa
>b) I know "SVC D" is also entered for normal task termination. In an ld
>MVS debugging manual I found that the first byte of R1 is x'08' this indicates
>RTM2 is called for task termination cleanup. The x'08 does no longer seem to
>hold true. How can I identify such an non-error an SVC D ent
44 matches
Mail list logo
