SiteMap
Page Bottom  Documentation NewLeaf

SwimGold SitePlan

This webfolder provides context and specs which are a technical plan for continuing development of digital archives for United States Masters Swimming, Inc. The current version of the RFP is at www.SwimGold.org/committee/rfp/files.htm If you would like to print a copy of our full technical plan (or see it on one page), go to www.SwimGold.org/committee/rfp/siteplan.htm.

The principles underlying our plan are these:

  1. USMS has an exceptional asset in its archives and a desire to preserve that asset.
  2. Maintenance procedures have been developed using a very powerful language called APL because that was the best tool for the person doing the technical work and he was a volunteer desiring to use the best tools available to him.
  3. Preservation of the asset requires that all databases and text files be stored in text format so they can be imported into any other environment.
  4. We will begin a process whereby alternative procedures will be sought for doing some of the work of the H&A Committee so that there will be less dependence on the language APL.
  5. A user interface is needed so that existing procedures can be used by people other than their creator.
  6. The H&A Committee will maintain a general posture of only using its existing APL procedures in their current application or in natural extensions of it.
  7. The H&A Committee will document its procedures and cooperate with others who will aid in the process of integrating H&A work with work by other committees. This is expected to result in our procedures being rewritten in other languages in some cases.
  8. As alternative procedures are developed in USMS, we will use them wherever possible to aid their becoming refined and institutionalized.
This contract will be awarded to the proposal which best meets our minimal requirements while carrying us forward towards our vision.

Our minimal requirements are these:

  1. All our archives content must be exported to text files.
  2. Our maintenance programs must be revised so they keep our text files current in real-time.
  3. We need a user interface to help others use our existing archives maintenance programs.
(this report was created 4/ 4/07 16:38)

CONTEXT

This section of the RFP provides information that may be of help in understanding what we are doing and how we are doing it. If you are reading quickly to get the essence of this RFP, skip to "The Consultancy".

Background

The objectives of the USMS History and Archives Committee are to preserve and maintain USMS archives at an internet site and a secure physical location. Our digital archives reside at www.SwimGold.org where they were placed when Dorothy Donnelly and Carl House began working in 1995 to create a site where important USMS archive files would be safeguarded and available for viewing. The secure physical location is the Henning Library at the International Swimming Hall of Fame (ISHOF), where the paper originals and duplicate backups of electronic media and microfiche will be conserved and stored.

The archives currently consist of 6,531 webpages with 256,338 links connecting them (as of 2/13/02). All databases are internally consistent and up to date (with the exception of records). The database is managed under program control, not human labor (although research and some data preparation is still labor intensive). All of the systems development work was done with volunteer labor and donated professional services. USMS has never had to pay for an internet server or for programming related to our archives.

Our most difficult technical accomplishment has been to create and implement a "permanent swimmer id" which enables us to link together all the information we have on any one person despite name changes due to marriage, preferences which change from year to year, and, simply, errors. There are 11,876 people whose information is now tracked by this means (as of 2/13/02). Each year we receive approximately 20,000 new records of information for individuals plus additional information on relays. Information on individuals requires the addition of approximately 600 new names/ages to our list of permanent swimmer ids at each of three seasons each year. At present, we do not identify relay information with the swimmer id.

At present our digital archive system is comprised of 8398 files in 145 folders requiring 181mb of storage. In addition, we have 69 database tables with 83mb of data (?) and one file of programs for maintaining our archives (4mb).

It is our job now to move forward with thoughtful and orderly planning and conversion so that this work is integrated into USMS in an institutional way and so that nothing is lost. The goals of the History and Archive Committee by convention next year (Sept., 2002) are to have our databases all in conventional (text) formats and to have a user interface for the maintenance system so that people other than the creator can use it.

  1. The first task in the technical plan is to convert all the source files (tables and narrative text) into a conventional text formats. Databases and tables will be exported into comma delimited format (.csv) while narrative text will be exported into text files (.txt).

  2. In addition, the programs that manage the archives (written in APL) need to be converted so that they will work from the text files and conclude by updating the text files. This is for security purposes, so there is very little possibility of data ever being lost or unavailable to non-APL people. Backups to CD including all these files are made and distributed periodically.

  3. A user interface must be written so that people other than the creator of these systems can use them.

This could be achieved by many different strategies. It is our feeling that ultimately maintenance of our information should be done on the web, so it would be preferable that all work be done in a way that will transfer to the web in the easiest possible way. We should employ technologies that help us prepare for transfer to the web. In the meantime, our work can be done from a CD which allows us to closely control distribution of any sensitive files. The implementation of this could mean that all screen forms will be expressed in a format whereby they can be compiled either for Windows or for HTML. Minimal achievement in this regard will mean that they will be completed in either Windows or HTML. Possibly our screen forms will be completed in both, but only one format is required for this consultancy.

So, we have 3 fixes at this point: text files as source data including comma delimited for databases and text vectors for narrative information, Windows and/or HTML and/or Javascript/Jscript for screens, and APL as the language that our current maintenance system is written in.

We will keep in mind the desireability of completing all conversion work so that the systems assets of the H&A Committee can be used in 3 different environments,

  1. APL/Javascript/Windows/HTML/Active X and appropriate databases from a CD,
  2. APL/Javascript/HTML/Active X and appropriate databases on an NT Server, and
  3. APL/Javascript/HTML/Active X and appropriate databases on a Unix server.

All systems require ongoing maintenance, so it is not assumed there will be no future work required. But, it is hoped that the future maintenance work can be done by Carl and/or other members of the 3 related committees on a volunteer basis (H&A, R&T, Computer On-Line). Future maintenance will be an important consideration in awarding this contract.

Should USMS ever decide to convert to a permanent registration number or code, a great deal of the work in preparing for that transfer may have been done in this effort. Meanwhile, a permanent swimmer id is essential for maintenance of our archives.

The Vision

Our vision is far greater than the scope of this RFP, but it seems useful to articulate our vision as context for proposals.

Miscrosoft has said there are four core languages that will be on all computers: C#, C++, VB/VBScript, and Javascript/Jscript. We are recommending that H&A shift emphasis from APL to Javascript because Javascript will be in every modern Windows based computer on the planet and will be overwhelmingly pervasive on the Internet. We intend to simplify use of Javascript by creating a scripting language that will use procedures written in Javascript and sometimes in other languages. Use of other languages is especially sensible where fully functional code is already written in another language that can be used from Javascript. This includes fully functional code that has already been written in APL to manage USMS archives.

We're making progress in figuring out how to move History & Archives systems to become more "conventional" in accord with the HOD mandate from Louisville convention. Some of our ideas may not be sufficiently far along for implementation, but we thought it would be useful to articulate them as best we can today. What we have in mind is a scripting language that will provide utilities and that can be used from Access, C++, Javascript or whatever environment one chooses. We think it important that whatever we create be able to run either on the Internet or on one's home computer without an Internet connection. When running on the internet, it should run on a zero footprint basis, that is, requiring no installation; nothing will need to be installed on your hard drive. Our vision is that this will satisfy requirements for Top Ten processing software and other LMSC's, and it may lead the way to a future suite of programs for processing Top Ten by the R&T Committee. We first named it TTSscript, but it's easier to say TScript, so that's it's name now. It will be similar to Javascript, but far simpler. (Javascript is Microsoft's implementation of Javascript, freshly written to the same specs to avoid Sun's refusal to allow Microsoft to use the name Java in any form).

TScript will be a "very high level, very small" programming language. It will be designed to create reports, forms for data entry, and to do batch processing. It is intended to increase the productivity of programmers while being simple enough for use by non-programmers.

TScript will be built on Javascript, but I hope it will be so simple there is no need for anyone to understand Javascript to use TScript. TScript will be our way of making our software run both on the internet and in your home computer and it will allow USMS people to modify programs. We will create TScript as a special way of doing things in USMS and anytime we want to extend it we will do it in the Javascript way.

People who have used scripting languages like HTML will have no trouble using TScript. Also, people who are familiar with command line processing will have no trouble. Newcomers to programming may find it a bit of a challenge at first, but help will be available. And, a program will be developed that will write scripts according to the users specifications.

TScript is not designed to be a complete language. Instead, it is designed to empower users of other languages and databases by making available to them utilities written in other languages, including APL. One of the benefits of TScript is that programs written in it will run either on the internet or in a standalone computer under Windows. TScript programs will also be able to run in a home computer augmented by data available from the Internet.

About APL

USMS digital archives are stored in an unadorned state. In other words, they have no enhancement that represents a commitment to any computer language or technology (except for some simple html enhancement).

We process our archives for on-line presentation using a language called APL. This language has been chosen because it is a very powerful language and the Chairman of the H&A Committee (Carl House) is skilled with it. Ray Polivka [polivkar@juno.com] taught APL internally at IBM for 20 years and since retirement from IBM teaches APL to employees of other corporations. When asked for some words on APL, he offered this. "APL is especially effective not only because of its rich and sophisticated mathematical facilities but also because of its conciseness and consistency. These last characteristics are rare in programming languages. Its original design was done with the user and the application developer in mind. This makes APL a very fine prototyping tool. Today a programmer or nonprogrammer user can write an APL program and run it on a vast range of computers from large mainframes, servers to the smallest PCs under a variety of operating systems such as Windows XP-9x, 3.1 DOS, OS/2, Linux, Unix, MVT, MFT, Solaris. All of that is transparent to the APL program. Yes, of course when there is particular hardware to be used that is factored in gracefully. The APL world is a dynamic place today." Ray goes on to say "From my personal experience, I can tell you that there is APL use at IBM, Massachusetts General, Lincoln Life, Connecticut General, Morgan Stanley, Hartford Life, ICGM, AllState, and Cognos." Carl adds SoftMed Systems, Pacific Life, Ryder Systems, CheckFree, The Rouse Company, and Prudential Financial.

Microsoft announced on February 13 the availability of software it has spent $2 billion developing. This software focusses on the Internet and predictions are it will change life in America. An example of its use is this: When you are driving home during rush hour, the navigational system in your car will be able to check current driving conditions to find your fastest way home.

Microsoft has announced that this software will allow developers to work in any of 20 specific languages. The languages are listed alphabetically, so APL is first on the list.

Here's the story: www.pvmm.com/refer/dotnetstrategy.htm#apl. At the bottom of the story you click to see it on the NYT website.

Web Servers

USMS prefers that our archives be hosted on the same server used by USMS.org. At the present time, our archives are hosted on an NT Server. If there is good reason to remain on the NT Server, we can, but we would like to understand the reasons for staying there if it is proposed that we do so.

The SwimmerID

Making sure we've properly identified each swimmer is the toughest job in the management of our archives. The Top Ten process only gives us name and age of the swimmer (the LMSC field is not dependable). Names are often different from how they appear in the Registration file due to marriages, nicknames, whims and errors.

We maintain a permanent SwimmerID for each of the approximately 12,000 people who are included in our archives. We have a list of every name/age with which they've been recorded. When new information comes in, all those contained in the list are assigned the permanent SwimmerID. All names/ages which are not in our list are matched either in a guessing process or by serious research. Some errors are certain to persist in this process, but it is the best we can do until USMS Registration and Top Ten are administered with a universal permanent swimmer id.

The SwimmerID has three parts. The first 3 characters are the 3 most obscure letters of the last name. Characters 4 and 5 are birthyear. Characters 6 and 7 are birthday encoded with a function called "Date_code". This is documented in the function "SWIMMERID". In our databases, these three fields are called: Alphacode, Birthyear and Birthday.

Database connectivity

USMS has several important database systems.

The H&A Committee uses database and website maitenance tools created by Carl House using the language APL. These tools were required because our databases had no key field and included many misspellings, name changes, and other errors. We also knew there would be great variety in the nature of information we gathered and that it might be vast in quantity. We felt it important that our archives be stored with the least possible enhancement (raw content) and that our processing not be labor intensive. These are a set of special conditions that are not common to most database or website creation tasks.

There are few other users of APL in USMS, and volunteer labor is very important to how USMS gets things done. Therefore, we are committed to using tools that are in widespread use in USMS whenever we can.

The archives catalogue is a good example. That project is new. There are other tools available that will do the job. There is, therefore, no need to use APL. At present, the tool we are using is Excel, but that is likely to change in the future. At the present time, the APL compiler is reading the Excel file and creating an html page (without any importing or exporting). So, existing APL capability is being used to display the catalogue on-line, but APL is not being used to create or maintain the catalogue. APL performs a similar function in reading Gail Roper's Excel file of Olympians who have swum USMS and Mary Beth Windrath's file of Nat.Champ. meet results and Sandi Rousseau's file showing who has what Nat. Champ. meet results. In all 4 of these cases, the APL webpage compiler is reading the file exactly as it is being given to us without any importing or exporting.
/committee/archives.htm - Barbara Dunbar's archives catalogue.
/committee/olympians.htm - Gail Roper's list of Olympians in USMS.
/committee/champresults.htm - Sandi Rousseau's list of Nat. Champ. results.
/committee/natsdb.htm - Mary Beth Windrath's file of Nat. Champ. results

We've now moved all these items into one place and have hopes that Barbara will be able to improve how they are organized and that she will lead the creation of maintenance procedures for these databases and tables and catalogues. (She will need technical help.)
/committee/datatables.htm

Making Data Available

Currently data is available from static files and also in response to specific requests. Clearly, in the future we should make our data available from a web server in response to user query without human intervention. Proposals in response to this RFP may include such a provision, but this subject is not a required item in the RFP. We believe that others in USMS are well able to satisfy this desire.

Webpage Design

The template we are using for presenting information on the web is a separate subject from any issues related to how information is gathered, improved and stored. In order to make this point, on February 10 we changed most of our archive webpages so that they look very similar to the template used on the USMS.org website. On February 13 our on-line archives were changed back to the template we have been using (at the request of the USMS Webmaster). But, in this experiment we learned a few things.

One thing we learned is that there will be some adaptation required if we wish to make the USMS template work for our archives.

Here's how our experiment went. Our digital archives are organized in 35 folders. 26 of these folders readily accepted the USMS.org template. 9 folders will take a little more work to accept the USMS.org template because they have many pages and all pages are at the same level in menus. This can be solved by organizing swims by gender and age group, LMSC's by Zone and Clubs by LMSC to form two levels of menu structure.

We are gathering data in forms that do not require any particular presentation style or technology. The fact that it was easy to convert from the SwimGold style of presentation to the USMS.org style of presentation should establish that archive gathering & cleansing and archive presentation are different subjects, though we care deeply about both subjects.

Here are some specific requirements for the template we can use for presentation on the internet.

  1. USMS archives need two exploding or dropdown toolbars, one "global" (to the site) and one "local" to the folder. Our "global" menu is top right; our "local" menu is horizontal and under the larger smiling sun logo. USMS.org achieves two by placing a "local" menu on the the right when it is needed; the vertical left menu in the USMS.org template is a "global" menu.
  2. It's better to store the javascript in an "assets" folder rather than add it to the html page. We believe this reduces bandwidth, at least for websites organized like SwimGold is organized.
  3. Horizontal toolbars are better than a left menu because the left menu complicates printing. We believe printing is very important for archives webpages.
  4. The javascript we are using can be improved to work better on the Mac, to work better with older versions of Netscape (v 4.7), and maybe for other browsers as well. The javascript we are using is an older version and could be made more modern.

Storing race times

Our archives text files will store race times in the customary 1:23.45 or 23.45 format. However, many systems have difficulty handling the colon (Excel and dBase), so, if it is desired the H&A Committee will make available an alternative "cleansed" format when requested. This RFP does not need to deal with this.

The following was written by Leo Letendre and seems useful as a USMS convention. "I have written a number of programs which need to store time including 3 or 4 for swimming. When a data type has been available within the language which is time based (for example the VAX had a 64 bit date/time format with resolution of 100 microseconds) I have used that. On systems that do not have a time data type, I have generally found it easier to store it as either a real number or a string that looks like a real number. That is, it was stored in the form of 123.45 for 1:23.45. The reason I chose this format is based upon ease of manipulation. Yes, I had to remove any formatting when accepting input and add it when I printed the time but everything else in between was simplified. If I had to convert from real number to string, string to real number, convert from SCY to SCM, sort, etc, I did not have to worry about formatting (eg. for a 100 free, making sure the 59.99 had a : in from if it all of the time so that it would sort correctly). As far as someone looking at the internal representation I would suggest that the number of people who really need to worry about it is limited and should be able to read 123.45 for what it is." (Leo Letendre)

Future maintenance

It is expected that future maintenance will be provided by the "Client" with significant contribution to documentation by "Users". We will also cooperate with others in USMS who may develop software in other languages which can supplement or replace our current software.

Other

URLs (uniform resource locators, a web site's address) and web page names should remain constant as much as possible so that search engines, links, and "favorite places" continue to work.

APL computer systems in use by the H&A Committee use proprietary utilities and subsystems that have been developed by Carl House during his several decades of consultancy in development economics. Any improvements or adaptations to these utilities to aid in their use by USMS does not constitute a change in ownership. Permission is granted to USMS for the use of any of these utilities and subsystems for as long as USMS wishes, including the waiving of any license fees that might be required by Carl House or his assigns now or in the future for the use of these proprietary systems by parties other than USMS. If in this consultancy, it is proposed that any other proprietary software is to be used, then any required license fees or other payments must be part of the cost proposal (bid). If any liability for future license fees might be incurred by USMS in this consultancy, then the consultant is required to give appropriate notice to USMS as soon as such liability becomes a possibility. USMS reserves the right to refuse to allow the use of any software that might require future license fees or royalties that is not divulged in the original cost proposal and included in the consultancy contract.

THE CONSULTANCY

This contract will be awarded to the proposal which best meets our minimal requirements while carrying us forward towards our vision.

Our minimal requirements are these:

  1. All our archives content must be exported to text files.
  2. Our maintenance programs must be revised so they keep our text files (.txt & .csv) current in real-time on a webserver.
  3. We need a user interface so others can help in the maintenance of our digital archives.

For purposes of this RFP, the following terms are defined.

Data to be exported - the RFP

A Request for Proposals (RFP)

This is a request for proposals for converting a database presently stored in APL .sf files to text formats. The database is the source data for a very large website SwimGold.org which serves as the digital archives of United States Masters Swimming, Inc. (USMS) (181 mb, 8404 files, 145 folders).

The export procedure should be automated so it can be easily repeated at a later time. Maintenance of the APL files will continue while USMS develops a strategy for enterprise database management. The structure and scope of USMS digital archives will not change during the several months required to develop an enterprise database strategy, though data will be added within the current scope and structure.

The source files reside on a PC running Windows 2000 Professional and are processed with programs written in APL+Win version 4.0. It is our belief that knowledge of APL is essential to undertaking this consultancy.

Data currently stored as text vectors should become .txt files. Data stored as matrices with fixed width fields should become .csv (comma delimited files -- the data contains no commas). The new text files will be stored in the same directory structure as their web counterparts, so there will be no name conflicts. This means that the 145 folders in \SwimGold\ will be mirrored with 145 folders in \Archive\. (The actual number of folders will be less because many folders only have graphics for which no conversion is needed and other folders are only used to syncronize the local site with the server.)

Some level of documentation may be helpful to enable others to use the text files. Perhaps a catalogue in both digital and paper format is desired, but it may not be necessary if folder structure and file names are sufficient to provide documentation. The proposal should consider this. The proposal should also consider how we can be assured that the text version of the database includes all of the data items in the APL version. Control should be provided for on the number of items and perhaps on some sort of "checksum". This RFP does not require any consideration of the software needed for maintaining the database, nor for anything equivalent to a dBase header or other file control or pointer system other than whatever catalogue might be proposed.

File naming conventions will be important to making it possible that this facility and its catalogue will be self-maintaining as much as possible. The following is the naming conventions for most Top Ten files prepared for the web. All text files created in this consultancy should follow some variation of this naming scheme and the resulting naming scheme should be carefully documented and followed.

Top Ten files prepared for the web have names with 8 characters.

  1. "t" or gender if not both: "m"=men; "w"=women.
  2. "t" or course if not all 3: "s"=SCY; "l"=LCM; "i"=SCM ("international").
  3. year.
  4. year, e.g. year uses 2 characters in the form "99" for "1999".
  5. type: "i=individual; "r"=relay.
  6. sanctioning body: "u"=usms; "w"=fina.
  7. age group.
  8. age group: age group is identified by the lower end of the age group, e.g. 35=35-39.

The ambiguity in the above paragraphs is intentional. It is intended to give the consultant latitude in proposing how best to serve USMS. It is expected that proposals will NOT be ambiguous and USMS protection rests in the comparative evaluation of proposals, in the contract procedure, and in the evaluation of deliverables.

No conversion is to be made of image files, but where they appear in SwimGold they should be copied into the corresponding folder in "Archive". Documentation of image files is not within the scope of this consultancy.

Files which must be exported are listed here. If the "#records" is zero, then it is a file of narrative data and each "file component" is a text vector. File component numbers must be offset by one as the file component structure is zero origin. Where data has fields, they are shown. Where fields have fixed width, the width is shown in parenthesis after the field name. Someday our databases will be able to have a single field to identify the swimmer (when we have a permanent swimmer id used in Registration and R&T). In anticipation of that day, exported files should place all fields that identify the swimmer last with the SwimmerID first among those. Someday in the future we will be able to truncate our databases to include only data up to the SwimmerID. In addition, the "Record" field should be eliminated from Top Ten files (4211-4227). Our APL files include a header equivalent to a dBase header. Data is always included after the header, so if a file has 120 components and 70 data items that means the header occupies the first 50 components. Further clarification will be available from the Client (H&A Chairman) during the consultancy if needed. Files in "Archive" will not match files in "SwimGold" one-to-one because "Archive" will not include some files generated from other data, some clarifying files, and, most importantly, because Top Ten core databases should organized by season (3 per year) while "SwimGold" web files are by age group and the current Top Ten APL source files are by year (4211-4227).

Data Flow

The Core Databases

Top Ten by Age (since 1993)
•  file descriptor= USMS Individual Top Ten -- 1993 ; file name= F4211.sf; size in bytes= 1270676 ; last modified= 3/22/02 21:48:03.326; FCNs= 21-1565 file#= 4211 ; #FCNs= 1545 ; #records= 13327 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 1994 ; file name= F4213.sf; size in bytes= 1282412 ; last modified= 3/22/02 21:48:04.078; FCNs= 21-1561 file#= 4213 ; #FCNs= 1541 ; #records= 13480 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 1995 ; file name= F4215.sf; size in bytes= 1340840 ; last modified= 3/22/02 21:48:05.800; FCNs= 21-1561 file#= 4215 ; #FCNs= 1541 ; #records= 14209 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 1996 ; file name= F4217.sf; size in bytes= 1294908 ; last modified= 4/09/02 10:48:39.637; FCNs= 21-1573 file#= 4217 ; #FCNs= 1553 ; #records= 13616 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 1997 ; file name= F4219.sf; size in bytes= 1587456 ; last modified= 4/10/02 16:56:43.546; FCNs= 21-1529 file#= 4219 ; #FCNs= 1509 ; #records= 17353 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 1998 ; file name= F4221.sf; size in bytes= 1782904 ; last modified= 3/14/02 08:52:02.545; FCNs= 21-1553 file#= 4221 ; #FCNs= 1533 ; #records= 19761 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 1999 ; file name= F4223.sf; size in bytes= 1786224 ; last modified= 3/22/02 21:48:08.193; FCNs= 21-1560 file#= 4223 ; #FCNs= 1540 ; #records= 19792 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 2000 ; file name= F4225.sf; size in bytes= 1806704 ; last modified= 4/09/02 10:48:41.700; FCNs= 21-1559 file#= 4225 ; #FCNs= 1539 ; #records= 20045 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4).
•  file descriptor= USMS Individual Top Ten -- 2001 ; file name= F4227.sf; size in bytes= 1961152 ; last modified= 4/10/02 16:56:44.257; FCNs= 21-1549 file#= 4227 ; #FCNs= 1529 ; #records= 19812 ; fields= 1.Name (17) , 2.Age ( 3) , 3.space ( 1) , 4.LMSC ( 2) , 5.CLUB ( 4) , 6.Time ( 9) , 7.Record ( 2) , 8.Place ( 2) , 9.space ( 1) , 10.SEX ( 1) , 11.space ( 1) , 12.Agegrp ( 7) , 13.space ( 1) , 14.Stroke ( 4) , 15.Distance ( 5) , 16.Course ( 3) , 17.space ( 1) , 18.Date ( 6) , 19.space ( 1) , 20.Alphacode ( 3) , 21.Birthyear ( 2) , 22.Birthday ( 4). Current files are by year including all three seasons; "Archive" text files must be separated by season.
Top Ten Relays (since 1998)
•  file descriptor= USMS Top Ten Relays <\swimgold\tt\relays >; file name= F4521.sf; size in bytes= 1364500 ; last modified= 4/02/02 17:37:13.483; FCNs= 51-64 file#= 4521 ; #FCNs= 14 ; #records= 0 . Relays are probably same as received from R&T, but should be provided for.
All-Americans (since 1972)
•  file descriptor= USMS All-Americans (since 1972) (PGS_DB RECAP) <\swimgold\tt\aah >; file name= F4510.sf; size in bytes= 2437604 ; last modified= 4/10/02 19:42:28.636; FCNs= 53-82 file#= 4510 ; #FCNs= 30 ; #records= 11828 ; fields= 1.Alphacode ( 3) , 2.Birthyear ( 2) , 3.Birthday ( 4) , 4.SEX ( 1) , 5.space ( 1) , 6.LNAME (20) , 7.FNAME (20) , 8.MI ( 1) , 9.CITY (20) , 10.STA ( 2) , 11.ZIP (10) , 12.space ( 1) , 13.LMSC ( 2) , 14.space ( 1) , 15.CLUB ( 4) , 16.Age2000 ( 3) , 17.Sport ( 2) , 18.space ( 4) , 19.Agegrp ( 7) , 20.AAYear ( 4) , 21.Age ( 3) , 22.space ( 1) , 23.Name (23).
All-Stars (since 1987)
•  file descriptor= USMS All-Stars <\swimgold\tt\ash >; file name= F4519.sf; size in bytes= 135576 ; last modified= 4/08/02 11:02:04.067; FCNs= 53-82 file#= 4519 ; #FCNs= 30 ; #records= 613 ; fields= 1.Alphacode ( 3) , 2.Birthyear ( 2) , 3.Birthday ( 4) , 4.SEX ( 1) , 5.space ( 1) , 6.LNAME (20) , 7.FNAME (20) , 8.MI ( 1) , 9.CITY (20) , 10.STA ( 2) , 11.ZIP (10) , 12.space ( 1) , 13.LMSC ( 2) , 14.space ( 1) , 15.CLUB ( 4) , 16.Age2000 ( 3) , 17.Sport ( 2) , 18.space ( 4) , 19.Agegrp ( 7) , 20.AAYear ( 4) , 21.Age ( 3) , 22.space ( 1) , 23.Name (23).
USMS Records (current only)
•  file descriptor= USMS Records <\swimgold\records\usms >; file name= F4536.sf; size in bytes= 733716 ; last modified= 4/02/02 17:37:09.627; FCNs= 56-157 file#= 4536 ; #FCNs= 102 ; #records= 1836 ; fields= 1.SEX , 2.Agegrp , 3.Distance , 4.Course , 5.Stroke , 6.Name , 7.Date , 8.Time . USMS records are out of date, but they should be provided for.
FINA Masters World Records
•  file descriptor= FINA Masters World Records <\swimgold\records\fina >; file name= F4535.sf; size in bytes= 441996 ; last modified= 4/02/02 17:37:07.814; FCNs= 56-119 file#= 4535 ; #FCNs= 64 ; #records= 1120 ; fields= 1.SEX , 2.Agegrp , 3.Distance , 4.Course , 5.Stroke , 6.Name , 7.Country , 8.Date , 9.Time . FINA records are out of date, but they should be provided for.
Remembering USMS All-Americans
•  file descriptor= Remembering USMS Swimmers <\swimgold\remember >; file name= F4517.sf; size in bytes= 62684 ; last modified= 4/27/02 23:29:56.999; FCNs= 0†0½1 file#= 4517 ; #FCNs= 0 ; #records= 0 ; fields= 1.Alphacode ( 3) , 2.Birthyear ( 2) , 3.Birthday ( 4) , 4.SEX ( 1) , 5.space ( 1) , 6.LNAME (20) , 7.FNAME (20) , 8.MI ( 1) , 9.CITY (20) , 10.STA ( 2) , 11.ZIP (10) , 12.space ( 1) , 13.LMSC ( 2) , 14.space ( 1) , 15.CLUB ( 4).
The SwimmerID Registry (this is kept consistent with the Registration file)
•  file descriptor= Official Registry for the USMS Permanent Swimmer ID; file name= F4260.sf; size in bytes= 1125984 ; last modified= 4/20/02 22:28:26.928; FCNs= 21 file#= 4260 ; #FCNs= 1 ; #records= 12198 ; fields= 1.Alphacode ( 3) , 2.Birthyear ( 2) , 3.Birthday ( 4) , 4.SEX ( 1) , 5.space ( 1) , 6.LNAME (20) , 7.FNAME (20) , 8.MI ( 1) , 9.CITY (20) , 10.STA ( 2) , 11.ZIP (10) , 12.space ( 1) , 13.LMSC ( 2) , 14.space ( 1) , 15.CLUB ( 4).
The Preferred Names File (this overrides the Registration file, as to preserve nicknames & middle initials)
•  file descriptor= Preferred Names for Archives (inc. nicknames & MI); file name= F4250.sf; size in bytes= 8968 ; last modified= 3/28/02 12:39:34.958; FCNs= 21-44 file#= 4250 ; #FCNs= 24 ; #records= 48 ; fields= 1.Alphacode ( 3) , 2.Birthyear ( 2) , 3.Birthday ( 4) , 4.SEX ( 1) , 5.space ( 1) , 6.LNAME (20) , 7.FNAME (20) , 8.MI ( 1) , 9.CITY (20) , 10.STA ( 2) , 11.ZIP (10) , 12.space ( 1) , 13.LMSC ( 2) , 14.space ( 1) , 15.CLUB ( 4).
Support tables for LMSC names, e-mail addressses, etc.
•  file descriptor= Swimming - LMSC Web Links (move 4149 FCNs 3 4 5 to file 4151); file name= F4151.sf; size in bytes= 53008 ; last modified= 4/21/02 22:10:10.859; FCNs= 11-14 file#= 4151 ; #FCNs= 4 ; #records= 174 .
All Names/Ages in Top Ten Since 1993 with assignment to SwimmerID (these could be reduced to 1 file)
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 1993 Ages; file name= F4281.sf; size in bytes= 2087728 ; last modified= 4/18/02 12:13:36.243; FCNs= 21 file#= 4281 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 1994 Ages; file name= F4282.sf; size in bytes= 2087728 ; last modified= 4/18/02 12:13:36.694; FCNs= 21 file#= 4282 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 1995 Ages; file name= F4283.sf; size in bytes= 2087732 ; last modified= 4/18/02 12:13:37.125; FCNs= 21 file#= 4283 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 1996 Ages; file name= F4284.sf; size in bytes= 2087784 ; last modified= 4/18/02 12:13:37.645; FCNs= 21 file#= 4284 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 1997 Ages; file name= F4285.sf; size in bytes= 2087712 ; last modified= 4/18/02 12:13:31.567; FCNs= 21 file#= 4285 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 1998 Ages; file name= F4286.sf; size in bytes= 2087712 ; last modified= 4/18/02 12:13:32.047; FCNs= 21 file#= 4286 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 1999 Ages; file name= F4287.sf; size in bytes= 2087712 ; last modified= 4/18/02 12:13:32.618; FCNs= 21 file#= 4287 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 2000 Ages; file name= F4288.sf; size in bytes= 2087712 ; last modified= 4/18/02 12:13:33.059; FCNs= 21 file#= 4288 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).
•  file descriptor= Swimmers Who Have Made USMS Top Ten with 2001 Ages; file name= F4289.sf; size in bytes= 2087712 ; last modified= 4/18/02 12:13:33.940; FCNs= 21 file#= 4289 ; #FCNs= 1 ; #records= 22169 ; fields= 1.LNAME (20) , 2.FNAME (20) , 3.MI ( 1) , 4.BDATE ( 8) , 5.SEX ( 1) , 6.LMSC ( 2) , 7.CNUM ( 3) , 8.CLUB ( 4) , 9.space ( 1) , 10.Name (17) , 11.Age ( 3) , 12.space ( 1) , 13.Chapter ( 4) , 14.Alphacode ( 3) , 15.Birthyear ( 2) , 16.Birthday ( 4).

Compiled Information About Individual People, LMSCs & Clubs

All-Americans Ever (by swimmer)
•  file descriptor= USMS - All-Americans Ever <\swimgold\tt\aae >; file name= F4515.sf; size in bytes= 893080 ; last modified= 4/27/02 15:13:09.528; FCNs= 58-84 file#= 4515 ; #FCNs= 27 ; #records= 0 .
All-Stars Ever (by swimmer)
•  file descriptor= USMS - All-Stars Ever <\swimgold\tt\ase >; file name= F4514.sf; size in bytes= 141432 ; last modified= 4/08/02 11:02:04.207; FCNs= 58-84 file#= 4514 ; #FCNs= 27 ; #records= 0 .
Top Ten Index (by birthday)
•  file descriptor= USMS Top Ten Index <\swimgold\tt\ndx >; file name= F4506.sf; size in bytes= 4169416 ; last modified= 4/18/02 21:58:14.223; FCNs= 52-136 file#= 4506 ; #FCNs= 85 ; #records= 0 .
Top Ten Names
•  file descriptor= USMS Top Ten Names <\swimgold\nms >; file name= F4507.sf; size in bytes= 876876 ; last modified= 4/22/02 12:18:13.495; FCNs= 52-78 file#= 4507 ; #FCNs= 27 ; #records= 8941 .
Summary by Club
•  file descriptor= USMS Clubs <\swimgold\clubs >; file name= F4524.sf; size in bytes= 141612 ; last modified= 4/20/02 22:28:25.246; FCNs= 57-271 file#= 4524 ; #FCNs= 215 ; #records= 0 .
Summary by LMSC
•  file descriptor= All-Americans Ever by LMSC <\swimgold\lmsc >; file name= F4518.sf; size in bytes= 42548 ; last modified= 4/02/02 17:36:59.032; FCNs= 57-110 file#= 4518 ; #FCNs= 54 ; #records= 0 .

Beyond Data

Text & Images

Stories about USMS Swimmers
•  file descriptor= Stories about USMS Swimmers <\swimgold\sto >; file name= F4526.sf; size in bytes= 1172680 ; last modified= 4/27/02 15:04:37.052; FCNs= 51-303 file#= 4526 ; #FCNs= 253 ; #records= 0 .
The History Project
•  file descriptor= USMS History <\swimgold\hist >; file name= F4516.sf; size in bytes= 502836 ; last modified= 4/21/02 22:10:11.620; FCNs= 51-136 file#= 4516 ; #FCNs= 86 ; #records= 0 .
The Oral History Project
•  file descriptor= USMS Oral History <\swimgold\oralhist >; file name= F4528.sf; size in bytes= 160260 ; last modified= 4/21/02 16:56:32.830; FCNs= 51-92 file#= 4528 ; #FCNs= 42 ; #records= 0 .
Swimming Esthetics
•  file descriptor= Swimming Esthetics <\swimgold\esth >; file name= F4523.sf; size in bytes= 54556 ; last modified= 4/20/02 22:28:23.964; FCNs= 51-59 file#= 4523 ; #FCNs= 9 ; #records= 0 .
Top Ten Photo Gallery
•  file descriptor= Top Ten Photo Gallery (4481 4527 4227) <\swimgold\pix >; file name= F4527.sf; size in bytes= 292944 ; last modified= 4/27/02 15:04:35.629; FCNs= 61-75 file#= 4527 ; #FCNs= 15 ; #records= 0 .

Other

Top Ten Process
•  file descriptor= USMS History & Archives Committee <\swimgold\committee >; file name= F4529.sf; size in bytes= 549508 ; last modified= 4/27/02 15:04:36.240; FCNs= 51-172 file#= 4529 ; #FCNs= 122 ; #records= 2191 .
Top Ten Home Page
•  file descriptor= USMS Top Ten <\swimgold\tt >; file name= F4504.sf; size in bytes= 367776 ; last modified= 4/21/02 17:44:34.183; FCNs= 58-113 file#= 4504 ; #FCNs= 56 ; #records= 2800 .
SwimGold Home Page
•  file descriptor= USMS Archives Website <\swimgold >; file name= F4511.sf; size in bytes= 67568 ; last modified= 4/21/02 16:56:32.610; FCNs= 51-64 file#= 4511 ; #FCNs= 14 ; #records= 245 .

Deliverables

Deliverables are three in number and shall be completed in the sequence shown below. Deliverables will be evaluated by designated USMS people within one week of delivery. USMS will designate several evaluation people so if one person is too busy to perform evaluation, others will do so. The H&A Chairman and Vice-Chairman are committed that they will complete their evaluation within the one week time period.

Data

A compact disk shall be created which contains text versions of all SwimGold data. All data shall be organized in subfolders corresponding to subfolders in SwimGold except that the folder below root will be named "Archive" rather than "SwimGold". This should be delivered as 3 copies as quickly as possible for review by USMS people. At conclusion of the consultancy, ten copies will be delivered which include software.

Software

The automated export procedure shall be written so that it senses the complete structure and contents of SwimGold and, if it does not exist, creates "Archive". If "Archive" already exists, the export procedure shall prepare for export every item of data in "SwimGold" and, if it is different from the corresponding item in "Archive", it will replace the "Archive" file. If the new file is not different from the existing file, then it should not overwrite the old file. This is important to protect the date time stamp on the file. The software shall include an install procedure so that it can be used by anyone authorized by USMS to update the "Archive" text files from the normal backups of History & Archives data maintained by the H&A Committee or by anyone with access to the main computer used by the H&A Committee Chairman. The software shall include any required run time system. The export software completed in this consultancy is expected to run on a PC running under Windows 98 or later.

Documentation

This RFP calls for an export structure which is to a great extent self-maintaining. However, whatever documentation is needed to install and operate the "Archive" maintenance procedures shall be included.

Directions for Submissions of Proposals

Proposals should be delivered by April 1, 2002 to Carl House, 5871 Bartram Street, Boca Raton, Florida 33433 by either U.S. mail or by e-mail to Carl House or Carl House. His telephone number is 561-368-7445. An e-mail receipt will be sent confirming receipt of each proposal, so include the appropriate e-mail address in the proposal package.

Modifying APL programs

Existing APL programs must be revised to work from text files and to update text files automatically when they complete executing. The Client will work with the Consultant to achieve this. The Consultant should assume that these functions are working properly. If any bugs or inadequacies in pre-existing programs are discovered during this consultancy, it is the Client's job to fix them.

User interface

A user interface must be created that will permit the User(s) to execute all functionality necessary to maintain the archives databases and website. While most functionality already has working APL programs, there will be some functions that will require more work by the Client. However, any function that will be required by the user must be provided for in the user interface. The user interface may be entirely in Windows, or entirely in javascript, or both. Please see Vision.

A complete list of the top level of menus in the user interface and the functions in each top level group will be added to this RFP before it is made public. They will be presented in some detail in Critical Procedures.

Deliverables

Deliverables will be provided in several stages.
  • As soon as they are available, text files and the catalogue should be delivered as 4 copies of a CD for review by others in USMS. Additional copies will be required after review is complete.
  • The second deliverable will be functions revised in collaboration with the Client so that they work from and update text files whenever they are used.
  • The third deliverable will be a user interface which allows User(s) to do the work that heretofore has been done by the Client.
  • The fourth deliverable will be whatever documentation of our systems seems appropriate for the Consultant to write. Further documentation will be written by the Client and by User(s). The documentation to be delivered should be spelled out in the proposal.

CRITICAL PROCEDURES

This is a list of the critical procedures and functions used in maintaining USMS Archives at present. Most of these do not need to be addressed in proposals written in response to the USMS H&A RFP. They are listed for reference and to begin the documentation process both for Committee and/or User activity and for others who may wish to rewrite or acquire these facilities in a better way. This list of procedures will not be carefully documented for the RFP, but they must be included in the User Interface and in documentation. In general, it is the Client's job to assure that these work properly, though in a few cases the Consultant may be requested to consider solving certain problems. Each procedure to be included in the user interface will be identified from the list below. For planning purposes, the following is suggested. If the proposal is a Windows MDI solution, the MDI form will have 7 child forms each of which will call 3 to 12 procedures. The child forms will have names like: e.g. File, Edit, View, Process, Review, Tools, Help. Further refinement of this list may be made before the RFP is publicized. It is expected that the "Client" will modify the user interface as it evolves on the basis of the experiences of "Users".
(100.....) Steps that precede the use of the registrar file: Top Ten
(120....U) determine where data will go, build files if needed, or EMPTYFILE
(........).. fcns needed are 0 (21 rows), 1 4 5 7 9 11 12 13 14
(140....U) make sure 4200 3 is right, & hardwired TNF„ in IMPORTWALT
(160....U) run EMPTYFILE for best protection against errors
(180....U) ImportTopTen IMPORTWALT
(180.03..) identify destination files (TNS[;1]=individual, TNS[;2]=relay)
(180.06..) identify source file(s) and key variables
(180.09..) identify next source file to process within loop of source files
(180.12..) obtain data for current source file
(180.15..) convert delimited literal vector to a nested array
(180.18..) add columns for missing fields
(180.21..) split Name into FNAME MI LNAME
(180.24..) delete number sign and leading zeros from Place
(180.27..) extract MI from FNAME
(180.31..) combine FNAME MI LNAME into Name
(180.33..) define Distance, Course, Stroke from Event Number
(180.36..) define Agegrp from Age
(180.39..) convert SEX from integer to alpha
(180.42..) assign SwimmerID, LMSC, Club from the SwimmerID registry
(180.45..) ensure required fields are in incoming data
(180.48..) identify swimmers not in SwimmerID Registry & add them
(180.51..) protect existing LMSC data where empty cell will overwrite
(180.54..) make sure leading zeros are present on Birthyear if SwimmerID exists
(180.57..) add a space in case it is needed
(180.59..) loop thru each SEX/Agegrp/Event to place data on html support file
(180.63..) sort by "Time" & post "Place" (handling ties)'
(180.66..)
(180.69..) write data to appropriate place for storage
(180.72..) build FDIR based on FMV[16]
(.......U) TTDBUTIL © make sure place is ¼1†½M in every FCN, to verify the import process
(........).. cannot be run again later, this is to catch Pieter's mistakes after import
(.......U) TTDBUTIL © not defaults, insert "Place" & impose conventions (elim lead 0's)
(.......U) remove periods in LNAME FNAME Name fields & "DUS" (must revise to do this)
(.......U) make sure settings on what is "preliminary" are correct (4200 14) 1999LCM ; TTDBEXPORT[344]
(........) make sure LMSC designations in Pieter's file are not lost where they do not exist in 4289
(........) a newly imported file still must have POSTTEAM run to allow comparison to prior file
(........) preliminary Top Ten run at this point (TTDBEXPORT) required 2 hours for 1999LCM 11/9/99,
(200.....) Steps that precede the use of the registrar file: other core databases
(220....U) AAH_UTIL for files /aah/ and /ash/ (4510 & 4519)
(300.....) Steps that use the registrar file
(320....U) USMS_REG: import USMS Registrar file via dBASE‘IMPORT & place in TNT (if new Reg file)
(........) see instructions in the fn: USMS_REG
(........) SWIMMERID to assign duplicated swimmer ids & SEX errors in Registrar file
(........) more work to do to handle dups & handle all troublesome 4253 4254 4255 4256
(340....U) make sure all names/ages in 4285,
(360....U) MOVE_DATA_ uses MOVE_DATA_M (move data in one batch based on SwimmerID)
(........) FIXSWIMMERID & MOVE_DATA_ may be to be run in iteration while fixing swimmer ids
(.......U) USMS_REG is the procedure for importing REGISTRAR files (also tells how to clean it up)
(........) REGISTRAR (to carefully match names & select SwimmerID)
(380....U) LMSC & club in, & then
(400.....) Steps that follow use of the registrar file
(410....U) update FLS_TTDB
(420....U) create files 4111 4406 per files movings fcns 1 4 5 8 20 & 1
(........).. add new files 4221 4222 to 4200 3 for POSTTEAM in manner of ¯2+
(........) update lines 28-33 of TTLMSCDATA for new files (if new year)
(........).. prepare file 4242 to accept the database from file 4221
(440....U) POSTTEAM (if no new Registrar file, then POSTTEAM only changes new names in 4289)
(460....U) create file 4112
(462.....) TTLMSCDATA
(464....U) TTDBEXPORT (run at end of POSTTEAM for det, lmsc & age if needed)
(........).. SWIMMER © post the database to file 4242
(470....U) (run at end of POSTTEAM if needed)
(490.....) update 4200 5 & 6 (if new year)
(.......U) add another year to home pages for cgi files (4501 4502 4503) (if new year)
(.......U) every year WWW_TT_LMSC must be run to add a new year to /tt/ LMSC pages
(........) was probably written out to each 4504,FCN by WWW_TT_LMSC
(500.....) Data tables derived from the core databases
(510....U) TTDB_HTM_INDEX
(520....U) TTDB_HTM_NAMES
(540....U) AAH_UTIL for files /aae/ and /ase/ (4515 & 4514)
(560....U) ALLAMERICANS TTDB_MinText (especially important to run 3rd part if there is a SwimmerID change)
(580....U) AATTDBMENU (creates list of #1 swims & AA menus by LMSC & Agegrp)
(600.....) Compiling webpages that are dependent on the databases
(610....U) qkw_Master
(640....U) qkw_htm_xref 0
(660....U) make sure all valid swimmer ids in file 4289 are in file 4260
(700.....) Cataloguing images (including annotation, ImageCatalogue)
(740....U) PHOTOGALLERYMENU
(760....U) WWWUTIL post summary of FMV vectors from all Text Element files to TTDBMV[5],3
(800.....) Special projects
(........) LMSCWebPages
(........) LMSC_URL
(........) The USMS Archives Catalogue
(........) The SwimmerID Registry
(........) encoding birthdays, how the SwimmerID is formulated
(........) TTDB_RANK (calling qkw_index) processes FINA & USMS records
(900.....) Proliferation
(920.....) uploading to the server, and synchronizing the server with the source computer(s)
(940.....) install procedure
(960.....) error handling The encoding of e-mail addresses to deter "harvesting" gave us an opportunity to discover how many HTML pages each major function creates or maintains. This was possible because every HTML file was changed to use encoded e-mail and the number of files uploaded after each procedure was noted. Here are the results. qkw_Master - 3067 HTML files were changed in a 1:55 (2 hour) run and 57 minutes were required to upload the revised files.
qkw_htm_xref - 545 HTML files were changed in a 6 minute run and 14 minutes were required for upload.
TTLMSCDATA - no HTML files were changed, the run (inc. POSTTEAM) took 20 minutes.
TTDBEXPORT - 2936 HTML files were changed in a 39 minute run (inc. POSTTEAM & TTLMSCDATA) and 55 minutes were required for upload.
TTDB_HTM_INDEX - no HTML files were changed, the run took ?? minutes.
TTDB_HTM_NAMES - no HTML files were changed, the run took :03 seconds.
LMSCWebPages - 54 HTML files were changed in a :45 second run and :30 seconds were required for upload (for the top folder only).
ServerSync - a complete ServerSync verification with no actual uploading takes about 6 minutes.
Backup - a complete backup verification with no actual copying takes about 2 minutes.

COMMENTS

The following comments were received on 3/7/02 and are about the RFP as reduced to include only the conversion of APL data to text files. Revisions to the page called "files.htm" have been made in response to these comments. Further discussion can be had by e-mail or telephone if it appears that I have not been responsive to some comment. (Carl House, 3/7/02)

Leo Letendre

1) You mention the fact that there are 8400 files and then later list a number of them much smaller than 8400. Maybe a bit more on the hierarchy of the file system would be useful.

2) In a similar vein, if you are expecting the conversion to be automatic, that is start it up and walk away, you need to let people know how they can determine what type of file a given file is. That is, what handles are available as one courses through the directory structure to determine if the file contains Top Ten data, pictures, records, etc.

3) You give an example of how a Top Ten file is named yet the file name given for the Top Ten files (e.g. file name= f4211.sf) doesn't conform to the rules.

4)Do you expect files containing images to be converted to something? You list them at the end of the RFP but you really don't address them in the body of the text.

5) You use a few terms which are either APL specific or are not commonly used (any more?) such as FCN. You might want to mention what they are and why they are useful.

6) You say "Relays are probably same as received from R&T, but should be provided for." The final RFP should be specific and not leave any uncertainty on our part.

Just some quick thoughts. Keep on plugging!, Leo Letendre

Jim Matysek

I've reviewed the current RFP at http://www.swimgold.org/committee/rfp/files.htm. Overall, I believe that it accomplishes what we need for this RFP and is mostly sufficient for a contractor to bid on. There may be some questions and clarifications for bidders, but that is normal for RFP's. It could use a little more detail in some respects if we can get these in before releasing it (specification of exact number of input and output files and specification for output file format).

Here are some specific comments on the RFP:

"A Request for Proposals (RFP)" Section:

- In the second paragraph, the text "(and implement?)" is not appropriate for the RFP.

- I'm a little confused by the 4th paragraph. The first sentence says that some level of documentation is needed to enable non-APL people to use the text files. Since the text files are language-independent (that's why we're doing this RFP), I don't understand the statement. Also, I believe the first two sentences should be a little more authoritative in what our requirements for documentation are, if any is needed (shouldn't be any words like "some level" and "perhaps"). I thought the details of the RFP should specify the file structure well enough that there would be no documentation of the text files required of the contractor. We're supposed to be specifying that the contractor will receive x APL files and will deliver the ability to generate y text files from the data contained in the APL files at any time (note: x and y should be specified). We should also be specifying the format of the text files, so I don't see the need for the contractor to deliver any documentation on them (note that this output file format specification is missing).

- The 4th paragraph also discusses a checksum of some sort for the exported data set. I don't see how this would help in any way. The checksum of the exported data would be, for example, some hexadecimal number derived from the exported data (for example 4A3C65). This number is merely a derived number from the EXPORTED data, similar to saying that it is 145,324,278 bytes in size. It has no direct correlation to the source data in the APL files that can be externally verified to prove that all data from the APL files was exported. If it were the same as a checksum for the data as contained in the APL files, we would not need the RFP - we would already have the data in the APL files exactly as we need it. While I understand the desire to have some sort of proof that the data from the APL files has all been successfully exported, I do not see a way to achieve this except through inspection of the data itself. At some point, we have to verify that the tool does what it is intended to do and then trust that it will keep doing that from then on. This doesn't remove the need to do some minimal inspection of output when changes are made, but those inspections are more to look for gross errors, not to verify that everything is exactly right.

"Data Flow" "The Core Databases":

- This section specifies the structure of the data to be found in a set of APL files. This is good! I would think that a specification for the file structure desired for each corresponding text file to be output would be appropriate here.

"Compiled Information About Individual People, LMSCs & Clubs": "Beyond Data " "Text & Images " "Other":

- These sections list files that mostly have 0 records, and none of them specify a file layout. I can understand that the Stories about USMS Swimmers includes 237 FCN's, and these probably correspond to 237 text stories (similar comments for the Oral History Project section), but I don't understand what the 125 records or 86 FCN's are for The History Project. When I browse the link for the History Project, I can't find anything that implies there is a set of similarly structured data or files in that area - it is just a text description of what the History project is all about. What am I missing? All of the other things in this whole section have similar questions.

-Jim Matysek

Hugh Moore

I'm impressed. You did some fast work on the revision. Here are my comments:

The RFP states "The structure and scope of USMS digital archives will not change during the several months required to develop an enterprise database strategy, though data will be added within the current scope and structure."

This seems to imply that we will be changing the structure in the future. That's not surprising. However, we're wasting our money unless we develop a plan so that such changes can easily be incorporated in the new "export tool".

Be careful when using the word "should". "Should" is not binding. If possible use the word "shall". Examples: "Data currently stored as text vectors should become .txt files. Data stored as matrices with fixed width fields should become .csv (comma delimited files -- the data contains no commas). " If we want to mandate the "requirement" we need to use "shall".

The RFP states "Some level of documentation will be needed to enable others (non-APL people) to use the text files. Perhaps a catalogue in both digital and paper format is desired, but it may not be necessary if folder structure and file names are sufficient to provide documenation. The proposal should consider this." I don't think that we should put the burden of documentation on the bidders. It appears that you have done a great job of defining the structure. I think that we can assume that anyone importing the data into a data base application will not need any information beyond the file definition that you already provided.

The RFP also states "The proposal should also consider how we can be assured that the text version of the database includes all of the data items in the APL version. Control should be provided for on the number of items and on some sort of "checksum". " I think that we may need to "brainstorm" this a little. Since you already list the number of records and file size, I'm not sure that a checksum will buy us much since I'm not sure how the bidder can checksum the existing data.

I'll spend some more time looking at the RFP tomorrow morning.

Hugh Moore

Lynn Hazlewood

Thanks for getting the changes requested by the EC done so quickly. I have a few comments on your RFP:

1) In the paragraph where you describe the deliverables, I think you should be more specific. It requests the text format files and this is OK. However, you say the export procedure should be automated so it can be repeated. You don't say they have to also deliver the programming that accomplishes the export procedure. Conceivably, they could charge us to redo the export each time we need to do it.

2) I would like to see more specifics on the output side of the equation. For example, you describe the current file names and formats in detail, but do not specifically give the file names and formats (with examples) for the output (you imply this). You have a somewhat indirect way of expressing things and this is OK for those of us who know what you're talking about. I am wondering if someone looking at this cold will be able to follow your meaning and deliver exactly what we're looking for.

3) You do not say that the bidders will be able to examine the APL files before they submit their bids. They will have to have some way of determining what the conversion issues will be when they put a price on it.

4) I'm somewhat uncomfortable about the documentation issue. We should specify the documentation we're looking for.

5) In what form will we be presenting the RFP? Is this to be a stand-alone document delivered in hard copy or PDF format? The reason I ask is, there is a lot of information on the web site that is not part of the RFP. By following the various links from the main RFP page, you can get into these other areas. I think we need to focus the bidders' eyes only on the RFP. You could add an appendix that points to the other information, but the demarcation of the actual RFP should be clear.

6) Do we need to include information on the bid evaluation and contract administration process in the RFP? Would this impact how bidders respond?

Hopefully, we can clear up these questions and any other people may have quickly so we can get to the actual bidding process. Thanks for all your hard work. --

Lynn Hazlewood

horizontal line
to home page e-mail Page Top