| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
Hi
The Mail Janitor Utility does not run correct if OA$DDS_PRIME is 2. The reason
is: the receipient may not be unique.
The Problem is, MJU does not finish correctly but does not send any
error messages. In the log-file shows only what receipient is the reason for the
error. This is my example:
****
Drawer: [GRAU]STANDARD is being processed at 04:05am
Drawer owned by VMS account: GRAU Last log-in at: 13.Mai.1994 06:28am
User has logged in since last clean EW run - proceeding
Drawer: [GRAU]STANDARD emptying wastebasket
Drawer: [GRAU]STANDARD reorganized
Drawer: [GRAU]STANDARD Number of messages deleted = 2
After cleaning, the Wastebasket contains 2 documents
Sending mail to: GRAU with statistics for drawer STANDARD
-> 1 GRAU RIT CSY ZRH ( Grau, Daniel RIT CSY )
-> 2 GRAU RIC ECP ZRH ( Grau, Ursula RIC ECP )
Versenden Sie diese Nachricht, wenn Sie sie abgeschlossen haWeiter mit [Return].
****
After GRAU MJU does not continue and MJU does not set the permanent symbol
LAST_CLEAN_RUN in SYSTEM.PST to the new date.
What I did was setting the Logical to 0:
$!SM_EW.COM
$!
...
$ wo "I running ALL-IN-1 under account ""''a1_account'"""
$!
$ DEF/PROC/EXEC OA$DDS_PRIME 0 <-------------------
$ wo "OA$DDS_PRIME set to 0" <-------------------
$!
$ allin1/reenter/username='a1_account' -
/noinit/password="''a1_account_pass'"
...
I think this is the best (easiest) fix for the problem.
C-ya Ursi
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4182.1 | IOSG::MAURICE | Six Programmers in search of an analyst | Thu May 19 1994 11:00 | 11 | |
Hi,
Thanks for the information. The good news is that we already have made
this fix in V3.1, where the MJU is integrated into ALL-IN-1.
Another bit of good news in V3.1 is that scripts can now change
OA$DDS_PRIME whilst ALL-IN-1 is running.
Cheers
Stuart
| |||||
| 4182.2 | ownership problem with the site element | TAKEOF::ERNI | Ursula Erni | Tue May 24 1994 10:05 | 23 |
Hi Unfortunately the procedure failed. The problem appears because of customization management. All site elements are owned by OA$MANAPP. Now SMJACKET.COM checks if the procedure (SM_EW.COM) has the same ownership as the comfile (SMJACKET.COM). I don't understand why SMJACKET wants to check that. The quickest is to set the owner to [ALLIN1] but at the next change in the element SM_EW.COM the owner-ship ist set back to OA$MANAPP. So my idea is to take out the owner identification in SMJACKET.COM ... $ owner_com_file = f$file(com_file,"uic") $ owner_ok = owner_com_file .eqs. owner_this_file $ if .not. owner_ok then goto err_bad_own ... Please tell me if this could run me into other problems. C-ya Ursi | |||||
| 4182.3 | It's to do with security | IOSG::SHOVE | Dave Shove -- REO2-G/M6 | Tue May 24 1994 13:26 | 12 |
The ownership tests are to do with security.
They are perhaps a bit paranoid, but they're there to stop a rogue
Administrator abusing the mechanism which lets them run certain jobs
under privileged VMS accounts.
I won't say more here - except to say that, if you trust those users
who are granted Administrators not to abuse the system, you could
remove the checks. That might be sensible if, for example, your
"Administrator" is really the system manager anyway.
Dave.
| |||||