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



Yes, but unless I am missing something, this isn't a constant. The value
of using a constant rather than an initialized variable is that you
can't accidently change the value of the constant. While with this
solution you, or someone else later, could accidently change the value
of one of the days. A somewhat likely example would be something like
this.

If     DayOfWeek.Sunday = Today 
   Or DayOfWeek.Saturday = Today;
  ItsTheWeekend = *ON;
EndIf;

Latter someone is changing the program and modifies it to look like
this. 

If     DayOfWeek.Sunday = Today; 
   DayOfWeek.Saturday = Today;
  ItsTheWeekend = *ON;
EndIf;

Now DayOfWeek.Saturday is no longer 7.

Joe Lee

>>> Hauser@xxxxxxxxxxxxxxx 12/30/2004 11:22:56 >>>
Hi Lee,

you can do so, if you replace const through INZ and define the field as
1S 0
or 1P 0:

D DayOfWeek      DS                qualified
D   Sunday                   1S 0  inz(1)
D   Monday                   1S 0  inz(2)
D   Tuesday                  1S 0  inz(3)
D   Wednesday                1S 0  inz(4)
D   Thursday                 1S 0  inz(5)
D   Friday                   1S 0  inz(6)
D   Saturday                 1S 0  inz(7)
 *-----------------------------------------
 /EXEC SQL  :Today = DayOfWeek(Current_Date)
 /END-EXEC

 /Free
   Select;
   When Today = DayOfWeek.Sunday;
   When Today = DayOfWeek.Monday;
   ...
   EndSL;
   *inLR = *On;
 /End-Free

Birgitta
-----Ursprungliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx 
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]Im Auftrag von Joe Lee
Gesendet: Donnerstag, 30. Dezember 2004 20:03
An: rpg400-l@xxxxxxxxxxxx 
Betreff: Re: Long Constant Names


An interesting idea occurred to me while reading this. Would it be
possible to add constant qualified data structures? These constants
would be used and defined just like a variable qualified data
structure.
So you would have something like the following.

DayOfWeek     DS                 Qualified Const
 Sunday                                 Const(1)
 Monday                                Const(2)
 Tuesday                               Const(3)
 Wednesday                          Const(4)
 Thursday                              Const(5)
 Friday                                   Const(6)
 Saturday                              Const(7)

 /Free
  Select;
   When  today = DayOfWeek.Sunday;
   When  today = DayOfWeek.Saturday;
  EndSl;
/End-Free


This would help avoid the need to have "long" constant names, at least
in the still fixed format D specs, and provide an easy and consistent
method of specifying context.

Would something like this be a "good" thing? And how hard would it be
to implement, Hans? Barbara?

Joe Lee

>>> antoine.contal@xxxxxxx 12/30/2004 08:12:34 >>>

Steve,

You're right. In fact, this double semantic load a constant has to
bear
is the reason I'm talking about constant names specifically, and not
variable names in general. Generally speaking, the constant should
state
both the context (e.g.,
'dayofweek', 'ErrMsg') and the value (e.g. 'monday', 'StUpd').

I'd rather put an underscore between the two parts, but if I can't
have
more than 15 chars, I have to use chars sparingly.

Regards.

--
Antoine CONTAL



something else to keep in mind is that a constant will 99% of the time
be one of a set of values.
   dayofweek_monday
  dayofweek_tuesday

  statuscode_active
  statuscode_held
  statuscode_deleted

It follows that the constant name should always indicate that
relationship. What better way is there than the first half of the name
is the name of the constant set, the second half is the name of the
constant within that set? You dont have to use the underscore if you
dont want to.

-Steve



Les informations contenues dans ce message sont confidentielles et
peuvent constituer des informations privilegiees. Si vous n etes pas
le
destinataire de ce message, il vous est interdit de le copier, de le
faire suivre, de le divulguer ou d en utiliser tout ou partie. Si vous
avez recu ce message par erreur, merci de le supprimer de votre
systeme,
ainsi que toutes ses copies, et d en avertir immediatement l
expediteur
par message de retour.
Il est impossible de garantir que les communications par messagerie
electronique arrivent en temps utile, sont securisees ou denuees de
toute erreur ou virus. En consequence, l expediteur n accepte aucune
responsabilite du fait des erreurs ou omissions qui pourraient en
resulter.
--- ----------------------------------------------------- ---
The information contained in this e-mail is confidential. It may also
be legally privileged. If you are not the addressee you may not copy,
forward, disclose or use any part of it. If you have received this
message in error, please delete it and all copies from your system and
notify the sender immediately by return e-mail.
E-mail communications cannot be guaranteed to be timely secure, error
or virus-free. The sender does not accept liability for any errors or
omissions which arise as a result.
$!1$!



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.