Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/projects/dfs/team/JP2PP-test-report-V2_2beta14.txt Дата изменения: Mon Nov 19 13:09:12 2001 Дата индексирования: Sun Apr 13 22:54:42 2008 Кодировка: Поисковые слова: http astrokuban.info astrokuban

TEST REPORT FOR P2PP V2_2beta14
===============================



Tests performed from Oct 30 to Nov 15, 2001.

Running on HP-UX 11, jre 1.1.8 with VLTMARCH2001 (SEG test machine called '
wu0oh'), accessing SEGSRV12 in direct mode, account 'visitor'.
First testcases were run as user '1901' on an SEG cache, then from Nov 5 using
several operational caches sent by Paranal (mostly on the 52005 FORS2
engineering cache, and also some other VM caches) .


-------------------
Performed tests
-------------------
Main goal was to:
- test all new bug fixes as listed in the release note at
ftp://ftp.eso.org/pub/users/uss/ohs/jp2pp/P2PP-V2_2beta14.txt
in particular fixes of bugs originated on previous V2_2int2 version.
- see how the new P2PP behaves with current Paranal's caches (backward
compatibility).
- and the communication with BOB.


Main functionalities of P2PP have been tested:
* Manipulation of OBs (create, duplicate, move, delete, verify), for science
and calibration OBs mostly using FORS2 templates, and some with ISAAC.
* Import/export OBs.
* Save as OBD format.
* Synchronize OB components.
* Check in / check out, directly accessing DB.
* Generation of reports (Execution Time, ObsBlock breakdown, Verify).
* Interface to BOB (fetch of OBs, load OBD file generated by P2PP).
* Execution of the Verify function with some very basic EVM scripts.
* Super-user (user '0') has been used to query some OBs, edit some
of them and verify whether changes are saved.

Changes on TSF, "View phase 1 targets" and "download target definitions" were
quickly verified, since it has been deeply tested with previous beta
(V2_2int2).

The new Appserver V2_2beta14 has not been tested here.


--------------
Conclusion
--------------
This test session represents an effort of about 28 hours spread over 10
working days.

23 bug fixes were to be addressed by this beta14.
* 20 can be considered as solved
* 2 can be considered as partially solved (i.e. solved but with side effect)
* 0 can be considered as not solved
* 1 has not been tested (use of the new Appserver)

On total, 12 new bugs were found:
* 0 Critical (was 0 with V2_V2int2, 12 with V2_2beta10)
* 5 High (was 6 with V2_V2int2, 18 with V2_2beta10)
* 7 Minor (was 5 with V2_V2int2, 8 with V2_2beta10)

6 of those bugs should be fixed for next beta.
Others will be fixed later or still need to be discussed: 3 of them will
anyhow be added in the Known Problems list.


Important issues to be mentioned are:

* A specific TSF/OB inconsistency leads P2PP to hang, and not to be able
to modify the OB
-------------------------------------------------------------------------
See comment 37) hereafter.


* A mean to automatically re-parse a paramfile is needed
--------------------------------------------------------
As already described in previous V2_2int2 Test Report, several bugs previously
detected with beta10-11-12 about this issue are now fixed. But it's still
useful to mention how easy it is to introduce inconsistencies, for instance
when:
- attaching by mistake a second p_targ file (when a p_focf or a p_gbr is
expected)
- downloading a target definition from the "View Phase1 targets" menu item
- or simply when modifying by hand RA or DEC in the TP

They are several inconsistencies with current Paranal's caches, due to the
fact that:
- reading a V2_1_5 cache with V2_2beta14 does not re-parse the attached
paramfiles.
Also, notice that duplicating a Paranal's OB, or even checking-in it doesn't
re-parse paramfiles too. Only import makes the paramfile to be re-parsed.

There is no mean for P2PP V2_2beta14 to detect such inconsistency, and even if
an EVM script or the user himself detects it, the user will not be able to
automatically retrieve correct values from the paramfile. The only way (which
is not so elegant) would be to explicitely re-attach the same paramfile, i.e.
re-enter paramfile name via the corresponding "Select File" box.

==> After some discussion with Michele, Dave and Tim, it has been decided that
a new menu item (called "update from paramfile", for instance) has to be
implemented for next V2_2 beta.

This current possibly surprising behavior (how easy to introduce
inconsistencies, and no way to automatically detect them) should also be
explained to Paranal.


* Changes in TSF or ISF after OBs were created are not properly handled
-----------------------------------------------------------------------
The Paranal's caches contain quite a lot of invisible inconsistencies due to
changes in TSF or ISF definitions (for instance due to recent changes on the
RANGE of the DET.READ.CLKIND parameter of type "keyword").
For instance, about 70% of the current Paranal's 52005 FORS2 OBs are concerned
by this DET.READ.CLKIND modification.

"Invisible" means here that the user has *explicitely* to click/select the OB
via the main P2PP grid to get a red dot (otherwise the OB looks valid).
This even happens for OBs previously checked-in (may get a red dot, even if
checked-in).
==> I would then suggest to describe to Paranal this possibly surprising
behavior and add a related description in the list of known problems.


* Negative Execution Time existence
-----------------------------------
The bug about negative Execution Time values should still be considered as
open, and needs to be fixed before delivering V2_2 to Paranal, first because
negative values are not meaningful, second because they "corrupt" totals
calculated on a set of OBs.
It occurs because the value is converted in seconds and then saved as a short
integer; it becomes negative when the Execution Time value exceeds about 10
hours.
==> After some discussion, it has been decided to make a database structure
change to allow greater values for next beta.


* Possible to check-out OBs already attached to an OT queue
-----------------------------------------------------------
P2PP allows to check-out an OB which is already attached to an OT queue. It
displays an error message, but quite unclear (we already decided this action
item for V2_4). When attaching an OB to a queue, its status is not set to 'A'
(as expected to this beta-release ?).
==> this behavior should be explained to Paranal.


Finally, main bugs found in the previous V2_2int2 release can be considered
as solved:
- Synchronizing an AT attaching a paramfile didn't automatically update target
values in TP.
- Synchronizing AT, OD, CS and TP didn't preserve the "execution time" value.
- the "Verification error log" box displayed when running Verify didn't give
the OB name and the count of correct OBs.
- Synchronizing an OD to a Calibration OB made P2PP to hang up.






-------------------------
Detailed test results
-------------------------
Comments from Karim, replies from Cynthia.


About Execution Time feature
----------------------------
1)
MINOR:
Copy/Paste an AT now recomputes the Execution Time as it should, but
only after having selected another OB: I mean that the OB View is *not*
updated immediatly after clicking on Paste; one has to select another OB
(anyone), then select the pasted OB again to see the OBView updated.
This can be surprising (actually I was surprised myself ...).
If possible or not too complex, I suggest the Synchronize to automatically
re-compute Execution Time value (if not possible for V2_2, this behavior
should at least explained in the Known Problems).
Same problem for Copy/Paste OD.
==> to be fixed in next release (Calculate execution time if an OB Description
is pasted from another OB)


2)
Save an OB as OBD format: the Execution Time is not in the correct
format in the OBD file (OBS.EXECTIME "482" in OBD, while the OB View gives
00:08:02.000"
I am also wondering if this field is really necessary in the OBD (?).
==> desired behavior (482 corresponds to seconds)


3)
HIGH:
I created again an OB having a negative Execution Time value ...
(corresponding OBX file sent to Cynthia in a separate email).
4)
I guess this is a consequence of previous pt 3)
Reports>Execution Time Report also gives some negative values
(e.g. OB-ID 108398 in SEGSRV12:
report gives -584:19:56.736 while correct value is 23:59:59.000).
==> Yes, 3 and 4 are related because the calculation call is the same.
This problem is caused by the calculated Execute Time causes an integer
overflow and in Java a number larger than the max integer value wraps
to the highest negative number.
==> A DB structure change will be done for the next beta (V2_2).
Solution:Update execution time to default to -23:59:59.000 if
a negative number or a value greater than 23:59:59.000
is calculated.


5)
(very) MINOR:
Reports>Execution Time Report
The Totals values are preceeded by a strange "OT" word: what does it
mean ? (certainly very minor)
==> Need to check with Maurizio for meaning


6)
1539 item is solved (Execution Time doesn't appear anymore in OBX).


7)
Duplicate an OB correctly sets the Execution Time value in the target OB.


8)
Execution time is now correctly displayed and updated for Calibration
Blocks.


About paramfile/target values
-----------------------------
9)
Copy/Paste an AT attaching a p_targ file: OK, the target values
are automatically updated on the target OB side (previous V2_2int2
bug is solved).


Check-out
---------
10)
HIGH
Check-out a normal OB (peviously created with V2_2int2):
error message for the first OB
"An error occured while reading/writing data. Dependant foreign key
constraint violation in a referential integrity constraint
dbname='obrep2', table name='obs_blocks', constraint
name='fk_schedule_items_ob_id'.
error code=547
sql state=23000
Command has been aborted
error code=3621
sql state=01ZZZ"

I remember this message is about bugs 0821 and 0822 (to be solved for
"2.2.1" on the web
...) and Maurizio saying that this happens because one OB is associated
to a queue and
therefore it cannot be checked out, because that would violate a
referential
integrity constraint ("fk_schedule_items_ob_id"). We should report a
better error message, this is fine, and we already agreed on that, but
the new problem
here is that:
a) I was *able to check-out the OB* : I can see it in my P2PP OB grid
b) and the OB is still in the DBB list
So it is a "strange state": the OB is checked-out but still stored in
the DB and
append to a queue.

Trying to check it in then originate a Java exception and an error
message:
CLASS DbaseMgr - ensureNotAlreadyCheckedIn: sql = SELECT status FROM
obs_blocks WHERE ob_id IN (108398)
Dequeueing:
ObservationBlock[name='big-one-for-OT2.2int2-test',id=10839803]
org.eso.ohs.persistence.ObjectIOException: This object is already
checked-in!
Please use the database browser to ensure that
the checked-in items are as you wish them.
If you have serious problems, contact ESO Support for help
at
org.eso.ohs.dbase.phase2.DbaseMgr.ensureNotAlreadyCheckedIn(DbaseMgr.java:233)
at org.eso.ohs.dbase.phase2.DbaseMgr.checkIn(DbaseMgr.java:205)
at
org.eso.ohs.persistence.ProtectingStorageMgr.checkIn(ProtectingStorageMgr.java:414)
at
org.eso.ohs.persistence.AuthenticatingStorageMgr.checkIn(AuthenticatingStorageMgr.java:506)
at org.eso.ohs.p2pp.Persistence.checkIn(Persistence.java:289)
at
org.eso.ohs.p2pp.actions.CheckInAction$IncrementalCheckIn.performStep(CheckInAction.java:498)
at
org.eso.ohs.apps.actions.IncrementalActionAutomaton.run(IncrementalActionAutomaton.java:167)
at
javax.swing.SystemEventQueueUtilities.processRunnableEvent(SystemEventQueueUtilities.java:332)

Conclusion:
It's possible to check out an OB previously appended to a queue with
J-OT, which should not occur. Doing so generates an unclear error message to
the user, and somehow corrupts the P2PP local cache.
==> This can/should not happen when using the new OT. The new OT, when
appending an OB to a queue, set the OB status to "A" (accepted).
No OBs with this status maybe checked out for editing in p2pp.
Only if someone has explicitly changed the status of an OB and not
removed it from the queue will this problem arrise.
The current error message is:
" This OB can not be checked out as it has been passed to the telescope
team for execution"- Nick
==> KH: OK, to be verified with next P2PP V2_2beta.
==> Furthermore, a script has be developed and applied on ASTOPP, PROBS,
SEGSRV12, to convert status of related OBs to the new "A" value.



11)
[1371] (period selector in DBB beyond 70: OK, solved

[no SPR] 'Sky Tran' and 'Instruments' selection criteria now
allow multiple selection): OK, solved

[1534] (exception when entering 90 in Max DEC)": OK, solved

[1539] (Execution Time ignored in IMPEX): OK, solved

[1542] (verif reports displaying local storage OB-ID): OK, solved

[1514] (improve error message when TSF not available to server): OK,
solved

[1541] (0 OB(s) verified without erro): OK, solved

[1409] (download phase 1 target to a checked-in OB): OK, solved

[1428] (killing window in super-mode): OK, solved

[1481, 1482] (create a cache as super-user): OK, solved

[no SPR] (Exec Time not displayed for CalibOB): OK, solved

[no SPR] (exception when displaying a row in the Phase 1 target grid):
I tried to re-create same failing OB as with V2_2int2 and could not
reproduce the bug. I also retrieved targets on several other OBs
and everything was fine. So, I guess this bug is fixed.



12)
I think I went through all main features of the Execution Time function.
The most important question now is: has USG or someone verified that
values computed by P2PP are correct ?!
==> Calculation was verified in previous releases.


13)
Great, item [0971] can now be considered as solved at least about the features
I tested:
- attaching a correct p_targ: automatically update the TP.
- attaching a wrong one: reports an error (at least for PAF.NAME missing,
and DEC value not in appropriate format (07000) for instance).
- attaching a p_focf or a p_gbr file: doesn't alter previous TP values.
- synchronize AT: re-computes TP values
- duplicate OB: preserves target values
As already mentioned above, there are still some easy ways to create
inconsistencies but if we inform in advance the users it should be acceptable.


14)
MINOR:
[1464]
OK, new OBs get 2000 instead of J2000, but not all previously created
checked-in OBs. Furthermore, when Download Phase1 targets, values still
are J2000. Should we need a script to update previous values in the
DB ?
==> Need is talk to Fernando about this issue


15)
MINOR
A reminder about Lockinfo:
I crashed P2PP on my very poor X-term (12 Mb RAM), and when trying to
re-start I got an error message saying that same user ID is already connected.
This is the way the lockinfo feature works, fine, but just a reminder to you
to explain this in the Release Note and the User's Manual: in such case,
one has to remove the corresponding file in the cache directory. Paranal
should be aware of it before running the new V2_2.
==> Improved error message when a lock file is detected.
The new message includes the lock file path so it may
be deleted if desired. 12-NOV-2001 NK
Add to Release Notes. 13-11-01 CMM


16)
[1018] (browsing for RA is circular):
Period 66, Instrument FORS2, SEGSRV12
- RAmin=2 and RAmax=23 returns 37 rows ordered from 2 to
23 values, indeed
- RAmin=23 and RAmax=2 returns 54 rows: values from 23 to 0, and
values from 0 to 2 (I mean here I don't get values greater than
2 and lower than 23). Seems to be the expected behavior, isn't it ?
==> desired behavior


17)
[1531] (EVMs called before check-in): OK, I can see the EVM report
displayed, when checking in the OB, if this one contains some errors
(according to my -very basic- scripts).


18)
[1529] (rules 1 and 2 of the templates meta-data). I run the 2 following
testcases:
a> create a FORS2 OB, save it locally but *not check-in*.
Save it as OBD file.
Export it, too.
Quit P2PP.
Modify a TSF (FORS2_mxu_acq) used by the previous OB: exchange order
of TEL.TARG.ADDVELALPHA and TEL.TARG.ADDVELDELTA: so, now
TEL.TARG.ADDVELDELTA comes first, and ...ALPHA in second position.
Re-start P2PP: OK, the FORS2 TSF are re-analyzed.
View the previous OB: the FORS2_mxu_acq keywords are displayed according
to the new order (TEL.TARG.ADDVELDELTA first, then...ALPHA).
Save as OBD again (with a new name).
Export (with a new name).
Compare previous IMPEX and new one: only change is about the 2 keywords
order.
Compare previous OBD and new one: only change is about the 2 keywords
order.

b> now select an OB which was already checked-in *before* applying the
TSF order modification (also attaching the FORS2_mxu_acq template).
So, the order modification is still applied here.
View it: I see the *latest* order (TEL.TARG.ADDVELDELTA first,
then...ALPHA).
Run DBB and View from there the same OB: I see the latest order
(TEL.TARG.ADDVELDELTA first, then...ALPHA).
Save it as OBD file.
Export it, too.
Now, check-out this OB and View it: again, I see the latest order
(TEL.TARG.ADDVELDELTA first, then...ALPHA).
Save as OBD again (with a new name).
Export (with a new name).
Compare previous IMPEX and new one: no difference
Compare previous OBD and new one: no difference

I guess this is the expected behavior.
==> desired behavior


19)
[1527] (ISF entries not resolved for *.VALUE keywords)
==> OK, solved (verified with Tim via ISQL)


20)
[no SPR] (Synchronize AT was enabled when adding a template for the
first time)
I'm not sure to understand everything here :
- Create an OB
- Do not attach any template
- the Synchronize menu allows to Copy the OD, but not the AT: why ?
all 2 items (i.e. AT and OD should be both disabled, why only AT ?)
- Now, Copy the OD from this blank OB.
- Paste it to another OB already having some attached templates (AT+
OD): the
previous OD is removed: I don't think this is really good.
Copy OD should be allowed only if the source OB contains an OD.
==> This is as designed, for historic reasons an OB always has a OD.


21)
[1473] (new Appserver architecture)
To be tested as soon as after Tim prepares a test environment.
==> We need it get with Dave to create a test that allows two versions, with
two instruments, with 2 different app. servers using the same Data cache.


22)
MINOR
Running Execution Time report on a set of checked-in OBs (from DBB): if
one TSF is not found anymore or invalid, an error message is displayed, which
is good. This message recalls the TSF name but not the concerned OB.
I think it's should be good to also give name of OBs for which a TSF is
not correct.
==> next version


23)
Running in super-mode, and testing the Edit button: made some changes,
press on the save button, quit and re-start P2PP, query the modified
OB: OK changes are preserved.



Some more results about the V2_1_5/V2_2 backward compatibility
---------------------------------------------------------------
I got 2 caches directories from Paranal, one very big about FORS2/UT4
(ten users, about 500 OBs), another for VLTI (one user, about 200 OBs).

24)
First testcase is the following:
- read with P2PP V2_2beta14 the original VLTI cache (=cache originally
created with current official V2_1_5). Select and View some OBs on different
folders: OK, no problem, no Java exception, I can see the OB details,
anyway I can not be sure that what I see is the same as what was created
with P2PP V2_1_5.


25)
so, second testcase:
- now, quit V2_2beta14, and start V2_1_5 with same VLTI cache. Select
all possible OBs (218 VLTI OBs, most of them without error, with
different status values (Initiated, Executed, Aborted, ...), none of
them checked-in).
- export all those OBs
- quit V2_1_5 and re-start V2_2beta14 again with same VLTI cache. Select
all OBs and export them (into another directory).
- compare every IMPEX using a small script I developed (this script
takes every IMPEX file generated by V2_1_5, takes the corresponding one
as generated by V2_2beta14, and runs a diff): great ! no difference is
reported.


26)
Read the V2_1_5 cache with P2PP V2_2beta14 and run the Verify function
on about 100 VINCI OBs which are supposed to be correct (=no red dot)
selected at random: no error reported by P2PP V2_2beta14.

So the V2_1_5 VINCI cache is correctly retrieved by V2_2beta14.


27)
Now, let's see how it is with a FORS2 cache (user 52005):

- I first run P2PP V2_1_5 on the 52005 cache created with V2_1_5.
I select all OBs, and export them. Then quit P2PP.

- Run P2PP V2_2beta14 on the same 52005 cache created with V2_1_5:
the P2PP grid looks the same. Do not click on any OB
but select them via the CTRL-A key and export all of them.

- compare IMPEX from V2_1_5 and ones from V2_2beta14: no difference.

- Once again, run P2PP V2_2beta14 on the same 52005 cache created with
V2_1_5, but here click on some OBs: a red dot appears for some of them
and the Verify reports "errors on OD" !
After some investigation and discussion with Nick and Tim about this
strange situation, I perform the following:
- Running P2PP V2_2beta14 on an empty cache this time, I import
the IMPEX files previously generated by V2_1_5. Doing so, the import log
displays quite a lot of warnings (see the attached
'import-IMPEX-215-with22b14.report' file).
- export (into another directory) these OBs.
- and finally, compare original IMPEX (generated by V2_1_5) and the last
ones (i.e. imported then exported): several differences are found
(see the attached 'comp-p2pp-impex.txt' file).


Explanation
-----------
The DET.READ.CLKIND values are declared "invalid" during import and then
reset to the default value: looking at the corresponding TSF, it turns
out that indeed the original values were not anymore in the RANGE
definition of this parameter in the TSF.

Following example is for OB called 'NGC330_astromet' and its TSF called
'FORS2_img_obs_crsplit'
Diff on file: NGC330_astromet.obx
48c48
< DET.READ.CLKIND "225kHz,2x2,low"
---
> DET.READ.CLKIND "200kHz,2x2,low"

I think that Paranal first created the OB with the "225kHz,2x2,low"
value.
Then, some time later, they modified the 'FORS2_img_obs_crsplit.tsf' as
following:
# --------------------------------------------------------------------
TPL.PARAM "DET.READ.CLKIND"; # Next template
parameter
DET.READ.CLKIND.TYPE "keyword"; # Keyword type
DET.READ.CLKIND.RANGE "200kHz,2x2,low 200kHz,1x1,low"; # Valid range
DET.READ.CLKIND.DEFAULT "200kHz,2x2,low"; # Default value
DET.READ.CLKIND.LABEL "CCD Read-out Setup"; # Label use in P2PP

which means that the original "225kHz,2x2,low" value was removed from
the RANGE, and that's why import detected a warning, and replaced it with
the DEFAULT one.


HIGH
When running P2PP V2_2beta14 on such "inconsistent" OBs, a red dot
appears only when selecting them, or viewing them. Simply displaying the P2PP
grid doesn't make the red dot visible.
This is I guess not a critical bug to be discussed in a next SCCB meeting: if
possible, display the red dot even without having to first click on such OBs.

Notice that V2_2 is much better than V2_1_5 here, since V2_2 can detect
the error, while V2_1_5 never ! Indeed, V2_1_5 says nothing when clicking on
the OB, Verifying it, even when running a check-in, attaching it to an
OT queue, and fetching it from BOB ... And, what is really bad is that the
OB always contains the original parameter value (e.g. "225kHz,2x2,low" for the
OB given as example above), even when it became obsolete after the TSF change.
V2_2 will not solve the "inconsistent" OBs already stored in DB, but at
least will detect ones which are simply saved locally.


There is another issue with V2_2 which is minor I guess:
MINOR
Importing such inconsistent OB modifies it: the obsolete value is
replaced by the new default one, and then lost.
But if the OB is retrieved by reading the cache, the obsolete value is
simply in red (if the user selects the OB ...) meaning that the original value
is *not* lost. So, different behavior here while one can except the same.
I'm then thinking about a change change to be done on the import: offer
the user to keep the original value; this can be useful if the change done
in the TSF was actually wrong and the user modifies it afterwards to retrieve
the original values (this can also happen, why not ?).
This improvement can be discussed in a next SCCB.

Not very important: another minor bug in the current V2_1_5 only: in the
same situation as above, the combobox associated to the keyword displays the
RANGE values (from TSF), but also the original value which becomes obsolete
after the TSF change.
V2_2 behaves correctly: it displays the authorized values from RANGE only.


28)
HIGH
Another comment about the paramfile/target feature: when reading
the Paranal cache, the .p_targ file is *not* parsed and target values
remain to 00:00:00.000
The same if checking-in a "Paranal" OB.
Duplicating a "paranal" OB doesn't make the paramfile to be parsed, too
(it works for a new OB created with V2_2beta14).
Is it the expected behavior for V2_2beta14 ?
Re-reading the documentation on the uss web about the paramfile
handling, I don't retrieve anything about backward compatibility. Maybe I'm
tired ...

Anyway, import a Paranal OB works fine: the paramfile is parsed
(and paramfile parsing works correctly when attaching a new p_targ file
to the template).
==> Fix in next beta


29)
MINOR I hope.
This is the first time after several hours of use. I think
this happended when deleted an OB: the auto-save was run almost in
parallel
maybe (?): error message "an error occured while reading/writing data.
object not in memory -100523981703" and Java exception
Saving: ObservationBlock[name='toto',id=-100523981703]
UNEXPECTED EXCEPTION while saving -100523981703
org.eso.ohs.persistence.ObjectNotFoundException: object not in memory:
-100523981703
at
org.eso.ohs.persistence.ObjectManager.putBusObj(ObjectManager.java:736)
at
org.eso.ohs.persistence.AutoSaver.storeQueue(AutoSaver.java:352)
at org.eso.ohs.persistence.AutoSaver.run(AutoSaver.java:314)
==> Need to reproduce. Add to Know Problems Report ?


30)
Create a FORS2 OB, check it in.
Run new JOT V2_2beta15, append the OB to a queue. Quit JOT, re-start
P2PP and try to check-out the OB:

"Dependant foreign key constraint violation in a referential integrity
constraint. dbname='obrep2, table name = 'obs_blocks', constraint
name='fk_schedule-Items_ob_id' "

And the OB *is* checked-out.

An improvement for next V2_4 to give a more meaningfull P2PP error
message was already discussed in SCCBs (is item 1515), anyhow I would also
suggest:
- to say in the list of known problems, that P2PP V2_2 allows to
check-out OBs attached to queues (if status is Defined).
- to re-discuss this issue in a next SCCB (already an item in Maurizio's
To-Do list ?).
==> add to known problems


31)
Another interesting testcase: I was trying to reproduce problem 29)
found in previous V2_2int2 (see test report on the DFS Group web).

Import with V2_2beta14 an IMPEX previously created with V2_2int2 (2
weeks ago) (OB called my_first_V2_2int2_OB): the OBX is imported but
with several warnings:
"the following parameters were not imported for FORS2_lss_obs_off
because their values are fixed and cannot be edited:
DET.WIN1.ST
DET.WIN1.STRX
DET.WIN1.STRY
DET.WIN1.NX
DET.WIN1.NY


Export the imported OB (after renamed it warnings-on-WIN1-OB), and
compare OBX:
wu0oh visitor:~/P2PP/p2pp-2.2beta14 644 > diff
~/impex/my_first_V2-2int2_OB.obx ~/impex/warnings-on-WIN1-OB.obx
2c2
< name "my first V2-2int2 OB"
---
> name "warnings-on-WIN1-OB"
6d5
< ExecutionTime "559:43:30"
43c42
< TEL.GS1.ALPHA " 23:59:59.999"
---
> TEL.GS1.ALPHA "23:59:59.999"
55,60c54
< DET.READ.CLKIND "A,2x2,high"
< DET.WIN1.ST "T"
< DET.WIN1.STRX "2048"
< DET.WIN1.STRY "2046"
< DET.WIN1.NX "2048"
< DET.WIN1.NY "2046"
---
> DET.READ.CLKIND "100kHz,2x2,high"


Explanation
-----------
What is sure is that the original ~/impex/my_first_V2-2int2_OB.obx was
created 2 weeks ago, with a previous FORS2 IP (the current official one
from USG).
When imported it, it attaches the last FORS2 IP I received from Paranal
last week (where the DET.READ.CLKIND was modified but also the
DET.WIN1.xxx keywords).

Official version from USG:
# --------------------------------------------------------------------
TPL.PARAM "DET.WIN1.NY"; # Next template
parameter
DET.WIN1.NY.TYPE "integer"; # Keyword type
DET.WIN1.NY.RANGE "ISF NY.RANGE"; # Valid range
DET.WIN1.NY.DEFAULT "ISF NY.DEFAULT"; # Default value
DET.WIN1.NY.LABEL "CCD Window Y Size"; # Label use in P2PP

Current version from Paranal:
more ~/instruments/FORS2/FORS2_lss_obs_off.tsf
# --------------------------------------------------------------------
TPL.PARAM "DET.WIN1.NY"; # Next template
parameter
DET.WIN1.NY.TYPE "integer"; # Keyword type
DET.WIN1.NY.RANGE "ISF NY.RANGE"; # Valid range
DET.WIN1.NY.VALUE "100"; # Allocated value
DET.WIN1.NY.LABEL "CCD Window Y Size"; # Label use in P2PP


Seems normal (a parameter with VALUE is not anymore in the IMPEX), but please,
confirm.
This is again an example of impact of ISF/TSF changes.


32)
Now, on same OB as previous 31) item, View phase 1 targets>Query, select
target C1252.9-2827 and download it to the OB: OK, the target definition
is downloaded, and no more ClassCast exception".
So, previous item 29) (see my V2_2int2 Test Report) seems to be fixed.


33)
So, next is testing P2PP with BOB OCT2001 (I get a test machine now from
Paola Sivera).
And after that, still verify OBs status handling between P2PP and J-OT.


34)
Running P2PP as super-mode. Running BOB too.
Select an OB in the P2PP DBB grid, fetch it: BOB says:
"Could not communicate with OH"
Is it normal = no way to send an OB to BOB from P2PP/super-mode ?
==> as designed, no action


35)
I created an OB for the FORS2 prog-ID called 166.A-0701(A) which is in
Visitor Mode. Run BOB, fetch the OB: OK, the OB is sent to BOB, status to
Initiated, and ID to 108601.
Run the P2PP DBB: OK, period 67: I see OB ID 108601.
Run the P2PP DBB: OK, period 66: I see OB ID 108601, too.

Is it normal ? prog-ID starting with 1 (166.A...) corresponds to large
programs which may last more than 6 months, isn't it ?
==> as designed, no action


36)
Similar to comment 39) of OT V2_2beta15:
MINOR
Running P2PP this time accessing same IP as 39) (FORS2 summary.idx file is
null): P2PP debug log also give same message, then is running. But trying to
create a new OB is impossible: no TSF is visible in the P2PP grid.
I know what is wrong here because of the debug messages, but Paranal
will not.
I then suggest to:
- automatically delete the summary file, and re-create it each time P2PP
is run (?), or at least display an error message to the user explaining that
the file is null or corrupted, and must be first deleted, before re-starting
P2PP.
- for OT, is this file really necessary (?)
==> add to known problems


37)
This comment correspond in fact to comment number 23) of the
OT V2_2beta15 report:
HIGH
First I did the following with OT: run DBB, select 5 OBs previously
created attach them to a queue (second-OT-V2_2beta15-queue).
Run the verify report on them: several errors reported. For instance on
OB ID 108243 it says:
3 errors in the OD
Diff RA is out of range

So, I quit OT and run P2PP to check this OB. I run P2PP as super-mode
(because I didn't know which user. Run a query to retrieve thos FORS2 OBs, OK I
can see 108243. Edit it: yes the Diff RA is out of range (>99999), and there are
3 fields in red certainly because this OB (created with previous beta11
in June) has obsolete TSF. I then decided to modify the Diff Ra to enter a
proper value: fine.
Do the same for the 2 first OD values: fine.

For the third one, I was able to select a new value (combobox), but when
clicking else to valid my selection (I clicked
into a empty field) the selected combobox still appears on a line with
no corresponding keyword and Java exception:
java.lang.ArrayIndexOutOfBoundsException: 3
at
org.eso.ohs.p2pp.views.ODGridModel.setValueAt(ODGridModel.java:505)
at
org.eso.ohs.p2pp.views.AcquisitionModel.setValueAt(AcquisitionModel.java:343)
at javax.swing.JTable.setValueAt(JTable.java:1422)
at javax.swing.JTable.editingStopped(JTable.java:2557)
at
javax.swing.DefaultCellEditor.fireEditingStopped(DefaultCellEditor.java:281)
at
javax.swing.DefaultCellEditor.stopCellEditing(DefaultCellEditor.java:239)
at
org.eso.ohs.p2pp.views.ODTemplateTable.stopCellEditing(ODTemplateTable.java:280)
at
org.eso.ohs.p2pp.views.ODTemplateTable$TableMouseListener.saveChanges(ODTemplateTable.java:524)
at
org.eso.ohs.p2pp.views.ODTemplateTable$TableMouseListener.mouseExited(ODTemplateTable.java:565)
at
java.awt.AWTEventMulticaster.mouseExited(AWTEventMulticaster.java:247)
at
java.awt.AWTEventMulticaster.mouseExited(AWTEventMulticaster.java:247)
at
java.awt.AWTEventMulticaster.mouseExited(AWTEventMulticaster.java:247)
at java.awt.Component.processMouseEvent(Component.java:2364)
at java.awt.Component.processEvent(Component.java:2203)
at java.awt.Container.processEvent(Container.java:901)
at java.awt.Window.processEvent(Window.java:367)
at java.awt.Component.dispatchEventImpl(Component.java:1812)
at java.awt.Container.dispatchEventToSelf(Container.java:955)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:1839)
at
java.awt.LightweightDispatcher.trackMouseEnterExit(Container.java:1706)
at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:1600)
at
java.awt.LightweightDispatcher.dispatchEvent(Container.java:1531)
at java.awt.Container.dispatchEventImpl(Container.java:933)
at java.awt.Window.dispatchEventImpl(Window.java:509)
at java.awt.Component.dispatchEvent(Component.java:1744)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Then P2PP hangs, and the Java exception is repeated.
Anyhow, I'm able to close the OB View and use again the DBB.
Run another query where I still get same OB and Edit it again: same
problem, same exception.
Close the OB View again and Edit another OB: same problem ... and the
last selected combobox still appears for this *different* OB (created with
last P2PP beta with correct TSF this time ) !!!

Quit and re-start P2PP: I can view several OBs. The one I modified still
displays its original values (= its errors).

So, it seems that there is a "bad" TSF/OB inconsistency which leads P2PP
to hang and prevent me to modify the related OB.
==> Next beta