From: CSBVAX::MRGATE!KVC%YMIR.BITNET@CUNYVM.CUNY.EDU@SMTP 3-APR-1988 17:16 To: ARISIA::EVERHART Subj: Starting queues (was Re: Mail delivery job lives forever!) Received: from YMIR.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 5652; Sun, 03 Apr 88 16:59:33 EST Date: Sun, 3 Apr 88 14:43 PDT From: Kevin Carosso Subject: Starting queues (was Re: Mail delivery job lives forever!) To: info-pmdf@YMIR.BITNET X-VMS-To: IPMDF Resent-date: Sun, 3 Apr 88 14:45 PDT Resent-to: INFO-PMDF-LIST@YMIR.BITNET > We think that our problem was due to the fact that QUEUES, including the > MAIL$BATCH queue, were started before the PMDF_STARTUP file executed. If a > delivery job was due to start at the time of the re-boot then it would > initiate before the logicals for PMDF were defined. Since the job 'keeps on > trunkin' it indeed trucks forever, bombing every time a logical is needed. > > We now start the MAIL$BATCH queue from PMDF_STARTUP, after everything > is set up correctly. This was very interesting for me: I hope someone else > finds this gem interesting also. Note that this sort of thing can cause problems with many things besides PMDF. What I do, as a general solution to the problem, is make sure my SYSTARTUP.COM is sequenced properly. I initialize the queues using the /NOSTART qualifier and then explicitly start them at the end of the system startup procedure. I guess the idea is that you want batch process to start up at about the same time you're ready for interactive process. I think this would be a better solution than relying on PMDF_STARTUP to start the MAIL queue. As an aside, when I was managing a large system at my previous job, we wanted to use batch jobs as part of the system startup. We set up a special queue for system startup tasks (in fact, there was one of these for each machine in the cluster) which was started much earlier in the boot. /Kevin Carosso kvc@ymir.bitnet Innosoft International Inc. kvc@nrc.com