🚀 go-pugleaf

It's always been a case of find what works and avoid what doesn't with these
ancient macros.  A simple approach tends to be least problematic.  You
should not have to deal with picking up the closing parenthesis.  Having
used all of these macros since the late 70's (but not any more and
unfortunately I don't have ready access to my code anymore (on the other
hand I'm retired and I don't care)), I would suggest using a validity check
exit to do a simple table lookup of reserved words rather than trying to use
IKJRSVWD, and use the exit to pass or fail each operand.

Raymond H. Earle

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Tony Harminc
Sent: Monday, September 25, 2006 5:41 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: IKJPARS questions

Sigh. Every few years I do something with IKJPARS, and I usually regret it.
It's not that it's *so* bad; it's mostly that I just don't use it often
enough.

So here's what I want to do: I want a command something like:

cmd pos1 pos2 keyword1(value1) keyword2(value2)

where value1 is one of a short list of choices. I almost said "of keywords",
but I don't mean keywords in the IKJPARS sense, because keywords are never
required, and I need a required operand.

So it looks to me as though what I need is a list of Reserved Words,
defined, of course, by IKJRSVWD followed by an IKJNAME for each acceptable
value.

It would be nice if these strings were processed like keywords to the extent
that any unambiguous truncation would be accepted, but the doc is pretty
clear that it doesn't work this way.

Well, there are three ways to use IKJRSVWD: standalone, as part of IKJOPER,
or as part of IKJTERM. OK - try the easiest first.

Problem one: my assembly fails miserably, and it soon becomes clear that
while the PCL defining macros I've used in the past (e.g. IKJIDENT,
IKJKEYWD) use the label you supply to define the PDE, IKJRSVWD puts it on
the PCE! I looked at the macros, and it's all hardcoded. Why.? I realize
this must be very old stuff, but what would've possessed the designers to
commit this huge inconsistency?

Problem two: rework so that I extract the PDE offset from the PCE. Well, it
sort of works, but with the bizarre exception that the closing parenthesis
of the keyword argument is taken as part of the argument. In other words, I
get
IKJ56702I INVALID <whatever>, value1)
IKJ56718A REENTER THIS OPERAND+
for some valid value of value1. This is ridiculous, or more likely I'm doing
something wrong. Well, some more reading suggests that IKJRSVWD is not
supported as an IKJKEYWD subfield, but only as a true positional. OK - so I
try IKJRSVWD as an IKJOPER subfield. It also sort of works, but has the same
problem with that closing paren.

OK - so I define an entire extra set of value1 possibilities, but this time
containing the closeing paren as part of the string. And that works.!

So is this WAD, or am I taking the wrong approach? Of course the other way
of doing this is to use IKJIDENT for the subfields, and than do the lookup
in one's own mainline code, or maybe in a validity check routine. But then
what's IKJRSVWD for?

Sigh again.

Tony H.