On Wed, Nov 15, 2017 at 11:19 AM, Willy Jensen <[email protected]> wrote:
> Hi John, > not an answer to your very interesting LE suggestion, which I will study > in details later. > But you mention somewhere that you are trying out the IEFPRMLB macro, and > are using both ALLOCATE and FREE - as I recall. > I have a program reading a parmlib member and creating a REXX stem. In > there I just use IEFPRMLB with Request=ALLOCATE, read=YES and freeclose=YES > , which does the allocate, read and close in one go. Of course the buffer > has to be big enough, but if it isn't you will be told how big it needs to > be. A test shows that there is no allocation after the program has > finished, so I take that to prove that the FREECLOSE=YES actually works. > > My call: > IEFPRMLB REQUEST=ALLOCATE,ALLOCDDNAME=ddname,BLANK72=YES, > CALLERNAME=callname,MEMNAME=mbrname,MOUNT=NO, > READ=YES,READBUF=(10),RETMSG=NO,S99RB=NO,WAITDSN=NO, > RETCODE=prrc,RSNCODE=prrs,FREECLOSE=YES > > Another thing, one simple method for FREE and ALOCATE could be calling > BPXWDYN like this: > Link EP=BPXWDYN,param=alloc,VL=1 > alloc ds 0a > dc al2(l'allocstr) > allocstr dc c'alloc dd(meals) dsn(SYSA.LIB.CNTL) shr reuse' > > Note, BPXWDYN is re-entrant, so you could probably LOAD and CALL it, but I > haven't tried. > True on BPXWDYN. There may be slightly less overhead from using a PC to call a system resident module than doing a LOAD, but maybe not. And it's likely a wash about which is "better" because both work and are understandably. At least more so than using SVC 99 directly with text units et al. My use of ALLOCATE with READ=NO and a separate FREE was deliberate in my test. Basically, I did an ALLOCATE, READMEMBER, then FREE. Which is, almost, like what you did. In my case, I specified that the DDNAME had to be PARMLIB. So, if the user had a //PARMLIB in his JCL, the ALLOCATE would fail. I would ignore this (in real code, I would double the RC & RSN). I would then do the READMEMBER on the DD:PARMLIB. If the user had allocated a PARMLIB in the DD, the member would be read from the user's allocation. Otherwise the ALLOCATE would have succeeded, and the READMEMBER would have read from the system PARMLIB concatenation. I felt this was a very easy way to implement: "If the user allocates PARMLIB in their JCL, then use that allocation to read the input member. Otherwise, allocate the system PARMLIB concatenation and use that to read the input member." What I was doing was replacing some code in TSSO which dynamically allocates (hard coded) 'SYS1.PARMLIB', does a FIND for the requested TSSO parmlib member (TSSOPARM by default); then does a BSAM READ, in a loop, to actually read the TSSO configuration. My IEFPRMLB ALLOCATE; READMEMBER; FREE is significantly simpler code. No OPEN, no FIND, no READ, no CLOSE. So no RMODE(24) dependancy. Joyousness. > > rgds > Willy > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown
