Re: Named Indicators

[cmassoglia@xxxxxxxxxxx (Charlie Massoglia)]

>Believe the ability to define your own named indicators has been 
>announced for V4 - although it may be V4R2 - still, 1998.
>
The named indicator support in V4R2 is little more than what can already be
done today.  Consider the following:

Indicator 20 is defined as a response indicator in the display file using
SETOFF(20) in the record format for Screen1.

iScreen1
i            *in20                    NameErr

c             EVAL   NameErr = Name = *BLANKS
c             EXFMT  Screen1

If Name is equal to blanks, NameErr will be set to '1' (true).  If Name is
not equal to blanks, NameErr will be set to '0' (false).  When the screen is
written, indicator 20 will be *ON if NameErr is equal to '1'.  Indicator 20
will be *OFF is NameErr is equal to '0'.  The support proposed in V4R2 adds
little to what we can already do and it still in effect requires you to
rename indicators used on a screen though I think INDARA is required instead
of using a response indicator in the display file.

The above sample without a named indicator is functionally the same as the
following:

c             EVAL   *in20 = Name = *BLANKS
c             EXFMT  Screen1

Unfortunately, you can not code named indicators today without renaming a
field on a screen.  Consider the following:

d NameErr      S           1A

c             EVAL   NameErr = Name = *BLANKS
c             IF     NameErr

If Name is equal to blanks, NameErr will be set to '1' (true).  If Name is
not equal to blanks, NameErr will be set to '0' (false).  The IF test should
prove true if NameErr is equal to '1' and false if NameErr is equal to '0'.
Except a compile error will result because NameErr is not a logical
variable.  Even with an indicator on the screen renamed as a field as in the
first sample, IF NameErr will produce a compile error.

The following would work today and might be more readable than testing an
indicator:

d NameErr      S           1A
d YES          C               '1'

c             EVAL   NameErr = Name = *BLANKS
c             IF     NameErr = *YES

All V4R2 will do is permit us to define NameErr as a logical variable to
avoid the compile error on IF NamErr.  This same support could be just as
easily if not more easily provided by permitting ANY character field to be
used on a logical expresion (e.g. IF, WHEN, etc.) just as it is now
permitted on the EVAL with 2 equal signs.

In all fairness, V4R2 does permit us to test for end of file (EQ indicator),
not found (GT on CHAIN or EQ on READs), file error(LT indicator), etc.
WITHOUT using an indicator at all.  This is a MAJOR improvement in RPG IV
but I think this new support uses new built-in functions, not named indicators.

The named indicator support we should be getting would be to equate the
indicator to a field IN THE DSPF or PRTF DDS or better yet, just use a field
instead of an indicator in the DDS.  That way you don't have to define an
indicator in the DDS and equate it to a field in the RPG IV program.  In
V4R2, if the indicator is changed in the DDS, you also must remember to
change it in in the RPG IV.  Defining the same thing in 2 different places
is redundant definition of data and is inappropriate.

Unfortunately this solution would require cooperation between Toronto and
Rochester.  Based upon past history, this is highly unlikely to happen as
evidenced by the following:

1. Date and time fields are supported in Toronto's RPG IV but not supported
in Rochester's DSPF and PRTF DDS.

2. Toronto's RPG IV is forced to use the worthless ILE line number in
compiles and execution time error messages making it impossible to track
down the SEU line number when you get an execution time error unless the
program is compiled DBGVIEW(*LIST) or you keep a copy of the compile listing
handy because Rochester's ILE requires ILE line numbers to be in ascending
sequence.

3.  Virtually all of Toronto's languages support multiple files,
subroutines, and structured constructs (DO, DOU, DOW, SELECT/WHEN, etc.)
while Rochester's CL has lacked these features since the S/38 (single DCLF
and no EXSR, DO, DOU, SELECT/WHEN, etc.).

4.  Toronto's RPG IV permits us to detect a referential integrity error but
Rochester's referential integrity support does not permit us to define a
message ID which the RPG IV program should display when the error occurs.

5.  Toronto's RPG IV and Rochester's DSDPF DDS permit us to virtually
eliminate indicators in an interactive maintenance program using
DSPATR(&FIELD) but where is the ability to position the cursor on a field
name without using indicators and without using a hard coded line number and
position?  We had this support some 20 years ago on a System/3 in RPG II and
CCP using an HGB as I remember.

Triggers, referential integrity, Query governor, internet support and all
the other wonderful enhancements which Rochester has given us are great.
But a lot of us still have to spend the majority of our time writing and
maintaining systems written in RPG.

I would be interested in any comments on this from other users in general or
Toronto (or Rochester for that matter) in particular.

Please do not misunderstand what I am saying.  I LOVE RPG IV and really
appreciate what Toronto and Rochester have given us so far.  I hate having
to go back to code in RPG III because it seems so cumbersome when compared
to RPG IV.  I just want RPG IV to live up to its full potential.  RPG IV is
much more than a programming language - it is a programming environment.
DDS and CL must be integrated with RPG IV.  This will require far more
cooperation between Toronto and Rochester that has been previously demonstrated.
 


Charlie Massoglia, Massoglia Technical Consulting, Inc.
PO Box 1065, Okemos, MI 48854, USA
517-676-9700  Fax: 517-676-1006  EMAIL: cmassoglia@voyager.net


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *