"%SEARCH-E-NOFILE, no file found" and "-RMS-E-FNF, file not found" difference

[Arch_Muthiah]

Hi,

Env: Alpha/OpenVMS 8.2
My macro program searches for a string by going thru all user's entire HOME (LOGIN) directory. I am passing the directory files name to $PARSE and $SEARCH rms services this way using NAM and FAB ....
Ist time: disk:[username1...]*.*
some time: disk:[test_dir...]*.*

$PARSE returns success status, but $SEARCH fails, it returns file not found (RMS$_FNF) status in R0.

I have "RMS$_FNF" error processing loop for some other purpose. Instead I expect my program should go to "%SEARCH-E-NOFILE, no file found" loop.

$ search disk:[username1...]*.* str_2b_serch
%SEARCH-W-OPENIN, error opening disk:[username1...]*.*; as input
-RMS-E-FNF, file not found
%SEARCH-E-NOFILE, no file found

This "-RMS-E-FNF, file not found" error will come in lot many other situation also, we know.

How can we differentiate "%SEARCH-E-NOFILE, no file found" error from "-RMS-E-FNF, file not found".

Is there any other symbol which gets filled with "%SEARCH-E-NOFILE, no file found" error in NAM or any other RMS block?.

I tested all RMS$ return code related with $SEARCH routine.

Thanks in Advance.
Archunan

[Steven Schweda]

The system service $SEARCH is completely
unrelated to the command/program SEARCH. You
may get %SEARCH errors from the SEARCH
command, but you will never get one from the
$SEARCH system service.

If $SEARCH returns RMS-E-FNF on the first
call, then you got no match to the
(wildcard?) file spec. I believe that you
need to count the files yourself.

[Steven Schweda]

Note, for example, the "Condition Values
Returned" section in the description of
$SEARCH:

http://h71000.www7.hp.com/doc/731FINAL/4523/4523pro_034.html#index_x_1153

No SEARCH$_anything, only RMS$_things.

[Arch_Muthiah]

Hi,

$SEARCH routine returns "-RMS-E-FNF, file not found" error in too many instances such as for ...
1. disk:[username1...]*.* --- in this case, under username1 home dire, there is no files, it is a empty dir.

2. disk:[username1...]nonexisting_file.dat --- in this case nonexisting_file.dat is not available.

The $SEARCH fails in these two situations are difft. Isn't it?, but it returns "-RMS-E-FNF, file not found" error and goes to the same loop for both case.

I want to seperate the error type for the first case. that is "any user's home directory is empty".

I am testing R0 against #NAM_WILDCARD for some other purpose, but to trap this error, I found no use with this test.
-------------------

Yes I saw the return values specific to the $SEARCH routine.

Thanks for your response, steve.
Archunan

[Steven Schweda]

> The $SEARCH fails in these two situations are difft. Isn't it?

In the first case, you're looking for a file
which doesn't exist, while in the second
case, you're looking for a file which doesn't
exist.

There may be some other (clever) method, but
if you wish to use $SEARCH to test for
"[username1]", then I believe that you'll
need to look for "username1.DIR;1" (one level
up).

What do you wish to do differently if the
directory doesn't exist? If the answer is,
"create some file there", then you should
get a distinctive failure when you try to
create the file in a nonexistent directory.

[Steven Schweda]

What are you using for $PARSE, syntax-only?

When I set nam[l]$v_synchk, I see %x00010001 =
%RMS-S-NORMAL for a good directory or a bad
directory.

When I do _not_ set nam[l]$v_synchk, I see
%RMS-S-NORMAL for a good directory, but
%x0001c04a = %RMS-E-DNF ("directory not
found") for a bad directory.

That would seem to solve your problem.

I won't ask why you're using MACRO32.

[Arch_Muthiah]

Nice to know you have C/RMS experience.

nam$v_synchk is used to check the existance of dire/device. For this, just we can use RMS$_ return status.

Also $PARSE needs to fill some of the other NAM fields for the consecuetive $SEARCH call, if I set nam$v_synchk, I can not supply those NAM fields values to $Search service.

For the information, my program plungs down to each user's LOGIN directory, and reporting "any misowned dirs/files", "dirs/fils protection", "any hidden dirs", "any disUSEREd accounts", "any USER without login dirs", "COM procedure availablity", etc...

Even I noted down the values in R0 after $search call to test against that values, (assuming this exception value may not be defined in RMS and NAM blocks),but this is also not usefull, because that value is for RMS$_FNF only.

Now I understand that there is no specific symbol I can use to catch this kind of errors, now I am in a trial using extra dummy variables and changing the prog flow.

Archunan

[Steven Schweda]

Read it again.

With nam[l]$v_synchk NOT set, sys$parse()
fails with %x0001c04a = "%RMS-E-DNF,
directory not found", if the directory does
not exist.

At least it does for me.

alp $ exec px home_sms:[sms]*.*
parse (normal) sts = %x00010001.
parse (synchk) sts = %x00010001.

alp $ exec px home_sms:[no-such-dir]*.*
parse (normal) sts = %x0001c04a.
parse (synchk) sts = %x00010001.

Are you checking the status from $PARSE?

[Steven Schweda]

Perhaps I should read _your_ stuff again,
instead.

If you $SEARCH for "*.*" and get %RMS-E-FNF,
then the directory is empty.

If you $SEARCH for any specific file (like
"nonexisting_file.dat") and get %RMS-E-FNF,
then that specific file does not exist.

I don't see a problem. Why should these be
different?

[Arch_Muthiah]

Steve, you arg is ok. but my customer wants FNF, DNF, DNR, FND, etc etc... conditions reported seperately with proper reason. I feel their request is reasonable to differentiate any "invalid file", "file not found", "no files found - empty dir" in their environment. As I said my progrm processes "any misowned dirs/files", "dirs/fils protection", "any hidden dirs", "any disUSEREd accounts", "any USER without login dirs", "COM procedure availablity", etc...
For this I have many macro subroutines inside the main macro prog. You knew that macro has very limited procedural approach, but now I am trying to use couple of dummy variables, and going to expand code for this to short out this issue.

[Robert Brooks_1]

For this I have many macro subroutines inside the main macro prog. You knew that macro has very limited procedural approach . . .
---

Yeah, that's why VMS Engineering does virtually all new development in C, not MACRO-32. Even experienced MACRO-32 coders agree that it's much less error-prone and quicker to develop in a procedural language. The code substantially easier to maintain, too.


-- Rob

[Arch_Muthiah]

Bob,

I agree, c is easy and we can avoid these kind issues when we use procedural lang. But I don't think MACRO is error prone.
when we need to develop a application which drills/extracts all kind of info from any kind of programs/applications, there is no altenate to macro, this may be the reason why my application had been started with macro. I am just docking few more modules to the existing applications.

Maximum we avoid writing any more new modules in macro unless otherwise there is strong reason to do that. We already wrote thousands of C and Cplus subprograms, but the most of the main prog are still in macro. Any way we planned to move this whole appln to I64 shortly using c,cplus,java.

Archunan

[Steven Schweda]

> [...] but my customer wants [...]

I still don't see the problem.

$PARSE fails with "RMS-E-DNF, directory not
found" if the directory does not exist.

$SEARCH for "*.*" gets "RMS-E-FNF, file not
found" (the first time) if the directory is
empty.

$SEARCH for "specific.file" gets "RMS-E-FNF,
file not found" (the first time) if the
specific file does not exist.

In the last two cases, you get the same
answer (RMS-E-FNF), but this should be
confusing only if you forget which question
you were asking.

[Arch_Muthiah]

Friends,
Thanks for your suggestions...

I have added the following lines of code, and it works fine.
...
...
bbs #errsup_set, getfiledesc_flags,100$
TSTL ITSADIR ; it is a dir?
BNEQ 410$ ; nope
MOVZBL NAM$B_ESL(R11), R2 ;see if its a dir
MOVL NAM$L_ESA (R11), R3
MATCHC #4,DIROBJ,R2,(R3) ; is it dir?
BNEQ 410$ ; nope
MOVL #1 ITSADIR ; its a is dir
...
...


Archunan