You can always reuse indicators, as often or as many times as you want. The problem is, if you're dealing with an old, ancient, archaeic program that originated from RPG II or RPG III which should be retired or rewritten, you'll need to carefully analyze how it uses whichever indicators you're thinking of reusing in order to avoid messing up its current logic. You may have to save the values of an indicator to a work variable and then re-use that indicator, and then copy the value from the saved variable back into it once your new logic is done with it. A better solution is to convert the program to RPG IV, if it hasn't already been done. Then, the only reason to even use the numbered 1-99 indicators is if it's an interactive program that uses a display file and needs those indicators to condition various behaviors on the screen. Any other numbered indicator can be replaced with a named indicator, where you can define and use as many as you want. And depending on what those indicators are being used for, you may be able to completely eliminate them by relying on the built in functions (BIFs) for file and record status (functions like %EoF, %Found, %Equal, etc.). So instead of using a resulting indicator after a file operation, and then testing the value of that indicator to know whether or not a record was retrieved ,you would leave the resulting indicator off, and just use the approprate BIF to condition your logic. Instead of: <pre> KEYFIELD CHAIN MYFILE 98 IF *IN98 = *Off (proceed) ENDIF </pre> you would do this: <pre> KEYFIELD CHAIN MYFILE IF %Found(MYFILE) (proceed) ENDIF </pre> or this: <pre> /Free CHAIN (KEYFIELD) MYFILE; IF %Found(MYFILE); (proceed....) ENDIF; /End-Free </pre> CWC ***************************** Re-write your program without indicators and publicly flog the person who wrote the program to set an example. Steve

You can always reuse indicators, as often or as many times as you want. The problem is, if you're dealing with an old, ancient, archaeic program that originated from RPG II or RPG III which should be retired or rewritten, you'll need to carefully analyze how it uses whichever indicators you're thinking of reusing in order to avoid messing up its current logic. You may have to save the values of an indicator to a work variable and then re-use that indicator, and then copy the value from the saved variable back into it once your new logic is done with it. A better solution is to convert the program to RPG IV, if it hasn't already been done. Then, the only reason to even use the numbered 1-99 indicators is if it's an interactive program that uses a display file and needs those indicators to condition various behaviors on the screen. Any other numbered indicator can be replaced with a named indicator, where you can define and use as many as you want. And depending on what those indicators are being used for, you may be able to completely eliminate them by relying on the built in functions (BIFs) for file and record status (functions like %EoF, %Found, %Equal, etc.). So instead of using a resulting indicator after a file operation, and then testing the value of that indicator to know whether or not a record was retrieved ,you would leave the resulting indicator off, and just use the approprate BIF to condition your logic. Instead of: <pre> KEYFIELD CHAIN MYFILE 98 IF *IN98 = *Off (proceed) ENDIF </pre> you would do this: <pre> KEYFIELD CHAIN MYFILE IF %Found(MYFILE) (proceed) ENDIF </pre> or this: <pre> /Free CHAIN (KEYFIELD) MYFILE; IF %Found(MYFILE); (proceed....) ENDIF; /End-Free </pre> CWC ***************************** Re-write your program without indicators and publicly flog the person who wrote the program to set an example. Steve