Securing RPG, CL Sources Codes

2880 pts.
Hi !

I need to secure the RPG, CL program source codes with a Token or Permission or Hidden mode or Any keys from other power users to edit or view. What are the possible ways to achieve this. Infact these codes are used in an application and I need to protect this anyone. Even the QSECOFR should not be able to find or edit.


Answer Wiki

Thanks. We'll let you know when a new response is added.

Not sure if it can be done. You could change authority on the QRPGLESRC and QCLLESRC filed for that specific library and only allow one user access. The problem would be trying to keep QSECOFR out.  A person with QSECOFR could go in and change the password for that user with access. then login using the new password  and make changes.

Discuss This Question: 2  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TheRealRaven
    Including QSECOFR (or a local security officer which is better) doesn't make sense and contradicts the basic reason for its existence. Further, there should be no reason to be concerned since perhaps at most two staff members should be able to sign on as a security officer and all activity should be audited. No one should be signing on as QSECOFR except under IBM's instruction once a local *SECOFR is created.

    Similar caveats apply to profiles with *ALLOBJ special authority. There are ways for a *ALLOBJ user to obtain any other special or user authority. Because of that, there should only be one or two profiles (other than *SECOFR profiles) with *ALLOBJ, and all activities should be audited.

    Since *SECOFRs and *ALLOBJ users can't be protected against, those all need to be considered as a separate category. A monitoring procedure to verify activities is the expected action. Combined with minimizing the use of such profiles results in minimal effort.

    Beyond that, basic object authority should be about all that's needed. Don't grant authority for things a profile shouldn't be doing.
    36,880 pointsBadges:
  • GregManzo
    If you are wanting to stop users with *ALLOBJ from accessing source files, that aint gonna happen - unless you remove *ALLOBJ from them (but that would be defeating the point of having secofr profiles in the first place).
    But I have seen software shops that maintain package software on their own system & ship object-only to their clients. If _that_ is what you are trying to achieve then read up on the Debug encryption key (DBGENCKEY) parameter. It lest you compile src into the object for debugging, but stops the client from seeing it.
    2,970 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: