I don't think VARSTORAGE(HIGH) is the best approach. I would stick with
LOW. The message suggests that RACF is running out of storage. .OUTTRAP
knows nothing about userlists, so it's probably not an OUTTRAP
message. Further, the return code is not from OUTTRAP, it is from the
command being executed. So I would not have thought this is an OUTTRAP
issue..
RACF does not use the same storage as REXX for data. In fact, they could
compete and lead to an out of space condition, such as you might have here,
with a small REGION= or some other space constraint situation.
FYI: The following statement is false:
>When you output data to a REXX stem and you use that same
>tem over and over again, the storage for the stem is not reused by REXX.
>In other words, every time you use the same stem name, new storage is
>allocated, the old storage for the stem is not freed
When you give a new value to a variable, a compound variable or a stem, the
old value(s) become/s inaccessible in the data heap. Individual compound
variables (tails) of the same stem can be widely scattered depending on how
they were allocated, how they were reassigned values, and what else was
going on. So, it's best not to think of a stem as a block of storage, or
even that consecutive elements have monotonic addresses.
Inaccessible data is called "garbage" and is subject to reclamation via
garbage collection. After garbage collection, everything accessible is
moved to the beginning of the heap, and the free space is consolidated at
the end. New data is assigned consecutive addresses as in a stack, until
the space runs out, and garbage collection is needed again.
I don't know how REXX chooses the initial heap size or if a larger heap is
requested as an out-of-space recovery.
So the space for a variable, etc. that is assigned a new value is never
lost. It is made available again when space runs out and garbage
collection is performed. It is true that values that are not replaced
continue to take up space unless explicitly or implicitly DROPped.
It is true that values that are not replaced continue to take up space. If
you assign values to 100 elements of a stem, and then assign new values to
10 of them (without DROPping the stem or changing the default value), the
remaining 90 elements will still exist, take up space, and be accessible by
their tails. It matters not if the tails are numeric or otherwise.
If you have some pathological case where you have a large stem of many
megabyte strings, using DROP when you are done with it will turn the data
into collectable "garbage" (inaccessible space). However, if you have a
lot of local variables, compound variables and/or stems, using PROCEDURE [
EXPOSE ... ] will be a tad faster and probably more maintainable.
For example:
UserIdList:
procedure
signal on error name RACFNonZeroRC
call outtrap "RACFOut."
"Your RACF command"
call outtrap "off"
UsrLst = ""
do iR = 1 to RACFOut.0
parse var RACFOut.iR /* some pattern to extract a value into UId . */
UsrLst = UsrLst UId
end iR
return Usrlst /* Stem gets dropped implicitly as part of the return. */
RACFNonZeroRC:
say "RACF command ended with RC" RC
exit RC
Everytime the function/subroutine returns, the space used by the stem is
made available for reclamation by garbage collection. The same goes for
UId and iR, in this case.
I hope this helps.
OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.
On Fri, Apr 8, 2022 at 8:02 AM Seymour J Metz <sme...@gmu.edu> wrote:
> Unless there is a gateway from the bit.listserv.* news group to the
> listserve, Usenet articles will not be visible on the list. IBM-MAIN used
> to have a unidirectional gateway from listserv to Usenet; that may be true
> for TSO-REXX as well.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ________________________________________
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Vaid Laturkar [vnath2...@gmail.com]
> Sent: Thursday, April 7, 2022 12:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Command execution through OUTTRAP giving rc -1645
>
> Bob, not sure about it. I have written in group bit.listserv.tsorexx.
>
> On Thu, Apr 7, 2022 at 7:01 PM Bob Bridges <robhbrid...@gmail.com> wrote:
>
> > Vaid, I haven't seen this post on TSO-REXX yet, just so you know.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* Hmmm, I found a strange piece of plastic on the floor that looks like
> > it broke off of something, but I have no idea what. Better save it in
> the
> > junk drawer until I die. */
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf
> > Of Vaid Laturkar
> > Sent: Thursday, April 7, 2022 00:01
> >
> > cross post to IBM-MAIN, TSO REXX.
> >
> > We have a long running REXX exec working at different customer sites.
> > This uses OUTTRAP to trap output of RACF command 'SEARCH CLASS(USER)' and
> > then iterates through the list for further processing.
> >
> > Recently at one customer site, this command execution through REXX exec
> is
> > giving RC -1645 (and incomplete user list) when executed using one user
> id
> > but works when executed using other ID. (gets all users)
> >
> > READY
> > %MYEXECV
> > 46 *-* cmd ---> The cmd variable has 'SEARCH CLASS(USER)' command
> > +++ RC(-1645) +++
> >
> > We tried to add "PROFILE VARSTORAGE(HIGH)" before OUTTRAP and increased
> > the REGION parameter on job too. But somehow it's now working. Earlier we
> > had a similar issue and specifying this profile setting has worked.
> > There are around 145K+ users and user in error is only able to trap
> around
> > 89K users only. RACF permission wise this id is set up properly. so
> that's
> > no issue.
> >
> > The code snippet goes as below:
> > 000041 issue_scmd:
> > 000042 /*---------------------------*/
> > 000043 address TSO
> > 000044 "PROFILE VARSTORAGE(HIGH)"
> > 000045 x = OUTTRAP(rec.,,'NOCONCAT')
> > 000046 cmd = 'SEARCH CLASS(USER)'
> > 000047 cmd
> >
> > Any pointers on how this can be further investigated. Thanks in advance.
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
