Operating System - OpenVMS
1748151 Members
3960 Online
108758 Solutions
New Discussion юеВ

Re: NOMSG + create failed

 
Wim Van den Wyngaert
Honored Contributor

Re: NOMSG + create failed

Hein,

Yes, it is create/fdl that is causing the problem. I have errorhandling but only get the error code, not the message stack. Unless I explecitly ask for it (as I will do from now).

Yes, I used to maintain (generate) fdl's too, 10-15 years ago.

The FDL is a static files that doesn't move and is only accessed by the procedure itself.
I tested if exclusive access is needed and the answer is NO. So, I think it must be something differently.

Filling error messages based upon user complaints is the wrong way to go. You need someway of scanning the sources and checking if all codes are present in the libraries. That's how we used to work in COBOL.
Wim
Hein van den Heuvel
Honored Contributor

Re: NOMSG + create failed

> Yes, it is create/fdl that is causing the problem.
> I have errorhandling but only get the error code, not the message stack.
> Unless I explecitly ask for it (as I will do from now).

'Normally' it just shows up in the batch log no? Or is this spawned perhaps.
If it is spawned, then I'd strongly recommend to call FDL$CREATE instead.

> Yes, I used to maintain (generate) fdl's too, 10-15 years ago.

I think you mis-read or I did not write clearly enough.
I actually maintained the FDL code for the VMS sources. :-).

> The FDL is a static files that doesn't move and is only accessed by the procedure itself.

As they normally are. So some other 'environmental' condition happened.
Some (pooled) process quota ran out?
Normally the FAB$L_STV field would have those details, not the primary FAB$L_STS.


> I tested if exclusive access is needed and the answer is NO. So, I think it must be something differently.

Well... exclusive access is indeed not needed, just read will do. But it will not work if an other stream already has exclusive access:

$ open x tmp.fdl
$ create/fdl=tmp test
$ close x
$ open/write x tmp.fdl
$ create/fdl=tmp test
%FDL-F-OPENFDL, error opening U$1:[HEIN]TMP.FDL;
-RMS-E-FLK, file currently locked by another user

> Filling error messages based upon user complaints is the wrong way to go.
> You need someway of scanning the sources and checking if all codes are present in the libraries. That's how we used to work in COBOL.

Again, I mis-communicated. Sorry.
It is 99.99% sure that all message are caught in message files. The purpose of filing a full documented report would be to learn how the application got in trouble and maybe fix that somehow or just help the customer to fix the problem... because it will be a customer applicaiton problem, not a 'missing' error message.

There are no missing error messages in VMS. Period.
In the VMS sources error message are never hard coded.
They are always symbolic and the symbols/values are generated from message sources files. If a a message is 'forgotten' a compile / link error (while building VMS) will occur and will be fixed.
The above has to be the assumtion / expectation. Sure, something may have sneeked by, but that's pretty darn unliekly and so an application problem is expected.

Now that application problem, may be due to a sub-optimal VMS setup choice ('surprise' location for an msg file) which VMS may be able to address, but it woudl be kinda od to run into that now, after decades of few / no problems

Groets,
Hein.
Martin P.J. Zinser
Honored Contributor

Re: NOMSG + create failed

Hello Wim,

one more thing you could try:

Bracket the create/fdl operation in a

set watch file/class=major
create/fdl...
set watch file/class=none

This should provide addtional information on the attempted file system operations. Yes, I know set watch is undocumented, but I have it from a reliable source that it is save to use ;-)

Greetings, Martin
Jan van den Ende
Honored Contributor

Re: NOMSG + create failed

SET WATCH is a real friend!!

(but don't forget it needs CMKRNL)

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor

Re: NOMSG + create failed

CMEXEC works for me, too. But, anyone with CMEXEC privilege can get into kernel mode with a small program anyway...
.
Wim Van den Wyngaert
Honored Contributor

Re: NOMSG + create failed

Found the reason.

While the procedure was doing create/fdl, another procedure was changing the protection on the directory in which the FDL was placed. Result : file currently locked by another user.

Wim
(wie zoekt die vindt)
Wim