I meant to add a comment and then got busy for a few days - apologies for the delay. Your original question, Lizette, was whether there's a way for a REXX program to detect an out-of-storage condition and trap it so the program can end in a less uncontroled way. Like programming geeks everywhere, none of us actually answered the question, as far as I noticed; we just spouting out other solutions. I did, at least.
I don't know the answer to your question now any more than I did last week, but now that you've said it's for loading into DB2 I do have another idea, although it involves a little extra rewriting. Like this:
1) Write the data one record at a time (EXECIO 1 DISKW) to a dataset
2) Connect with QMF
3) In QMF, run a procedure that loads the raw data into DB2
Getting your REXX to talk to QMF is extra work, but no more difficult than getting it to talk to DB2. The advantage is that procs running in QMF upload and download large datasets ~much~ faster than REXX can do it one record at a time with DB2 directly. I wrote some routines when I was at Discover in Chicago; the query came up with thousands of records, which at REXX's rate of input (at least back then) would have been impossible, say half an hour at a guess. But a QMF proc could load the query results into a dataset in just a few seconds, and the REXX could parse that raw data easily...or "quickly", rather, because the REXX had to know where to find the special hex characters that delimited the columns in each record. Still, well worth the effort.
This solves your RAM problem, you see, because you're writing out the data one record at a time, and yet you don't have to wait forever to load the rows into DB2 the slow way.
***@gmail.com, cell 336 382-7313
/* Your patient must demand that all his own utterances be taken at their face value and judged simply on the actual words, while at the same time judging all his mother's utterances with the fullest and most oversensitive interpretation of the tone and the context and the suspected intention....You know the kind of thing: "I simply ask her what time dinner will be and she flies into a temper". Once this habit is well established you have the delightful situation of a human saying things with the express purpose of offending and yet having a grievance when offence is taken. -advice to a tempter, from The Screwtape Letters by C S Lewis */
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of Lizette Koehler
Sent: Friday, July 14, 2017 11:37
Read a bunch of PDS Source datasets (proclibs, cntlibs, etc) create a repository entry of who did what/when. Upload to a DB2 table for historical analysis.
Job can produce (depending on source changes going on) anywhere from 1 line to 10s of thousands of lines of material to sift through.
In the dawn of time the code was sufficient. Now, I think the techniques used are starting to show their age. A rewrite is probably in order, but there is no one who supports the code. I get it because I am a little REXX-y. Probably a proper programming language would be better at this stage.
Henece the process to change region size rather than attempt to update the code. Old Philosophy, why should there be comments when I know what I am doing
>From: Hobart Spitz <***@GMAIL.COM>
>Sent: Jul 14, 2017 8:25 AM
>Subject: Re: [TSO-REXX] How to handle Machine storage exhausted
>Presumably your file is too large for the free space.
>Not knowing what you are trying to do, I can't be specific.
>I see these alternative options:
>1 - Read a bunch of records at a time: "EXECIO 100 ...", and process
>each batch, before reading more.
>2 - Use LINEIN ().
>3 - Add PROCEDURE to any routine that produces a large volume of
>4 - Make sure you don't have infinite recursion, or an infinitrly
>5 - Use the PIPE command if you have it.
>6 - Use SIGNAL OFF ERROR, check the EXECIO return cide, and, when
>storage runs out, DROP any stems you don't need and retry.
>On Jul 14, 2017 11:11 AM, "Bob Bridges" <***@gmail.com> wrote:
>I'm missing something, Lizette. When my REXXes use up the available
>RAM (as for example when I try to EXECIO * DISKR a file that's too big
>to fit), I get a lot of messages from the OS. Are you saying that this
>REXX traps that output and displays just:
> Machine store exhausted
>...and then two lines later:
>...? Because a) that's really weird (why would it say "Better."?), and
>anyway b) if you're trying to figure out what's causing this you should
>be able to find those error message somewhere in the REXX code and
>change that behavior to whatever would suit you better.
> ***@gmail.com, cell 336 382-7313
>/* Excellence is an art won by training and habituation. We do not act
>rightly because we have virtue or excellence, but rather we have those
>because we have acted rightly. We are what we repeatedly do.
>Excellence, then, is not an act but a habit. -Aristotle */
>From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On
>Behalf Of Lizette Koehler
>Sent: Friday, July 14, 2017 10:40
>I have been asked to look at this rexx to see how to handle the
>Machine storage exhausted
>Currently the job just dies and it takes a while to determine what is
>going on. Is there a way within a rexx (Signal perhaps) that would
>capture this event and allow me to jump to some code to exit nicely?
>The process continues to run and eventually fail. I would like to
>include some error handling for this to allow it to die nicer.
>I just recently bumped up the REGION size to 24M, I am now looking at
>bumping it to 128M.
For TSO-REXX subscribe / signoff / archive access instructions, send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX