The issue of the placement of the spool.log files also relates to the tskAAA.NNN files created during the printing process. Something has changed with ASHELL 5.0 (vs 4.8) re permissions, and I now have users who can't read the very tsk* files they have just created, because they are created with a different owner and group and they don't have any "other" perms. I'm not sure what's changed without going back and setting up a 4.8 test account, but something has.

Simply stated, here's what I've been doing:
One MIAME install, user john, group rpmrs.
Each customer has own ini file and data files, owned by customer-dependent group, all in group have RW for group files. It was working, mostly working now except for printing.

Immediate workaround is to add each customer user to the rpmrs group, but that lowers security and is kludgy.

Moving tsk files to customer-unique directory seems to be best solution.

I'm not sure what's changed here in 5.0, but you have long been able to control the placement of the spooler temp files (tskAAA.NNN) by defining an ASHTMP environment variable to point to the desired directory. (Otherwise it uses the miame.ini directory.)

Looking at the code, and after doing a test, it seems that the ownership of these temporary files is based on the actual login user, unless of course the ashell executable has the SETUID (+s) bit set.

So I'm not sure why the user that created the file (indirectly by spooling) would not be able to read it, nor am I sure why it would matter, since the file would normally only be read (and then deleted) by the spooler.

That said, it's probably still a good idea to upgrade the LOGDIR concept to allow for the SPOOL.LOG (and potentially other LOG files) to be placed in a specific location. But in thinking about that, there are a couple of other related upgrades (the ability to set the maximum size and number of archived copies) which have long been on the wish list, so I need to give it a little more thought before hammering out a patch.

I did look in master reference file for any reference to "tsk" files, but didn't see anything. Thanks for pointing out the ASHTMP variable which is I think all I need.

And I did notice that the 5.0 install did set the owner and group 's' bits (rwsrwsr-x), but didn't think too much about it at the time. That explains a couple of other issues I've been tracking down today.

Got to love those updates!!! (Yeah, I know it's the price of progress, keep 'em coming.)

There is actually an index entry for "Temporary print files", but perhaps another one could be added for "tskxxx files" or something like that.

There are a couple of other printing-related items on the wish list (like an easy way to archive copies of printfiles, since knowing the printfile name, program, time, etc., is only so useful without the actual printfile when trying to debug after-the-fact whether or why a report did or didn't print correctly.) I may need to schedule a "printing improvements" programming day...

Looks like I'm over the hump thanks to ASHTMP.

But, ... One more thing. How about ASHTMP as a statement in the INI file? It seems easier to manage there than as an environmental variable.

Perhaps for compatibility it only activates if $ASHTMP is null.

I'll consider that...