Operation Security using Operation rather than Security Level

[ge...@solutionserve.com]

I want to be able to show an operation (or not show) based on looking up a USER ID on a table that has a 1-many join over a second table that has records for each user - for each operation they can see. I simplified my code for the example below - but I am doing the same thing as this example and getting an error. Unless I can get by this problem or find an alternative, I cannot see the real value of Operation Security Operations in a dynamic use

The area I cant figure out is how do I dentify the current Operation running - and then pass that information to the Authorization program so it can have an SQL something like

SQL Operation to Secure is -- Sales Report One and in its Operation I stipulate Operation Security to run OPERSEC operation

the SQL of Sales Report One I used is

Select salesitem, salesqty, salesamt, ??!WOW_OP_ID as der_current_operation

user table has 3 fields: userid, userpw, userkey   --- 

usr_opxref table 2 fields: has xruserid , xroperation

OPERSEC operation has SQL of :

select userid 

from userlib.usertable 

left join userlib.user_op_xref on userid = xruserid 

where xroperation = ??der_current_operation

how do I figure out der_current_operation for the Sales Report One Operation so the Operation - OPERSEC knows the value in ??der_current_operation (or another type of parm)

when running Sales Report One above I receive error,  [SQL0418] Use of parameter marker not valid. Cause . . . . . : Parameter markers and the RAISE_ERROR scalar function are not allowed: -- As a value in a VALUES INTO statement. -- As an operand of a concatenation operation. -- As the operand of a scalar function. If the scalar function is VALUE, COALESCE, IFNULL, MIN, MAX, LAND, LOR, or XOR, then at least one of the arguments must not be a parameter marker. -- As the left operand of the LIKE predicate. -- As the operand of a unary minus. Parameter markers are also not allowed: -- In the SELECT clause of the statement string to be prepared. -- In an SQL statement in embedded SQL or in interactive SQL. -- In an EXECUTE IMMEDIATE statement. -- In a CREATE VIEW, CREATE TABLE, ALTER TABLE, or CREATE INDEX statement. -- In a statement processed by the RUNSQLSTM command. -- In a blocked INSERT statement. Recovery . . . : Ensure parameter markers and the RAISE_ERROR scalar function are only specified where they are allowed. A CAST specification can be used in many situations. Correct any errors. Try the request again