Hi

I set a Global Function with a security category that the User does not have.

User executes the main function OK, when the global is executed the PRO-IV Error is

661 - TYPE MISMATCH IN GLOBAL FUNCTION CALL FOR FUNCTION - @SFUNCT

just thought I'd post this as it might help if you encounter this Error Msg as I found it a little mis-leading

there are other postings on this site for this error msg - but not the problem I was encountering
==

I think as in pro-iv version 5.5 as part of the LOGON process to pro-iv, a Global function (part of bootstraps) is executed, as we were encountering this error msg above. When we added Catg USER to the Operator then the Error no longer occurred.

When running version 4.6 all our users only had Catg "APP" as all of our functions are Catg "APP", on the user implementation we'd changed catg of @SFUNCT & @RFUNCT from "USER" to be "APP" so that when these executed users did not get errors.

We carried out same changes @SFUNCT & @RFUNCT on Version 5.5 but are getting the 661 Error unless we ass Catg USER to the the operator.

(We generally use transparent logon to bypass the pro-iv LOGON and bing user to our APPlication Logon function).

What other functions like @SFUNCT & @RFUNCT do "application" users need access to ?

tnks

George

I think depends on the function type of the Global function, you need to set Security Link to function to the same function type function

For example, if the Global function you are going to set Function category security is WI type, then you need to create a WI type function and put it in the Security link. When security volication hits, system will then execute this function.

Hi

thanks for the reply

I dont think I have any problem with my application security categories for functions or globals, they are all set to same catg APP which the operators/users have.

The problem we are encountering is that we seem to need to add catg USER to our operators for them to be able to go logon to system (Ver 5.5). We dont want to add USER to the operators as this provides access to 102 functions supplied with the bootstraps such as $SM.

We could be mistaking - but we are thinking that there is a Global (bootstrap catg USER) executed at LOGON and this is causing our problem.

Is anybody out there using Version 5.5 where Catg USER is NOT assigned to their "application" operators and having no problems using LOGON ?
and IF so, how have you worked around that @SFUNCT & @RFUNCT are catg USER ?

Rgds

George

Funnily enough George the same message can be given for a completely different error - where a global function is called and the primary file is keyed on operator id where the value is reset to an invalid one. The file read/write error is also shown.

Odd.

Hi

(yep I'm aware that not all pro-iv error msgs are correct, the methodolgy of Testing for when things dont work went out of fashion in IT Industry a long time ago, if any testing is done then people seem to only test for normal working. Every IT trainee should be issued with a flow-chart stencil.)

anyway for msg 661 - dont be mislead

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

as mentioned above - adding Catg USER to operator has temporarily got us over the "problem", so I think our problem is definitely a Bootstrap Global.

We are checking that none of our APPlication functions are Catg USER

Again
We dont want to add USER to the operators as this provides access to 102 functions supplied with the bootstraps such as $SM. I suppose we could change category of some of these functions from USER to BOOT but we'd like to avoid this.

Is anybody out there using Version 5.5 (with ORACLE 9i) where Catg USER is NOT assigned to their "application" operators and having no problems using LOGON ?
and IF so, how have you worked around that @SFUNCT & @RFUNCT are catg USER ?

I mention ORACLE 9i as would LOGON differ in its execution using an ORACLE DB ????

Rgds


George

George,

What is a flowchart stencil?????

Bob Filipiak

(What you can not see is my hidden sarcasm)

Hi

Problem resolved

With pro-iv Version 5.5 there are additional Bootstap functions to the earlier Version 4.6.
One of these functions is "FUNCHECK", ita a Global Update, this function is referenced "somewhere" when an operator is logged in to the pro-iv system.

It appears that this "FUNCHECK" function is category USER and this explains why we need Add Category USER to the ordinary Application users/operators to prevent the earlier reported errors.

Ideally we dont want to have Catg USER on all operators as this could provide them with access to PRO-IV functionality which we'd prefer they could never access.

Now that I know the cause of the problem, its a matter of removing completely the Security Category from the "FUNCHECK" function or amed this functions Security Category to "APP". And remove Catg USER from the normal operators, leaving them with ony Category "APP" thats required for the business application.

Rgds

George