Re: RETRY - was ARR and CSVQUERY

2023-12-24 Thread Seymour J Metz
Jaffe Sent: Sunday, December 24, 2023 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RETRY - was ARR and CSVQUERY On 12/24/2023 9:35 AM, Tom Brennan wrote: > Thanks Peter! Yes, it was the surprise of an 0C4 when I expected 0C1. > Sometimes when totally confusing things like that happen I

Re: RETRY - was ARR and CSVQUERY

2023-12-24 Thread Ed Jaffe
On 12/24/2023 9:35 AM, Tom Brennan wrote: Thanks Peter!  Yes, it was the surprise of an 0C4 when I expected 0C1. Sometimes when totally confusing things like that happen I first assume the computer itself is at fault, not the code I'm working on.  And guess what, it's always the code :) This

Re: RETRY - was ARR and CSVQUERY

2023-12-24 Thread Binyamin Dissen
Or the hardware. Certain machine checks while masked will force a check-stop. On Sun, 24 Dec 2023 12:58:06 -0600 Jon Perryman wrote: :>Hi Tom, :>I think Peter misinterpreted your question because you provided too much information. :>> Peter Relson wrote: :>> I'm now thinking you just meant

Re: RETRY - was ARR and CSVQUERY

2023-12-24 Thread Jon Perryman
Hi Tom, I think Peter misinterpreted your question because you provided too much information. > Peter Relson wrote: > I'm now thinking you just meant that you were surprised that the recovery > routine did not complete successfully. I think you are asking the academic question if there is a

Re: RETRY - was ARR and CSVQUERY

2023-12-24 Thread Jay Maynard
Doggone computers...durn things always do what you tell them to. On Sun, Dec 24, 2023 at 11:35 AM Tom Brennan wrote: > Thanks Peter! Yes, it was the surprise of an 0C4 when I expected 0C1. > Sometimes when totally confusing things like that happen I first assume > the computer itself is at

Re: RETRY - was ARR and CSVQUERY

2023-12-24 Thread Tom Brennan
Thanks Peter! Yes, it was the surprise of an 0C4 when I expected 0C1. Sometimes when totally confusing things like that happen I first assume the computer itself is at fault, not the code I'm working on. And guess what, it's always the code :) On 12/24/2023 5:58 AM, Peter Relson wrote: Tom

Re: RETRY - was ARR and CSVQUERY

2023-12-24 Thread Peter Relson
Tom B wrote I was referring to my experience with a JES2 exit which setup its own recovery routine. In that code you could see it free any getmain'd memory, etc. like you mentioned. But also in that code was an error that caused an 0C4. So when the x'00' I added for temporary debugging ran

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Jon Perryman
On Sat, 23 Dec 2023 21:02:18 +0200, Binyamin Dissen wrote: >On Fri, 22 Dec 2023 15:07:33 -0800 Tom Brennan >wrote: > >:>So are you implying that in z/OS there are environments where I can run >:>a program without any built-in basic recovery? > >Yes. Most batch jobs run that way. Recovery in

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Jon Perryman
On Sat, 23 Dec 2023 15:54:38 +, Peter Relson wrote: >I view their being two main reasons for recovery (and not necessarily in the >order I show): Everyone ignores the third main reason which is stopping abends from becoming catastrophic. IBM knows this is ignored and plans accordingly.

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Binyamin Dissen
Only if you do tricky stuff. Such as playing with the PFLIH. If you get a program check there you may get a disabled wait. The FLIH will recognize unexpected recursion. Don't know if there is a "standard" IBM supported way to do this, though. On Sat, 23 Dec 2023 10:20:58 -0800 Tom Brennan

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Binyamin Dissen
On Fri, 22 Dec 2023 15:07:33 -0800 Tom Brennan wrote: :>So are you implying that in z/OS there are environments where I can run :>a program without any built-in basic recovery? Yes. Most batch jobs run that way. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software,

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Binyamin Dissen
On Fri, 22 Dec 2023 15:09:59 -0600 Jon Perryman wrote: :>On Fri, 22 Dec 2023 10:26:41 -0800, Tom Brennan wrote: :>>But I think it's overkill for a recovery routine to have it's own :>>recovery routine (if that's even possible in a JES2 exit environment). :>z/OS exits have built in recovery,

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Tom Brennan
Yes, and I'd add: if you get 4096 - free 4096 Don't free 1024 like I did once. Code like that tests just fine but then dies 8 hours later when the address space runs out :) On 12/23/2023 8:12 AM, Colin Paice wrote: Expanding on what Peter said. It is horses for courses. If you are writing

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Tom Brennan
Thanks Peter! I always appreciate your responses and also the responses from others at IBM. But I was trying to ask a question that I may not be able to ask correctly. Let me try anyway: I was referring to my experience with a JES2 exit which setup its own recovery routine. In that code

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Colin Paice
Expanding on what Peter said. It is horses for courses. If you are writing a program which can be running for months before restart you need to clean up everything - for example ensure any storage obtained is released. Someone gave me some guidance if you open it - close it if you get it - free

Re: RETRY - was ARR and CSVQUERY

2023-12-23 Thread Peter Relson
Tom B wrote >So are you implying that in z/OS there are environments where I can run >a program without any built-in basic recovery? To be a bit snide, you "can" run a program without any recovery, of course. Whether you should or not is an entirely different question. I view their being two

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Jon Perryman
On Fri, 22 Dec 2023 18:35:52 -0800, Tom Brennan wrote: >Never mind, my question wasn't clear and I don't know how to better explain it. >> >>> So are you implying that in z/OS there are environments where I can run >>> a program without any built-in basic recovery? Sorry I misunderstood that

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Tom Brennan
Nevermind, my question wasn't clear and I don't know how to better explain it. On 12/22/2023 5:25 PM, Jon Perryman wrote: On Fri, 22 Dec 2023 15:07:33 -0800, Tom Brennan wrote: So are you implying that in z/OS there are environments where I can run a program without any built-in basic

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Jon Perryman
On Fri, 22 Dec 2023 15:07:33 -0800, Tom Brennan wrote: >So are you implying that in z/OS there are environments where I can run >a program without any built-in basic recovery? I don't condone omitting recovery but CBTTAPE.ORG has many exits that do not include any recovery. The vast majority

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Tom Brennan
So are you implying that in z/OS there are environments where I can run a program without any built-in basic recovery? On 12/22/2023 1:09 PM, Jon Perryman wrote: On Fri, 22 Dec 2023 10:26:41 -0800, Tom Brennan wrote: But I think it's overkill for a recovery routine to have it's own

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Jon Perryman
On Fri, 22 Dec 2023 10:26:41 -0800, Tom Brennan wrote: >But I think it's overkill for a recovery routine to have it's own >recovery routine (if that's even possible in a JES2 exit environment). z/OS exits have built in recovery, diagnostics and recursive abend handling. Since IBM did the work

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Tom Brennan
I remember adding X'00' to the instruction stream of a JES2 exit so it would abend on a test box, in order to dump data at that point. I was very confused because it got an 0C4 instead. Turned out the previous owner apparently never tested the recovery routine. But I think it's overkill for

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Tony Harminc
On Fri, 22 Dec 2023 at 12:16, Jon Perryman wrote: [...] > You missed my point where I was trying to get the OP to understand some > fundamental mistakes made with ARR's and PC routines. Maybe you can help > clarify what I did not make clear. My comment about SDWA and alet 2 (HOME) > was prefaced

Re: RETRY - was ARR and CSVQUERY

2023-12-22 Thread Jon Perryman
On Thu, 21 Dec 2023 13:37:21 +, Peter Relson wrote: >>Jon P wrote >>The SDWA can be referenced by alet 0 or alet 2. >if this was meant to indicate that you could choose either, that wouldn't be >true for an ESTAEX or ARR or IEAARR established for primary <> home. Hi Peter, You missed my

Re: RETRY - was ARR and CSVQUERY

2023-12-21 Thread Jon Perryman
On Wed, 20 Dec 2023 00:56:14 -0500, Tony Harminc wrote: >On Wed, 20 Dec 2023 at 00:48, Jon Perryman wrote: >> I locate the base reg and verify the branch around the module eyecatcher >The trick is to not abend when you try looking at the eyecatcher. > A wild branch can easily destroy what you

Re: RETRY - was ARR and CSVQUERY

2023-12-21 Thread Peter Relson
Jon P wrote The SDWA can be referenced by alet 0 or alet 2. Perhaps this was referring to the specific example. But in general, if this was meant to indicate that you could choose either, that wouldn't be true for an ESTAEX or ARR or IEAARR established for primary <> home. The SDWA is in the

Re: RETRY - was ARR and CSVQUERY

2023-12-20 Thread Peter Relson
If you haven't changed the data or conceivably the environment, retrying the instruction will get the same result. That shouldn't be a surprise. If you were to try, you'd likely have to decipher the instruction so that you could figure out what data and/or regs it was using and make sure to

Re: RETRY - was ARR and CSVQUERY

2023-12-19 Thread Tony Harminc
On Wed, 20 Dec 2023 at 00:48, Jon Perryman wrote: > On Tue, 19 Dec 2023 21:20:29 -0500, Joseph Reichman > wrote: > [...] > >If you are looking for entry point modname if primary CSVQUERY would give > you that > > CSVQUERY will not always work which is why IBM diagnostic messages do not >

Re: RETRY - was ARR and CSVQUERY

2023-12-19 Thread Jon Perryman
On Tue, 19 Dec 2023 21:20:29 -0500, Joseph Reichman wrote: >It seems to me that SDWA has values from the home address space such as >SDWARBAD For the CBT recovery example, the PC definition has PRIMARY (alet 0) and HOME (alet 2) point to the PC owner ASID. Secondary (alet 1) is the PC

Re: RETRY - was ARR and CSVQUERY

2023-12-19 Thread Jon Perryman
On Tue, 19 Dec 2023 23:13:46 GMT, esst...@juno.com wrote: . >I have been following the thread on ARR and CSVQUERY, and started >thinking about a retry routine. The discussion is about a CBT file that has been referred

Re: RETRY - was ARR and CSVQUERY

2023-12-19 Thread Joseph Reichman
It seems to me that SDWA has values from the home address space such as SDWARBAD If you are looking for entry point modname if primary CSVQUERY would give you that > On Dec 19, 2023, at 6:35 PM, Binyamin Dissen > wrote: > > Retry means retry the UOW, not (necessarily) the failed

Re: RETRY - was ARR and CSVQUERY

2023-12-19 Thread Binyamin Dissen
Retry means retry the UOW, not (necessarily) the failed instruction. For example, if the code is aware that a control block / address space may be gone while it wou;d be referenced, retrying means branching to the logic where the item was known to be gone. Although I actually had a case where

RETRY - was ARR and CSVQUERY

2023-12-19 Thread esst...@juno.com
* Hello, . I have been following the thread on ARR and CSVQUERY, and started thinking about a retry routine.