Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/projects/dfs/team/OT-test-report-V2-1-4-beta1.txt Дата изменения: Thu Sep 27 11:15:33 2001 Дата индексирования: Sun Apr 13 22:54:31 2008 Кодировка:

TEST REPORT for Java OT V2-1-4-beta1
=====================================

Tests performed from 25/05/2001 to 26/05/2001.
Main goal here was to check whether major bugs originated on previous
V2-2-beta release were correctly fixed (See corresponding Test Report
from November 2000 on the DFS Group Home Page) and current Release
Note items correctly implemented.

Tests were performed on following configuration:
wg0arc visitor:~ 497 > uname -a
HP-UX wg0arc B.11.00 A 9000/782 2000404527 two-user license
wg0arc visitor:~ 498 > whoami
visitor

accessing SEGSRV12, and running in debug mode.

Answers from Maurizio on 13 june 2001.


Main performed tests
--------------------

Every functionality except the ones related to Mask Tracker, as
described in the Java OT Test Report
(see http://www.eso.org/projects/dfs/team/OHS.html).
Concentrating on robustness and ergonomics.

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

Following bugs were found:
* 5 new Critical (in fact, one corresponding to a previous
bug not properly fixed: item 1166).
* 27 High criticity
* and 16 Minor


Detailed tests results from KH
------------------------------
1) MINOR: OT should be run with 64 Mb memory, instead of 32 Mb, isn't it
? (see hereafter)
wg0arc visitor:~ 529 > DATAFLOW_DIR: /diska/flowmgr
DATAFLOW_JAVA: /diska/flowmgr/dfs/dataflowJava
DFS_EXTERNAL: external-3_2
SWING_HOME: /vlt/MAR2001/java/swing-1.1
JRE: /vlt/MAR2001/java/jdk-1.1.8/bin/jre
BASE: /diska/flowmgr/dfs/dataflowJava
options: -debug
optjre: -Dorg.eso.ohs.bob.vltroot=/vlt/MAR2001/CCSLite -mx32m
-Ddebug.mode=true -nojit
RTAPENV: wg0arc
==> Fixed


2) MINOR: when quitting, OT should ask for confirmation, as it does for
J-P2PP and J-Panel tool.
==> Fixed


3) HIGH: title of main box should display:
- name of accessed DB server, as it does for J-P2PP and J-Panel tool,
something like: "DB=SEGSRV12"
- and clarify the login name, something like:
"USER=0" instead of "0" (which is rather unclear).
==> Fixed


4) HIGH: Queue chooser: it's possible to change order of the 3 columns
(Name, Size, Description),
by dragging one column header, which is fine.
==> In fact it is *not* fine and was disabled.
I suggest to be able to sort those queues by double-click on a column
header (as it works for the OB View of P2PP, for instance). Paranal people like
this sorting facility.
==> Item 1393.


5) HIGH ? Queue chooser: the "description" field is ALWAYS blank here:
is it normal ?
then how can I enter this field ?
==> Fixed by removing the "description" field (it's an arbitrary text field,
possibly multiline). It can be edited in the QView.


6) HIGH: QueueView again: top of the box is strange: "StartTime.
Description"
then newline with "Duration" and telescope". StartTime can then never be
correctly displayed, no ?
==> Fixed


7) question: QueueView. Open an existing quite big queue (336 OBs).
Rename it.
Debug messages say
UPDATE schedule_items SET sequence = 0 WHERE ob_id = 103747 AND sch_id =
108009
for *each* OB.
Why is it required to run 336 updates on the schedule_items table just
to rename a queue ?
==> Edit->Rename was dropped. To rename a queue one can simply type in a new
name and File->Save the queue (note that File->SaveAs will instead
create a copy of the queue with a new name).
I added item 1394 to optimize the saving of a queue so that one does not
need to run many delete/insertion pairs if only the name of a queue has changed.


8) HIGH: a known problem I guess:
Open an existing queue (created with OT tcl/tk): QV comes, then
File>Close raises a warning
message saying "Queue ... was modified. Do you want to save the changes
before closing", where
obviously I didn't perform any change here.
==> Fixed.


9) MINOR: I think Query execution times, as reported by debug messages,
are wrong:
whatever I'm querying, I always get values starting with 21:30 ... (21
hours to run a query ?!).
examples:
Query execution time: 21:30:01.861
0
Query execution time: 21:30:00.481

or
Query execution time: 21:30:01.866
0
Query execution time: 21:30:00.420
==> Item 1389


10) QV, obs blocks grid: select an OB, click on Remove: a confirmation
message should be displayed.
==> I'm not sure, since this is not a destructive action: if you close the
queue without saving it the Remove action is effectively undone. I don't
like too many confirmation boxes, they tend to get on people's nerves
(editors don't ask you every time "are you sure?" when you delete a line).


11) HIGH: when removing an OB from a queue, then immediatly after close
the queue, a warning message
saying the queue has been modified but not saved should be displayed.
==> Fixed


12) HIGH: maybe same problem as 7): select an OB (queue with 336 OBs).
Mark status as D (or whatever
in fact).
This
UPDATE tempdb..tmp_schedule_items SET sequence = 331 WHERE ob_id =
101234 AND sch_id = 108009
is repeated 336 times: why ?
==> This should be fixed, but in this case I'm not 100% sure.


13) HIGH: there are 2 ways to rename a queue from the QV: either
File>Save as..., or Edit>Rename: one
only is enough !
==> Fixed


14) HIGH: QV: "Edit>Clear..." should be renamed "Edit>Clear all", as
other items about *ALL* OBs
are also named with "all" ("Select all" or "deselect all").
==> Fixed


15) MINOR: QV: "Edit>Clear..." should not contain the 3 dots: 3 dots are
only to be used when
a new box requesting to enter new inputs is opened (see WORD, EXCEL,
...).
==> Fixed


16) MINOR: main OT box: it should be nice, when simple-click on a queue,
to put corresponding QueueView
box on top of opened boxes (Paranal usually opens 7 to 10 queues at the
same time, having current
screen full of boxes).
==> Fixed. What we cannot do, though, is re-open an iconized window; we'll
need Java 1.4 for that (item 1396 for V.2.x).


17) HIGH: QV: the number of rows is not refreshed when removing an OB
(but the debug messages
indicate how many OBs exist before and after the remove).
If I save the queue, QV and main OT box are still not refreshed. I need
to close and then re-open the queue
to see the new (correct) number of OBs.
==> Item 1395.


18) HIGH: main OT box: File>New opens a "Select telescope" box: list of
telescope is not enterely
displayed (on HP). This "Select telescope" box should be bigger
(otherwise, the user has to re-size it
manually, which is boring).
==> Item 1397.


19) HIGH: main OT box: File>New opens a "Select telescope" box: several
telescopes are missing in particular
VLTI and La Silla's telescopes (La Silla may also use OT one day ?).
==> Fixed. The list of telescopes depends on the list of installed IPs.


20) HIGH: when File>New then "Select telescope", a new QV is created,
but the telescope name is missing
(on this QV). I suggest to add the telescope name in the QV box title
(and also in the main OT box).
==> Item 1398.


21) HIGH: QV: select an OB, click on
==> On where?


22) CRITICAL: QV 108009 (SEGSRV12), select OB 103747, then click on
Display: following error message
("I/O error while reading OB 103747), and Java exception. This OB was
created with a previous Tcl/tk OT.
CLASS TemplateSignature - init:
CLASS TemplateSignature - initParamList:
CLASS TemplateSignature - initParamList: loop: i =12
org.eso.ohs.persistence.ObjectIOException: TemplateSignature corrupt?
FORS2_img_obs_exp
at
org.eso.ohs.dbase.phase2.TemplateSigDBIO.read(TemplateSigDBIO.java:142)
at
org.eso.ohs.dbase.phase2.DbaseHandlerCB.read(DbaseHandlerCB.java:187)
at
org.eso.ohs.dbase.DbaseStorageMgr.read(DbaseStorageMgr.java:360)
at
org.eso.ohs.persistence.ObjectManager.getBusObj(ObjectManager.java:869)
at
org.eso.ohs.ot.gui.QueueViewManager.displayOB(QueueViewManager.java:687)
at
org.eso.ohs.ot.gui.QueueViewManager.access$1(QueueViewManager.java:672)
at
org.eso.ohs.ot.gui.QueueViewManager$22.actionPerformed(QueueViewManager.java:451)
at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1066)
Seems to be a problem of TSF file (a template which doesn't exist in the
TSF
directory, but OB checked-in): at least, the error message should be
more clear. But this
is something to be clarify: how P2PP and OT should handle such situation
?
==> We'll have to look into this, because we could not reproduce it. Anyway:
item 1400.



23) MINOR: hide somehow the "selected columns" because once there are
chosen, the user doesn't need
to see them all the time.
==> This requires an upgrade of the DBB package. Item 1401 on that to-do list.


24) HIGH: save the last "selected columns", and apply this list by
default for any queue newly opened
(even for existing queues), even if re-starting OT.
==> Item 0333 on the DBB to-do list.


25) HIGH: OB details: open exactly same OB View as P2PP, with all values
in grey (since none can be modified
by OT, to be confirmed).
==> Item 1402.


26) HIGH: QV: when adding an OB into the execution sequence, I suggest
to keep it in the
observation blocks grid (as it is now), but set it in grey or with a
specific color to
indicate it is in the execution sequence. I guess it is difficult to
easily find
OBs which are already in the execution sequence or not, in particular
with big queues.
==> The split between OB list and execution list, and in general the entire
Queue View, needs to be reviewed. Item 1142.



27) HIGH: I would split the QueueView in 3 distinct parts:
1- Queue itself: containing the "StartTime", "Duration", Telescope",
"description",
"name", and ID. Plus following buttons (as graphical icons: reload,
close, save, delete,
print, dump).
2- The OBs associated to the queue: and displayed/hidden small box with
"selected columns", then
the grid itself, with existing buttons.
3- the execution sequence: grid + buttons.
==> See above.


28) MINOR: remove the queue number from the OBs grid and from the
execution sequence : no interested to repeat
it for each OB.
==> Can't be done -- those numbers are needed for internal processing.
Moreover, OT operators on the mountain do use those numerical OB IDs.


29) MINOR: QueueView: queue with several OBs, where *no one* is
currently selected.
Click on the "Comment" button does nothing, but a warning message saying
something
like "Comment applies on selected OB. Please, first, select one" would
be better
(and it's like that with P2PP).
In fact, this is the same for ALL other QueueView buttons: Display,
Mark, Remove, Execution, ...
==> Fixed.


30) MINOR: When running OT, why not automatically display the Queue
chooser, with queues ordered by last modification time. Usually, Paranal
users first open
*existing* queues, check them, eventually update, and then possibly
create a new one.
==> Fixed.


31) MINOR: QueueChooser: add a column with telescope and instrument.
==> There is no concept of an 'queue instrument' -- one can associate OBs of
different instruments to the same queue.
For telescope, item 1398.


31) CRITICAL: maybe it's because I'm somehow tired or because it's
spring, but is there a way to display some more "sexy" colors, in
particular for the background !!! why this so sad grey, and characters
always in black !!!
Is it possible to put some more colors for OT boxes:
- a clear blue or while for background,
- instead of buttons with simple text, put graphical icons (for
instance, for copy, paste, move up, move down, ...).
- play with character color to separate (e.g. OBs which are yet in the
execution sequence, ...)
- add a symbol to say that current queue has been updated but not yet
saved,
In fact, I'm not only joking here, I really think we have to think how
to improve ergonomics
of our tools, because it's also very important.
A lot of things can be done here, I give you several ideas here,
but maybe a specific meeting should be organised for this topic ... ?
==> See my reply to point 26 above.
Yes, I think a review meeting is in order.


32) MINOR: DB browser: period list to be extended to 80 (limited to 70,
here).
==> Fixed.


33) MINOR: OT main box: File>New, then "Select telescope": a "cancel"
button is missing (the user
is forced to select a telescope and create a new queue, while he should
be able to decide not
to do it, afterwards).
==> "Cancel" button is hidden by pull-down menu.


34) CRITICAL: DB browser with SEGSRV12. Query all FORS2 OBS (with "OB
Type"=Observation).
Select then an OB (ID=107969), and click on "Selection>Delete OB(s)" ==>
following
error message "JZ006: Caught IOException: java.io.IOException: JZ0C0:
Connection is already closed"
and Java exception.
Notice that for several other OBs, no problem, it works fine.
DELETE FROM schedule_items WHERE ob_id in ( 107970 )
Key = ob
DELETE FROM exec_sequences WHERE ob_id in ( 107970 )
Key = ob
proc_uss_delete_ob 107970
java.sql.SQLException: JZ006: Caught IOException: java.io.IOException:
JZ0C0: Connection is already closed.
at com.sybase.jdbc.ErrorMessage.raiseError(ErrorMessage.java)
at com.sybase.tds.Tds.nextResult(Tds.java)
at com.sybase.tds.Tds.getCancel(Tds.java)
at com.sybase.tds.Tds.cancel(Tds.java)
at com.sybase.jdbc.SybStatement.doCancel(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.removeOB(DBUtil.java:249)
at org.eso.ohs.ot.util.DBUtil.removeOBs(DBUtil.java:230)
at
org.eso.ohs.ot.gui.OTViewManager$SelectionPopupListener.deleteOB(OTViewManager.java:703)
at
org.eso.ohs.ot.gui.OTViewManager$SelectionPopupListener.access$0(OTViewManager.java:698)
at
org.eso.ohs.ot.gui.OTViewManager$2.actionPerformed(OTViewManager.java:608)
at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1066)
==> Item 1403.


35) CRITICAL: one Queue opened, but not selected in the main OT box.
Then, File>Process reports
which opens a "Select Reports Files". First, was is strange is the
"enter path or folder name"
value here which is "1/dataflowJava". Then, I don't understand why the
"enter file name" field contains
"data" as value. And finally, if I click on OK, I get following Java
exception (but no error
message):
CLASS SwingFileChooser - getList: UIManager ID Motif
Exception occurred during event dispatching:
java.lang.NullPointerException
at
org.eso.ohs.ot.actions.ProcessReportAction.actionPerformed(ProcessReportAction.java:77)
at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1066)
at
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1101)
at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:378)
at
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:250)
at javax.swing.AbstractButton.doClick(AbstractButton.java:226)
at
javax.swing.plaf.basic.BasicMenuItemUI$MenuDragMouseHandler.menuDragMouseReleased(BasicMenuItemUI.java:718)
at
javax.swing.JMenuItem.fireMenuDragMouseReleased(JMenuItem.java:455)
at
javax.swing.JMenuItem.processMenuDragMouseEvent(JMenuItem.java:364)
at javax.swing.JMenuItem.processMouseEvent(JMenuItem.java:321)
at
javax.swing.MenuSelectionManager.processMouseEvent(MenuSelectionManager.java:267)
at
com.sun.java.swing.plaf.motif.MotifMenuUI$MouseInputHandler.mouseReleased(MotifMenuUI.java:136)
at
java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:227)
==> This menu item is related to manual processing of MMU report files
(MaskTracker).


36) HIGH: dump a queue: OK it creates as many obd files as OBs contained
in the queue. But a progress
bar is missing here: Paranal usually dump very large queues (with
hundreds of OBs), which may take
time and then requires the user to know how this operation is processed.
==> Fixed.


37) HIGH: several menu items not yet implemented, I guess it's for next
betas, isn't it ?
==> Yes


38) HIGH: QV, select an OB status is "C" (for instance), then
"OBs>Comments". By default, status displayed
by the "SetObserver Parameters" is P: why ? should not be "C", instead ?
Then, keep this "P" new value for the status, enter a grade value and a
comment and click OK: debug messages
seem to indicate the changes are performed. Reload the queue: OK QV grid
shows "P" as status for this OB,
but if I re-call "OBs>Comments", I don't see last values of grade and
comment I just entered.
Save this queue and again "OBs>Comments": still I don't last values of
grade and comment.
Finally, what are those "OBs>Comments" meant for and different from all
other usual comments
that can be entered with P2PP for an OB ?
==> Fixed.


39) HIGH: QV grid. Select an OB (it's then highlighted with blue).
Modify his status with OBs>Mark.
The status change is performed correctly and automatically re-displayed
(without having to refresh the QV grid with Reload or any manual
action), but it should be better
to still highlight the current OB. Indeed, this is a common rule for
ergonomics to still highlight
the last modified object to always know which one was last modified.
==> In fact, in the current beta (a) status change is *not* automatically
redisplayed, and (b) OB stays selected. Have to look into that: item 1405.


40) HIGH: QV grid: when clicking on a column header a sort is
automatically performed which
is very useful. It should be very nice if a new click perfoms a sort in
reverse order
(first click in ascending order, second click in descending order).
==> Another item for the DBB to-do list -- 1406.


41) MINOR: "added optional item DUMP.DIRECTORY in site.cf file": No
I don't see such keyword in my site.cf file (which is
under ~flowmgr/dfs/dataflowJava/config/ with the DFS installation
procedure,
not under ~/config). But I see a keyword called "PAF.DIRECTORY" ...
==> Yes, I need to document the new keywords. It's on my personal to-do list
since a long time, sorry.


42) HIGH: I had previously quit JOT, even logout from wg0arc.
And later on, re-login to wg0arc, run JOT in debug mode, enter the
username "0" and its pwd, then
following java exception raised.
Anyway JOT main box comes and I'm able to open a queue.
Quit JOT, and re-start, no more Java exception ...

Creating... tables tempdb..tmp_schedule_items tempdb..tmp_exec_sequences
Key = ob
....tables tempdb..tmp_schedule_items tempdb..tmp_exec_sequences already
defined into the DB
appname set to 'schedule'
CommandMonitor created for SCRIPT
cmd listener added
CommandMonitor created for EVENT
script listener added
CLASS SwingFileChooser - setCurrentDirectory: File = null
CLASS SwingFileChooser: Instanciating
CLASS SwingFileChooser: UIManager ID Motif
CLASS SwingFileChooser - getList: UIManager ID Motif
CLASS SwingFileChooser - setCurrentDirectory: File =
/diska/flowmgr/dfs-4_4_1-ot-2.1.4beta1/dataflowJava/data
Exception occurred during event dispatching:
java.lang.NullPointerException
at
javax.swing.plaf.basic.BasicDirectoryModel.getFiles(BasicDirectoryModel.java:84)
at
com.sun.java.swing.plaf.motif.MotifFileChooserUI$MotifFileListModel.fireContentsChanged(MotifFileChooserUI.java:544)
at
com.sun.java.swing.plaf.motif.MotifFileChooserUI$MotifFileListModel.contentsChanged(MotifFileChooserUI.java:549)
at
javax.swing.AbstractListModel.fireContentsChanged(AbstractListModel.java:82)
at
javax.swing.plaf.basic.BasicDirectoryModel.fireContentsChanged(BasicDirectoryModel.java:121)
at
javax.swing.plaf.basic.BasicDirectoryModel$DoChangeContents.run(BasicDirectoryModel.java:341)
at
javax.swing.SystemEventQueueUtilities.processRunnableEvent(SystemEventQueueUtilities.java:332)
at
javax.swing.SystemEventQueueUtilities.access$0(SystemEventQueueUtilities.java:328)
at
javax.swing.SystemEventQueueUtilities$RunnableTarget.processEvent(SystemEventQueueUtilities.java:369)
at java.awt.Component.dispatchEventImpl(Component.java:143812)
at java.awt.Component.dispatchEvent(Component.java:1744)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Furthermore, ps command gives:
wg0arc visitor:~ 505 > ps -ef | grep visitor
visitor 22110 22107 0 18:24:45 pts/5 0:00 ccsJanitor -p 22107 -s
46353 -n 25
visitor 23901 22024 2 18:30:37 pts/5 0:00 grep visitor
visitor 22101 22024 0 18:24:31 pts/5 0:00 jot
/diska/flowmgr/dfs/dataflowJava/bin/jot -debug
visitor 17404 17376 0 16:10:03 pts/4 0:00 -bash
visitor 23900 22024 2 18:30:37 pts/5 0:00 ps -ef
visitor 22107 22101 0 18:24:31 pts/5 0:05
/vlt/MAR2001/java/jdk-1.1.8/bin/PA_RISC/native_threads/jre -
visitor 22024 22022 1 18:22:52 pts/5 0:00 -bash
==> This happens intermittently with P2PP as but it doesn't seem to have any
practical consequence. We have no idea where it comes from... item 1407.


43) HIGH: a provocative suggestion ! why not merge the main OT box and
the QueueChooser one ?
Why these 2 separate boxes ? I suggest to have only one containing, by
default, ALL existing queues
associated to the current OT user, i.e. the current QueueChooser box
with the File and Edit menus
coming from the main OT box.
Furthermore, tis will make OT very similar to the P2PP GUI concepts.
==> This we did -- fixed.


44) HIGH: in the QueueChooser *always* set *by default* the last
modified queue
and *always keep it as selected* (until another queue is modified or
selected):
this simple improvement will make life much easier for users, in
particular when
they have to fetch OBs (with current implementation, they usually forget
to select
a queue before running a fetch, which is really boring sometimes).
==> In the new implementation at least one open queue is always selected. I
think your requirement is satisfied, please confirm.


45) MINOR: items 1026/1043: try to append a FORS2 OB to a FORS1 queue:
OK, it's refused as it should
with a warning message, but this message should be corrected: says
"Unable to append OB/CB
because the queues teplescope (UT2) is different to the OB/CBs (UT1)".
Better to say: "selected OB refers to queue UT1, while current queue
refers to another telescope (UT2):
append failed"
==> Fixed.


46) MINOR: some debug messages are not clear for me: e.g.
!!!!!!!!!!!!! @@@@@@@@@@@@ OB ID 10739003
!!!!!!!!!!! @@@@@@@@@ Temp id 10204107
or
!!!!!!!!!!!!! OB ID 10094103
@@@@ Printing out 100941
@@@@ Printing out 100942
are both repeated something like 100 times, just when entering a comment
for an OB (small queue
with only 3 OBs).
The Comment itself is correctly performed, but some debug messages may
need to be removed, isn't it ?
==> Those messages are only intended for the programmers, we cannot commit
to making them useful or consistent. Many of them are just junk, anyway,
and will be removed from the final beta.


47) MINOR: File>Dump works now, but naming OBD files is different
between P2PP and OT:
P2PP asks the user to enter a filename while OT creates a default one: I
would suggest
to have same schema here (since same people can use both P2PP and OT at
Paranal). The
default naming schema of OT sounds better, so I would suggest to
implement it on P2PP.
(another reason is that P2PP is currently not consistent: it requires to
enter a filename
for OBD, but creates default ones for IMPEX files). So, the less the
user has to enter
inputs, the better it is.
==> The naming scheme is different because P2PP dumps one OB at the time,
the OT many -- I don't see why we should reduce the flexibility offered
by P2PP. In any case, dumping OBDs is only meaningful to engineering
users, that is, "special" users.


48) CRITICAL: item 1166 is *not* fixed (OB status remained D after fetch
by BOB). Even after a fetch
(properly performed), status remains to D (instead of I) both in
Observation Blocks grid and in the
Execution sequence grid (QueueView box). But, it is set to I in the OB
display part (QV, too).
Furthermore, even if re-loading the queue (after the fetch), status
remains to D here.
Finally, with the DB browser, even if re-running a query, status remains
to D.
I set this issue as critical, not only High priority, meaning that
status changes
are not enough clear, then that we need to have up-to-date
specifications ...
==> Item 1166 reopened.


49) HIGH: item 0980 should not be considered as closed, since there are
still
several cases where Quit doesn't ask for saving modified queues (see my
previous
comments).
==> Fixed.


50) except items 116 and 0980, ALL other items listed in the V2.1.4beta1
Release note were checked by me, and seem to be correctly solved.
==> OK


51) I also tested transfer of OBs to BOB with the latest VLT MARCH2001
we have on wg0arc: no problem.
==> OK