If your programs uses calls to SCU3 then you already have a sort of parameter transaction which passes parameters. Quite likely the screen program fields do not support all parameters so it stops in the selection screen, in which case depending on your release you might still be able to add input and hit Enter, or you are kicked out.
A better option is a parameter transaction for START_REPORT on RSVTPROT with a screen variant name passed as parameter and authorize the user correctly for that table log. They might attempt to change the table selection if they can access it, but will be blocked if not authorized -> authorize S_TABU* correctly and then you do not even need to care how they get to the table.
Or create a parameter transaction for SE16 with variant selection on table DBTABLOG directly, but output is less friendly. Also some user might change the layout and selection options are regenerated and then you cannot pass the parameters anymore.
Even better -> give them a parameter transaction to the SM30 view which maintains the table -> via the menu options they can navigate to display changes (as they can access the view data already) and will see the change log (if activated).
Cheers,
Julius
