Re: qsh from cl

Hi John

Well, that explanation was worthwhile for me at least, as I now get where
you are coming from.

Understanding that style is in the eye of the beholder, I (personally)
would never willingly change this:

ADDPFTRG FILE(CMC2) TRGTIME(*AFTER) TRGEVENT(*INSERT) +
PGM(ASL1106R)

to this:

ADDPFTRG CMC2 *AFTER *INSERT PGM(ASL1106R)

That said, I get that ending up with long command strings on a 24x80 screen
wastes a lot of real estate.

As I said, I have written a lot of CL programs and generally front ended
them with commands to create an easy way to automate or speed up various
operations. The biggest danger to dropping the keywords is that if new
keywords are added then the positional parameters pretty quickly break.
Because I would sometimes change the order or defaults in my own programs
specifying parameters and keywords afforded me a certain level of
built-in certainty against my own changes. I can see where this would not
be so much an issue with IBM commands but it's probably still not something
I would do.

On a more practical level, if I want to search for all my programs
specifying a before trigger it's a lot easier to search for TRGTIME(*AFTER)
than just the bare *AFTER. This has come to my aid a number of times when
grepping source files at customer sites to try and root out various
practises.

Most people I know (including me) would probably have to prompt your
example to see what the keywords were and then if I forgot to push F12 all
the formatting is lost (and, alas, no "Undo" function in SEU...)

Just to close the loop on the prettifier comments I certainly see why you
would need the prettifier to know the commands and keywords now.

My thinking was to write something that would change your example to:

ADDPFTRG FILE(CMC2) +
TRGTIME(*AFTER) +
TRGEVENT(*INSERT) +
PGM(ASL1106R)

Which while still ugly in the sense of verbosity at least is a little
easier to read (and probably easier automate).

Anyway, I am not trying to convince you my way is better, I am just
explaining how I arrived at my approach.

At least partly it was because in the absence of any simple choice I just
gave up fighting with the prompter making the kind of annoying formatting
choices you are talking about.

On Thu, Mar 8, 2018 at 9:56 AM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Wed, Mar 7, 2018 at 2:08 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:

On Wed, Mar 7, 2018 at 8:01 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Tue, Mar 6, 2018 at 5:21 PM, Evan Harris <auctionitis@xxxxxxxxx>

wrote:

I rarely go more than 1 or 2 parameters on the command line without
specifying the option as well

One or two parameters is generally all you need for CL *programs* also.

That's not my experience; I have written a lot of CL programs and plenty

of

them used more than a couple of parameters. Anything beyond trivial is
likely to wind up with at least one command with more than a couple of
parameters.

I finally see where the disconnect is. I am talking about whether the
parameters you use need to be specified by keyword or not. If you
don't need the keyword, then I generally prefer to leave the keyword
off.

The parameters which don't require a keyword are referred to as
"positional" (because they can be inferred purely by their position),
and there are usually very few of these for any given command, no
matter how many total parameters are available for that command.

I should have given examples right from the beginning, but I didn't
have a connection to an i at the time to check my work. I am guessing
you aren't the only one who would understand me better with an
example, so here goes.

If you let SEU's prompter format your ADDPFTRG command, you'll get
something like this:

ADDPFTRG FILE(CMC2) TRGTIME(*AFTER) TRGEVENT(*INSERT) +
PGM(ASL1106R)

Whereas I prefer it to look like this:

ADDPFTRG CMC2 *AFTER *INSERT PGM(ASL1106R)

Not only have I left off some of the keywords, I've also positioned
the statement closer to the left edge. (I would indent it if it were
within a DO..ENDDO block.) The shorter version takes up just one line
instead of two, and its meaning is, in my opinion, just as clear as
the longer version.

Now, this particular command happens to accept a relatively high
number of positional values. As it turns out, even the PGM keyword
isn't required (my shop is at 7.1 in case that makes a difference), so
it has at least four positional (keyword-optional) parameters.

But in this case I find that including PGM has sufficient value to
justify the extra verbosity. (1) The cost in verbosity is pretty low.
IBM could have chosen the costlier PROGRAM instead of PGM. (2) I can
see how someone's intuition might be to specify the program instead of
the file as the first parameter. So the keyword provides a noticeable
benefit in terms of disambiguation.

Whereas TRGTIME and TRGEVENT are, to me, relatively expensive and do
not provide any disambiguation, due to the restrictions on the
possible values. If you even know what a trigger is, you won't be
wondering whether *AFTER is a file or a program or an event. It could
only reasonably be a time. This is what I mean when I say a keyword is
"obvious".

So, I think that was perhaps a painfully detailed run-through of my
thought process when I am writing CL, but hopefully that clears up for
some people what is going through my mind, and what the heck I am
talking about.

I have no problem with people having a different sense of what's
aesthetically pleasing or what's readable. I'm quite sure I'm in the
very, very small minority in my CL tastes. But I do like for people to
understand me, so that they know what they are disagreeing with. ;)

I have no
idea why your prettifier would need to know anything about which
unnecessary options it could safely remove. By defintiion anything in the
CL program is required because it has been specified (at least in my
experience).

Hopefully you get it now. The prettifier has to know which KEYWORDS
are optional. That is, it has to know which parameters can be
specified purely by position. If it encounters any other keyword-value
pairs, it can safely assume that the keyword is required. And as
demonstrated above, I might want to hand-tweak the prettifier so that
it doesn't automatically remove everything that the compiler would
allow to be removed (such as the PGM keyword for the ADDPFTRG
command).

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD