Modifying the VSAM Request Parameter List (RPL)

[Dave Clark]

This isn't strictly an Assembler question -- more of a "How to
Modify a VSAM RPL Efficiently in Assembler" type of question. But...

The reason I say "efficiently" is because of the dynamic nature of
this external assembler REXX function I am working on. Unlike a high-level
compiler that knows what is needed before a particular READ request and
can create a single MODCB RPL request at that point, I have a nested IF
situation before my GET request that is a bit of a nightmare to say the
least and is a program size hog to say the most.

In particular, I have 18 MODCB RPL requests just before my GET
request. This is because the caller may have requested an OPEN and then a
READ request that has the following different option combinations.

Call RXVSAMIO ddname, 'OPEN'
<, 'INPUT'|'UPDATE'|'OUTPUT'|'APPEND'|'RESET'
<, 'SEQUENCE'|'RANDOM'|'DYNAMIC' > >;

Call RXVSAMIO ddname, 'READ'
<, 'NEXT'|'PREV'
|'RBA'|'KEY' <, 'EQUAL'|'GTEQ' > >;

I asked this question on the VSE listserve and got the hint to use
the MF=(L,...) and MF=(E,...) macro parameters to separate configuration
of the parameter list from the execution of that parameter list. That
helped a bit to reduce the program size. However, each MODCB MF=(L,...)
request still generates its own in-line parameter list template (ACES)
that "wastes" 20 to 22 bytes before using another 10 bytes to copy the
16-byte ACES to the dynamic storage parameter list area I have provided.
And that's just the 18 combinations that I have before the GET request --
not to mention a similar (though smaller) nested IF before the POINT
request.

So, finally, here is the question... Is there some assembler
technique to further reduce the storage requirements of the following
sequence of instructions? For example... Is there some way to build the
OPTCD value in a separate string and then pass it to a single iteration of
the MODCB MF=(L,...) invocation?

IF RQARG2,EQ,C'N' GET NEXT
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,UPD)
ELSE
IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NUP)
ELSE ACCESS IS DIRECT
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NSP)
ENDIF
ENDIF
ELSE
IF RQARG2,EQ,C'K' GET BY KEY
IF RQARG3,EQ,C'G' GTEQ
IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KGE,SEQ,FWD,UPD)
ELSE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KGE,SEQ,FWD,NUP)
ENDIF
ELSE ACCESS IS DIRECT
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KGE,DIR,FWD,UPD)
ELSE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KGE,DIR,FWD,NSP)
ENDIF
ENDIF
ELSE EQUAL
IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KEQ,SEQ,FWD,UPD)
ELSE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KEQ,SEQ,FWD,NUP)
ENDIF
ELSE ACCESS IS DIRECT
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KEQ,DIR,FWD,UPD)
ELSE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(KEY,KEQ,DIR,FWD,NSP)
ENDIF
ENDIF
ENDIF
ELSE
IF RQARG2,EQ,C'P' GET PREV
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,BWD,UPD)
ELSE
IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,BWD,NUP)
ELSE ACCESS IS DIRECT
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,BWD,NSP)
ENDIF
ENDIF
ELSE GET BY RBA
IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(ADR,SEQ,FWD,UPD)
ELSE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(ADR,SEQ,FWD,NUP)
ENDIF
ELSE ACCESS IS DIRECT
IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(ADR,DIR,FWD,UPD)
ELSE
MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),
OPTCD=(ADR,DIR,FWD,NSP)
ENDIF
ENDIF
ENDIF
ENDIF
ENDIF
PUSH ACONTROL
ACONTROL FLAG(NOPAGE0)
MODCB MF=(E,PARMLIST) MODIFY THE RPL
POP ACONTROL
IF R15,(NZ,LTR),R15 IF FAILED
MVC MACRO,=CL8'MODCB/R' INDICATE OPERATION PERFORMED
ST R0,SAVE_R0 SAVE REGISTER 0
OI OPTFLAG,CTLBLKF SIGNAL ERROR IN CTLBLK
BAS R5,SHOWRESN PASS BACK RTN AND RSN CODES
LHI R5,16 SET RETURN CODE
B RETERR GO RETURN ERROR
ENDIF ENDIF


Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331



*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Tom Harper]

Dave,

Why not dispense with MODCB and just modify the RPL yourself using IFGRPL DSECT?

Tom Harper

Phoenix Software International

Sent from my iPhone

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
02/24/2022 11:49:34 AM:

> Why not dispense with MODCB and just modify the RPL yourself using
> IFGRPL DSECT?

That sounds like an intriguing idea. What are the negative
ramifications of doing it that way? ...and is there anything "special"
that has to be done after making such direct modifications?

[Abe Kornelis]

Dave,

I used MODCB extensively in the past and it served me well.

The case you're describing may make that approach rather unwieldy.

As suggested before, you might consider using the mapping macro
(IFGRPL if I recall correctly off the top of my head) and address the RPL
fields and masks directly.

The drawback is that you will have to know and understand the
layout and workings of the RPL. You're skipping all sanity checks
that MODCB would implement for you.
Also, if anything changes in the RPL structure, your program will
at least need to be re-assembled.

It is up to you to guesstimate how much of a risk that poses to you ...

Kind regards,
Abe Kornelis
===========




Op 24/02/2022 om 17:33 schreef Dave Clark:

[Tom Harper]

The result is the same.

Sent from my iPhone

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
02/24/2022 11:49:34 AM:

> Why not dispense with MODCB and just modify the RPL yourself using
> IFGRPL DSECT?

And let me ask the question this way... I already have the IKQRPL
DSECT in my program. Are you saying that if I want to directly modify the
VSAM RPL that I should NOT do it through the IKQRPL DSECT only but should
use the IFGRPL DSECT, instead? I did look at the IFGRPL macro (which
looks like VTAM, not VSAM) and it invokes the ISTRPL macro (definitely
VTAM) under the covers. So, then I looked at the ISTRPL macro and I see
that among other things it also invokes the IKQRPL macro under the covers.
That is what prompted me to ask this question.

[Tony Harminc]

On Thu, 24 Feb 2022 at 11:33, Dave Clark <dlc...@winsupplyinc.com> wrote:
[...]

> IF RQARG2,EQ,C'N' GET NEXT
> IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE
> MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,UPD)
> ELSE
> IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL
> MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NUP)
> ELSE ACCESS IS DIRECT
> MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NSP)
> ENDIF
> ENDIF
> ELSE
>

[...]

I would avoid MODCB like the plague. It has not been significantly updated
for decades, and can't even do many of the things you'd probably want. On
top of that, there are performance issues (though probably not huge) with
calling an external routine to do what you can do directly yourself. MODCB
was a nice idea, but the implementation was never up to the theory.

As I see while writing this, just doing it yourself by updating IFGRPL
fields has already been suggested. I agree. The thing to keep in mind is
validating the input so that what you change in the RPL is not invalid or
inconsistent. (In theory MODCB should take care of this, but I don't think
it'll produce a message or return code sufficient to make the problem
clear.) You can try to validate as you go (e.g. in your code above but
without the MODCBs), or you can do a validation pass first, and only when
you're sure you have a correct set of things to do, do them.

Tony H.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

02/24/2022 12:19:43 PM:

> As I see while writing this, just doing it yourself by updating IFGRPL
> fields has already been suggested. I agree.

OK, my only question is whether I have to do this through the
IFGRPL DSECT or whether I can just use the IKQRPL DSECT directly? Does
IFGRPL have something I will need that IKQRPL does not?

> You can try to validate as you go (e.g. in your code above but without
> the MODCBs), or you can do a validation pass first, and only when
> you're sure you have a correct set of things to do, do them.

Everything has already been validated before the process gets to
this point. At this point it is just conditional statements to see what I
need to do. But at least if I don't have to use MODCB then I can
rearrange and simplify these conditional statements.

[Gary Weinhold]

Are the mappings identical; the answers for MVS versions of the macros
may not be the same for the VSE versions.

The values you want to set better be at the same displacements.

On 2022-02-24 12:29 p.m., Dave Clark wrote:
> "IBM Mainframe Assembler List"<ASSEMBL...@LISTSERV.UGA.EDU> wrote on
> 02/24/2022 12:19:43 PM:
>> As I see while writing this, just doing it yourself by updating IFGRPL
>> fields has already been suggested. I agree.
> OK, my only question is whether I have to do this through the
> IFGRPL DSECT or whether I can just use the IKQRPL DSECT directly? Does
> IFGRPL have something I will need that IKQRPL does not?
>
>
>> You can try to validate as you go (e.g. in your code above but without
>> the MODCBs), or you can do a validation pass first, and only when
>> you're sure you have a correct set of things to do, do them.
> Everything has already been validated before the process gets to
> this point. At this point it is just conditional statements to see what I
> need to do. But at least if I don't have to use MODCB then I can
> rearrange and simplify these conditional statements.
>
>
> Sincerely,
>
> Dave Clark

Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: wein...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

[Tom Harper]

You may use whichever DSECT you want. I just use IFGRPL but that’s just my preference.

Sent from my iPhone

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

02/24/2022 12:35:27 PM:

> You may use whichever DSECT you want. I just use IFGRPL but that’s
> just my preference.

Thanks. I have confirmed that both of the following generate the
same mapping for a VSAM RPL. The second one just also overlays the
mapping for a VTAM RPL.


IKQRPL DSECT=YES

IFGRPL DSECT=YES,AM=VSAM

[Tom Harper]

It helps to look at this from a historical perspective. When VSAM was introduced in the early 1970s, the DCB equivalents to the ACB and RPL we’re hopelessly convoluted, and the theory was to provide an API to mask the complexity.

As it turns out, the cure of MODCB and SHOWCB was worse than the problem, as the ACB and RPL (and EXLST) were just not that complicated.

The IBM code I saw for VTAM never used MODCB either. And these control blocks have been static for decades with a few minor extensions.

Happy coding!

Tom Harper

Phoenix Software International

Sent from my iPhone

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

02/24/2022 11:49:34 AM:

> Why not dispense with MODCB and just modify the RPL yourself using
> IFGRPL DSECT?

Well, it turns out that modifying the IKQRPL DSECT directly saved
2,224 bytes on my program size -- and my program still works (at least, as
much of it as I have tested up to this point). What I previously posted
was replaced by the following, which is 42 source lines shorter. Feel
free to point out any additional improvements that might be made. Thanks,
all.


L R8,FILERPL GET RPL ADDRESS
USING IKQRPL,R8 TEMPORARY ADDRESSABILITY

IF RQARG2,EQ,C'N',OR,RQARG2,EQ,C'P' IF NEXT/PREV
OI RPLOPT1,RPLSEQ SET SEQUENTIAL PROCESSING
NI RPLOPT1,X'FF'-RPLDIR NOT DIRECT PROCESSING
IF RQARG2,EQ,C'P' IF PREV
OI RPLOPT2,RPLBWD SET BACKWARD PROCESSING
ELSE ELSE NEXT
NI RPLOPT2,X'FF'-RPLBWD SET FORWARD PROCESSING
ENDIF ENDIF
ELSE BY KEY/RBA
NI RPLOPT2,X'FF'-RPLBWD SET FORWARD PROCESSING
IF RQARG2,EQ,C'R' BY RBA
NI RPLOPT1,X'FF'-RPLKEY NOT KEY PROCESSING
OI RPLOPT1,RPLADR SET ADR PROCESSING
ELSE BY KEY
OI RPLOPT1,RPLKEY SET KEY PROCESSING
NI RPLOPT1,X'FF'-RPLADR NOT ADR PROCESSING
IF RQARG3,EQ,C'G' IF GTEQ
OI RPLOPT2,RPLKGE SET KGE PROCESSING
NI RPLOPT2,X'FF'-RPLGEN NOT GENERIC PROCESSING
ELSE ELSE EQUAL
NI RPLOPT2,X'FF'-RPLKGE NOT KGE PROCESSING
NI RPLOPT2,X'FF'-RPLGEN NOT GENERIC PROCESSING
ENDIF ENDIF
ENDIF ENDIF

IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL

OI RPLOPT1,RPLSEQ SET SEQ PROCESSING
NI RPLOPT1,X'FF'-RPLDIR NOT DIR PROCESSING
ELSE ACCESS IS DIRECT
NI RPLOPT1,X'FF'-RPLSEQ NOT SEQ PROCESSING
OI RPLOPT1,RPLDIR SET DIR PROCESSING
ENDIF ENDIF
ENDIF ENDIF

IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE

OI RPLOPT1,RPLUPD SET UPD PROCESSING
NI RPLOPT2,X'FF'-RPLNSP NOT NSP PROCESSING
NI RPLOPT2,X'FF'-RPLNUP NOT NUP PROCESSING
ELSE ELSE NOT UPDATE
NI RPLOPT1,X'FF'-RPLUPD NOT UPD PROCESSING

IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL

NI RPLOPT2,X'FF'-RPLNSP NOT NSP PROCESSING
OI RPLOPT2,RPLNUP SET NUP PROCESSING
ELSE ELSE ACCESS IS DIRECT
OI RPLOPT2,RPLNSP SET NSP PROCESSING
NI RPLOPT2,X'FF'-RPLNUP NOT NUP PROCESSING
ENDIF ENDIF
ENDIF ENDIF

DROP R8 REMOVE ADDRESSABILITY

[Seymour J Metz]

I found modifying a DCB, DECB or IOB trivial, while fooCB were a mare's nest - or should that be dog's breakfast?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Tom Harper [tomh...@PHOENIXSOFTWARE.COM]
Sent: Thursday, February 24, 2022 1:02 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Modifying the VSAM Request Parameter List (RPL)

[Peter Relson]

The desired interface would be if MODCB provide a "modify form" (MF=M).
Your use case is exactly what the modify form is for.
However, MODCB (at least the z/OS MODCB) doesn't.

So your choices are between an extended if-then-else for every combination
you want (obviously very unpleasant) and building the parameter list
yourself.

You asked about the downside of doing so? Basically, that you have to get
it 100% right or all bets are off.

If you go that route, you should check byte for byte and register for
register that what you build is what the macro would have built

The other downside is that you are in unsupported territory (at least
would be for z/OS). The interface is the executable macro. But at least if
you got it 100% right you could reproduce any problem using a real macro
invocation such that it would become reportable.

Peter Relson
z/OS Core Technology Design