RdB; Inability to execute complex queries in detached process

[Richard J Maher]

Hi John,

>>>>>>>>>>>>>>>>>>
If you want a detached process running under a different USERNAME from the issuing process,
<<<<<<<<<<<<<<<<<<<

I don't think he does; I think Willem is just one of many trying to implement a very poor-man's server.

>>>>>>>>>>>>>>>>>>>
the simplest supported means to achieving it is to encapsulate your RUN/DETACHED command in a command procedure (WITHOUT "/UIC=") and "SUBMIT/USER=username" that procedure.
<<<<<<<<<<<<<<<<<<<

Perhaps the simplest but yet another poor choice that has been discussed many times. Poor in performance, o/head, error-handling, and functionality. Why not go crazy and actually write a little program? I know it's not scripting and no one does it anymore but just $persona_assume and the $creprc and off you go. VMSNOTES circa 6.2 15 years ago?

But let me go out on a limb here and suggest that what Willem really wants is to have a setup where he has transparent multi-threading and an active pool of VMS processes serving a far greater number of clients yet have the servers "become" the client whilst performing work on their behalf?

Look for t3$persona_assume in the attached file. And all with *not one* additional VMS privilege required for the server process!

Of course what goes hand in hand with VMS personae is the very useful rdb "session authorization" functionality as in: -

SQL> set session authorization persona :ws_integer

The problem unfortunately is that Rdb engineering (or at least one person in Rdb engineering) refuses to add the "persona" syntax and demands that you lug around VMS passwords *in the clear*.! A real shame :-(

Cheers Richard Maher

[Willem Grooters]

Consider it known that this solution isn't the brightest one. But I was called in too late to change matters. I just have to work around it. Sorry guys, but these things happen ;)

The problem is not that queries are not executed. They are - for ANY user. Just those that contained subqueries failed - depending on the size of the dataset. Simple as that.

The matter is: why.

Crossposting does have advantages. See the solution found.

[Willem Grooters]

Since teh problem happened on complex queries, thoughts were a lack of workspace. Since the program runs in a detached process, SYS$LOGIN, SYS$LOGIN_DEVICE, and SYS$SCRATCH are not defined. RDMS$RUJ seemed not needed (it's read-only).

Adding:

$ define/nolog sortfile0
$ define/nolog sortfile1
$ define/nolog sortfile2
...
$ define/nolog rdms$bind_work_file

before running the executable, as suggested on Oracle Metalink, solved the issue.