Thread View: bit.listserv.tsorexx
4 messages
4 total messages
Started by Steve Thompson
Thu, 21 Feb 2013 15:02
Re: EXECIO vs. Sx37
Author: Steve Thompson
Date: Thu, 21 Feb 2013 15:02
Date: Thu, 21 Feb 2013 15:02
60 lines
3801 bytes
3801 bytes
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, Steve Thompson ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: EXECIO vs. Sx37
Author: Paul Gilmartin
Date: Thu, 21 Feb 2013 15:12
Date: Thu, 21 Feb 2013 15:12
24 lines
2143 bytes
2143 bytes
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 ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: EXECIO vs. Sx37
Author: Steve Thompson
Date: Thu, 21 Feb 2013 15:52
Date: Thu, 21 Feb 2013 15:52
36 lines
2509 bytes
2509 bytes
From: Paul Gilmartin <PaulGBoulder@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). ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: EXECIO vs. Sx37
Author: Paul Gilmartin
Date: Thu, 21 Feb 2013 20:47
Date: Thu, 21 Feb 2013 20:47
16 lines
1822 bytes
1822 bytes
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 ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads