Re: Question About ATTACHX and ECB

[Peter Relson]

Ray Pearce wrote:
> Should this have been
> ICM   R15,7,SUB_ECB+1

Since the answer is "yes", we conclude that a value of "40" means that 
the ECB actually was 40xx (and quite possibly 4000) which is what 
you'd expect from a POST upon normal completion.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Neil Duffee]

Gotcha.  I didn't investigate DETACH in any way.  It explains why no one else 
jumped up.  My apologies.  I'll step back now.  *grin*

>  signature = 8 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?"  Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent"  John Norgauer 2004
"Schrodinger's backup: The condition of any backup is unknown until a restore 
is attempted."  John McKown 2015

-Original Message-
From: Steve Thompson [mailto:ste...@cop...net] 
Sent: October 5, 2016 16:13
Subject: Re: Question About ATTACHX and ECB

As I read the macro, it wants the Address TO the address.

On 10/05/2016 03:13 PM, Neil Duffee wrote:
> Caveat:  as a daily digestor, responses are delayed.
>
> n00b alert: my assembler is rusty & little used these daze but doesn't "LA   
> R1,TCB@" load the address of TCB@ into R1.  After "ST  R1,TCB@", I would have 
> expected "LR1,TCB@" instead.
>
> (granted it's probably just an e-mail/transcription typo)
>
> -Original Message-----
> From: Steve Thompson [mailto:ste...@cop...net]
> Sent: October 4, 2016 22:47
> Subject: Re: Question About ATTACHX and ECB
>
> But it was pretty simple. [xnip]
>
> The ECB was cleared by MVCL with the Getmained area, but I did have an XC 
> SUB_ECB,SUB_ECB.
>
> Then the ATTACHX with PARAM=,ECB=SUB_ECB,and MF=(E,(1)),SF=(E,(15))
>
>ST  R1,TCB@   Capture the TCB ADDR
> [xnip]
> WAIT ECB=SUB_ECB
> LR3,SUB_ECB
>
> LA   R1,TCB@
> DETACH (1)
>  [xnip]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Peter Relson]

A posted ECB of xx40 can be either
system completion code of 400; or
reg 15 value of 40 on normal return to the system.

You can tell "which" by bit TcbEndingAbnormally (introduced in z/OS 1.12 
for exactly this purpose) -- on in the first case, off in the second.
I believe that the value in the low 3 bytes of the posted ECB will also 
match the value in STCBCMPC (not necessarily the value in TCBCMPC)
Note that if you did ATTACHX with ECB, the TCB will still be around for 
you to look at, after the ECB is posted.

I'm still curious about Steve's assertions about use of "CALLDISP" and 
about DETACH abending. Neither of those are likely to be correct 
interpretations of what's going on. 

I'm still curious about just when Steve "saw" the ECB contents with an RB 
that was waiting. Was it by display from code that executes after the 
POST? By a dump?
The fact is what I wrote: the ECB provided on ATTACHX will be posted upon 
termination of the task in all cases (on a memterm, one would not consider 
the task to have terminated). If the code does not "wake up" then in some 
way the ECB provided on ATTACHX was not the ECB being waited on.  But then 
if the code does not "wake up" no further instructions would have been 
executed. If the code does wake up and the ECB is not "posted" when looked 
at then either the ECB has been waited on by something else after the post 
or the display is not of the right ECB.

Other posts have suggested that it would have been helpful to show the 
exact values that resulted (return code, ECB contents, ECB address, etc), 
by some print mechanism. I agree.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

On 10/06/2016 07:56 AM, Ray Pearce wrote:

You've been asked to post the exact contents of the ECB.
You posted that it was xx40.

Yes, the hi order in that case I had dropped by the way I loaded the Register.


But you loaded the register with
ICM   R15,7,SUB_ECB

Should this have been
ICM   R15,7,SUB_ECB+1

Ray Pearce



The following code segment demonstrates the results clearly 
without having to read the dump. Just look at the SUMMARY with 
the REGs.


 LMR1,R10,LM
 ICM   R1,7,ICM1
 ICM   R2,7,ICM1+1
 ICM   R3,F,ICM1
 ICM   R4,B'1001',ICM1+4
 EX0,*
ICM1 DCX'0123456789ABCDEF'   String to TEST ICM
*MASK 1 1 1 1
*MASK 0 1 1 1
*MASK+1 0 1 1 1
*MASK+4   1 0 0 1
LM   DCA(0,0,0,0,0,0,0,0,0,0)


It appears that I have terribly confused what the PoOP says about 
ICM.


Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Peter Relson]

>As I read the macro, it wants the Address TO the address.

Steve is correct about the interface to detach.

>From the book:

tcb addr 
Specifies the address of a fullword on a fullword boundary containing the 
address of the task control block for the subtask to be removed from the 
system

I'm not a fan of that extra level of indirection, but that's what was 
implemented almost 45 years ago (an old version of DETACH has the julian 
date 72271).

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Ray Pearce]

>> You've been asked to post the exact contents of the ECB.
>> You posted that it was xx40.
> Yes, the hi order in that case I had dropped by the way I loaded the Register.

But you loaded the register with
ICM   R15,7,SUB_ECB

Should this have been
ICM   R15,7,SUB_ECB+1

Ray Pearce

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

As I read the macro, it wants the Address TO the address.

On 10/05/2016 03:13 PM, Neil Duffee wrote:

Caveat:  as a daily digestor, responses are delayed.

n00b alert: my assembler is rusty & little used these daze but doesn't "LA   R1,TCB@" load the 
address of TCB@ into R1.  After "ST  R1,TCB@", I would have expected "LR1,TCB@" instead.

(granted it's probably just an e-mail/transcription typo)

>  signature = 8 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?"  Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent"  John Norgauer 2004
"Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted."  John McKown 2015


-Original Message-
From: Steve Thompson [mailto:ste...@copper.net]
Sent: October 4, 2016 22:47
Subject: Re: Question About ATTACHX and ECB

But it was pretty simple. [xnip]

The ECB was cleared by MVCL with the Getmained area, but I did have an XC 
SUB_ECB,SUB_ECB.

Then the ATTACHX with PARAM=,ECB=SUB_ECB,and MF=(E,(1)),SF=(E,(15))

   ST  R1,TCB@   Capture the TCB ADDR
[xnip]
WAIT ECB=SUB_ECB
LR3,SUB_ECB

LA   R1,TCB@
DETACH (1)
 [xnip]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

Tom:

I have been answering you and others via answering the group when 
answering one poster.


I think I ticked Peter Relson off because I answered him and 
someone else at the same time I was answering him.


After all, this is a LIST server. So I should be able to answer 
the list, right?


On 10/05/2016 08:27 AM, Tom Marchant wrote:

On Tue, 4 Oct 2016 22:46:43 -0400, Steve Thompson wrote:


Sorry, not allowed.


Not allowed what?


To post the source of the program.


You've been asked to post the exact contents of the ECB.
You posted that it was xx40.
Yes, the hi order in that case I had dropped by the way I loaded 
the Register.



But what was being challenged by Charles was whether or not I was 
correctly reading the contents when I said I got posted with a 
S400. So, I demonstrated to him that it was a S400 and not 
something else, like, X'4000' or X'0400'.




Earlier you had posted that it looked like an RB address.

Yes, I had. Yes it did.




I don't have any more time for this.


You have not offered a single word of appreciation to the people who have been 
giving you their time to try to help you find your error.


True that I have not. And for that I do apologize.

I do appreciate people giving pointers. And when I can, I also do 
the same.



You continue to assert that there is something wrong with the system, and the 
only evidence that you provide is that you once found a bug before. You refuse 
to provide basic details.


And this bug I found "once upon a time" just happened to be in 
the past 3 weeks. And I did post the APAR number, here it is 
again: OA51375.


My manager told me I should open a ticket with IBM. When I have 
gotten this module to work, I'll find some time for that.



And now YOU don't have time for this.


I don't have time to continue chasing the ATTACHX problem.

Tell me, do you have actual programming work that you have to do 
with deadlines? I do. Not only do I have that, but I am a 
bottle-neck for various groups where I work that NEED this 
in-house written utility upgraded.


So, I have certain things I have to get fixed and I'm given a 
certain amount of time. When that time is up, I better find 
another way that works and get. iT. DONE.


If you don't have those kinds of pressures, walk a mile in my shoes.



You just found your way to my s**t list.


Yeah, it happens. But wait until you have some problem happen 
that makes no sense at all, and someone on your Super List, 
actually knows the answer and gives it to you.




Regards,
Steve Thompson

ps. It is weeks like this that make me miss Shmuel Metz (and 
sorry if I wrecked your name again, I never was good at spelling it).


pps. As I have done in the past, I will do again. If I find the 
answer to the ATTACHX problem, even if it was me making a 
goofball error, I will report what I found.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Neil Duffee]

Caveat:  as a daily digestor, responses are delayed.

n00b alert: my assembler is rusty & little used these daze but doesn't "LA   
R1,TCB@" load the address of TCB@ into R1.  After "ST  R1,TCB@", I would have 
expected "LR1,TCB@" instead.

(granted it's probably just an e-mail/transcription typo)

>  signature = 8 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?"  Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent"  John Norgauer 2004
"Schrodinger's backup: The condition of any backup is unknown until a restore 
is attempted."  John McKown 2015


-Original Message-
From: Steve Thompson [mailto:ste...@copper.net] 
Sent: October 4, 2016 22:47
Subject: Re: Question About ATTACHX and ECB

But it was pretty simple. [xnip]

The ECB was cleared by MVCL with the Getmained area, but I did have an XC 
SUB_ECB,SUB_ECB.

Then the ATTACHX with PARAM=,ECB=SUB_ECB,and MF=(E,(1)),SF=(E,(15))

   ST  R1,TCB@   Capture the TCB ADDR
[xnip]
WAIT ECB=SUB_ECB
LR3,SUB_ECB

LA   R1,TCB@
DETACH (1)
 [xnip]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Tom Marchant]

On Tue, 4 Oct 2016 22:46:43 -0400, Steve Thompson wrote:

>Sorry, not allowed.

Not allowed what?
You've been asked to post the exact contents of the ECB.
You posted that it was xx40. 
Earlier you had posted that it looked like an RB address.

>I don't have any more time for this.

You have not offered a single word of appreciation to the people who have been 
giving you their time to try to help you find your error.

You continue to assert that there is something wrong with the system, and the 
only evidence that you provide is that you once found a bug before. You refuse 
to provide basic details.

And now YOU don't have time for this.

You just found your way to my s**t list.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

Sorry, not allowed.

But it was pretty simple.

The SVC50 (someone complained about it being complicated) is an 
OLD trick to put breadcrumbs in the CPU trace table. It does 
clear R15 to zero. But it shows you 0 & 1 contents.


It is coded just like this:
SVC  50

You don't have to set any value in any register unless you need 
to save R15's value.


The ECB was cleared by MVCL with the Getmained area, but I did 
have an XC SUB_ECB,SUB_ECB.


Then the ATTACHX with PARAM=,ECB=SUB_ECB,and MF=(E,(1)),SF=(E,(15))

  ST  R1,TCB@   Capture the TCB ADDR

And I did use a variable to hold the PGM address for ATTACHX to 
get to it.


Check of R15 for zero, if not would go to a USER ABEND had I 
taken out the EX 0,* (because I want to see EXACTLY what the REGs 
are when R15<>0.


   WAIT ECB=SUB_ECB
   LR3,SUB_ECB

   LA   R1,TCB@
   DETACH (1)

   ICM   R15,7,SUB_ECB
   BZRETURN

Then some logic to determine which ABEND macro to use based on 
R15 being greater than X'FFF'.


Yes, here and there I had an EX 0,* because S0C3 rarely ever 
happens by accident. And I used that for stepping through the 
code, checking register contents, and the CPU trace table.


BUT, I got so fed up with this, that I stole someone's code for 
doing a LINK just so I could get this routine back into production.


And if you saw what I said to Peter Relson, yes, I have run into 
some strange stuff, opened an ETR and there is now a APAR for a 
problem with ESPIE. It takes a S0C4 in IBM's code.


I don't have any more time for this.

Regards,
Steve Thompson

On 10/04/2016 04:36 PM, Charles Mills wrote:

Wow. Something is odd.

S400 = Explanation: Execute channel program (EXCP) processing found an error
while processing an I/O request. One of
the following is true ...

Possible, but not real likely.

So after IDCAMS runs to RC=0 your ECB contains 4040?

I would check for storage overlays, proper definitions, proper coding of the
ECB= parameter, ...

You want to post the essence of your code?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Thompson
Sent: Tuesday, October 04, 2016 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question About ATTACHX and ECB

Yes. So that would mean that I got, xx40.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Tony Harminc]

On 4 October 2016 at 16:15, Steve Thompson  wrote:
> Yes. So that would mean that I got, xx40.

I'm not sure what the above means, but I agree with Charles that you
are way overcomplicating this. CALLDISP and SVC 50?. Could you not
tell us the actual content of your ECB, as asked a couple of times?
And if you can't show the actual code, give at least a clear outline
without bringing new things into the mix, and without omitting
anything other than truly irrelevant items. Perhaps something like:

  XC  MYECB,MYECB
  ATTACHX EP=blah, ECB=MYECB
  ST  R15,RC
  LOG  'ATTACHX finished with RC=', RC
* Here there are a few instructions that do not call any system
service or modify MYECB.
  WAIT 1,ECB=MYECB
  LOG  'Returned from WAIT'
  LOG  'MYECB content =',MYECB

and then show us the value of MYECB here.

Also, when you say "SYSPRINT shows IDCAMS got CC=0", that doesn't say
that the ATTACHed subtask has finished; it just says that IDCAMS
printed a message about its status.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Charles Mills]

Wow. Something is odd.

S400 = Explanation: Execute channel program (EXCP) processing found an error
while processing an I/O request. One of
the following is true ...

Possible, but not real likely.

So after IDCAMS runs to RC=0 your ECB contains 4040?

I would check for storage overlays, proper definitions, proper coding of the
ECB= parameter, ...

You want to post the essence of your code?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Thompson
Sent: Tuesday, October 04, 2016 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question About ATTACHX and ECB

Yes. So that would mean that I got, xx40.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

Yes. So that would mean that I got, xx40.



On 10/04/2016 02:34 PM, Charles Mills wrote:

the ECB shows a S400


You know the post bit is in the first byte and the RC in the right-hand
bits? So a posted ECB with RC=0 would be 4000?

RC=8 would be 4008

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Charles Mills]

> the ECB shows a S400

You know the post bit is in the first byte and the RC in the right-hand
bits? So a posted ECB with RC=0 would be 4000?

RC=8 would be 4008

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

On 10/04/2016 08:13 AM, Peter Relson wrote:

And what the ECB contains is puzzling to me. Why would my WAIT
get posted, if the task in question had not finished?


It would not. It could not, unless you posted it yourself.
If you're saying that you looked at the ECB after the POST and at that
time it contains an RB address then either the ECB was not POSTed (and you
did not wake up because of the POST but because of something else) or
something else has subsequently waited on it.


Well, IDCAMS, the Attached program, ran to CC=0 according to the 
SYSPRINT DD.





The ATTACHX is done, then in a bit, the WAIT on the named ECB is
done, immediately followed by a CALLDISP (NON-APF) to ensure that
the sub task has "terminated" so that the DETACH doesn't take an
ABEND (which I've had that happen as well).


I don't believe that. The CALLDISP cannot be useful let alone necessary.
DETACH will not abend at any point after the POST has occurred unless, I
suppose, you are issuing it a second time.


OK, but ATTACHX gave back R15=0.

And I do not use the POST macro. So, I'm not doing the POST.

I have taken the CALLDISP out, and still do not get posted with 
CC=0. The last test showed S400.


BTW - I could see where CALLDISP gets done because I'm using the 
CPU trace to see that I hit my SVC50s correctly and I get to see 
all the other trace entries, including when dispatch kicked me 
back off at the instruction following CALLDISP.


Back to this test I ran just before responding to this (which 
does not have CALLDISP in it). There is no summary dump info in 
the JES log for the IDCAMS TCB (again, SYSPRINT shows IDCAMS got 
CC=0).


So, it didn't ABEND. But yet, the ECB shows a S400.

While this might be a non sequitur, I've already discovered a bug 
in "SPIE" (OA51375). And I battled with that one for a week to 
make sure it wasn't me doing something stupid.



The POST is done out of an internal call to DETACH after termination has
completed. When ECB (or ETXR) is used on the ATTACH(X), free-ing of the
TCB itself and de-chaining it from the TCB queues is not done until your
DETACH.


It may or may not need to be APF authorized.


APF authorization is not relevant to the discussion. That may affect the
result of the target task (success or failure) and thus the completion
code of the POST, but not when the ECB is posted.


I dunno, it was in answer to someone asking if IDCAMS was APF 
authorized. I just used one posting to answer a few questions.



Peter Relson
z/OS Core Technology Design



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Charles Mills]

It sounds like you are over-complicating things my friend.

- Clear the high-order byte of the ECB to 0.
- Issue the ATTACHX with the ECB.
- Check for non-zero return code. Note that many errors (like S806) come back 
on the ECB, not from the ATTACHX.
- Do whatever other work the main task wants to do
- WAIT on the ECB
- When the WAIT completes, the task return code is in the ECB. Remember the 
format: an S806 will look like 40806000. A U4000 will look like 4FA0.
- Gather any information you want out of the subtask TCB (optional)
- Issue DETACH

It's that simple. Anything else is I think an over-complication.

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Peter Relson]

>And what the ECB contains is puzzling to me. Why would my WAIT 
>get posted, if the task in question had not finished?

It would not. It could not, unless you posted it yourself.
If you're saying that you looked at the ECB after the POST and at that 
time it contains an RB address then either the ECB was not POSTed (and you 
did not wake up because of the POST but because of something else) or 
something else has subsequently waited on it.


>The ATTACHX is done, then in a bit, the WAIT on the named ECB is 
>done, immediately followed by a CALLDISP (NON-APF) to ensure that 
>the sub task has "terminated" so that the DETACH doesn't take an 
>ABEND (which I've had that happen as well).

I don't believe that. The CALLDISP cannot be useful let alone necessary.
DETACH will not abend at any point after the POST has occurred unless, I 
suppose, you are issuing it a second time.
The POST is done out of an internal call to DETACH after termination has 
completed. When ECB (or ETXR) is used on the ATTACH(X), free-ing of the 
TCB itself and de-chaining it from the TCB queues is not done until your 
DETACH.

>It may or may not need to be APF authorized. 

APF authorization is not relevant to the discussion. That may affect the 
result of the target task (success or failure) and thus the completion 
code of the POST, but not when the ECB is posted.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Tony Harminc]

On 3 October 2016 at 19:52, John McKown  wrote:
> On Mon, Oct 3, 2016 at 6:35 PM, Steve Thompson  wrote:
>
>> It is 0. I know this because I do a compare for anything other than zero
>> going to S0C3 (  EX  0,*).
>>
>
> I used to do that. I really prefer my "new" method (which I think I got
> from someone here).
>
>LT Rx,ECBADDR
>JZ *+2  # THIS ABENDS S0C1

There are many. For a change I like
LE0,*+4
SQER  0,0

which produces, on z/OS, a 0E0-1D abend (square root exception). Not
too many of those happen in a typical app.

But I think we had a strong discussion of these "cute" abends some
years ago. Just issue an appropriate user ABEND macro and be done with
it, was the mainstream thinking.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

You caught onto that.

There are some reasons why I've asked my question(s).

Regards,
Steve Thompson



On 09/30/2016 08:09 PM, Charles Mills wrote:

This is a pretty common sort of thing to do and it works for me 

Are you saying "When I ATTACHX IEFBR14 everything works as I expect but when I 
ATTACHX IDCAMS I get the funny completion code"? That somehow seems unlikely. From 
ATTACHX's point of view, IEFBR14 and IDCAMS are pretty much the same thing.

Not your situation, but IIRC, DETACH does in fact post the ECB if and only if the subtask 
has not yet completed -- that is, DETACH "completes" the subtask. IIRC.

Charles


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[John McKown]

On Mon, Oct 3, 2016 at 6:50 PM, Steve Thompson  wrote:

> ​
>
>
> For the rest of you, sorry for the delay in responding, I had so much
> going on this weekend that I had to wait until sundown tonight before I
> could reply (Rosh Hashanah).
>

​A belated La Shana Tova!​ A peaceful and prosperous 5777.



> Regards,
> Steve Thompson
>
>

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[John McKown]

On Mon, Oct 3, 2016 at 6:35 PM, Steve Thompson  wrote:

> It is 0. I know this because I do a compare for anything other than zero
> going to S0C3 (  EX  0,*).
>

​I used to do that. I really prefer my "new" method (which I think I got
from someone here).

   LT Rx,ECBADDR
   JZ *+2  # THIS ABENDS S0C1


>
> Regards,
> Steve Thompson
>
>

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

Peter:

I'll be double-checking that, but, the WHOLE scratch area where 
the ECB is, is set to x'00' by an MVCL before I ever get to the 
ATTACHX (yes, the area is bigger than 1K).


And what the ECB contains is puzzling to me. Why would my WAIT 
get posted, if the task in question had not finished?


But, just to be sure, I can put an XC immediately ahead of the 
ATTACHX.


The ATTACHX is done, then in a bit, the WAIT on the named ECB is 
done, immediately followed by a CALLDISP (NON-APF) to ensure that 
the sub task has "terminated" so that the DETACH doesn't take an 
ABEND (which I've had that happen as well).


IDCAMS does take a bit to run, with just a comment line so it 
will have something to process.


Another person asked about IDCAMS. It may or may not need to be 
APF authorized. In any case, my code is NOT APF authorized. So as 
long as what is requested does not need authorization (APF that 
is), this works (has been for DECADES with the original version 
of the code that was RMODE24, NON-G3 compliant (if you don't know 
look up the history on I-Bank/D-Bank and 256 byte cache lines).


For the rest of you, sorry for the delay in responding, I had so 
much going on this weekend that I had to wait until sundown 
tonight before I could reply (Rosh Hashanah).


Regards,
Steve Thompson


On 10/02/2016 05:40 PM, Peter Relson wrote:

What is missing from the OP is just when he has looked at the ECB.

Given that it has an "RB address" it almost certainly has the "wait bit"
on. It has not yet been posted.

So why is there a question? Once the ECB is posted it will have the value
documented.

The ECB is posted when the attached task ends (whether normally or
abnormally); it is then up to the attacher to issue DETACH.

As has been alluded, it is also important to have initialized (usually to
zero) the ECB prior to issuing the ATTACHX.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Steve Thompson]

It is 0. I know this because I do a compare for anything other 
than zero going to S0C3 (  EX  0,*).


Regards,
Steve Thompson

On 10/03/2016 03:11 AM, Rupert Reynolds wrote:

To get things clear, what's the RC from ATTACHX?

Rupert
On 1 Oct 2016 00:05, "Steve Thompson"  wrote:


I'm doing some work and needed to do an ATTACHX with an ECB.

So for test purposes I'm attaching IDCAMS. It runs and gives CC=0.

Ok, in the main task, I've done the ATTACHX with the ECB and then went and
did a few instructions and then did a WAIT for the ECB.

CPU trace shows I don't get dispatch again until the POST is effected for
the ECB.

I've looked at the ECB and my understanding of the doc for ATTACHX is that
it gets posted with the CC from the sub task, or ABEND if it is that the
program ABENDed.

My ECB has, what appears to be, an RB address.

Now I did have it giving me back the zero (hey, ATTACH IEFBR14, it works).

But now with IDCAMS or an internal program (written to give S0C3 to test
what happens), I'm getting other than what is documented.

I've taken various dumps, I've been tracing using SVC 50 (originally
documented as NOP now reserved, but it still works as NOP).

I tried capturing the contents of the ECB before issuing the DETACH in the
case it gets changed by the effect of the DETACH, but it is the same before
and after.

I'm just baffled.

Anyone know of a working example I could take a look at?

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Rupert Reynolds]

To get things clear, what's the RC from ATTACHX?

Rupert
On 1 Oct 2016 00:05, "Steve Thompson"  wrote:

> I'm doing some work and needed to do an ATTACHX with an ECB.
>
> So for test purposes I'm attaching IDCAMS. It runs and gives CC=0.
>
> Ok, in the main task, I've done the ATTACHX with the ECB and then went and
> did a few instructions and then did a WAIT for the ECB.
>
> CPU trace shows I don't get dispatch again until the POST is effected for
> the ECB.
>
> I've looked at the ECB and my understanding of the doc for ATTACHX is that
> it gets posted with the CC from the sub task, or ABEND if it is that the
> program ABENDed.
>
> My ECB has, what appears to be, an RB address.
>
> Now I did have it giving me back the zero (hey, ATTACH IEFBR14, it works).
>
> But now with IDCAMS or an internal program (written to give S0C3 to test
> what happens), I'm getting other than what is documented.
>
> I've taken various dumps, I've been tracing using SVC 50 (originally
> documented as NOP now reserved, but it still works as NOP).
>
> I tried capturing the contents of the ECB before issuing the DETACH in the
> case it gets changed by the effect of the DETACH, but it is the same before
> and after.
>
> I'm just baffled.
>
> Anyone know of a working example I could take a look at?
>
> Regards,
> Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Peter Relson]

What is missing from the OP is just when he has looked at the ECB.

Given that it has an "RB address" it almost certainly has the "wait bit" 
on. It has not yet been posted.

So why is there a question? Once the ECB is posted it will have the value 
documented.

The ECB is posted when the attached task ends (whether normally or 
abnormally); it is then up to the attacher to issue DETACH.

As has been alluded, it is also important to have initialized (usually to 
zero) the ECB prior to issuing the ATTACHX.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Mike Schwab]

Is IDCAMS and APF program?

On Fri, Sep 30, 2016 at 7:09 PM, Charles Mills  wrote:
> This is a pretty common sort of thing to do and it works for me 
>
> Are you saying "When I ATTACHX IEFBR14 everything works as I expect but when 
> I ATTACHX IDCAMS I get the funny completion code"? That somehow seems 
> unlikely. From ATTACHX's point of view, IEFBR14 and IDCAMS are pretty much 
> the same thing.
>
> Not your situation, but IIRC, DETACH does in fact post the ECB if and only if 
> the subtask has not yet completed -- that is, DETACH "completes" the subtask. 
> IIRC.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Steve Thompson
> Sent: Friday, September 30, 2016 4:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question About ATTACHX and ECB
>
> I'm doing some work and needed to do an ATTACHX with an ECB.
>
> So for test purposes I'm attaching IDCAMS. It runs and gives CC=0.
>
> Ok, in the main task, I've done the ATTACHX with the ECB and then went and 
> did a few instructions and then did a WAIT for the ECB.
>
> CPU trace shows I don't get dispatch again until the POST is effected for the 
> ECB.
>
> I've looked at the ECB and my understanding of the doc for ATTACHX is that it 
> gets posted with the CC from the sub task, or ABEND if it is that the program 
> ABENDed.
>
> My ECB has, what appears to be, an RB address.
>
> Now I did have it giving me back the zero (hey, ATTACH IEFBR14, it works).
>
> But now with IDCAMS or an internal program (written to give S0C3 to test what 
> happens), I'm getting other than what is documented.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Charles Mills]

This is a pretty common sort of thing to do and it works for me 

Are you saying "When I ATTACHX IEFBR14 everything works as I expect but when I 
ATTACHX IDCAMS I get the funny completion code"? That somehow seems unlikely. 
From ATTACHX's point of view, IEFBR14 and IDCAMS are pretty much the same thing.

Not your situation, but IIRC, DETACH does in fact post the ECB if and only if 
the subtask has not yet completed -- that is, DETACH "completes" the subtask. 
IIRC.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Friday, September 30, 2016 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question About ATTACHX and ECB

I'm doing some work and needed to do an ATTACHX with an ECB.

So for test purposes I'm attaching IDCAMS. It runs and gives CC=0.

Ok, in the main task, I've done the ATTACHX with the ECB and then went and did 
a few instructions and then did a WAIT for the ECB.

CPU trace shows I don't get dispatch again until the POST is effected for the 
ECB.

I've looked at the ECB and my understanding of the doc for ATTACHX is that it 
gets posted with the CC from the sub task, or ABEND if it is that the program 
ABENDed.

My ECB has, what appears to be, an RB address.

Now I did have it giving me back the zero (hey, ATTACH IEFBR14, it works).

But now with IDCAMS or an internal program (written to give S0C3 to test what 
happens), I'm getting other than what is documented.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question About ATTACHX and ECB

[Tony Harminc]

On 30 September 2016 at 19:05, Steve Thompson  wrote:
> I'm doing some work and needed to do an ATTACHX with an ECB.
>
> So for test purposes I'm attaching IDCAMS. It runs and gives CC=0.

OK

> Ok, in the main task, I've done the ATTACHX with the ECB and then went and
> did a few instructions and then did a WAIT for the ECB.

Did you zero the ECB before you did the ATTACHX? If the POST bit
(X'40') is already on when you WAIT...

> CPU trace shows I don't get dispatch again until the POST is effected for the 
> ECB.

OK. What does the POST trace entry look like? R0 contains the value to
go in the ECB.

> I've looked at the ECB

After you regain control after the POST, I assume...

> and my understanding of the doc for ATTACHX is that
> it gets posted with the CC from the sub task, or ABEND if it is that the
> program ABENDed.

OK

> My ECB has, what appears to be, an RB address.

Is the POST bit (X'40') on? The WAIT bit (X'80')? Perhaps tell us the
exact content of the ECB.

> Now I did have it giving me back the zero (hey, ATTACH IEFBR14, it works).

> But now with IDCAMS or an internal program (written to give S0C3 to test
> what happens), I'm getting other than what is documented.

I'm not sure what this means. When you ATTACH IEFBR14, your ECB looks
good when your main wakes up? But when you ATTACH IDCAMS or other
programs, it has an RB address? Or something else?

Are you quite sure the ECB you WAITed on is one and the same as the
ECB you gave to ATTACHX? Particularly if neither is initialized, or is
in use for some other purpose, there's room for lots of trouble.

> I've taken various dumps, I've been tracing using SVC 50 (originally
> documented as NOP now reserved, but it still works as NOP).

How does SVC 50 play into this? As a trace table entry marker?

> I tried capturing the contents of the ECB before issuing the DETACH in the
> case it gets changed by the effect of the DETACH, but it is the same before
> and after.

DETACH shouldn't affect this ECB.

> I'm just baffled.

So far, so am I. But I'll bet there's a simple problem here that
you're not seeing.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN