5 replies to this topic

[Paul Taylor]

we are running: 6.2 release 6.2.65 green screen, I have a gs trying to do a global call to a ®report function and am getting the 661 type mismatch, I came across a post that said that as of version 5 calling a non global from a global should not be an issue after version 5 is this the case in this situation.

 

[DARREN]

That is correct. A global function can and often is called from a screen and/or update. 
Check the parameters in the interface to the global function are the same type as the parameters they are being mapped to i.e. Alpha to Alpha and Numeric to Numeric. 
Are you passing an array to the global report?
Does the global report have the correct function security category for your operator?
 
 

[Paul Taylor]

there are no parms, but it is a global function (global screen) calling a function (report)  GLOBAL-LSCALL(PCBC04A), security should not be an issue.

[DARREN]

a) Ensure the global report is defined as a global report (the global switch has been set) and it has been compiled.

Ensure the security category on the global report is defined in the security category of the operator that is attempting to run it. 

[Paul Taylor]

the global screen is calling a non-global report.

[DARREN]

You cannot do that.
Make the report global (set the switch and recompile).
You can still @LFUNCT to the report from other parts of the system (frowned upon - but does work) OR create a wrapper function that calls the global report and @LFUNCT to that from other parts of the system (obviously code changes required for this implementation solution).

Alternatively, @LFUNCT to the Report. This solution will require the window to close and then exit the parent function. 
You could enhance the window to pass back a parameter like #RunReport

...and in the parent function test the parameter
//

if #RunReport =  True then

   @LFUNCT = 'PCBC04A'

  FNEXIT

endif