× 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.



Here are my reason for not using literals in C spec.

My company has to work in several languages, so any literal that can
find it's way on a screen or on print must not be hard coded. What we do
is put the literals in message files and we retrieve the text in the
programs using the message id. We use the library list to control the
language selected, this way there is nothing to do in the programs when
we add a new language. So those kind of literals should never be hard
coded in programs.

As an aside, way back I used to work for a company where the company
name was hard coded in the "O" spec of every report. One day, the
company name changed. Well a full year after that, the old name was
still showing on some report. That is another reason to remove literals
from "C" spec. I ended up creating a file for the purpose of holding
repeatable literal values (that was on a S36)

Also, if the same literals will be used in more than one place, it
should be externalized (or at least defined in a constant). If I mistype
a constant name, I will get a compiler error. But if I mistype a
literal, I will have no compiler error but a potential bug that may not
be obvious to spot.

And a last benefit of declaring literals in D-spec: Clarity if the
literals is not self documenting.
Ex: What do "If KeyPressed = X'C3'" mean? But if you see "If
KeyPressed = Function12" the meaning is much more obvious.


"Roger Harman" <RHarman@xxxxxxxxxx> 4/5/2007 15:21 >>>
I think we need more info. What do you mean by literals? Report
headers, values to compare to, screen output? As always, the answer
is
most likely our old friend "it depends".

If you HAVE to define them in a program, I'd wholeheartedly vote for
the
"one section of the d-specs - preferably a /copy" route. Ease of
understanding trumps any micro-micro-miniscule performance aspect in
my
mind. I have to think the compiler is plenty smart enough to optimize
handling of literals regardless of how you declare them.

I like Birgitta's externalization of them. I'm going to save that
idea
to use down the road.



Tommy.Holden@xxxxxxxxxxxxxxxxx 05/04/2007 7:47:01 AM >>>
Literals will be handled by the compiler...the reason for Bruce's
"feeling" is IMO ease of maintenance. If the literal is defined in
every program every program will have to be modified before
recompiling.
Having the literals defined in a common copybook you only touch the
copybook to make the change and then just recompile the programs that
reference the copybook...you can't imagine the time this would save...


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kent Hohlen
Sent: Friday, May 04, 2007 9:26 AM
To: RPG400 (E-mail)
Subject: Re: Benefits of declaring literals in D-specs

A couple more questions.

Bruce, you said you thought having literals within the executable
portion of a program should be avoided. Are there any facts to base
your opinion
or is just the way you feel? If it is your feeling, why do you feel
this way?
I personally agree with your feeling, but I don't have any reasons to
backup my feeling.

Does anyone know (I'm looking your way Barbara Morris) if there is any
performance impact, good or bad, for declaring all literals in the
D-specs?
My feeling is the system would only have to interpret the literal once
when it is declared in the D-spec, but maybe this is handled by the
compiler
and isn't an issue.

Kent Hohlen
Eagle Window And Door

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.