MultiValue Tools

ROCKETEER Stuart MacKenzie posted 10-04-2022 05:23

Hi Nelson,
With regard to the error code 15001, I must confess I don't know the meaning of the error code, it is the error code returned for over 70% of the errors I'm aware of. 
errorDetailMessage provides the most useful information about the error, which is that it failed to load the subroutine, but it does not include any information about the specific subroutine.

There are 3 places you can look at to determine which subroutine call failed:

- The first and easiest place to look is the mvis.log file. You should see ERROR type log entries similar to this:
2022-10-04 02:54:58:150 [qtp1173643169-34] ERROR com.rs.u2.u2rest.b.c - [TWX_UV_XDEMO] U2DataStore: callSubroutine() 30105: Unable to load the subroutine on the server
2022-10-04 02:54:58:161 [qtp1173643169-34] ERROR com.rs.u2.u2rest.b.c - [TWX_UV_XDEMO] Server error occurred:
Incorrect VOC entry for SLEEP_TIME. 
- Secondly, if you have server side logging enabled for the account, you will see an error in the &COMO& directory. In this case:
Incorrect VOC entry for SLEEP_TIME.
- The third option is to enable the UniRPC serverdebug. This is an example of the log lines returned for this failure:
Tue Oct 4 02:54:58; errno=0: ICSubCall args=2,name=SLEEP_TIME,
Tue Oct 4 02:54:58; errno=0: arg[0]=1,
Tue Oct 4 02:54:58; errno=0: arg[1]=,
Incorrect VOC entry for SLEEP_TIME.
Tue Oct 4 02:54:58; errno=0: ICSubCall loadsub error.

I hope that helps provide additional insight but let me know if you have any questions.
Thanks
Stuart

ROCKETEER Mark Sapp posted 10-04-2022 13:25

Nelson,

With MVIS calling a backend BASIC subroutine - one other thing to consider is that there could be an issue with the backend code that dumps out of the program.  For example, a backend program that calls out to a subroutine where one of the parameters is missing in the CALL statement.  This will break / dump out to the ECL and then  MVIS will time out waiting for a response.   For debugging the backend processes I recommend creating a test program to run at TCL that will call the REST subroutine called by MVIS so that you can observe any errors that may be in the code itself. 

Regards,
Mark

Nelson Schroth posted 10-04-2022 16:56

Thanks for the responses.  Learned a lot about logging!
Turned out to be a subroutine cataloging problem on the U2 Account where ACCOUNT resides.

The best tool was the &COMO&  SCHEDULER_<account>_nnnn records.  Not sure what we enabled that caused these to be produced.  Thank heaven as the mvis.log lacked any real/valuable details.

Peter Cheney posted 10-04-2022 18:29

Is the offending subroutine globally cataloged? If you have recompiled it recently and not re-cataloged it globally then that _may_ be the cause. The other cause might be incorrect number of arguments being passed in either the MVIS config or the subroutine? Or a missing dynamic array in MVIS config? I would also test the  MVIS user connection to your server. Perhaps the password has changed or is expired? Hope this helps.