CMS problem: %CMS-F-BUG

[John McL]

Usually we have no problems with our CMS system but under one account, when we try to run $ CMS SHOW HISTORY we're getting errors from CMS saying

%CMS-F-BUG, there is something wrong with CMS or something it calls
-CMS-F-NOQIO, $QIO failed
-RMS-F-WER, file write error
-SYSTEM-F-BADPARAM, bad parameter value

Some investigations showed
(a) the problem exists for CMS SHOW ELEMENT and other commands
(b) the UIC group for this account is different to owner of library but all CMS files have protextion (,,,RE)

Any thoughts would be appreciated, solutions even more so.

[Volker Halle]

John,

by just reading the error message you've posted:

RMS-F-WER indicates WRITE access failed

Protection: RE indicated only READ access granted

What if that account would have SYSPRV or BYPASS granted temporarily ? Would the CMS SHOW still fail ?

Volker.

[John McL]

It made no difference, Volker. The same error message appeared. (I know BYPASS can enable some special things in CMS, but apparently it won't solve this problem.)

(Sorry for delayed response. I was away from work on Friday.)

[John McL]

I should add that in a Batch job everything works fine, but failed in a detached job (a web server) reportedly even when the privileges for the owner account of the detached job was given BYPASS and SYSPRV as default privileges.

(I'm relaying this for someone without direct access to this forum.)

[John Gillings]

John,

>I should add that in a Batch job everything
>works fine, but failed in a detached job

Interesting... I'd check for logical names or other actions in LOGIN.COM that may be missing in the detached job.

I'd also check where the quotas are set - explicit PQL or from SYSGEN? Perhaps BYTLM is too low?

[Hein van den Heuvel]

>> I should add that in a Batch job everything works fine, but failed in a detached job (a web server) reportedly even when the privileges for the owner account of the detached job was given BYPASS and SYSPRV as default privileges.

John, ask them if it ever worked. I doubt it.

I suspect CMS might be using SYS$SCRATCH or SYS$LOGIN, neither of which is setup for a detached job.
So either make the job start LOGINOUT and then chain to the real task, or define a suitable SYS$LOGIN and/or SYS$SCRATCH in a suitable logical name table.

For now, just to confirm the suspicion, define both in LNM$SYSTEM.
Any 'normal' use will resolve above that.

hth,
Hein

[John McL]

The failing process, APACHE$WW_nnnn, is running as a subprocess to process APACHE$SWS0000, which I think is detached.

APACHE$WW_nnnn has a SCRIP$LOGIN and SCRIP$SCRATCH defined.

The right hand column of SHOW QUOTA says
Direct I/O limit: 300
Buffered I/O limit: 300
Open file quota: 279
Subprocess quota: 19
AST quota: 609
Shared file limit: 0
Max active jobs: 0


John

[Hein van den Heuvel]

>>> APACHE$WW_nnnn has a SCRIP$LOGIN and SCRIP$SCRATCH defined.

That's just great, but why would CMS care? It would only care about CMS$mumbles and SYS$mumbles... if it cares at all.

How about running the success case using SET WATCH FILE/CLA=MAJOR and explain each file access witnessed trying to understand whether the same file/directory could be accessed from the other context?

fwiw,
Hein

[John McL]

Sorry Hein, my mistake. I was distracted. I should have written SYS$SCRATCH and SYS$LOGIN.

[Brad McCusker]

Your base note said "under one account" you get errors. That of course implies that under other accounts you do not get errors.

For the two accounts in question (one that gets errors, and one that does not get errors) is everything else the same? You are using the same application (apache), you are performing the same tasks, etc? I suspect the answer is no, but please clarify.

The reason for my question is to try to better understand the situation you are in.

I'd also like to see the answer to someone's previous statement questioning if it ever worked as you expect it should.