Steve Thompson wrote:
>And to your rhetorical question -- Yes it is called a loose canon.
Ouch. I deserved that!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the
And to your rhetorical question -- Yes it is called a loose canon.
[Back to flinging REXX...]
Steve Thompson
On 9/6/2023 4:16 PM, Wayne Bickerdike wrote:
Lionel,
Does the storage not dropped create a problem? Or is this just a thing you
want cleaned up?
On Thu, Sep 7, 2023 at 4:02 AM Paul
The site that asked me seemed to think it important.
On Wed, Sep 6, 2023 at 3:16 PM Wayne Bickerdike wrote:
> Lionel,
>
> Does the storage not dropped create a problem? Or is this just a thing you
> want cleaned up?
>
> On Thu, Sep 7, 2023 at 4:02 AM Paul Gilmartin <
>
Lionel,
Does the storage not dropped create a problem? Or is this just a thing you
want cleaned up?
On Thu, Sep 7, 2023 at 4:02 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 6 Sep 2023 13:46:25 -0400, Phil Smith III wrote:
> >
> >This is not meant to be
On Wed, 6 Sep 2023 13:46:25 -0400, Phil Smith III wrote:
>
>This is not meant to be snide, just a citation of sorts: these behaviors were
>discussed long ago when Rexx was introduced to VM/CMS, are established canon.
>(Is that redundant? Can there be UNestablished canon?)
>
I used to know that.
Gil wrote:
>My understanding is that to DROP a compound stem frees all associated storage.
Correct.
>Freeing an individual variable or member of a compound does not. In fact, it
>can be demonstrated that to DROP an individual member of a compound actually
>*increases* the storage used.
Also
On Wed, 6 Sep 2023 15:40:03 +, Rob Scott wrote:
>
>isfreset("all") will drop all SDSF special variables. It won't drop any
>column stems.
>
>However, we are not sure if dropping a variable always releases the storage.
>We have seen cases where REXX just marks the SVB available but the
what you
are, reputation merely what others think you are. - - - John Wooden
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Rob Scott
Sent: Wednesday, September 6, 2023 10:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF REXX Question
Lionel
isfreset("all")
t Software
From: IBM Mainframe Discussion List On Behalf Of
Lionel B. Dyck
Sent: Wednesday, September 6, 2023 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF REXX Question
EXTERNAL EMAIL
After using the SDSF REXX API and issuing the "rc = isfcalls('off')" is
there a way to rele
After using the SDSF REXX API and issuing the rc = isfcalls(off) is
there a way to release/free the storage that the various calls to the API
have allocated. I know I can do a drop isfulog. But is there a general
way?
TIA
Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github:
and delete all copies.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, May 31, 2017 10:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF/REXX question
On Thu, 1 Jun 2017 02:24:43 +, Hardee
On Thu, 1 Jun 2017 06:37:04 -0500, John Gateley wrote:
>I had a similar problem. In my case I was reading JESYSMSG to check the return
>codes of preceding steps and usually JESYSMSG was there but occasionally it
>was not, and in these cases the job elapsed time was quite low.
>I added a call to
On Thu, 1 Jun 2017 08:02:12 -0500, John Gateley wrote:
>0.7 was by trial and error, 0.6 was not long enough for a single IEFBR14 job.
>
>I already had the REXX assembler function so I only had to code this
>JRGSTIM('7')
>
That's probably been done enough times by enough programmers to
justify an
0.7 was by trial and error, 0.6 was not long enough for a single IEFBR14 job.
I already had the REXX assembler function so I only had to code this
JRGSTIM('7')
also I did not know about SYSCALL :-)
--
For IBM-MAIN subscribe /
-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF/REXX question
Hardee, Chuck wrote:
>I am having a random timing issue with a REXX that I am developing using SDSF
>calls.
>The REXX identifies the job name and number within which it is running and
>then attempts to use SDSF to find and proces
On Thu, 1 Jun 2017 06:37:04 -0500, John Gateley wrote:
>..
>I added a call to an assembler program at the start of the REXX to issue a
>STIMER for 0.7 seconds and then JESYSMSG was always there.
>
How did you arrive at the number, 0.7? Ratner than simply using
SYSCALL 'sleep 1', you wrote a
I had a similar problem. In my case I was reading JESYSMSG to check the return
codes of preceding steps and usually JESYSMSG was there but occasionally it was
not, and in these cases the job elapsed time was quite low.
I added a call to an assembler program at the start of the REXX to issue a
Hardee, Chuck wrote:
>I am having a random timing issue with a REXX that I am developing using SDSF
>calls.
>The REXX identifies the job name and number within which it is running and
>then attempts to use SDSF to find and process the SYSOUT datasets already
>created by previous steps in the
On Wed, 31 May 2017 22:25:34 -0500, Paul Gilmartin wrote:
>
>>3) If this is a timing issue, is anyone aware of a means by which I can
>>cause the REXX to delay a second or two before attempting to read the queue
>>entries for the job (name) being executed?
>>
>ADDRESS SYSCALL 'sleep 2'
>
On Thu, 1 Jun 2017 02:24:43 +, Hardee, Chuck wrote:
>
>I am having a random timing issue with a REXX that I am developing using SDSF
>calls.
>The REXX identifies the job name and number within which it is running and
>then attempts to use SDSF to find and process the SYSOUT datasets already
Hello Listers,
I am having a random timing issue with a REXX that I am developing using SDSF
calls.
The REXX identifies the job name and number within which it is running and then
attempts to use SDSF to find and process the SYSOUT datasets already created by
previous steps in the job.
The
21 matches
Mail list logo
