[Os-project-managers] Painted into a corner

[Horand Gassmann]

Hi guys,

this is going to be a rather long message, but for Jun's benefit it is  
best to recap the discussion that Kipp and I had on the subject.

1. Prior to today, the user's manual read (in the section on the  
send() command --- 4.4.2 or 5.4.2, depending on the configuration),  
second paragraph: "The send method requires a jobID.[...] When no  
JobID is specified, the OSSolverService method first invokes the  
getJobID service method [and] puts this into an OSoL file..."

There also was an element oscommandline->jobID in the OSCommandLine  
object, and the implementation of the send() method checked whether  
oscommandline->jobID is empty, in which case a call to getJobID() was  
initiated. However, we neglected (I think by way of an oversight) to  
implement looking for jobID in the command line parser.

In addition, there was a problem in that the jobID once created had to  
be put into an OSoL file, and since we never read any existing OSoL  
file, whatever was there would have been clobbered.

2. Today Kipp and I discussed the situation and decided to do the following:

(i) make the OSoL file mandatory, containing at least  a <jobID> element;
(ii) eliminate oscommandline->jobID;
(iii) put all of this into the user's manual.

3. However, I have had a change of heart since then. The problem, as I  
see it now, is that we preclude any possibility of reusing an OSoL  
file, and in particular make it nearly impossible to create automatic  
loops that solve a problem repeatedly.

4. My current thinking is that the idea of an oscommandline->jobID was  
not a bad one, since the jobID could be supplied on a command line  
that could be generated automatically. We needed, however, to  
implement the jobID properly as part of the command line parser. If  
there was no jobID specified, then the generation of an automatic one  
also has lots to recommend it.

In addition, we need to make sure that any information contained in an  
OSoL file does not get lost. This would mean that any OSoL file would  
have to be read and parsed, checked for the presence of a <jobID>  
element, and the information of the <jobID> element would have to be  
replaced by the command line information, if a jobID was specified  
there, or by the return value of a call to getJobID() if there was no  
jobID on either the command line or in the OSoL file.

The big disadvantage of this approach seems to be that it violates a  
principle we set out at one point, which states that we will neither  
read nor write an OSoL file locally for a remote job. On the other  
hand, we already violate that principle when we parse an AMPL .nl file  
that contains array-valued options. If an OSoL file is also present,  
both files /must/ be combined in order to retain all the information,  
and that is how I did implement things in OSnl2OS.cpp.

Just thought we should all be aware of this. I invite your comments, as usual.

Cheers

gus

-------------------------------------------------------

Horand I. Gassmann, Professor

Kenneth C. Rowe School of Business, Dalhousie University
6100 University Avenue, PO Box 15000
Halifax, Nova Scotia, Canada, B3H 4R2
ph. (902) 494-1844
fax (902) 494-1107

http://myweb.dal.ca/gassmann/