Subject: | |
From: | |
Reply To: | Schlosser, Robert (Contractor) |
Date: | Thu, 23 Dec 1999 08:08:01 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Rick
I have this thing about letting anyone submit jobs in the C queue. There is
another way to get the entire job into the C queue without having to allow CS
priority to anyone who notices that it can be had. Insert the following command
right after the job card
!altproc ;pin=0;pri=cs
This will alter the priority for the process tree to CS, any subsequent runs
will also receive this priority. This has worked well for me.
Bob Schlosser
(321) 674-4938
-----Original Message-----
From: Computer And Software Enterprises, Inc. [mailto:[log in to unmask]]
Sent: Thursday, December 23, 1999 2:16 AM
To: [log in to unmask]
Subject: Re: MPE/iX 6.0 & FTP Problems
In article <[log in to unmask]>,
<[log in to unmask]> wrote:
>First check priority of INETD in the JINETD.net.sys job.
>
>:print jinetd.net.sys
>!job jinetd, manager/?.sys/?
>!run inetd.net.sys;pri=cs
>!eoj
>
>The line #2 should be modified do include ";pri=cs".
Caution! Caution! When you run a process within a job in the CS queue,
and the root CI for the job is in the DS queue (default, and assuming CS
is higher priority than DS and doesn't overlap), if the CS process loops
for any reason, the job will not respond to an ABORTJOB command until
either the root CI is increased to CS priority, or the looping process is
reduced back into the DS queue.
I discovered this wonderful problem when I had a problem with Apache son
processes looping. No new jobs would start. Aborting job did not make
Apache go away. Increased root CI process for Apache job to CS. Apache
job aborted at that time.
The better alternative may be to allow CS job priority. That would allow
the use of PRI=CS on the job statement. However, that would allow any
user to run a job at CS.
This is a problem which needs to be solved before daemons such as inetd
will be reliable on the 3000.
Rick Gilligan
|
|
|