>> The IBMer that created that field name should be...
> I disrespectfully strongly disagree. This is a perfectly good name.
The name is long, no underscores, and does not use the industry standard
so it is prone to typos. A better name would have been:
QVSIMG_LPAR_NAME
Itsbetterthanusingnospacesinasentenceandexpectingittobereadeasily.
Tony Thigpen
-----Original Message -----
From: Peter Relson
Sent: 02/21/2014 08:17 AM
I think everyone agrees that the "no whitespace" rule for continuation of
a non-macro statement is a real pain.
If only all of you vocal customers would band together and get suitable
requirements in place, even the resource-constrained HLASM team might be
able to justify the effort.
They know of the problem (having heard not just from me about it). Even if
there is a compatibility argument, some *process option could be added to
say "I want the new rule for my module".
Robert's approach of 0's is a very interesting one. I had not seen that
before.
We've done the following:
MVC 0(L'QVSIMGLOGICALPARTITIONNAME,R4),*
QVSIMGLOGICALPARTITIONNAME Move out the LPAR name
not having thought of the 0's idea.
As to
The IBMer that created that field name should be...
I disrespectfully strongly disagree. This is a perfectly good name. The
more self-explanatory a variable name is, the more readable code is.
And readable code is the most important thing that we can leave to those
who follow us. Given how well-known "LPAR" is maybe they could have chosen
not to spell out LogicalPartition. I'd also say that with a good variable
name, the "line comment" can be reserved for describing the "why" because
the "what" is obvious. "Move out the LPAR name", arguably, is not a good
comment as it does not add to the reader's understanding, given the
understandable variable name.
I would also question the use of all-upper case. I believe that the
"experts" say that reading mixed case is easier than all-upper, such as
QVSImgLogicalPartitionName.
Peter Relson
z/OS Technology Design
