VMS MAIL %MAIL-E-FILNOTDEL error

[Tim Nelson]

Has anyone seen this error before ?
%MAIL-E-FILNOTDEL, error deleting SYS$SCRATCH:[UTIL.BKU]MAIL_210A_SEND.TMP;*
-RMS-F-DEV, error in device name or inappropriate device type for operation
%MAIL-E-FILNOTDEL, error deleting SYS$SCRATCH:[UTIL.BKU]MAIL_210A_EDIT.TMP;*
-RMS-F-DEV, error in device name or inappropriate device type for operation

This only reports the error when running a DCL script via batch.
Commands used is:
$ MAIL_PROCEDURE:
$set noon
$open/write mailfile tmp_mail.txt
$write mailfile "''err_msg1'"
$close mailfile
$mail/subj="Alert - OSIBK1 Backup ''status'" -tmp_mail.txt "user@mycompany.com"
$delete/nolog tmp_mail.txt;*

[Uwe Zessin · Accepted solution]

'-RMS-F-DEV' -- I would check the logical name SYS$SCRATCH in that context. Just put one line at the top and make sure you create or logfile (or redirect the output):
$ show logical sys$scratch* /full

[Tim Nelson]

I will put in script and rerun..

Did you notice that the path in the error stated sys$scratch:[current_working_dir]
which is not correct.

a manual show log sys$scratch shows:
"SYS$SCRATCH" = "SYS$SYSROOT:[SYSMGR]" (LNM$JOB_81663980)

[Uwe Zessin]

Yes, I have noticed that. So either the system-wide SYLOGIN or the user's LOGIN.COM is altering the logical name.

[Tim Nelson]

Here is the real kicker..
I have another script that also runs via batch with same mail code and no errors.
$ MAIL_PROCEDURE:
$!MAIL SOMEBODY
$set noon
$open/write mailfile tmp_mail.txt
$write mailfile "''err_msg1'"
$close mailfile
$mail/subj="Alert - OSIBK1 BCV MERGE ''status'" tmp_mail.txt "user@mycompany.com"
$delete/nolog tmp_mail.txt;*
$ return
$!END MAIL_PROCEDURE

[Doug Phillips]

Are you submitting the job under the SYSTEM account or using submit/user= ? Is something in the syslogin.com or the user's default login.com setting something or skipping something because of mode=batch? SYSTEM usually runs the SYS$MANAGER:LOGIN.COM file, so is there something unusual in there?

SYS$SCRATCH is defined at login time as the user's default directory and can be and usually is different for every user.

[Dale A. Marcy]

That is the error message you would receive if Sys$Scratch has been deassigned (or never defined). Is it possible there is a branch based on an f$mode() being batch or not being interactive that could cause the logical to be deassigned in either the sylogin procedure or the user's login procedure?

[Tim Nelson]

submitted under SYSTEM using.
Here is the output after using show log sys$scratch
%SHOW-S-NOTRAN, no translation for logical name SYS$SCRATCH
%MAIL-E-FILNOTDEL, error deleting SYS$SCRATCH:[UTIL.BKU]MAIL_2259_SEND.TMP;*
-RMS-F-DEV, error in device name or inappropriate device type for operation
%MAIL-E-FILNOTDEL, error deleting SYS$SCRATCH:[UTIL.BKU]MAIL_2259_EDIT.TMP;*
-RMS-F-DEV, error in device name or inappropriate device type for operation

[Hein van den Heuvel]

>> Dale A. Marcy Jul 29, 2004 20:15:01 GMT ->> ---------------------------------------------
>> That is the error message you would receive if Sys$Scratch has been deassigned (or never defined). Is it possible there is a branch based on an f$mode() being batch or not being interactive that could cause the logical to be deassigned in either the sylogin procedure or the user's login procedure?

Sounds good Dale!

>> Tim Nelson Jul 29, 2004 20:19:21 GMT
>>-----------------------------------------
>> submitted under SYSTEM using.
>>Here is the output after using show log sys$scratch
>> %SHOW-S-NOTRAN, no translation for logical name SYS$SCRATCH

This confirms Dale's thoughts.
Please make sure a valid sys$scratch is defined for all users (Before F$MODE() check in sylogin!)

In the mean time I check the Mail sources a little. It suggests it will only conditionally delete (wildcarded) send and endi tmp file using a global flag. In practice though it seems always to try, whether a temp file was created or not.
The code explicitly checks for 'FNF' (File Not Found) and declares victory if it received that specific error. But 'DEV' triggers the 'FILNOTDEL' condition.
So just define sys$scratch and maill will get FNF back from RMS and it will be happy.

hth,
Hein.





%MAIL-E-FILNOTDEL, error deleting SYS$SCRATCH:[UTIL.BKU]MAIL_2259_SEND.TMP;*

[Volker Halle]

May SYSMAN> SET ENV/NODE be involved ? SYSMAN will not have SYS$SCRATCH defined in the remote node environment.

SYS$SCRATCH is defined as a JOB-wide EXEC-mode logical name by LOGINOUT and cannot easily be deleted.

You can easily test, if some code is deleting SYS$SCRATCH by submitting a simple DCL-procedure with just a SHOW LOG/FULL SYS$SCRATCH in the same environment in which your mail procedure is run.

Volker.

[Tim Nelson]

I have been looking around and cannot seem to find where sys$scratch is being defined.
not in sylogicals, sylogin.com, login.com
I see a few references but not the define. It is definately defined as show log sys$scratch from a interactive login is valid. Where is the best place. I see it mentioned that it may/could be defined separetly per each user's login.com.
What would be the recommendation ?

Thanks to all for the help !!

[Doug Phillips]

sys$scratch is defined by the login process itself, not within the com files. It is set to the default device and directory found in the users UAF record.

Maybe if you provided us with the exact command you use to submit the job, and tell us more about your configuration, someone might think of something.

[Uwe Zessin]

I would try to trace this in the logfile. Put a '$ SET VERIFY' at the top of SYLOGIN.COM

Well, perhaps better use a conditional like:
$ if f$mode().eqs."BATCH" then $ set verify

[Tim Nelson]

So if sys$scratch is defined by the login process itself then would there be any reason why this would not be assigned when a script is submitted via batch ? I would initially guess batch type jobs do not execute the login procedure and a special definition would need to be created in either sylogin.com or login.com in order to define this logical and hence rid me of these messages.
If so, I am supprised that something like this is not already a "default" or "templated" item in either sylogin or login.com.
System info if interested:
AS1200
VMS 7.3-2
job submitted via a VMS CRON like process using:$ spawn/output=nl:/log/nowait/proc='prcnm' 'command'
CRON.COM submitted via:
$ run -
/detach -
/input = admin:[util.cron]cron.com -
/output = admin:[util.cron.log]cron.log -
/error = admin:[util.cron.log]cron.error -
/process = "Cron_DAEMON" -
/queue_limit = 20 -
/subprocess_limit = 20 - !make high enough for spawned commands
/page_file = 10000 -
/time_limit = 0 -
/extent = 1024 -
/file_limit = 50 -
/uic = [SYSTEM] -
/prior=10 -
sys$system:loginout.exe

[Wim Van den Wyngaert]

Tim,

I already had a thread in which I say that detached processes stink.
1) TT is defined differently (i'm at home, I can't check)
2) no login is executed
3) some logicals are missing (e.g. sys$scratch)
4) process is not really user bound

Yet another victem. When are they going to implement "su -" as in Unix ?

Wim

[Wim Van den Wyngaert]

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=630742
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=625675

[Uwe Zessin]

Now I am puzzled...

How do you start your 'mail procedure' - via SUBMIT or RUN/DETACH (the second command creates a detached process, not a batch job!).

Try a RUN/DETACH/AUTHORIZE - this should create SYS$SCRATCH (I haven't fully checked the threads that Wim has given, but I have seen /AUTHORIZE is mentioned, so I won't go in detail here.


I suggest you leave out the /ERROR qualifier fromthe RUN command. In that case all output to SYS$ERROR is writte to /OUTPUT as well. I found it much easier to read a complete logfile.

[Tim Nelson]

The "cron" process is constantly running as a detached process.

The DCL script that sends an email is executed via the "cron" process as a spawned process.

I will play around a little with the way the "cron" process is executed to see if /auth or some other switch helps.

If not I with either ignore the %MAIL error or include the define for the sys$scratch in somewhere.

Thank you !

[Wim Van den Wyngaert]

Tim,

Uwe is right. On Unix one should call this a batch job but on VMS we don't. It's detached.

But, for 1 time, Unix does the job better.

Wim

[Martin P.J. Zinser]

Hi Tim,

which "Cron" are you using, a "homegrown" one or one of the publicly released implementations? I might be able to test this
a bit more around here.

A save way to make sure you have sys$scratch without messing with it in case it already has been put in place is something along the lines of

$ if f$trnlnm("sys$scratch") .eqs. "" then define sys$scratch dev:[dir]

Greetings, Martin

[Tim Nelson]

Martin,

The "cron" like utility is something I found on the www. I had to make some mods to allow for down to the minute and a couple tweeks here and there to spruce it up.

I am hoping not to have to include checking for sys$scratch in every script written. I am going to try to add it directly into the "cron.com" script to see if I can address it that way.
Currently calling the mail subsystem is the only place complaining about sys$scratch.

Muchas gracias.

[Tim Nelson]

FYI,

I defined sys$scratch in the "cron" like process itself and yes it took care of things. Thanks to all !!!

type cron_test.log
"SYS$SCRATCH" = "ADMIN:[UTIL.CRON.LOG]" (LNM$PROCESS_TABLE)


I have another question:
Where is the below "verify" output coming from ? This is from the "cron" like processes log. The only place I see something like this is at the top of sylogin.com. Why would this be echoed to output ?

type cron.log
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
Spawning command: @ADMIN:[UTIL.CRON]CRON_TEST.COM at 2-AUG-2004 09:45:00.38
%DCL-S-SPAWNED, process CRON_TEST spawned

[Antoniov.]

Hi Tim,
I lost this thread :-(
About your last question:
If you comand procedure (@ADMIN:[UTIL.CRON]CRON_TEST.COM) is executed directly assume same input/output of caller.
I guess you run this command wiyhi spawn (because I read DCL-S-SPAWNED message); in this case you have define input and output file using /INP and /OUT qualifier; default valut of /OUT qualifier is SYS$OUTPUT file,

Antonio Vigliotti

[Dale A. Marcy]

Verify is turned on until it is optionally turned off by the statement

$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))

It will turn verify off if the logical SYLOGIN_VERIFY is defined as a 0 (zero) or a "FALSE" value. If you do not want to see any of the output, move this line to the top of your sylogin procedure and add a single hollerith (') in front of the F$VERIFY as shown below:

$ VERIFY = 'F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))'
$ Set NoOn

I also add the hollerith at the end of the statement, but it will function with out it.

[Tim Nelson]

Got it..

Thanks again...

This should be the end of this thread.

Merci buckets,

Tim