- Is there anyway to trace only those programs that run in a specific activation group?
- To the best of my knowledge, this, unfortunately, cannot be done. However, you can specify which specific ILE programs you want to trace using the TRCJOB command.
- Say you have a number of programs that make up a single application and they all run in the same activation group, what would be the ramifications if one of the programs has its activation group attribute changed, accidentally or otherwise?
- The repercussions of this depend on the interaction and dependence between the program that was changed and the other programs that use the original activation group. For example, if the programs share an ODP (open data path) and that ODP is scoped to the activation group level, then the app won't function properly - the changed program will not be able to share the ODP. If the programs are not sharing any resources, or if the resources are all scoped to the job level, then the repercussions are probably limited to a very slight loss of performance.
- Is there any way, given a specific activation group name, to determine which programs will run in that activation group?
- The only way to tell what activation group a program uses is to use the DSPPGM command. But this is only half the battle. Remember, a program can have an activation group attribute of *CALLER. When this is the case, you won't be able to determine which activation group it will run in until run-time - it will run in whatever activation group the program that calls it is running in.
For those programs that use *CALLER, I suppose you could cross-reference them to an outfile produced by the DSPPGMREF command. But even this won't produce 100-percent accurate results if, for example, you use C or you activate a program dynamically. Also, there is no equivalent to the DSPPGMREF command for service programs, so you won't be able to account for any service programs that call the programs.
- Can you determine which programs use (i.e., import) data items exported from a specific service program?
- Not directly, but you could build a utility using system APIs to cross reference service program exports to the programs that import them.
- When you make a change to procedure in a service program and you use the binder language to maintain compatibility between the new service program and any programs already using (bound to) the service program, can you still use the old version of the procedure?
- There is no "old version" of the procedure. Service programs can have many signatures but only one copy of the procedures. This is a common misconception about the binder language. If you want to keep the original procedure, then you will need to create a new procedure with a different name instead of modifying the original. Then, you can use whichever one you want.
- What is the difference between exported data items and procedure parameters?
- Don't confuse these two completely different concepts. Exported data items are essentially global variables that any other module can access if it imports them. In addition, any number of modules can concurrently share an exported data item. Procedure parameters are passed on the call stack from a calling procedure to a called procedure and are private to (i.e., known only to) the calling procedure and the called procedure.
Think of exported data items as OPM RPG variables; they could be accessed by any subroutine in the program (although you didn't have to explicitly import them in the subroutines). You can also make a loose analogy by noting that exports are to modules (and service programs) what parameters are to procedures; they are a way of sharing data among modules, whereas parameters are a way to share data between two procedures.
- If you use the UPDSRVPGM command to update a service program with a new version of a module, will that have any effect on programs that already use (are bound to) the service program?
- Any time you use the UPDSRVPGM command - just like any time you use the CRTSRVPGM command - a new signature is generated for the updated service program. If the new signature is the same as the old one, then you're OK. This happens when you don't add any new procedures to the module and you don't change the interfaces of the existing procedures (a procedure interface is made up of the number of parameters, the type and length of each parameter, and the return value).
If you do add a procedure or change an existing procedure's interface, then a different signature will be generated and any programs already linked to the service program will get a "signature mismatch" error the next time they are run. To avoid this problem, you must use the binder language to maintain signatures manually and use the Export and Export source file parameters on the UPDSRVPGM command to specify the name of your binder language source member (just as you would when using the CRTSRVPGM command).
This was first published in August 1999