Problem with *READ Trigger Program

60 pts.
Tags:
RPG ILE
RPG IV
RPGLE
Caller Program A Reads a record from File X.

"After-Read-Trigger" kicks in and calls Program B.

Program B changes the Read-Record's fields as per the required logic (I can see the modified trigger-buffer in debug).

Software/Hardware used:
RPGLE

Answer Wiki

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

Are you asking how to do this or are you having a problem with an existing program. If it is the latter, then what problem are you having?

===================================================================

A READ trigger receives a <i>copy</i> of the buffer that is passed to the program, not the buffer itself. Whatever the READ trigger does to the data will not be seen by any program. (Nor <i>should</i> it be seen by the application!)

Tom

===================================================================

Thanks for the quick response.
But, is there a way around that?
In other words, we need to do kind of “our own field-level security”, without modifying too many programs. I thought the Read-Trigger would help in that.
Any ideas??

Discuss This Question: 9  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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Ihabik
    Sorry, it seems like my question was not pasted complete. Program B is in development, and I am asking how to make it work as I want. The problem is that trigger program B does not return the changed data to the caller program A.‎ How to make caller program A to utilize data from the "Trigger Buffer"?‎ Please note that Caller Program A cannot be changed.‎
    60 pointsBadges:
    report
  • TomLiotta
    The concept of "trigger" is that they are part of the database. A trigger always fires at its appointed time regardless of the access method. A READ trigger with *CHANGE capability could cause the database to present wrong data to DSPPFM. A CPYF could result in copies that were not actually in the file. The simplest queries could be misleading. There isn't even any way to guarantee the validity of the data types in the buffer -- it could be garbage. (SQL validates on WRITEs. It implicitly trusts READs.) And it would all happen without existing applications knowing it. No existing program could trust what the database was handing to it. So, if an input buffer is to be controlled, it should be done with VIEWs and possibly UDFs. The application should make the request. It should know what it's asking for. I'd need to think for a while in order to come up with a useful idea for you -- if a good one exists. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    A logical file might be created which had selected columns values as blanks or zero's...
    50,205 pointsBadges:
    report
  • TomLiotta
    A logical file might be created which had selected columns values as blanks or zero’s… This is possible, but actually requires at least two LFs or this new LF and the existing PF.. One LF (or the PF) would be used for the unrestricted users and this new LF would be used for users that shouldn't have access. However, it does require either a change to ProgramA or a change in how ProgramA is called. The change would perhaps involve issuing an override to select the file based on which user ProgramA was running under. It's likely that there are numerous programs in addition to ProgramA, and all of them would need similar overrides. (An OPNQRYF could be constructed differently depending on user. That eliminates an actual LF creation, but adds a performance hit.) The LF would be carefully constructed to generate the same format level as the original file. A VIEW using UDFs could make the "user decision" without overrides. Unfortunately, a VIEW can't specify ORDER BY and doesn't provide keyed/random access. ProgramA would need changes unless it was already a SQL program -- if it was, the change might be limited only to the database and ProgramA shouldn't notice the change. Tom
    125,585 pointsBadges:
    report
  • Ihabik
    Thanks Tom for the idea. It sounds good, but unfortunately programA is not SQL; it is RPGLE. Also, I cannot change ProgramA or change how ProgramA is called. Thanks.
    60 pointsBadges:
    report
  • philpl1jb
    Don't give up so quick on it .. we're still brain storming or was that barn storming. It could be a minor change right when the user logs in. Adding a library to their User Profile above the application program or adding an override right at that time..if this logical file were in another library it could have the same name as the physical, same format so if there aren't overrides of this file in the application or specific libraries used in the RPG opens .. then this is easy, and Tom can tell you how. But most important - the physical file shouldn't be updated from this logical or you will loose the data in the hidden fields Phil Phil
    50,205 pointsBadges:
    report
  • BigKat
    Hi Philpl1jb, That last sentence should be in bold, italics, underline, blinking text, neon colored,... :)
    8,220 pointsBadges:
    report
  • TomLiotta
    A particular difficulty comes out of "I cannot change ProgramA or change how ProgramA is called." There are implications to that, especially when the statement comes from a developer who is creating READ triggers and is using using debug to verify changes in memory. (Not to mention thinking enough to post a question on a forum such as this.) Some level of competence is implied. So, if sufficient authority to use debug and to create programs and add triggers exists, but the capability to change existing source and control program entry doesn't exist, perhaps the reasons need to be clarified in order to understand the environment. Maybe it's a 3rd-party package. Maybe all ProgramA's already control what file(s) they open. Maybe lots of things preclude various possibilities. The environment needs to be described so we know what's possible. Tom
    125,585 pointsBadges:
    report
  • Ihabik
    Yes Tom, you are absolutely right. ‎ ‎"it’s a 3rd-party package." & "all ProgramA’s already control what file(s) they open."‎ I just didn't think I needed to go into many details at the beginning, but I think I should.‎ The file I mention here is used by hundreds of programs of this package, and all what we need to do is ‎to encrypt one field. ‎ I already succeeded to deal with the authority part, encrypt the data, and insert it to the file using ‎‎"Before-Insert" trigger. I have also succeeded to check the authority & decrypt it to the original correct ‎value and see it in debug. All what I need now is to show it to the authorized users, if they call a ‎program to READ that field & display it. ‎ That is why I was hoping that the READ-Trigger would return the decrypted data to the buffer of the ‎reading program, but now I understand it is not...‎ I am not giving up yet, but whether I get a solution or not, I am happy with the experience of such an ‎amazing brain storming, and I do appreciate the input of everyone here.‎ Thanks,‎ Ihab
    60 pointsBadges:
    report

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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

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

Following