Someone suggested (now I can't find the original message) that you could
place another program higher-up in the library list to circumvent the
security routines, and that's true. But even if a program hard-codes
the library name (instead of *LBIL) you could easily replace the
security service program with one of your own, and bypass security that
You could even rename the existing srvpgm, put your own code in it's
place, and have your code call the original one. Thus, making the
problem very hard to detect. (Basically, you've just written a Trojan)
Since the parameters would be going through your program, you could
inspect them and reverse-engineer the process to some degree.
Walden suggests that this could also be done with a *MODULE:
True. But can't I just do an updpgm with a new module to replace yours?
I guess the argument is that I'd need to know the signature which is
easier to know for a srvpgm than an embedded module.
It's true that you could potentially do the same thing this way -- the
problem is that it's very difficult to find out what the exports of the
original module were. (Assuming that the *MODULE object wasn't actually
You'd have to know exactly which routines were exported from the module
in order to duplicate them in your own code.
This is easy with a SRVPGM, since you can see the routine names with the
DSPSRVPGM command. However, it's not so easy with bind-by-copy, since
the names aren't visible unless you can inspect the *MODULE object.