EXECIO vs. Sx37

[Steve Thompson]

I have a large REXX that uses EXECIO to write members into a PDS (alloc,
execio ...(...finis), free...).

Ok, so I write or re-write a member some number of times and get an Sx37.
Well, that gives RC=20, and in that case I go execute an IEBCOPY within
the REXX code.

What happens if the ABEND is NOT a Sx37? Well, I go do the IEBCOPY....
come back and redrive to get the S??? ABEND again. I want to do a better
job of error trapping and recovery than just blindly doing the compress.

I have tried using OUTTRAP and can't capture the message(s) so I can
interrogate them to know what is the correct course of action for recovery
(while I CAN do that for ocopy!!).

The irony of this is, other code I have written for doing dump analysis
with IPCS, I've jumped through hoops to get rid of messages that just
become noise to the user. Here I need to capture message to interrogate
them and I just can't seem to find the way to do it.

I have been using Google for the past hour and I have not seen one example
of how to capture these messages, but I did see an old post that says it
is impossible.

I have been searching all the PDFs that I have for TSO/REXX and I just
don't see how to do this.

Is there some method that I am missing or is that old post correct, that
you can't intercept or capture those IEC032I messages (or something
similar) because they are done via WTO? What about the IRX0250E messages,
that show up in the SYSTSPRT with the other output I'm creating?



Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Adrian Stern]

Make the pds into a library

[Steve Thompson]

From: Adrian Stern <adrian...@GMAIL.COM>
Date: 02/20/2013 01:04 AM

Make the pds into a library

<SNIPPAGE>

What happens if the ABEND is NOT a Sx37? Well, I go do the IEBCOPY....
come back and redrive to get the S??? ABEND again. I want to do a better
job of error trapping and recovery than just blindly doing the compress.

I have tried using OUTTRAP and can't capture the message(s) so I can
interrogate them to know what is the correct course of action for recovery
(while I CAN do that for ocopy!!).

<SNIPPAGE>

That is not an option at this point. We discussed this at length and there
is a problem where PDSE does not allow us to truncate it like you can a
PDS (compress and then release the free space).

Meanwhile, your approach ignores the problem that I hit: "redrive to get
the S??? ABEND again."

Even a PDSE can fill up or have other errors (which from experience make
them a total loss, having to be deleted and redefined).

So it turns out that some simple answers miss other issues. EXECIO returns
RC=20 regardless of the type of ABEND or error it got. There are other I/O
errors and/or storage errors that one can get while doing I/O -- but no
way that I've found, so far, that allow me to interrogate those messages
to know what to do.

[Paul Gilmartin]

On Feb 20, 2013, at 08:01, Steve Thompson wrote:

> From: Adrian Stern <adrian...@GMAIL.COM>
> Date: 02/20/2013 01:04 AM
>
> Make the pds into a library
>
> <SNIPPAGE>
>

> Even a PDSE can fill up or have other errors (which from experience make
> them a total loss, having to be deleted and redefined).
>
> So it turns out that some simple answers miss other issues. EXECIO returns
> RC=20 regardless of the type of ABEND or error it got. There are other I/O
> errors and/or storage errors that one can get while doing I/O -- but no
> way that I've found, so far, that allow me to interrogate those messages
> to know what to do.
>

Make the PDS into a z/OS UNIX directory. Write to it with
address SYSCALL instead of EXECIO. Address SYSCALL returns
very distinct error diagnostics.

-- gil

[Steve Thompson]

From: Paul Gilmartin <PaulGB...@AIM.COM>
Date: 02/20/2013 09:25 AM

On Feb 20, 2013, at 08:01, Steve Thompson wrote:

> From: Adrian Stern <adrian...@GMAIL.COM>
> Date: 02/20/2013 01:04 AM
>
> Make the pds into a library
>
> <SNIPPAGE>
>
> Even a PDSE can fill up or have other errors (which from experience make
> them a total loss, having to be deleted and redefined).
>
> So it turns out that some simple answers miss other issues. EXECIO
returns
> RC=20 regardless of the type of ABEND or error it got. There are other
I/O
> errors and/or storage errors that one can get while doing I/O -- but no
> way that I've found, so far, that allow me to interrogate those messages
> to know what to do.
>
Make the PDS into a z/OS UNIX directory. Write to it with
address SYSCALL instead of EXECIO. Address SYSCALL returns
very distinct error diagnostics.

<snip>

If that had been a valid option, I wouldn't have been having problems with
ocopy to start with.

Regards,
Steve Thompson

[John McKown]

Just for my own edification, are you open to replacing the EXECIO with some
other, functionally equivalent, facility? I don't have one on hand, but it
appears to me that EXECIO is simply not designed to do what you want. So
maybe what is needed is a "superset EXECIO" function. EXECIO is not a REXX
language facility, per se. It is an "external" routine which is designed to
work within REXX. Which means that we (OK, somebody) could run a
functionally equivalent routine in some compiled language.

Just a thought. I _might_ have the talent to write such a thing. But
getting the physical energy is another matter. I hate winter.

--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

[Adrian Stern]

Sorry - was this a batch job?

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Steve Thompson

[Steve Thompson]

From: John McKown <john.arch...@GMAIL.COM>
Date: 02/20/2013 10:11 AM

Just for my own edification, are you open to replacing the EXECIO with
some
other, functionally equivalent, facility? I don't have one on hand, but it
appears to me that EXECIO is simply not designed to do what you want. So
maybe what is needed is a "superset EXECIO" function. EXECIO is not a REXX
language facility, per se. It is an "external" routine which is designed
to
work within REXX. Which means that we (OK, somebody) could run a
functionally equivalent routine in some compiled language.

Just a thought. I _might_ have the talent to write such a thing. But
getting the physical energy is another matter. I hate winter.

<SNIPPAGE>

John:

No, I'm not trying to replace EXECIO.

I'm trying to work within the language and the function/features provided.
I do not have the time nor have I been authorized to write a replacement
for the I/O functions of REXX in the MVS world. Had I been authorized for
that, I would do all the error recovery -- since I was, at one time, a
developer of MVS privileged code (SVCs, FRRs, SRBs, etc.) for different
ISVs and IBM. Come to think of it, referring to the COBOL thread on
IBM-Main, I could do the I/O entirely in COBOL (wouldn't be the first time
I dropped to that old workhorse to get something done FAST). ;-)

The thing I am writing is expected to be a fire and forget automatic tool
to solve a problem with collecting source that has been edited on
different platforms. The original tool was in Java, and it was *not*
mainframe based, yet it was trying to provide source to z/OS and then xfer
certain things to zVM. And it, as is typical of such development (in my
not so limited experience) did timings so that it could know when to issue
the next command and other things that made it unreliable.

I tried to fix it, but the amount of time to overhaul it, versus re-write
the functions in REXX... Management told me to "git er done". I am not far
enough along to use ISPF/PDF library management tools. I am having to get
data (source) from the Unix System Services side. And this is where I keep
having heartburn.

At this point, I am on the edge of discussing things that IBM considers
"internal/confidential" so I can't go into much more detail than this.

[Steve Thompson]

Let's get ourselves on the same page -- now that I have things working as
well as I can.

This is not a multiple step batch job running REXX. The REXX code is
reading a file produced by another REXX that ran under ISPF.

"Why would you do that?!?" you ask.

Because of penalties that a user gets for doing batch work under TSO. In
a worse case scenario, this REXX tool that I'm writing will be running, in
batch, for an hour doing massive amounts of I/O across many data sets
(DSORG=PS & PO) along with files in the HFS. Try this in a TSO session and
your terminal will be hung for hours, and someone will have to hit <ENTER>
every so often to get rid of the "***" that will appear at the bottom of
the screen now and then (and that's with all user selectable diagnostics
off, and minimal use of SAY for audit trail requirements)

To give you an idea, just the time it takes to find and determine which
files to copy to the PDSes takes up to 5 minutes in the TSO/ISPF session.
NO processing of the files themselves, just running the selection criteria
to capture the full path names (for ocopy in the batch REXX). .

The processing of the selected files is done with a REXX running a large
loop. We have been talking about, so far, the problems with all the
hassles I've had with source that have been edited on other platforms to
be compiled on MVS/VM.

IEBGENER doesn't do what I need (first thing I tried). ocopy does for 90+%
of what I need (I had to write some special REXX code to solve the
show-stopper 10%).

EXECIO gives RC=1 when it truncates a record (something ocopy should have
done). But when it can't write to the PDS for any reason, it gives RC=20.
So I need to know why it gave the RC=20. Blindly calling IEBCOPY for a
compress in place may be a waste of cycles because we may have a different
problem that has to be fixed.

OUTTRAP does not capture these messages. MSG(ON) does not capture them,
only causes them to be written to SYSTSPRT.

Ending the step and then starting again with a new step is not feasable,
because you can only have so many steps in a JOB and you can't jump
backwards...

I really need to be able to write some REXX functions or exits to solve
these problems, but I have not been given the authority to do this.
Everything has to be CLIST/REXX, TSO Commands, ISPF/PDF functions, and/or
IBM utility programs.

So, I've gotten things to work as best as I can for now. Now I'm off to
the next set of things that have to be done before I have to go do the
related versions of this on VM (where errors during I/O can be diagnosed
inside of REXX).

Thanks for the brain storming,

[Paul Gilmartin]

On Feb 21, 2013, at 08:02, Steve Thompson wrote:
>
> IEBGENER doesn't do what I need (first thing I tried). ocopy does for 90+%
> of what I need (I had to write some special REXX code to solve the
> show-stopper 10%).
>

I'm curious; what's the deficiency in IEBGENER?

> EXECIO gives RC=1 when it truncates a record (something ocopy should have
> done). But when it can't write to the PDS for any reason, it gives RC=20.
> So I need to know why it gave the RC=20. Blindly calling IEBCOPY for a
> compress in place may be a waste of cycles because we may have a different
> problem that has to be fixed.
>

Again, if you allocate SYSUT1 for IEBGENER with the LRECL of
your targed data set, it fails with a meaningful SYNADAF
diagnostic. I don't know whether you can trap that, and of
course there's no recovery, which you probably want.

-- gil

[Steve Thompson]

From: Paul Gilmartin <PaulGB...@AIM.COM>
Date: 02/21/2013 09:28 AM

On Feb 21, 2013, at 08:02, Steve Thompson wrote:
>
> IEBGENER doesn't do what I need (first thing I tried). ocopy does for
90+%
> of what I need (I had to write some special REXX code to solve the
> show-stopper 10%).
>
I'm curious; what's the deficiency in IEBGENER?

<snippage>

unicode/ascii to Code page 1047. OPTCD=Q just doesn't get it.

And maybe I really screwed things up on the SYSUT1 DD, but IEBGENER had a
cow when it did a GET/READ and the records didn't have RDW/BDW, no length
info for undefined....

When I do ALLOC with a path, I do not know what that file actually looks
like, because it is mounted to the HFS. ALL the files I have to search
directory paths for actually exists on another system in another lab. I do
not know what the machine is.

And once this is working (what I'm building), there are vibes that it will
be used to fetch from other platforms that can be mounted to our HFS. So I
have to write as generically as I can. (What I wouldn't give for C:D being
installed on all these platforms -- all this conversion and write to PDSes
would be done).

[Dave Salt]

I haven't been following this thread very closely so let me make sure I understand the problem. You're trying to copy UNIX files into a PDS, but if one of the copies fails there's no error message to explain why, just RC=20?

If that's the situation, and if you've tried everything else and nothing works, then here's a possibility. When the copy fails, what if you allocate a brand new (temporary) PDS and copy the UNIX file into that. Then, try to LMCOPY the member from the new PDS to the target PDS. If that fails, LMCOPY should give you a proper error message explaining why.

Dave Salt

SimpList(tm) - try it; you'll get it!

http://www.mackinney.com/products/program-development/simplist.html


> Date: Thu, 21 Feb 2013 08:12:26 -0700
> From: PaulGB...@AIM.COM
> Subject: Re: EXECIO vs. Sx37
> To: TSO-...@VM.MARIST.EDU

[Ken MacKenzie]

Have you tried using OCOPY?



Ken MacKenzie
Pramerica Systems Ireland Limited
is a private company limited by shares
incorporated and registered in the Republic of Ireland with registered
number 319900
and registered office at 6th Floor, South Bank House, Barrow Street,
Dublin 4, Ireland.

From: Dave Salt <ds...@HOTMAIL.COM>
To: TSO-...@VM.MARIST.EDU,
Date: 21/02/2013 16:04
Subject: Re: [TSO-REXX] EXECIO vs. Sx37

[Steve Thompson]

From: Dave Salt <ds...@HOTMAIL.COM>
Date: 02/21/2013 10:08 AM

I haven't been following this thread very closely so let me make sure I
understand the problem. You're trying to copy UNIX files into a PDS, but
if one of the copies fails there's no error message to explain why, just
RC=20?

If that's the situation, and if you've tried everything else and nothing
works, then here's a possibility. When the copy fails, what if you
allocate a brand new (temporary) PDS and copy the UNIX file into that.
Then, try to LMCOPY the member from the new PDS to the target PDS. If that
fails, LMCOPY should give you a proper error message explaining why.

<snip>

Ok, you come in at the end of a conversation, and the last thing you hear
is, "..his hat blew off and is stuck in the truck's radiator."

And now you want me to explain the whole thing again? lol.

No, his hat wasn't tied on, and it was the guy that started the APU that
blew the hat off and firmly wedged in the radiator. (Ok, so I'm a
frustrated pilot and am in serious need of flight time -- gotta turn fuel
into noise you know).

Addressing just the RC=20 problem: happens no matter what the ABEND is
that occurs during the EXECIO. It is possible that the PDS is out of
directory space and not full of gas. No, we can't use a PDSE because of a
feature that it does not have support for at this point.

I have the data copied from the HFS to the PDS and during that it was
translated using codepage 1047 so that all the wonderful braces, brackets,
etc. that c/C++ use are not lost.

Now, we return you to your regularly scheduled wrecking of REXX. (the
aural play on words in English is much better).

Regards,
Steve Thompson

[Dave Salt]

> Addressing just the RC=20 problem: happens no matter what the ABEND is
> that occurs during the EXECIO. It is possible that the PDS is out of
> directory space and not full of gas.

Obviously I don't understand the problem because I don't see why my suggestion wouldn't work.

Dave Salt

SimpList(tm) - try it; you'll get it!

http://www.mackinney.com/products/program-development/simplist.html

> Date: Thu, 21 Feb 2013 10:54:00 -0600
> From: stho...@US.IBM.COM

> Subject: Re: EXECIO vs. Sx37
> To: TSO-...@VM.MARIST.EDU
>

[Kopischke, David G.]

Have you any idea what's causing the error ??? I think you said it's not a space nor directory issue. Since compressing doesn't help, might it be a wrong length record ??? If so, is there a way to detect that while you're loading the PDS ???

This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.

[Adrian Stern]

So you didn't like the two-step job idea?

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Steve Thompson
Sent: den 21 februari 2013 17:54
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] EXECIO vs. Sx37

[Adrian Stern]

To use lmcopy he'd have to be running under ispf

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Dave Salt
Sent: den 21 februari 2013 18:06
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] EXECIO vs. Sx37

[Dave Salt]

> From: adrian...@GMAIL.COM

> To use lmcopy he'd have to be running under ispf

Yes.

Dave Salt

SimpList(tm) - try it; you'll get it!

http://www.mackinney.com/products/program-development/simplist.html

> Date: Thu, 21 Feb 2013 19:29:00 +0100
> From: adrian...@GMAIL.COM

[Paul Gilmartin]

On 2013-02-21 11:47, Dave Salt wrote:
>> From: adrian...@GMAIL.COM
>> To use lmcopy he'd have to be running under ispf
>
> Yes.
>

That can be arranged, even in a batch job.

What flavor Unicode do you have? UTF-8? Unicode
conversion might need to be handled in a separate
step.

You mention a problem with lack of RDWs. FILEDATA=TEXT
should solve that. But not for one of the 16-bit representations
of Unicode, nor for ASCII.

-- gil

[Paul Gilmartin]

On 2013-02-21 08:42, Steve Thompson wrote:
>>
> I'm curious; what's the deficiency in IEBGENER?
> <snippage>
> unicode/ascii to Code page 1047. OPTCD=Q just doesn't get it.
>

Don't even think of using OPTCD=Q in the 21st century. The JCL
RM says, "... the data set must reside on magnetic tape..."
It uses the wretched IGC0010C conversion table which converts
to/from an ASCII code page that no one has ever used but IBM.

-- gil

[Steve Thompson]

I'm out of this discussion. I've gotten things working as far as I can for
error recovery. I have the codepage translation working (via ocopy).

At this point, unless there is a change that will cut my CPU and/or Wall
time by 50%, I have to move on. I have to get to the VM side of things....
There is one of me to do all of the TSO/REXX/HFS/VM stuff.

Just got out of our status meeting and we have pressure to be production
in two weeks.

Again, thanks for all the brainstorming.

Steve Thompson

[Robert Zenuk]

Maybe this is too late... I've been swamped all week and finally had a chance to relax and catch up on email.... It was kind of suggested already by Adrian, but the SDSF/REXX interface let's you read the current TSO user's JESMSGLG. In the event the error condition is in the JOBLOG you can read it, parse it and code for the condition. The full directory will show up as the IEC217I B14-0C. Here is some sample code to try it out. Allocate a PDS FB 80 with DIR=1 and use the PDS in the ALLOC statement.

/* REXX - Read my TSO JOBLOG */
mem.1 = 'x'
do i=1 to 10000
mem = 'M'i
"ALLOC F(MEM) DA('YOUR.EMPTY.TEST.PDS("mem")') SHR REUSE"
"EXECIO * DISKW MEM (STEM MEM. FINIS"
if RC <> 0 then leave
end
say 'EXECIO RC='ERC 'for member' mem
if isfcalls('ON') <> 0 then exit 99
address SDSF "ISFEXEC DA"
call isferror 'ISFEXEC'
do i=1 to isfrows
if jname.i = mvsvar('SYMDEF','JOBNAME') then
do
address SDSF "ISFACT DA TOKEN('"token.i"') PARM(NP SA)"
call isferror 'ISFACT'
address TSO "EXECIO * DISKR" isfddname.1 "(STEM JOBLOG. FINIS"
do l=1 to joblog.0
say joblog.l /* insert error logic here */
end
end
end
exit 0
isferror: arg sdfscall
select
when isfmsg = '' then return
when isfmsg = 'DATA SET ALLOCATED' then return
otherwise
do
say isfmsg
do e=1 to isfmsg2.0
say sdsfcall right(e,2)':' isfmsg2.e
end
exit 16
end
end

Hope this helps,

Rob

-----Original Message-----
From: Steve Thompson <stho...@US.IBM.COM>
To: TSO-REXX <TSO-...@VM.MARIST.EDU>
Sent: Thu, Feb 21, 2013 1:56 pm
Subject: Re: EXECIO vs. Sx37 >> Answered, more or less for now <<


I'm out of this discussion. I've gotten things working as far as I can for

rror recovery. I have the codepage translation working (via ocopy).
At this point, unless there is a change that will cut my CPU and/or Wall

ime by 50%, I have to move on. I have to get to the VM side of things....

here is one of me to do all of the TSO/REXX/HFS/VM stuff.
Just got out of our status meeting and we have pressure to be production

n two weeks.
Again, thanks for all the brainstorming.
Steve Thompson
----------------------------------------------------------------------

or TSO-REXX subscribe / signoff / archive access instructions,