Difference between revisions of "Indicators"

From MidrangeWiki
Jump to: navigation, search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[[Category:RPG]]  
 
[[Category:RPG]]  
 +
==Overview==
 +
We will start with a little historical perspective.  [[RPG]] has always had just 99 indicators.  At some point, programmers were allowed to access them as if they were in an array (the [[*IN array]]).  After display files were introduced, they started eating up all the available indicators in order to position cursors, set display attributes and what not.  Pretty soon, there weren't enough indicators for both the display file and RPG.
 +
==Separate Indicators for Displays==
 +
The solution was to allow display files to have their own set of 99 indicators.  This is done by specifying the [[INDARA]] keyword in the display file, and the [[INDDS]] keyword on the file spec in the RPG program.  Once you've done this, RPG has its 99 indicators in the [[*IN array]], and the display file references the 99 indicators in the data structure specified in the [[INDDS]] keyword on the file spec.
  
We will start with a little historical perspective.  RPG has always had just 99 indicators.  At some point, programmers were allowed to access them as if they were in an array (the *IN array)After display files were introduced, they started eating up all the available indicators in order to position cursors, set display attributes and what notPretty soon, there weren't enough indicators for both the display file and RPG.
+
Now it is possible to have the display file's indicator data structure overlay the *IN array, by making the data structure based, and having its basing pointer point to the beginning of the [[*IN array]]If you do this, you're back to one set of 99 indicators, which negates the intention of having a separate set of indicatorsAnd it's a waste of coding time, since you have the same effect by leaving off the [[INDARA]] and [[INDDS]] keywords.
  
The solution was to allow display files to have their own set of 99 indicators.  This is done by specifying the INDARA keyword in the display file, and the INDDS keyword on the file spec in the RPG program. Once you've done this, RPG has its 99 indicators in the *IN array, and the display file references the 99 indicators in the data structure specified in the INDDS keyword on the file spec.
+
The following code shows the use the the INDDS keyword. The data structure name associated with it is DSPIND. This gives you another 99 indicators to use besides the *IN indicators. However, it will not "turn on" the *IN indicator in the same position. In other words, the statement "F3Exit = *ON" will not turn on *IN03.
  
Now it is possible to have the display file's indicator data structure overlay the *IN array, by making the data structure based, and having its basing pointer point to the beginning of the *IN array. If you do this, you're back to one set of 99 indicators, which negates the intention of having a separate set of indicators.  And it's a waste of coding time, since you have the same effect by leaving off the INDARA and INDDS keywords.
+
<pre>
 +
    FWrkStnNamDCF  E            WORKSTN SFILE(SUBFILE1:RRN1)
 +
    F                                    INFDS(PINFDS)
 +
    F                                    INDDS(DSPIND)  
  
The only reason I've ever seen for mapping a data structure to the *IN array is to allow naming the 99 RPG indicators so you don't have to use *IN34 or *IN(27), which are not very meaningful.  But you don't need to use INDARA or INDDS to do this.  Simply define a based data structure whose pointer points to the address of *IN01.  This data structure does NOT have to be specified in an INDDS keyword.  You don't even need a display file.  In other words, you could have a program with an INDARA display file where INDDS points to data structure ABC, and a separate based data structure XYZ that overlays the *IN array.  That way you can name the 99 RPG indicators and the 99 display file indicators. (Provided by Peter Dow)
+
    D DSPIND          ds                 
 +
    D Inds                          99A
 +
    D  FunctionKeys          01    30
 +
    D  ErrInds              80    89
 +
 
 +
    D  F3Exit                        n  overlay(Inds:03)                    Option...
 +
    D  F4Prompt              04    04n
 +
    D  F5Refresh            05    05n                   
 +
</pre>
 +
 
 +
==Mapping Indicators to Names==
 +
The only reason I've ever seen for mapping a data structure to the [[*IN array]] is to allow naming the 99 RPG indicators so you don't have to use *IN34 or *IN(27), which are not very meaningful.  But you don't need to use [[INDARA]] or [[INDDS]] to do this.  Simply define a based data structure whose pointer points to the address of *IN01.  This data structure does NOT have to be specified in an INDDS keyword.  You don't even need a display file.  In other words, you could have a program with an [[INDARA]] display file where [[INDDS]] points to data structure ABC, and a separate based data structure XYZ that overlays the [[*IN array]].  That way you can name the 99 RPG indicators and the 99 display file indicators. (Provided by Peter Dow)
 +
 
 +
 
 +
The following snippet of code shows what is needed to use the *IN array as the basis for renaming your indicators. Notice that there are no F specs. In this case if you use the statement "F3Exit = *ON", *IN03 will also be turned on.
 +
 
 +
This creates a pointer to the *IN array named Indicators@, which is used in the Indicators array as its base:
 +
 
 +
<pre>
 +
    ** Display File Indicator Usage using *IN as a base
 +
    D Indicators@    s              *  inz(%addr(*IN))
 +
 
 +
    D Indicators      ds                  Based(indicators@)
 +
    D Inds                          99A
 +
    D  FunctionKeys          01    30
 +
    D  ErrInds              80    89
 +
 
 +
    D  F3Exit                        n  overlay(Inds:03)                    Option...
 +
    D  F4Prompt              04    04n
 +
    D  F5Refresh            05    05n                     
 +
</pre>
 +
 
 +
The Inds sub field is the full length of the data structure. This can be used to allow you to use the OVERLAY keyword instead of from and to positioning.

Latest revision as of 17:32, 10 August 2007

Overview

We will start with a little historical perspective. RPG has always had just 99 indicators. At some point, programmers were allowed to access them as if they were in an array (the *IN array). After display files were introduced, they started eating up all the available indicators in order to position cursors, set display attributes and what not. Pretty soon, there weren't enough indicators for both the display file and RPG.

Separate Indicators for Displays

The solution was to allow display files to have their own set of 99 indicators. This is done by specifying the INDARA keyword in the display file, and the INDDS keyword on the file spec in the RPG program. Once you've done this, RPG has its 99 indicators in the *IN array, and the display file references the 99 indicators in the data structure specified in the INDDS keyword on the file spec.

Now it is possible to have the display file's indicator data structure overlay the *IN array, by making the data structure based, and having its basing pointer point to the beginning of the *IN array. If you do this, you're back to one set of 99 indicators, which negates the intention of having a separate set of indicators. And it's a waste of coding time, since you have the same effect by leaving off the INDARA and INDDS keywords.

The following code shows the use the the INDDS keyword. The data structure name associated with it is DSPIND. This gives you another 99 indicators to use besides the *IN indicators. However, it will not "turn on" the *IN indicator in the same position. In other words, the statement "F3Exit = *ON" will not turn on *IN03.

     FWrkStnNamDCF   E             WORKSTN SFILE(SUBFILE1:RRN1)
     F                                     INFDS(PINFDS)
     F                                     INDDS(DSPIND)  

     D DSPIND          ds                  
     D Inds                          99A
     D  FunctionKeys          01     30
     D  ErrInds               80     89

     D  F3Exit                         n   overlay(Inds:03)                     Option...
     D  F4Prompt              04     04n
     D  F5Refresh             05     05n                    

Mapping Indicators to Names

The only reason I've ever seen for mapping a data structure to the *IN array is to allow naming the 99 RPG indicators so you don't have to use *IN34 or *IN(27), which are not very meaningful. But you don't need to use INDARA or INDDS to do this. Simply define a based data structure whose pointer points to the address of *IN01. This data structure does NOT have to be specified in an INDDS keyword. You don't even need a display file. In other words, you could have a program with an INDARA display file where INDDS points to data structure ABC, and a separate based data structure XYZ that overlays the *IN array. That way you can name the 99 RPG indicators and the 99 display file indicators. (Provided by Peter Dow)


The following snippet of code shows what is needed to use the *IN array as the basis for renaming your indicators. Notice that there are no F specs. In this case if you use the statement "F3Exit = *ON", *IN03 will also be turned on.

This creates a pointer to the *IN array named Indicators@, which is used in the Indicators array as its base:

     ** Display File Indicator Usage using *IN as a base
     D Indicators@     s               *   inz(%addr(*IN))

     D Indicators      ds                  Based(indicators@)
     D Inds                          99A
     D  FunctionKeys          01     30
     D  ErrInds               80     89

     D  F3Exit                         n   overlay(Inds:03)                     Option...
     D  F4Prompt              04     04n
     D  F5Refresh             05     05n                      

The Inds sub field is the full length of the data structure. This can be used to allow you to use the OVERLAY keyword instead of from and to positioning.