Conference humane::scheduler

1064.0. "Improvment request from customer" by RULLE::LINDSTROM_S () Thu Apr 11 1996 11:24

I have just sent VSCHED_E07B021 and it solved his main problem.
And as thanks for that he sent me this internet mail attached below.
Any comments appreciated.

Regards Sten Lindstrom.

-------------------------------------------------------------------------------
Hello !

This report is written in english to make it easier to forward to persons
that are not fluent in Swedish.

First of all I'd like to say that the Scheduler as a product is very good
and we use it for a lot of our daily operations. The target is to get all
tasks that are performed on a regular basis into the scheduler.


BACKGROUND
==========
The scheduler runs on a VMS cluster with 4 nodes. The operating system
is VAX/VMS V5.5-2. CPU's are:

STO004, a VAX 6000-610
STO010, a VAX 6000-440
STO013, a VAX 6000-620
STO017, a VAX 7000-620

$ sched show status
Node   Version  Started              Jobs  Jmax   Log  Pri Rating
STO017 V2.1B-7   7-APR-1996 13:32:50    1     6     5    4   6706 <-- Default
STO004 V2.1B-7   7-APR-1996 13:37:47    0     6     5    4   1677
STO013 V2.1B-7   7-APR-1996 13:37:49    0     6     5    4   5899
STO010 V2.1B-7   7-APR-1996 13:37:55    0     6     5    4   1579
$


PROBLEMS
========
The problems are mainly of two different types:

	o TECHNICAL BUGS. This is the ordinary type of bugs, (errors).

	o FUNCTIONAL BUGS. Things work, but they do not work in the expected
	  way.

	o LACKING FUNCTIONALITY. Ideas for the next release (on VMS ?)


TECHNICAL BUGS
==============

1)	The command "$ sched show job 1" produces the following message:
	%NSCHED-F-NOSUCHJOB, No such job. This is correct since the job does
	not exist. If I try to load the same job via the graphical interface
	"Load Jobs window" I get the message "Insufficient privilege".


2)	The command "SCHED CHECK /ALL" does not seem to work. It is hard to
	tell but it executes very fast. I have tried to capture it by pressing
	CTRL/T around the command. Output follows:

	SCHEDULE>
	STO013::S95697 07:38:09 SCHEDULER CPU=00:00:06.50 PF=3972 IO=1161 MEM=1256
	SCHEDULE>check/all
	NSCHED-I-CHECKRQST- doing a consistency check of the database
	SCHEDULE>
	STO013::S95697 07:38:11 SCHEDULER CPU=00:00:06.50 PF=3985 IO=1166 MEM=1269
	SCHEDULE>exit
	$
	$ DIR NSCHED$:*.DAT /EXC=*XUI*.DAT

	Directory DISK102:[NSCHED]

	DEPENDENCY.DAT;1		102/102     20-MAR-1993 12:46:30.22
	SCHED$SD_CLASSES.DAT;1		48/48       10-NOV-1993 09:54:59.59
	SCHED$SD_RESTRICTIONS.DAT;1	72/72       10-NOV-1993 12:15:28.47
	SPECIAL_DAYS.DAT;1       	63/63       16-NOV-1994 17:59:28.87
	TEMP_PARMS.DAT;1          	9/9          8-MAR-1996 14:00:00.87
	VSS.DAT;3               	603/603     27-MAR-1996 21:04:37.25

	Total of 6 files, 897/897 blocks.


FUNCTIONAL BUGS
===============

1)	When loading new jobs via the graphical display "Load Job Window" the
	current user name appears every time. This is most irritating. The
	last input to this field should be "remebered" the next time the
	window is activated. I currently have to clear this field every time
	I load jobs that are not mine. As an operator this is a very common
	situation.

2)	It is generally possible to CUT FROM but not PASTE TO fields in the
	graphical display. This includes all sub-windows.

3)	The Pre- and Post function fields are too short. They should be at
	least twice the current length. It is very hard to fit a command that
	includes some parameters into these fields.

4)	When executing a job via a scheduler agent the logfile is stored on the
	agent node. This is not satisfactory. All other information about the
	job including execution of pre- and post functions is managed at the
	server node. Why not also the logfile ?  When trying to look at the
	logfile via the graphical interface (menu=jobs,option=display output)
	I get the message "Output file does not exist". If the logfiles are
	stored on the agent node the message should say so. The better solution
	is to store the logfile on the server node.

	We today handle this by defining a logical name bot at the agent and the
	server node that points to a directory on the server node where the log-
	files can be accessed. The solution is not satisfactory since it
	involves additional maintenance. Also how handle when two servers
	access the same agent ?


5)	There are 3 jobs that depend on each other as follows:

		1 -->--- 2 --->--- 3

	If job 2 is loaded into the Graphical Display job 1 will show up as
	a "shadow" job. This is a very good feature. It would have been even
	better if job 3 had showed up the same way (shadow).


6)	The command "$ SCHED SHOW JOB nnn /SYMBOLS" does not give any
	information about batch queue, only queue priority. The following
	symbol would be appreciated "SCHED$QNAME"


LACKING FUNCTIONALITY (VMS)
===========================

1)	It is not unusual to get the following directive, that the scheduler
	can not handle:

	"Run this job all workdays on an hourly basis from 07:00 AM to 05:00 PM"

	This is a typical requirement for gathering RMU statistics on a
	database


2)	We run a global business with subsidaries around the world. A lot of
	the system management is performed in Stockholm but we need to take
	into account the local time before performing backups etc. What is
	needed is a way to handle timezones also "daylight saving time". I
	have heard that this exists in V3 (UNIX-version). Will it be added
	to the VMS version (V2.1B...). Perhaps via NT (seamless integration
	is the word) ?


3)	It is not unusual that a DCL procedure is executed that reads and
	checks in various ways the jobs in VSS.DAT. The command used is
	"SCHED SHOW JOB nnn /SYMBOLS" (nnn = numerical). You start with
	job 1 and wish to proceede to EOF. There is today no way to know
	when EOF is reached since "%NSCHED-F-NOSUCHJOB, No such job" is
	signalled if a job is missing or if you are past EOF. A better
	message would be "%NSCHED-W-NOMOREJOBS, No more jobs in database".
	This would make it possible to detect EOF from within a DCL procedure.


4)	The program NSCHED$:VSS_REPORTS produces a report of what has happened
	during a certain period of time. A much needed enhancement is to get a
	compressed report where only errors (everything that is not SUCCESS)
	are reported.


================== RFC 822 Headers ==================
Return-Path: "sebcl3::s95697"@sebank.se
Received: by zigge.sgs.dec.com (UCX V3.3 VAX)
	Thu, 11 Apr 1996 14:18:45 +0200
Received: from mail.sebank.se ([129.178.88.65]) by server21.digital.fr (8.7.3/8.7) with SMTP id PAA21637 for <[email protected]>; Thu, 11 Apr 1996 15:14:56 +0100 (WET DST)
Received: from seb022.sebank.se by mail.sebank.se (SMI-8.6/SMI-SVR4)
	id PAA07259; Thu, 11 Apr 1996 15:15:36 +0200
Received: from SEB008 by seb022 (PMDF V4.3-7 #10220)
 id <01I3F4FW5YGW000XSU@seb022>; Thu, 11 Apr 1996 15:12:44 +0100
Received: by seb008.sebank.se (MX V4.0 VAX) id 15; Thu,
 11 Apr 1996 15:12:17 +0100
Date: Thu, 11 Apr 1996 15:12:17 +0100
From: "SEB-Data/A&T, Anders Wallin, tel +46-8-6393057"
 <"sebcl3::s95697"@sebank.se>
Subject: Bugs in the Polycenter Scheduler
Sender: "sebcl3::s95697"@sebank.se
To: [email protected]
Reply-to: "sebcl3::s95697"@sebank.se
Message-id: <[email protected]>
X-Envelope-to: [email protected]
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-VMSmail-To: stocl1::MX%"[email protected]"
X-VMSmail-CC: AWAL, BSE

Sten,

Thank you for your suggestions. I am glad to hear that your customers are happy with the Scheduler. My
recommendation is that you issue IPMTs for Scheduler bugs (errors), and then we can attempt to address those
problems formally. Each problem will get a response.

In case of suggestions, you can still submit priority 5 IPMTs. These IPMTs are considered suggestions for future
release of the product. We value inputs from our customers. Such inputs give us product enhancement ideas and we
do try to accomodate these suggestions for future products. 

Incidentally, there is a plan to have the next release of Scheduler on OVMS (probably V2.2) in Q1FY97. This
release will have native Motif interface, support of OVMS V7.0 and some existing bug fixes. I am not sure how many
of your suggestions may be accomodated in the next release, but we will look into it.

Regards,

Raminder Bhatia
Product Manager, Scheduler

    The "sched check" command sends a message to the default scheduler's
    mailbox, requesting that it read all records in the job database and
    do a consistency check.  The check is done by the scheduler server, not
    by the user interface

	Thanks for clearing things up for me but is there a way to
	get notified about the reslult of the CHECK?
	If there are inconsistencies , how do I know?
        Does this command fix inconsistencies in the database 
	or is this command just a way to get things updated?

	Regards Sten	

    The command fixes any inconsistencies (pids for jobs marked as running
    are checked to make sure they are really there, count of running jobs
    fixed if necesary, dependency pointers (nsched.dat holds the jobs a job
    depends on, and dependency.dat has the jobs that depend on a job)
    checked, and it runs any jobs that are runnable but haven't been run.
        
    The output (which is voluminous) goes to nsched's .log file on the node
    that the default scheduler is running on.  To see it, you may have to do
        $ SCHED SET DEBUG ON /NODE=default_node
        then $ SCHED CHECK
        then $ SCHED SET DEBUG OFF /NODE=default_node
        
    Don't forget to shut off debug output. Appending to the logfile makes
    the scheduler run slowly and it is bad if the logfile gets big - as
    it will quickly with debug output turned on.
    
    Most of the significant stuff that results gets written to the scheduler
    event log (whcih you can see with the log reader program) so you
    probably don't need to see the detail unless you are debugging a
    problem or are curious.