Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/projects/dfs/team/ot-test-plan.ps Дата изменения: Fri Jun 14 12:41:23 2002 Дата индексирования: Sun Apr 13 22:57:17 2008 Кодировка: Поисковые слова: arp 220

E U R O P E A N S O U T H E RN O B S E R VA T ORY
Organisation EuropИ enne pour des Recherches Astronomiques dans l'HИ misphХ re Austral.
EuropД ische Organisation fЭ r astronomische Forschung in der sЭ dlichen HemisphД re
VERY LARGE TELESCOPE
VLT Data Flow System
OT Integration Test Plan
Doc. No.:
internal docno: dfs- volxx- yy- zzz
Issue: 1.0
Date: Document info:Modified
Prepared: Karim HAGGOUCHI
. . . . . . .
Name Date Signature
Approved: Michele PERON
. . . . . . .
Name Date Signature
Released:
. . . . . . .
Name Date Signature

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Copies : Michele PERON
Maurizio CHAVAN
Tim CANAVAN
Bob KEMP
Dave SILVA
Michele ZAMPARELLI
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
CHANGE RECORD
ISSUE DATE SECTION/PAGE AFFECTED: REASON / INITIATION /
DOCUMENTS / REMARKS
1.0 Date All Preliminary release
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Table of Contents
List of tables
none
List of Figures
none
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
1. INTRODUCTION
1.1 PURPOSE
This document describes results of validation tests performed on OT release between and 2000.
1.2 APPLICABLE DOCUMENTS
AD1 : OT user's manual
VLT- MAN- ESO- 192000- 1777/1.3
AD2 : VLT Front- end Software requirements Document - 0.4
VLT- SPE- ESO- 19200- 1779
1.3. REFERENCE DOCUMENTS
RD1 : OT V2.2beta3 release Test Report
VLT- XXX- ESO- 19000- XXX date : 15 September 2000
RD2:
2. SCOPE
This release of "Java- OT" was validated on HP- UX 11 (not on other platforms) using SYBASE 12, on the
"wg0arc" machine, user "visitor". The OT user was '0' only.
The main goals were to check .
3. MAIN FUNCTIONALITIES
Glossary
MMU=Mask Manufacturing Unit
OS= Observation Software (a module of VCS)
General description
VIMOS=4 detectors
Each detector has a cabinet containing 100 slots used for mask storage.
A mask is put in the focal plane for any MOS observation.
MPS (the VMMCS process, in fact) assumes the role of server of OHS: OHS communicates to VMMCS what to
do and vmmcs will return to OHS what it really did.
Mask related setup parameters are part of the MOS setup paramaters. So Mask setup parameters will only be
defined in acquisition templates for Observation Block (i.e. not in science templates), and in calibration template
for Calibration Block. So, it will NOT be possible to change Mask sets within an OB after the initial acquisition.
Re- call: Calibration Block doesn't require an acquisition step: simply implies that the masks are loaded.
VIRMOS templates will include 16 specific parameters
4 "paramfile" parameters: INS.MASKi.ADP = 4 original ADF files with coordinates expressed in pixels. To be
filled in by the OB author, interacting with VMMPS.
4 integer: INS.MASKi.ID = ID of the generated masks. Filled in by OHS by parsing the MMR.
4 "paramfile" parameters: INS.MASKi.ADM = 4 processed ADF files, coordinates expressed in millimeters. Filled
in by OHS by parsing the MMR.
4 integer: INS.MASKi.NO = Instrument Cabinet positions (IC slot) of each mask. Filled in by OHS by parsing the
MIR.
FORS2 templates will include only
1 paramfile: INS.MASK.FOCF, corresponding to the original ".p_focf" file. Filled in by OHS by parsing FIMS.
Operational summary
MOS OBs will have to be defined at least 24 hours in advance of execution, in order to allow mask
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
manufacturing.
1/ Mask preparation
At OB preparation time, the OB author generates the ADFs in pixels coordinates using VMMPS for VIMOS (or
generates .p_focf/.p_gbr files via FIMS for FORS2). OBs and ADFs are stored in obrep2. The Mask.ID and IC
slot are left empty at this stage, meaning that no masks are yet available for that OB. These ADF and
p_focf/p_gbr files are simply attached to OBs.
2/ Mask manufacturing
When preparing the MTS (a few nights before execution), a set of MOS OBs needing masks is extracted from
the queue and the corresponding ADFs/pixels ones passed to VMMCS by OHS. OHS sends a MMO=Mask
Manufacturing Order.
Once masks are manufactured, a MMR (mask Manufactuing Report) is sent back to OHS, which will parse it.
OHS will then associate the ADF/millimeters and the new mask Ids and IC slots to the proper OB template
parameters, so that obrep2 can be updated.
3/ Mask insertion
Later on, OHS communicates to VMMCS the list of masks to be inserted in slots=MIO=Mask Insertion Order.
VMMCS returns the list of IC slot numbers (MIR=Mask Insertion Report) to be saved in obrep2.
4/ Mask discarding
After OB execution, OHS communicates to VMMCS the list of masks which can be discarded from the storage
cabinet (MDO=Mask Discarding Order). Re- use of masks is not possible now, but foreseen. OBs (obrep2) are
then updated according to the MDR=Mask Discarding Report.
==> Care must be taken in order to avoid discarding masks which are still needed for the next- day calibration
("linked" OBs).
==> Mask discarding doesn't apply to FORS2.
VMMCS provides then 3 possible services:
Mask manufacturing
Mask insertion
Mask discarding
in an asynchronous mode (i.e. OHS doesn't wait for service completion notification).
ADF files are PAF files, where the PAF.ID=NN.A- 9999X++yyyy- mm- ddThh:mm:ss.sss+Q
e.g. 66.C- 0438B (be careful : parenthesis around the obs. Run last letter are removed for UNIX
compatibility)
1.0patch3
date and time in ISO8601 format the original ADF file was generated.
Q=quadrant (1 to 4; always 1 for FORS2).
PAF.ID limited to 80 char in length.
PAF.ID is the same for ADF/pixels and ADF/millimeters.
MMO=OBD file, including all OBs for which VIRMOS/FORS masks must be cut.
MMR= contains the list of masks which were actually manufactured and the new ADFs/millimeters.
MIO=list of masks to be inserted in the ICs. If one of the requested masks is already inserted in the ICs, it will
not be unloaded and reloaded: but here its mask ID must be included in the MIO.
MIR= returns IC slot number, needed for OB execution (and then, OHS will make it available to BOB through
template parameters).
MDO= MPS knows about storage cabinet situation (how many slots currently used), but doesn't know about
which masks to be discarded. Therefore, OHS needs to pass on to the VMMCS server the list of masks to be
discarded.
MDR= when the discarding process is terminated, VMMCS server retuns to OHS lists of masks which were
actually discarded. OHS updates then corresponding OBs.
Data transfer between OHS and the Mask Preparation Software
MPS and OHS exchange information using the protocol defined in the VCS/OHS ICD: a BOB process acts
between OHS and the MMU OS, which implements the VMMCS. This is similar to what happens between OHS
and the VIMOS OS.
BOB/MMU asks OHS for NextObsBlock or PAFready services. OHS asks BOB/MMU for GetPAF service.
A NextObsBlock request is trapped by the MaskTracker and the latest available Order is wrapped in an OBD file
and returned to MMU OS. This OBD file include a single template (a mask manufacturing, insertion or discarding
template, depending on the Order file). This template includes a single paramfile (the MMO, MIO or MDO to be
processed). Execution of the template returns an OB termination status to OHS, as soon as the transfer is over.
When the Order is completed, VMMCS generates a Report and issues a PAFReady event. The report is
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
retrieved by OHS and processed by the Mask Tracker.
Notice that only Mask Insertion templates and Mask discarding templates are considered by MMU OS
(acquisition templates are ignored). Similarly, Mask Insertion templates and Mask discarding templates are
ignored by the VIRMOS OS.
Order and Report Files
1/ MMO = OBD file including all OBs which masks must be manufactured; the acquisition tsf include parameters
of type paramfiles whose values are the ADF/pixels files to be considered.
2/ MMR = set of masks that were actually produced. Filename is arbitrary but must be ".mmr". It is suggested
that file name includes current time and date. Each mask is described by 3 parameters:
- INS.ADMi : for VIRMOS only= ADF/millimeters
- INS.MASKi.NAID : VIMOS=value of the PAF.ID keyword of the ADF file; FORS2=string+number (a
mask id string)
- INS.MASKi.ID ; VIMOS=mask number assigned by MMU; FORS2=same as INS.MASKi.NAID.
3/ MIO = each mask is described by the same INS.MASKi.ID returned within the MMR. MIO name is arbitrary,
with extension ".mio".
4/ MIR = same as MIO (".mir") but contains INS.MASKi.ID and also INS.MASKi.NO (nb of the slot where the
mask was inserted).
5/ MDO (VIRMOS only) = same as MIO with ".mdo"
6/ MDR (VIRMOS only) = same as MIO with ".mdr"
Error conditions
order files corrupted or invalid format
missing or corrupted ADP
storage cabinet full: present MMO contains a number of ADPs higher than the number of free slots in the
storage cabinets.
Current MMO contains names of OBs whose corresponding masks have already been built or are going to be
built.
Insertion/discarding order file contains non- existing mask- IDs.
Preparing VIMOS OBs with P2PP
Run jp2pp - debug - noccs &
User 754, create a Calibration Block using the calibration VIMOS_mos_cal_Flat.tsf template.
Four ADP files are attached to this OB (1001- i.adp, i=1,4). This service mode OB is checked in into
SEGSRV12.
Interface OT/BOB
In /OT- P2PP/SYSTEM/COMMON/TEMPLATES/OBD : pafready.obd file to be fetched from BOB.
Works only if in /OT- P2PP/SYSTEM/COMMON/TEMPLATES/TSF, pafready.tsf file exists.
Create a INS_ROOT/SYSTEM/ADF directory where adp and adm files will be copied when manufacturing
masks.
INS_ROOT is set to ~/OT- P2PP
Run BOB by : bob- offline &
4. DETAILED RESULTS
tests corresponding to testcases were defined, but only testcases were run on this OT release.
All High and critical bugs originated on the previous OT 2.2beta3 release can be considered as FIXED.
Testcases which were not performed are not described hereafter (but their complete description can be found in
RD2).
Several main functions of OT were tested only in a "light" way :
.
The current way to manage Masks will really be difficult to operate :
- even if the OT user can know whether a MMO has been sent or not (looking at the mask.id value (- 1=no
sent)), a clear warning message or a specific flag in the OT OB grid will also be very useful.
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
- how the OT user can remember or be sure that a MIO has already been sent for a specific OB ?
- how to say to the OT user that a manufacturing, an insertion or a discarding order failed. A lot of errors may
happen here : so how OT should react ?
- what happens if only one or 2 masks out of the 4 failed ?
Defining specific "status" for EACH Mask is necessary to record each step of the Mask process " (MMO sent to
BOB, MMO received by BOB, MMO successfully executed, MMO failed, MIO sent to BOB, MIO received by
BOB, MIO successfully executed, MIO failed, ...), and for each status, the associated date.
Otherwise it will be very difficult for the OT operator to understand how the process is going on.
The new bugs are the following :
Bug description See details in
testcase(s)
Priority (Low,
High, critical)
AmChavan To-
Do list number
The following bugs can be considered as CLOSED :
Bug description See details in RD1
testcase(s)
Priority (Low,
High, critical)
AmChavan
To- Do list
number
Some new functionalities may be implemented :
Change request description See details in
testcase(s)
Priority
(Low, High,
critical)
AmChavan
To- Do list
number
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 1
Test description: * Run OT and check the main OT panel. Conclusion:
TestCase number: 1.1
Description:
* FILE menu
- "New"
- CTRL- N
- "Open"
- CTRL- O
Expected result:
- opens a new Queue View
- opens a new Queue View
- opens Queue Chooser
- opens Queue Chooser
Effective result:
- OK
- OK
- OK
- OK
Conclusion:
TestCase number: 1.2
Description:
* run OT with/witout debug
option
* check debug messages
Expected result:
* debug messages/no
messages mode
* clear understandable
debug messages
Effective result:
* NOK: when running jot
WITHOUT the - debug
option, jot correctly run
(Main panel displayed) but
then impossible to select
any "File" menu item :
nothing displayed, but the
"Edit" menu is active.
* NOK: following debug
message displayed quite
continuously (refreshed
almost every second), so
it's quite impossible to go
back to previous
messages in the X- term :
There are 0 mask table
entries to update
Is up to Date true
Is up to Date true
==> to be displayed every
minute would be enough
...
Conclusion:
NOGO : CRITICAL
NOGO: LOW
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 1.3
Description:
* login OT when
inconsistencies
between obs.
Runs and OBs
exist
Expected
result:
* error
message
displayed but
OT run
anyway ?
Effective result:
* following debug messages and OT main box not working:
READ: id=609006005(6090060); type=class
org.eso.ohs.dfs.ObservingRun
sql = SELECT DISTINCT obs_runs.id AS id,obs_runs.rank
AS rank,obs_runs.assigned_time AS
assigned_time,obs_runs.rank_class AS
rank_class,obs_runs.programme_id AS
programme_id,obs_runs.run_desc AS
run_desc,sched_rep.inst AS
inst_code,sched_rep.obs_mode AS
obs_mode,sched_rep.tel AS tel_code,sched_rep.progid AS
progid,obs_programmes.title AS
title,obs_programmes.period AS period
FROM obs_runs, sched_rep, obs_programmes, eso_users,
proposed WHERE
obs_runs.id = 6090060 AND obs_runs.id =
sched_rep.run_id AND
obs_runs.programme_id = obs_programmes.id AND
obs_programmes.id =
proposed.programme_id AND proposed.pi_flag = 0
org.eso.ohs.persistence.ObjectNotFoundException: Object
not found in database at
org.eso.ohs.dbase.phase1.DbaseHandlerOR.read(DbaseH
andlerOR.java:93) at
org.eso.ohs.dbase.DbaseStorageMgr.read(DbaseStorage
Mgr.java:360) at
org.eso.ohs.persistence.ObjectManager.getBusObj(Object
Manager.java:864) at
org.eso.ohs.persistence.ObjectManager.reassembleRefere
nces(ObjectManager.java:942) at
org.eso.ohs.persistence.ObjectManager.getBusObj(Object
Manager.java:873) at
org.eso.ohs.masktracker.Updater.updateNAIDs(Updater.ja
va:166) at
org.eso.ohs.masktracker.Updater.propagateMaskInfo(Upda
ter.java:263) at
org.eso.ohs.masktracker.Updater.run(Updater.java:95)
OK, this bug occured because our SEGSRV12 didn't
contain data for obs_runs.id = 6090060. Solved with Carlo
Boarotto.
==> But, anyway, why the OT super- user '0' needs to
access OPC63 ?
Furthermore, OT should have displayed an error message
here.
Finally, it would have been possible to run OT even if there
are inconsistencies between OBs and obs_runs.
Conclusion:
NOGO: HIGH
TestCase number: 1.4
Description:
Edit menu:
* "Clear"
* "rename"
Expected result:
* OBs removed from the current
queue
* curent queue renamed
Effective result:
* OK but this item should rather be
called "Remove OBs from queue".
Then, last OB details are not deleted
from the Queue View (these OB
details were displayed before
removing OBs)
* OK but this item should rather be
called "Rename queue"
Conclusion:
GO with side
effect
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 1.5
Description:
* quit OT
Expected result:
* warning message displayed
Effective result:
* NOK: when quitting JOT, a
confirmation box should be displayed
like with P2PP. Needed also if the
current queue was modified but not
saved before quitting.
Conclusion:
NOGO: HIGH
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 2
Test description: * Queue manipulation Conclusion:
TestCase number: 2.1
Description:
* create a new
queue
Expected result: Effective result:
* OK but: creating a new queue (by CTRL- N) without
doing anything else, and then close it : confirmation
message displayed saying that "the queue was
modified. Do you want to save the changes ...". Such
message should NOT be displayed since no
modification was performed on this new queue.
Conclusion:
GO with side
effect : LOW
TestCase number: 2.2
Description:
* open an existing queue
Expected
result:
*
Effective result:
* OK, but when opening a queue (a
new one or an existing one), it should
be selected by default on the main OT
panel (to avoid the frequent case where
fetching an OB without having
previously selected a queue).
* then, creating a new queue (by
CTRL- N) without doing anything else,
and then close it : confirmation
message displayed saying that "the
queue was modified. Do you want to
save the changes ...". Such message
should NOT be displayed since no
modification was performed on this new
queue.
* Queue Chooser, the button to close
this box should be named "Close" and
not "Cancel" to be consistent with other
OT boxes and with P2PP.
* Queue Chooser : the queue ID should
also be displayed, since queue name
are sometimes not understandable, and
several queues may get the same
name. For instance, for test purpose I
created several queues all named "No-
name" : no way to distinguish them
than the queue ID.
Conclusion:
GO with Side Effect :
MINOR
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 2.3
Description:
* save a queue
Expected result:
*
Effective result:
* OK, but when saving a
queue for the first time
(File>Save), OT should
ask to enter a specific
name (as it does for "Save
as ..."). Works like that
with WORD, EXCEL, ...
Conclusion:
GO with Side Effect
TestCase number: 2.4
Description:
* rename a queue
Expected result:
*
Effective result:
* OK, to be consistent with
P2PP: a "Queue name"
field should be added to
name a queue, and
automatically displayed in
the bar title. Otherwise,
the OT user doesn't know
how to name or rename a
queue (the "Edit/rename"
menu item is not very
convenient).
Conclusion:
GO with Side Effect :
LOW
TestCase number: 2.5
Description
:
* delete a
queue
Expected
result:
* queue
deleted
Effective result:
* NOK: unfortunately, I don't remeber the exact sequence of what I did
(something like creating, deleting, opening 2 or 3 queues ...), but I got the
following messages from OT: "You are into an inconsistent state. Please
close immediatly the application" error message and following Java
exception: com.sybase.jdbc.SybSQLException: Foreign key constraint
violation occurred, dbname = 'obrep2', table name = 'schedule_items',
name = 'fk_schedule_items_ob_id'.
at com.sybase.tds.Tds.processEed(Tds.java)
at com.sybase.tds.Tds.nextResult(Tds.java)
at com.sybase.jdbc.ResultGetter.nextResult(ResultGetter.java)
at com.sybase.jdbc.SybStatement.nextResult(SybStatement.java)
at com.sybase.jdbc.SybStatement.updateLoop(SybStatement.java)
at com.sybase.jdbc.SybStatement.executeUpdate(SybStatement.java)
at com.sybase.jdbc.SybStatement.executeUpdate(SybStatement.java)
at org.eso.ohs.ot.util.DBUtil.insertExtraData(DBUtil.java:740)
at org.eso.ohs.ot.util.DBUtil.updateQueueTable(DBUtil.java:702)
at org.eso.ohs.ot.gui.QueueItems
BView.copyOn(QueueItemsBView.java:103)
at org.eso.ohs.ot.gui.QueueView
Manager.saveAsQueue(QueueViewManager.java:1185)
at org.eso.ohs.ot.gui.OTViewManager
.actionPerformed(OTViewManager.java:395)
at javax.swing.AbstractButton.fireAction
Performed(AbstractButton.java:1066)
at javax.swing.AbstractButton$
ForwardActionEvents.actionPerformed(AbstractButton.java:1101)
at javax.swing.DefaultButtonModel.fire
ActionPerformed(DefaultButtonModel.java:378)
at javax.swing.DefaultButton
Model.setPressed(DefaultButtonModel.java:250)
Conclusi
on:
NOGO :
CRITICAL
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 2.6
Description
:
* delete a
queue which
Queue View
is still
opened
Expected
result:
* queue
deleted
Effective result:
* NOK: First, warning message asking to save the queue before closing it
: answer Yes. Then following error message saying "the following error
occurred while saving the Queue : object not in memory : 10412508".
Then impossible to close the current Queue, unless I answer NO to the
question relative to saving. The problem is also that I did save this queue
before trying to close it.
Conclusi
on:
NOGO :
HIGH
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 3
Test description: * Queue View Conclusion:
TestCase number: 3.1
Description:
*
Expected result: Effective result: Conclusion:
TestCase number: 3.2
Description:
* Reload OBs (already
appended to the current
queue)
Expected result:
* OB reload and
corresponding columns
updated
Effective result:
* OK
Conclusion:
GO
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 3.3
Description:
"Comment"
button :
* changing OB
status
* changing QC
grade
* entering a
very long text
into the
Comment field
* trying again to
attach a
comment
Expected
result:
* status
modified in
the QV grid
* QC grade
updated in
the QV grid
* Comment
attached to
the OB
Effective result:
* OK
* OK
* NOK: following Java Exception, and the comment was not
stored.
com.sybase.jdbc.SybSQLException: Incorrect syntax near ';'.at
com.sybase.tds.Tds.processEed(Tds.java) at
com.sybase.tds.Tds.nextResult(Tds.java) at
com.sybase.jdbc.ResultGetter.nextResult(ResultGetter.java) at
com.sybase.jdbc.SybStatement.nextResult(SybStatement.java)
at
com.sybase.jdbc.SybStatement.updateLoop(SybStatement.java
) at
com.sybase.jdbc.SybStatement.executeUpdate(SybStatement.j
ava) at
com.sybase.jdbc.SybStatement.executeUpdate(SybStatement.j
ava) at
org.eso.ohs.ot.util.DBUtil.updateOB(DBUtil.java:128) at
org.eso.ohs.ot.util.DBUtil.updateOBs(DBUtil.java:81) at
org.eso.ohs.ot.gui.QueueViewManager.commentOBs(QueueVie
wManager.java:738) at
org.eso.ohs.ot.gui.QueueViewManager$2.actionPerformed(Que
ueViewManager.java:225) at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.j
ava:1066)
* Error message : "implicit conversion from datatype 'TEXT' to
'VARCHAR' is not allowed. Use the CONVERT function to run
this query."
and Java exception com.sybase.jdbc.SybSQLException: Implicit
conversion from datatype 'TEXT' to 'VARCHAR' is not allowed.
Use the CONVERT function to run this query. at
com.sybase.tds.Tds.processEed(Tds.java) at
com.sybase.tds.Tds.nextResult(Tds.java) at
com.sybase.jdbc.ResultGetter.nextResult(ResultGetter.java)
at
com.sybase.jdbc.SybStatement.nextResult(SybStatement.java)
at
com.sybase.jdbc.SybStatement.updateLoop(SybStatement.java
) at
com.sybase.jdbc.SybStatement.executeUpdate(SybStatement.j
ava) at
com.sybase.jdbc.SybStatement.executeUpdate(SybStatement.j
ava) at
org.eso.ohs.ot.util.DBUtil.updateOB(DBUtil.java:128) at
org.eso.ohs.ot.util.DBUtil.updateOBs(DBUtil.java:81) at
org.eso.ohs.ot.gui.QueueViewManager.commentOBs(QueueVie
wManager.java:738) at
org.eso.ohs.ot.gui.QueueViewManager$2.actionPerformed(Que
ueViewManager.java:225) at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.j
ava:1066)
Conclusion
:
NOGO
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 3.4
Description:
* "Verify" button
Expected result:
* OB verified
Effective result:
* NOK : nothing happens :
not implemented yet
Conclusion:
NOGO
TestCase number: 3.5
Description:
* "Move Up" "Move down"
buttons
Expected result:
* OB moved
Effective result:
* OK
Conclusion:
GO
TestCase number: 3.6
Description:
* "Execution" button
Expected result:
* OB passed to the
execution sequence
Effective result:
* OK
Conclusion:
GO
TestCase number: 3.7
Description:
* "Copy/Paste" buttons
Expected result:
* OB copied from one
queue to a second one
Effective result:
* OK
Conclusion:
GO
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 4
Test description: * Repository browser Conclusion:
TestCase number: 4.1
Description:
* run a query
Expected result: Effective result: Conclusion:
TestCase number: 4.2
Description:
* sort results
Expected result:
*
Effective result:
*
Conclusion:
TestCase number: 4.3
Description:
* append an OB to the
current queue
Expected result:
* selected OB append to
the current queue
Effective result:
* OK, but when selecting
OBs via the OT browser,
the user usually select
some columns. It should
be better to display the
same columns when the
OBs are appended to a
queue : same columns
displayed in the QV grid.
Otherwise, the user has
select twice these
columns in the QV grid
and reload the OBs.
Conclusion:
GO with Side Effect :
HIGH
TestCase number: 4.4
Description:
* Count a query result
Expected result:
* same amount than the
one displayed just after
the query result
Effective result:
* NOK : the query result
says 62 rows; the "count"
says "pre- counted 72
rows (including
duplicates); manual count
gives 62 rows.
Conclusion:
NOGO : MINOR
TestCase number: 4.5
Description:
* close the Rep browser
Expected result:
*
Effective result:
* OK, but a "Close" button
should be added.
Conclusion:
GO with side effect :
MINOR
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 4.6
Description:
* "selection" button :
"Show queue" associated
to selected OBs.
* save result into a file
* print result.
Expected result:
* corresponding queues
displayed
* result saved on disk
* file printed
Effective result:
* OK
* OK
* OK
Conclusion:
GO
TestCase number: 4.7
Description:
* Rep browser, "Selection"
button : "delete OBs from
all queues"
Expected result:
* OB deleted
Effective result:
* OK
Conclusion:
GO
TestCase number: 4.8
Description:
* Rep browser, "Selection"
button : "delete OBs"
Expected result:
* OB deleted
Effective result:
* OK but if an OB is still
attached to a queue, a
warning message should
be displayed.
Conclusion:
GO with side effect :
HIGH ?
TestCase number: 4.9
Description:
* Rep browser, "Selection"
button : "Mark ..." status
Expected result:
* status updated
* same status value with
the P2PP Rep browser.
Effective result:
* OK
* OK
Conclusion:
GO
TestCase number: 4.10
Description:
* Compare P2PPRep
browser and OT rep
browser
Expected result:
* same content
Effective result:
* NOK : some minor
differences : most
important is the Status list
(in Prep, checked- in,...)
for P2PP; (P)artially
defined, (D)efined after
pahse II, ...) for OT.
Anyway same query gives
same resullt (same OBs
displayed).
"Count" gives same value.
"Sort" gives same result.
Conclusion:
NOGO : HIGH
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 5
Test description: Mask Orders / Reports - Nominal case Conclusion:
TestCase number: 5.1 sent a MMO
Description:
* Append a
previous checked-
in VIMOS OB to a
queue.
* Run the Mask
browser to retrieve
masks
corresponding to
this OB.
* Select in the QV
box the
Mask/Manufacturin
g Order item.
Select the current
Queue. Then, on
BOB side, click on
"fetch".
Expected result:
* OB append to the current queue
* mask_naid is set (format :
10495_2000- 10- 13T11:33:25.000),
but mask_slot_num and mask_id to
- 1).
* MMO fetched by BOB.
Effective result:
* OK
* OK
* NOK, even if MMO was fetched
error messages for each of the 4
masks : something like "MASK1.ID
is supposed to be float (value ""),
MASK1.NO is supposed to be
integer (value ""). Please correct
the OB and the signature file".
The MMO seems to have been
fetched by BOB (OB name and
content displayed in the BOB
panel).
Then pb in displaying OB content
on BOB side : mask content
unreadable, OB parts
superimposed.
* when sending an MMO, a
progress bar is really missing :
without the - debug option, there is
no way for the OT user to know
how things are going on.
Conclusion:
NOGO : HIGH
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 5.2 sent a MMR
Description:
* on BOB side, select
"File>Load Obs/From
files ...". And select a
pafready.obd file.
* click on "Start
observing" button.
And, select a MMR
file
Expected result:
* Select File box opened.
PAFready event sent to OT.
* test.mmr file selected.
MMR sent back to OT.
Mask.id values set (eg
120171, 220171). Mask- slot
still to - 1.
Effective result:
* OK, but how the user OT
knows that this event has
been sent to him ?
* OK, but a warning
message saying that MMR
has been received is
missing. Then how to inform
the OT user that the
insertion failed ?
* when sending an MMR, a
progress bar is really
missing : without the - debug
option, there is no way for
the OT user to know how
things are going on.
Conclusion:
GO with side effect :
CRITICAL
TestCase number: 5.3 sent a MIO
Description:
* Select in the QV box the
Mask/Insertion Order
item. Select the current
Queue. Then, on BOB
side, click on "fetch".
Expected result:
* MIO fetched by BOB
Effective result:
* NOK, error message
"Could not find the
template signature file for
0. This template can not
be executed ...", but
anyway BOB displays a
"Mask Insertion OB" entry
whose content seems
really to corresponds to
the current OB.
Conclusion:
NOGO : HIGH
TestCase number: 5.4 sent a MIR
Description:
* on BOB side, select
"File>Load Obs/From files
...". And select a
pafready.obd file.
* click on "Start observing"
button. And, select a MIR
file
Expected result:
* Select File box opened.
PAFready event sent to
OT.
* test.mir file selected.
MIR sent back to OT.
Mask._slot set.
Effective result:
* OK
* OK
Conclusion:
TestCase number: 5.5 sent a MDO
Description:
* Select in the QV box the
Mask/Insertion Order
item. Select the current
Queue. Then, on BOB
side, click on "fetch".
Expected result:
* MIO fetched by BOB
Effective result:
* OK, but error message
"Could not find the
template signature file for
0. This template can not
be executed ...", but
anyway BOB displays a
"Mask Discarding OB"
entry whose content
seems really to
corresponds to the current
OB.
Conclusion:
* Go with side effect :
HIGH
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 5.6 sent a MDR
Description:
* on BOB side, select
"File>Load Obs/From files
...". And select a
pafready.obd file.
* click on "Start observing"
button. And, select a MIR
file
Expected result:
* Select File box opened.
PAFready event sent to
OT.
* test.mir file selected.
MIR sent back to OT.
Mask._slot set.
Effective result:
* OK
* OK, but before
discarding masks, a
confirmation message
must be displayed for
EACH concerned OB.
Then it should not be
possible to allow
discarding masks for OB
not yet executed ?
Conclusion:
GO with side effect :
CRITICAL
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 6
Test description: Mask Orders / Reports - Error cases Conclusion:
TestCase number: 6.1 MMO
Description:
* send a MMO refering to non-
existent OB (=OB ID not stored
into DB)
* send twice the same MMO
Expected result:
*
Effective result:
*
Conclusion:
TestCase number: 6.2 MMR
Description:
* send a MMR refering to
non- existent masks
(=mask NAID not stored
into the Mask table)
* send twice the same
MMR
Expected result:
*
Effective result:
*
Conclusion:
TestCase number: 6.3 MIO
Description:
* send a MIO refering to
non- existent masks
(=mask NAIDs not stored
into the Mask table)
* send twice the same
MIO
Expected result:
*
Effective result:
*
Conclusion:
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 6.4 MIR
Description:
* send a MIR refering to
non- existent masks
(=mask IDs not stored into
the Mask table)
* send a MIR refering to
non- existent slots (=No-
slot not consistent)
* send twice the same
MIR
Expected result:
*
Effective result:
*
Conclusion:
TestCase number: 6.5 MDO
Description:
* send a MDO refering to
non- existent masks
(=mask NAIDs not stored
into the Mask table)
* send twice the same
MDO
Expected result:
*
Effective result:
*
Conclusion:
TestCase number: 6.6 MDR
Description:
* send a MDR refering to
non- existent masks
(=mask IDs not stored into
the Mask table)
* send a MDR refering to
non- existent slots (=No-
slot not consistent)
* send twice the same
MDR
Expected result:
*
Effective result:
*
Conclusion:
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 7
Test description: * Mask Browser Conclusion:
TestCase number: 7.1
Description:
* query masks
Expected result: Effective result: Conclusion:
TestCase number: 7.2
Description:
* sort mask query result
Expected result:
*
Effective result:
*
Conclusion:
TestCase number: 7.3
Description:
* update mask query
result
Expected result:
*
Effective result:
* why Mask NAID, Mask ID and
Slot number are always modifiable
via the Mask browser ? It may
lead to some inconsistencies, isn't
it ?
The default rule should be to set
these fields as NOT modifiable,
and then to enforce the user to
first ask for modification (for
example, enforce the OT user to
select another specific menu and
display a corresponding warning
message ...)
Conclusion:
NOGO : HIGH
TestCase number: 7.4
Description:
* check other
mask Tracker
buttons and
menu items
Expected result:
*
Effective result:
* NOK: fter click on the "Dismiss" button of
the Mask browser box, this button becomes
grey, and then the box is NOT closed as it
should. "Close" the box itself works then.
* the OT Mask menu (to select MMO, MIO
or MDO) should be replaced by specific
radio buttons to be placed in a proper place
of the QV box, so that the OT user always
know what kind of Order he is going to send.
These radio buttons should also contain a
fourth value when the OT user just want to
fetch a traditional OB ("OB to be fetched").
Conclusion:
* NOGO: LOW
* NOGO : HIGH
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 7.5
Description:
*Exit from Mask browser
Expected result:
*
Effective result:
* OK but a "Close" button
should be added
Conclusion:
GO with side effect :
MINOR
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Test Form
Tool: OT Release: V2.2int2
Tester: K. HAGGOUCHI Begin date : End date :
Test phase (unit, integration, validation, validation
acceptance, commissioning, other):
Test number: 8
Test description: * fetch VIMOS OB appended to OT queues Conclusion:
TestCase number: 8.1
Description:
* create a VIMOS OB attaching the 4
ADP files with P2PP, check- in.
* Quit P2PP. Run OT, retrieve this OB
via the OT Rep browser, append it into
a queue, add it to the execution
sequence.
* Run BOB in a normal way (=
WITHOUT the - offline option), check
that the current queue and OB are
selected, and fetch it. And finally,
execute the OB via BOB : status still
to D
Expected result:
* Status is D
* Status is D again.
* OB set to I
Effective result:
* OK
* OK
* NOK: status is still D :
should be I. May due to the
fact that a sequencer file was
missing (I got the usual
message about it).
Conclusion:
NOGO :
CRITICAL ?
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 8.2
Description:
* create a simple FORS1 OB (1 AT+
1 cal template). Check- in.
* add the corresponding sequencer
file under $INS_ROOT/.../SEQ
* Quit P2PP. Run OT, retrieve this
OB via the OT Rep browser, append
it into a queue.
* Save the queue.
Expected
result:
* Status is D
* OB appened
* queue saved
Effective result:
* OK
* NOK: nothing happens ! (the OB
doesn't appear in the QV grid (I'm sure
there was only one QV opened here).
* Error message "the following error
occured while saving the Queue:
attempt to insert duplicate key row in
object 'schedule_items' with unique
index 'pk_schedule_items" and Java
exception:
com.sybase.jdbc.SybSQLException:
Attempt to insert duplicate key row in
object 'schedule_items' with unique
index 'pk_schedule_items' at
com.sybase.tds.Tds.processEed(Tds.ja
va) at
com.sybase.tds.Tds.nextResult(Tds.jav
a) at
com.sybase.jdbc.ResultGetter.nextRes
ult(ResultGetter.java) at
com.sybase.jdbc.SybStatement.nextRe
sult(SybStatement.java) at
com.sybase.jdbc.SybStatement.update
Loop(SybStatement.java) at
com.sybase.jdbc.SybStatement.execut
eUpdate(SybStatement.java) at
com.sybase.jdbc.SybStatement.execut
eUpdate(SybStatement.java) at
org.eso.ohs.ot.util.DBUtil.insertExtraDa
ta(DBUtil.java:740) at
org.eso.ohs.ot.util.DBUtil.updateQueue
Table(DBUtil.java:702) at
org.eso.ohs.ot.gui.OTQueueBrowserVi
ew.save(OTQueueBrowserView.java:4
37) at
org.eso.ohs.ot.gui.QueueViewManager
.saveQueue(QueueViewManager.java:
1051) at
org.eso.ohs.ot.gui.QueueViewManager
$16.actionPerformed(QueueViewMana
ger.java:361) at
javax.swing.AbstractButton.fireActionP
erformed(AbstractButton.java:1066) at
javax.swing.AbstractButton$ForwardAc
tio
* NOK: status is still D : should be I.
Conclusion:
NOGO :
CRITICAL
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
TestCase number: 8.3
Description:
* Re- start OT, retrieve the OB from
testcase 8.2. Append it to the same
queue.
* Add the OB to exec sequence
* fetch it with BOB (running without
the - offline option)
* execute OB from BOB
Expected result:
* OB append
* OB added to exec
seq.
* OB fetched
* OB executed
Effective result:
* OK : here no problem !
* OK
* OK
* No because, sequencer file
was missing indeed
Conclusion:
GO
TestCase number: 8.4
Description:
* P2PP and BOB NOT running
* Re- start OT
Expected result:
*
Effective result:
* OK (main OT panel
appears) but : Java
exception:java.lang.ArrayInde
xOutOfBoundsException: - 1
at
org.eso.ohs.masktracker.Upd
ater.updateNAIDs(Updater.jav
a:179) at
org.eso.ohs.masktracker.Upd
ater.propagateMaskInfo(Upda
ter.java:263) at
org.eso.ohs.masktracker.Upd
ater.run(Updater.java:95)
Conclusion:
GO with side
effect: HIGH ?
TestCase number: 8.5
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Description:
* Re- start OT
* create a new
queue. Retrieve a
FORS2 OB
previously
created and
append it to the
queue. Add it to
exec seq.Run
BOB (WITHOUT
- offline)
* fetch and
execute the OB
from BOB
Expe
cted
result
:
* OB
appen
ded,
added
to
exec
seq.
* OB
fetche
d and
execu
ted
Effective result:
* OK
* OK but following Java exception:
Java exception:Is off line null OT.NextObsBlocks: 1 has valid selection - - - - >required
from Bob 1 Ob(s) and returned 1
<<<<<<<<<<< ID = 104135 <<<<<<<<<<< Ids are equal
>>> ObsBlockStatus( "1041 2000- 11- 16T17:39:09 STARTED" )
<<<<<<<<<<< ID = 10 READ: id=1041(10); type=null
java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java) at
org.eso.ohs.dbase.DbaseStorageMgr$HandlerRegistry.lookup(DbaseStorageMgr.java:90
3) at
org.eso.ohs.dbase.DbaseStorageMgr$HandlerRegistry.getHandler(DbaseStorageMgr.jav
a:914) at
org.eso.ohs.dbase.DbaseStorageMgr.read(DbaseStorageMgr.java:350) at
org.eso.ohs.persistence.ObjectManager. getBusObj(ObjectManager.java:864) at
org.eso.ohs.ot.icdVcs.ScriptListener.setBusObjStatusFromEventType(ScriptListener.java:
52) at org.eso.ohs.ot.icdVcs.EventListener. ObsBlockStatus(EventListener.java:62)
at org.eso.ohs.icdVcs.EventCmdBroadcaster.fire
StatusEvent(EventCmdBroadcaster.java:131) at
org.eso.ohs.icdVcs.EventCmdBroadcaster.
ObsBlockStatus(EventCmdBroadcaster.java:81) at
org.eso.vlt.base.Ccs.CcsSeqListener.cmdReceived(CcsSeqListener.java:109) at
org.eso.vlt.base.Ccs.CcsCommand Monitor.msgDispatch(CcsCommandMonitor.java:209)
at org.eso.vlt.base.Ccs.CcsMonitorList.notifyMsgRecvd(CcsMonitorList.java:51) at
org.eso.vlt.base.Ccs.CcsMonitorTable. notifyMsgRecvd(CcsMonitorTable.java:107)
at org.eso.vlt.base.Ccs.CcsEventLoop.runMsgRecv(CcsEventLoop.java:129) at
org.eso.vlt.base.Ccs.CcsEventLoop.run(CcsEventLoop.java:189)
>>> TemplateStatus(1041 1 2000- 11- 16T17:39:09 STARTED) >>> TemplateStatus(1041
1 2000- 11- 16T17:39:09 TERMINATED {}) >>> TemplateStatus(1041 2 2000- 11-
16T17:39:09 STARTED) >>> TemplateStatus(1041 2 2000- 11- 16T17:39:09
TERMINATED {}) >>> ObsBlockStatus( "1041 2000- 11- 16T17:39:09 TERMINATED" )
<<<<<<<<<<< ID = 10
READ: id=1041(10); type=null java.lang.NullPointerException at
java.util.Hashtable.get(Hashtable.java) at
org.eso.ohs.dbase.DbaseStorageMgr$HandlerRegistry.lookup(DbaseStorageMgr.java:90
3) at
org.eso.ohs.dbase.DbaseStorageMgr$HandlerRegistry.getHandler(DbaseStorageMgr.jav
a:914) at org.eso.ohs.dbase.DbaseStorageMgr.read(DbaseStorageMgr.java:350)
at org.eso.ohs.persistence.ObjectManager .getBusObj(ObjectManager.java:864) at
org.eso.ohs.ot.icdVcs.ScriptListener.setBusObjStatusFromEventType(ScriptListener.java:
52) at org.eso.ohs.ot.icdVcs. EventListener.ObsBlockStatus(EventListener.java:62)
at org.eso.ohs.icdVcs.EventCmdBroadcaster.
fireStatusEvent(EventCmdBroadcaster.java:131) at
org.eso.ohs.icdVcs.EventCmdBroadcaster.
ObsBlockStatus(EventCmdBroadcaster.java:81) at
org.eso.vlt.base.Ccs.CcsSeqListener. cmdReceived(CcsSeqListener.java:109) at
org.eso.vlt.base.Ccs.CcsCommandMonitor.msgDispatch(CcsCommandMonitor.java:209)
at org.eso.vlt.base.Ccs.CcsMonitorList.notifyMsgRecvd(CcsMonitorList.java:51) at
org.eso.vlt.base.Ccs.CcsMonitorTable.notifyMsgRecvd(CcsMonitorTable.java:107) at
org.eso.vlt.base.Ccs.CcsEventLoop.runMsgRecv(CcsEventLoop.java:129) at
org.eso.vlt.base.Ccs.CcsEventLoop.run(CcsEventLoop.java:189)
Query SQL Statement:
SELECT DISTINCT
'OB ID' = obrep2.dbo.obs_blocks.ob_id,
'Type' = obrep2.dbo.obs_blocks.type,
'MoonDis' = obrep2.dbo.constraint_sets.moon_distance,
'Instrument' = obrep2.dbo.obs_descriptions.instrument,
'OB Name' = obrep2.dbo.obs_blocks.item_name,
'UsrP' = obrep2.dbo.obs_blocks.userPriority,
'Templ' = obrep2.dbo.template_signatures.item_name,
'Status' = obrep2.dbo.obs_blocks.status
'ProgID' = opc63.dbo.sched_rep.progid
Then on BOB side, status still to D (instead of I). Quit OT (no Java exception)
Con
clusi
on:
NOG
O:
CRIT
ICAL
Issue Date: Document info:Modified Page: Page numbers/Statistics

OT Test Report VLT- xxx- ESO- 19000- xxx
Page: Page numbers / Statistics
Issue: 1.0 Date: Date
Issue Date: Document info:Modified Page: Page numbers/Statistics