× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Thu, Aug 25, 2016 at 1:40 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 8/25/2016 12:46 PM, John Yeung wrote:
I mean, the extra step is not a crime. It's not even expensive. But I
don't really see what it gains, and I hate to encourage unnecessary
code.

I have personally been... notified that an example like coolAPI('Z':
data) should clearly show the places where variables can be used. That
my example using a literal 'locked' their mind into 'only a literal can
go there' mode. To the point where he wrote code like

if condition1
coolAPI('A': data)
end
if condition2
coolAPI('B': data)
end
if condition3
coolAPI('C': data)
end

I wish I were joking.

I see. Well, then yes, inadvertently or reluctantly encouraging a
2-line procedure call is certainly preferable to haplessly encouraging
a "3-times-the-number-of-possibilities"-line procedure call. :P

Let me guess, the conditions could be fleshed out as follows and not
faze this person:

if actcode = 'A';
coolAPI('A': data);
endif;
if actcode = 'B';
coolAPI('B': data);
endif;
if actcode = 'C';
coolAPI('C': data);
endif;

Coders like that are... how can I put this humanely? Well, in the
other thread, you said

I'm not proposing a wonderful way to make a BIF.
I'm showing one way RPG and Rexx can interact.
And hoping that launches a few ideas.

I thought your post was great for the stated purpose, and I share your
hope. That's all I ever hope for when I give my Python examples. But a
coder who doesn't smell anything funky in the 9-line procedure call,
or cannot come up with the idea of using a variable instead of a
literal... well, they are not who I am writing examples for.

Let me back up. First of all, are you saying that they used the CT
array for the report title or for column headings? If the latter, then
was each heading its own array element, or were they glommed together
into one long element? And was ARR the actual name of the array?

Column headings.
One long element.
If ARR wasn't the actual name, it was something equally useless.

Adding a column of data to the O-spec meant puttering with spaces in the
compile-time array to make things line up. Ew.

Yeah, definitely ew.

What would have been a better way to write the O-specs?

OQSYSPRT H 203 1P
O OR OF
O UDATE Y 10
O 16 'Cust'
O 28 'Name'
O 48 'Address'
O D 1 01
O CUST# 17
O CUNAME 40
O ADDR 60

See, this is what I thought everyone was taught.

But it does have its own problems. For one, assuming the columns were
spaced fairly close together, inserting a column somewhere other than
the end (or anywhere at all, if the spool width is already mostly used
up) is still a chore. The least inconvenient way to do spooled RPG
output, in my opinion, is to use relative instead of absolute
positioning, though I'm almost certain that was not available in the
early days.

Now, I do see a thin defense of the
all-column-headings-in-one-long-string practice. That is: Some people
are really bad with counting and fiddling with numbers, and are much
better visually. So rejiggering column headings in a long string
would, for them, be a matter of pressing Space or Delete "until things
looked right". The benefit of this is magnified when the column you're
trying to insert is near the beginning, and you have enough room on
the page that you don't have to futz with the relative positions of
the remaining headings. In other words, before relative position
numbering, having things in a long string *was* the way to achieve
relative positioning (for headings).

And though I don't see how you can apply the same technique to the
column data, the fact is column headings often inherently have a
certain degree of decoupling from the data anyway (look at the
position numbers in your example above). So I guess some folks figure
they'll trudge through fiddling with numbers for the data, but they
still want their visual and/or relative positioning where they can get
it. (Have I stressed enough that I consider the defense of this
practice very thin?)

Fortunately for everyone involved, the consumers of reports are
increasingly asking for Excel anyway. Yes, there are holdouts, but
statistically speaking, they are an old and dying breed.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.