|
Size: 1787
Comment:
|
Size: 1776
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| *Since the access to the operational database is not being denied to other users, '''''everybody shall refrain from amending/adding modules to the operational database''''' unless he/she is part of the test team. | *Since the access to the operational database is not being denied to other users, '''''CUS scripters shall refrain from amending/adding modules to the operational database''''' unless he/she is part of the test team. |
| Line 5: | Line 5: |
| *Those desiring to work on CUS scripts when not in ''commanding duty'' are requested to do so in the '''''sftcode''''' database, accessible as cususer@pacs1. | *Those desiring to work on CUS scripts when not in commanding duty shall do so in the '''''sftcode''''' database, accessible as cususer@pacs1. |
As mentioned in the page Setup to schedule CUS from TOPE only scripts stored in the operational database can be scheduled by TOPE.
Only the test commander is allowed to amend or add scripts directly on the operational database.
Since the access to the operational database is not being denied to other users, CUS scripters shall refrain from amending/adding modules to the operational database unless he/she is part of the test team.
This strong recommendation is to avoid any danger of the currently used script being abruptly modified without the knowledge of the test team.
Those desiring to work on CUS scripts when not in commanding duty shall do so in the sftcode database, accessible as cususer@pacs1.
- The operational database contains only modules that have been used or are about to be shortly used for IL tests.
sftcode, on the other hand, contains all the modules that have been developed over the course of time. Periodically or by demand, we (DAC) shall update sftcode with the contents of the operational database. In this manner, those who will reuse their modules for further ILT activities, will find them in sftcode as they exist in the operational database should they need any further correction before being reused.
In order to avoid that a freshly amended module in sftcode be replaced by the existing version in the operational database, I (DAC) shall not update sftcode from the operational database when informed that a script is being modified.
When a sftcode script is ready to be moved to the operational database, the script author will be shown how to copy it to the operational database when his/her turn comes to be in the test team here at MPE.