|
Size: 1776
Comment:
|
Size: 1789
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| *This '''strong recommendation''' is to avoid any danger of the currently used script being abruptly modified without the knowledge of the test team. | *This '''strong recommendation''' is to minimise the possibiliy that the currently used script will be abruptly modified without the knowledge of the test team. |
| Line 7: | Line 7: |
| *''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. |
*'''''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 it when informed that a script is being modified. *When a '''''sftcode''''' script is ready to be moved to the operational database, the script author shall let me know or he/she be shown how to copy it to the operational database when his/her turn comes to be in the test team here at MPE. |
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 minimise the possibiliy that the currently used script will be 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 it when informed that a script is being modified.
When a sftcode script is ready to be moved to the operational database, the script author shall let me know or he/she be shown how to copy it to the operational database when his/her turn comes to be in the test team here at MPE.