Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Need help with RPG numeric Indicators and their purpose *IN66

Status
Not open for further replies.

ColumbiaDiver

Technical User
Jul 27, 2002
35
US
All,

I am in the process of updating an older RPG program and being fairly new to RPG programming, (but not programming in general) I am having a difficult time understanding indicators and their place and purpose in RPG. I know that the recommended programming is to not use the numeric indicators, but to name them so those that follow after can read your code easily. Unfortunately, I am the one who follows after and I am having a heck of a time following the logic.

I have spent considerable time Googling and I have found a lot of articles that detail how to remove numeric from your code but nothing that tell me clearly what the indicator means that are currently in my code. I'm looking for a table that will list the indicator and it's purpose, (based on what I've read its purpose can be based on what column it is located in).

I have a whole group of indicators in this program *IN61, 64,66,67,68,69,71,72,73,74,75,76,81,83,84,91,99 and *INLR. Some of the indicators start in column 12 of the source member and some start in column 50. The *INLR indicator is located in column 50.

Hopefully someone can help me out here as I really need to trace out this source code and I have a critical payroll change that needs to be complete by the end of the year and if I could figure out the details of what the code is doing, I should be able to make the change fairly easily, but trying to read and follow the logic is turning into a major headache. If it would be helpful I can attach a section of the code.

TIA

Gordon
 
Here is a tutorial that may help you . RPG was originally designed to be programmed using punched cards and used indicators to tell that something happened such as end-of-file or the result of a comparison. The numbers themselves don't really mean anything. There is a consensus among programmers that indicators 01 though 24 are the F1-F24 keys. Other than that, an indicator can mean whatever the programmer wants it to mean.

An indicator can have two values; on or off. An indicator in column 12 will be checking its on/off status. If you see something like N70 - it means that indicator 70 is off. Seeing 70 without the N means it is on.

Review the tutorial and ask back if you have any other questions. The part of the tutorial you may be most interested in is the calculation specs. It may be good to read the part on the RPG cycle, too.

If you can post some code, it would be helpful to tell what it's doing.

Tom
 
Tom,

Thanks I'll take a look. I do have one question. Since an indicator can be whatever the programmer wants it to be, how to I tell what the programmer set the indicators to be? I've searched through the source code to see if I could find someplace where the programmer has said indicator *x is set to do y, but i can't find anything that seems to be doing this. It may just be my lack of experience with RPG, it may be there, but just not obvious to me. Below is a sample of the source using the indicators. Would indicators be comparable to built-in variables with a Yes or No response?

Thanks

Gordon

RHH * READ DEDUCTION DATA FOR PRINTING AND SETUP PARTIAL ..RHH
RHH * HEADING. ..RHH
RHH C MOVE '0' *IN84 ..RHH
RHH C MOVE *BLANKS DNAME1 ..RHH
RHH C Z-ADD *ZEROS DAMT1 ..RHH
RHH C Z-ADD *ZEROS DYAMT1 ..RHH
RHH C *IN68 CASEQ '0' CHKDED ..RHH
RHH C END ..RHH
RHH C WRITE CKSTUB6 51 ..RHH
RHH C MOVE '0' *IN74 ..RHH
RHH C MOVE '0' *IN75 ..RHH
RHH C MOVE '1' *IN84 ..RHH
RHH C MOVE *BLANKS DNAME1 ..RHH
RHH C Z-ADD *ZEROS DAMT1 ..RHH
RHH C Z-ADD *ZEROS DYAMT1 ..RHH
RHH C *IN68 CASEQ '0' CHKDED ..RHH
RHH C END ..RHH
RHH C WRITE CKSTUB6 51 ..RHH
RHH C MOVE '0' *IN74 ..RHH
RHH C MOVE '0' *IN75 ..RHH
RHH C MOVE '0' *IN84 ..RHH
RHH C MOVE *BLANKS DNAME1 ..RHH
RHH C Z-ADD *ZEROS DAMT1 ..RHH
RHH C Z-ADD *ZEROS DYAMT1 ..RHH
RHH C *IN68 CASEQ '0' CHKDED ..RHH
RHH C END ..RHH
RHH C WRITE CKSTUB6 51 ..RHH
RHH C MOVE *BLANKS DNAME1 ..RHH
RHH C Z-ADD *ZEROS DAMT1 ..RHH
RHH C Z-ADD *ZEROS DYAMT1 ..RHH
RHH C MOVE '1' *IN67 ..RHH
RHH C MOVE '1' *IN69 ..RHH
RHH C MOVE '0' *IN74 ..RHH
RHH C MOVE '0' *IN75 ..RHH
RHH C* ..RHH
C ENDCHK DOWEQ '0'
* READ AND PREPARE INCOME DATA FOR PRINTING IF MORE INCOME
* RECORDS REMAIN TO BE READ FOR THIS CHECK
C *IN66 CASEQ '0' CHKINC
C *IN67 CASEQ '0' CHKWAG
C *IN69 CASEQ '0' CHKEIC
C END
* READ AND PREPARE DEDUCTION DATA FOR PRINTING IF MORE DEDUCTION
* RECORDS REMAIN TO BE READ FOR THIS CHECK
C *IN68 CASEQ '0' CHKDED
C END
* IF EITHER INCOME OR DEDUCTION DATA IS MINS
C *IN81 CASEQ '1' PRINTS
C *IN83 CASEQ '1' PRINTS
C END
 
If your program has an display file, maybe the ndicators are used for changing the appearance of the display fields (to highlight them, make them protected, or dark, ...etc)
*INLR is an special Last Record indicator. It will be set on when the program ends.

ColumbiaDiver said:
.. if I could figure out the details of what the code is doing, I should be able to make the change fairly easily...
IMO, the easiest way to figure out what the program do is to debug it. I suppose that you are on IBM iSeries, so use the STRDBG command to use the build in debugger.

When I started to work on IBM AS/400 (aka iSeries) I had experience with several programming languages, so I could learn languages like COBOL, CL and REXX easily self.
But with RPG it was not possible. Compared with other high level languages RPG is something like assembler, but it's de facto system language on AS/400. Although my shop uses for business COBOL, there are some utilities written in RPG. I didn't understand it and so I told my boss that I urgently need an RPG training - and I got it. I suggest you to do the same. In one week training you can learn the basics of RPG and then with help of the debugger you will be able to change the behavioor of the legacy programs.

Other ressources about RPG are here:
 
Without comments you really can't tell what the programmer meant for the usage to be. You have to match up the indicators with code farther down the program. Some indicators do self-define. For instance the line

RHH C WRITE CKSTUB6 51 ..RHH

is turning on 51 to trap an error on the write. The 51 likely starts in column 56. Sometime later in the program there should be code that references 51 on the left side such as column 10 that handles the error.

You have to scan the program for the indicators one at a time to try to match them up. It is a painful process.

How long has this program been running? It looks like it's from the 70's or '80's. Today there are more modern RPG coding structures that use fewer indicators and make it easier to read. There may be a conversion utility to convert the program to more modern code. I'll see if I can find one.

Tom
 

Guys,


Warning, Warning: Long post, so if you want to read the details of my RPG misery then read on, otherwise skip to the last paragraph [cry]

Thanks for the help and suggestions, really useful. Tom yes it's old. The issue is that way back when my company bought the financial system software it didn't have all the functionality that they wanted so they customized some of the programs. Unfortunately, when the company came out with new functionality in the generic modules my predecessors did not update the custom code so that it had the same functionality as the generic.

So fast forward to today. The IRS requires that all paychecks show the pay rates effective with the first payroll of 2014, so it falls to me to update the custom module so that it now prints pay rates on the checks.

So I've been hammering on this for a while and I've managed to sort out some of what it is doing by looking at the generic code which does print rates on the checks and comparing it against the custom code. Unfortunately, I can't use the generic program as the custom module does a lot of different things including formatting the check way different than the generic module

The program consists of two modules the RPG program, (PYGRG51) and a printer file (PYTRG51). When I create what is called an On-Demand check it prints all zeros in the location where the rates should appear, (where the 7 zeros are after the pay type) Like so

REGULAR 0000000 8000
OVERTIME 0000000 1000
DOUBLETIME 0000000 1500
PAID TIME OFF 0000000

So I've managed to figure out what is populating the zeros in the check. By commenting out the following code in the Printer file

007100 GBO A* N61 RATEH 9 4 28EDTCDE(4)
007200 GBO A* 61 RATES 9 2 28EDTCDE(4)
And
013200 GBO A* 81 IPAYRT 7S 3 19

When I go back to the RPG program and search for indicator 61 I find the following code:

017800 *
017900 C EXSR INIT
018000 C *IN91 DOWEQ '0'
018100 C CZDD IFNE 'D'
018200 C CZPAY IFEQ 'H'
018300 RHH C* Z-ADD CZBRT RATEH RHH 01/08/92
018400 C MOVE '0' *IN61
018500 C ELSE
018600 RHH C* Z-ADD CZBRT RATES LSS 01/08/92
C MOVE '1' *IN61
C END
C EXSR PRTCHK
C END
C LDQTYP IFNE '1' NOT ON-DEMAND
C CHKEY READE PYRCZ 91
C ELSE ON-DEMAND
C ODKEY READE PYRCZ 91
C END
C END
C MOVE '1' *INLR
C RETURN
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

If I un-comment line 0183 it will print the base employee rate on the check, in the wrong place, but I don’t want the base rate on the check, as the base rate could potentially vary. What I want is the current rates for the check in question.

In the data file the rates are defines as CZRTE1, CZRTE2 etc through CZRTEU. If I modify the printer file and add the following line to the code

GBO A CZRTE1 R 30EDTCDE(M)

I will get the first rate appearing on the check, repeated 3 times, since I have not added code for the other rates, (DT rate of 35.6800) and the zeros where the rate should actually be, like so.

Employee name
Address
City, State, Zip
35.6800
Employee name 35.6800
35.6800
REGULAR 0000000 8000 142720
OVERTIME 0000000 1000 26760
DOUBLETIME 0000000 1500 53520
PAID TIME OFF 0000000

It looks like the code for the rate is actually there in the custom module, but was commented out by the person who customized the program way back when. What I’m trying to do is figure out exactly what needs to be un-commented and or added to utilize the original code for adding rates to the checks.

At this point I am trying to figure out exactly what this section of code is doing as it seems to tie into weather the program populates the rates area on the check with zeros or if it populates it with the actual rates.
(Part of the same code snippet as above)
017800 *
017900 C EXSR INIT
018000 C *IN91 DOWEQ '0'
018100 C CZDD IFNE 'D'
018200 C CZPAY IFEQ 'H'
018300 RHH C* Z-ADD CZBRT RATEH RHH 01/08/92
018400 C MOVE '0' *IN61
018500 C ELSE
018600 RHH C* Z-ADD CZBRT RATES LSS 01/08/92
018700 C MOVE '1' *IN61
018800 C END

I've also tried to figure out the purpose of indicator *IN91, but so far no luck. A search of the code of indicator 91 turns up the following bedsides the above

RPG program

C LDQTYP IFNE '1' NOT ON-DEMAND
C CHKEY READE PYRCZ 91
C ELSE ON-DEMAND
C ODKEY READE PYRCZ 91
C END
C END

Printer file
No occurrences

Sorry for the long post. Can anyone offer some insight?

Thanks

Gordon

 
Guys,

FYI I spent a lot of time trying to make sure the formatting on the code and checks were easily readable but when I submitted the post it went wonky.

Sorry.

Gordon
 
ColumbiaDiver said:
...trying to make sure the formatting on the code and checks were easily readable but when I submitted the post it went wonky.
You have to submit the code between the marks [pre]
Code:
[/pre][/color] and [COLOR=red][pre]
[/pre]
 
Gordon,

I feel your pain. You are working with Infinium payroll. I recognize PYGRG51 as the check printing program. We are using the software where I work and have the same issues as you with updates and applying custom changes. We have not customized PYGRG51, so, I'm not familiar with that program.

Code:
C LDQTYP IFNE '1' NOT ON-DEMAND
C CHKEY READE PYRCZ 91
C ELSE ON-DEMAND
C ODKEY READE PYRCZ 91
C END

The above code has two READE lines. They are setting *IN91. 91 located in the equal condition of the READE opcode. READE means read-equal-key. That means that when the program is at end of file for the key, *IN91 is turned on; else, it is turned off.

One way to find out what lines an indicator is used on is to use the compiled listing. Compile the program. Near the bottom of the listing will be a cross-reference of where all of the fields are being used including indicators.

My compile listing of the program shows:

Code:
                                                14000003                                        
         87                                       054700M     054900M     055300M   14000004    
*RNF7031 90                                       163600D                                       
         91                                       049600      050900D     051100D     165300D   
                                                  165600D                                       
         99                                       053700D     053800      055700D     055800    
                                                  163900D     164000D     164300D     164400    
         LR                                       051400M

There are 5 references for indicator 91. The *RNF7031 means that indicator 90 is defined but not used anywhere. The line numbers are the compiled line numbers and not the source line numbers. You can scan the listing for the line numbers such as 49600 for indicator 91.

Infor owns the software. They have very good support. You might be able to get them to answer your questions. Although they don't support custom code, they do a great job at helping you find where to put custom code. You have to be current on your support contract with Infor.

Tom

[xmastree]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top