The process of uploading a Spec consists of
- Running Quality Assurance (QA) checks on the file
- Updating the 3GPP Specs Status Database, including
	- Uploading the new Spec file to the appropriate H drive location(s)
	- Synchronizing the public FTP server with the H drive
- Updating the web pages from the 3GPP Spec Status database


Running Quality Assurance (QA) checks on the file

The zip file of one or more specs to be checked must be placed in
\\Cu00000071\jmmdesktop\MCC_briefcase\SpecQaControl
(the computer name will need to be updated when the machine is upgraded, which happens from time to time)
or
C:\MCC_briefcase\SpecQaControl
if you are working on the computer which hosts the master database.

Open the master 3GPP Specs Status database and click on the "useful things" button. Then click on the "exotic admin functions" button (bottom right of the turquoise panel). The original form will close and the (red) admin functions control panel will open.

Open the record for the Spec in question, and check that a version record exists for the new version of the spec about to be uploaded. If necessary create that record.

Close the Spec record.

On the admin control panel, click the "check" button towards the bottom, in the area labelled "QA check new specs".

The database application will treat each waiting spec in turn, performing the following checks ...
...

The QA testing process is reported in the "currently doing" area of the admin form. A termination message is displayed when all files have been processed.

Specs which pass all tests will be moved to a subfolder "QaPass" of the above path.  Specs which fail one or more tests will remain in the original folder, and a text file describing the error(s) will be created in the same folder.

For failed specs, examine the error report and either fix the error(s) yourself or return it to the author for remedial action.  In the latter case, move the offending spec file and its error report file to the "rejected" subfolder.

After repair of the failed spec file, repeat the checking process as many times as necessary to make the spec pass the QA tests.

When checking of all specs to be processed is complete, move all spec files from the "QaPass" folder to 
H:\MCC\Staff\Meredith\incoming
(That is, copy them all to this location then delete from the QaPass folder.)

Note that no QA tests are run on draft specs: if the checking routine finds a spec not yet under change control, it is simply moved to the QaPass folder without checking.  Thus, for such draft specs, it is acceptable to bypass the QA check altogether, and move them directly to the "incoming" folder.

Note also that the QA check routines cannot (at the time of writing) handle specs composed of multiple Word files, as is the case for some very large Specs). These will consistently return an error message. You may of course do manual checks on these files. But move them directly to the "incoming" folder without attempting to conduct any further automatic checks.



Updating the 3GPP Specs Status Database with a new Spec version


On the computer which hosts the master database, open the Y:\ drive, supplying the necessary user credentials. These differ from the username and password needed to access the computer itself. Once successfully opened, you may close the windows explorer window for the Y:\ drive.

Open the database, then navigate to the spec in question and open its record using the "specs" button to the left of the spec number.

Navigate to the correct Release, either by clicking on the selector for the appropriate record on the Release form, or using the down (and up) arrow buttons on the top of the Version form. Navigate to the correct Version record.

On the Version record, double click on the field below the button labeled "New Specs inbox". (The field has a grey background.) This action will check that a file corresponding to the version of the spec in question exists in the "incoming" folder, and if so open a small form showing the date of receipt and copy the date shown in that form to the field in the version record.  If the "expert received" date is incorrect, set it to the desired date using the buttons on that form (today, tomorrow, yesterday) or by typing in the date; then repeat the double click on the grey date field on the version record.  Note that the double-click action will re-order the version records for the Release in question by descending version number.

If you wish to conduct any visual quality check on the new spec version - the automated QA checks above are not the be-all and end-all - you may do so.  When you have completed this optional step, double click the version record's "proof read" field, which will turn green (actually, the current date will be shown in green text on a green backgound, so you can check the contents of this field using shift-F2).

On the version record, double click the field labelled "uploaded". This will set the availalable date to the current date ("today") and copy the spec file to a holding bin.

If the spec is to be transposed by the SDOs, ie it fulfills the conditions of being 
a) under change control, 
b) pertaining to a frozen Release, and
c) not being a 3GPP-internal TR,
the "sent to EDM" field will be pale blue.  Double click the version record field "sent to EDM", causing the file to be copied to the ETSI DPC team's "standin" folder, and turning this record's field green (again, green text on green background).
Note: if you accidentally send for transposition a spec which should not be transposed, you can recover the situation by double clicking the header label "proof-read" to open the "standin" folder, where you can find and manually delete the file. Then manually erase the "proof-read" field for the version in question.

Now move the spec file from the "incoming" folder to the "done" subfolder by double clicking on the version record field labelled "nfa" (no further action). This will place a date-time stamp into the field.

You may record any MCC-internal remarks about the spec version in question in the right-most text field, just to the right of the "nfa" field.

When all (see important note below) specs in the current batch have been processed, click on the button "distribute specs" top right of the version form. This will open a separate utility programme labelled "Project1".

Note: if you have two or more versions of the same spec to process, proceed to the next step after you have processed each, else subsequents will overwrite previous ones, which will NOT be uploaded.

On the Project1 window, ensure that the correct meeting-related folder is shown, and if necessary correct it using the button "change meeting directory".

On the Project1 window, click the button "process spec files". A list of specs processed will appear in the information panel.  This button creates a DOS batch file which you may examine by clicking the "view batch file" button; you could potentially edit then save this batch file, but this should normally not be necessary, and this button can be ignored.

After the above step, the button "Copy files to internal network drive" will be enabled, and you should click it to run the batch file created above.

When that batch file has completed - and not before! - click the button "Reset for next batch of specs".  You can, if necessary, return and process more specs before proceding to the next step.

When all batches of specs have undergone the foregoing process, synchronize the public file server with the internal network drive by clicking the button "Copy internal to external 3GPP file server" button on the Project1 application. You may, if you wish, now close the Project1 window.

On the main Spec record (for any spec), click on the small button (writing pen icon) to the right of the URL field. This will, if necessary, update the URL field to point to the archive folder on the 3GPP file server for the spec, and will calculate the URL for the particular version just handled. After the routine is run, the "dwnload this version" button for the version record will acquire the legend "get it" and will be hyperlinked to the appropriate location. This routine actually processes ALL spec records, so need not be run after each and every spec has been handled.

Note that transferring Spec files to the public server requires that the Y:\ drive be accessible. This has a separate username and password from the normal ETSI network login, and must be expressly entered each time the computer hosting the master database is restarted.  This is described at the beginning of this procedure.



Updating the web pages from the 3GPP Spec Status database