CL2 file format

From Libre Aquatics Wiki, the free aquatics reference

CL2 is the older of the two file formats Hy-Tek ships in an export from Meet Manager. It carries a team’s roster and its entries, and sometimes the results of a meet as well, and it is the format Hy-Tek provides a documented route out of.

What it carries¶

A CL2 file moves roster and entry data between Team Manager and Meet Manager: a club’s swimmers and the events they are entered in before a competition, and in the other direction the results afterwards.¹ That is the same job Commlink did on a diskette in the 1990s, done as a file.

Like HY3 it is proprietary to Hy-Tek and has no specification the company has published, though volunteers worked out much of it. A CL2 line runs to 160 characters against HY3’s 130, its checksum occupies four columns where HY3 uses two, and it borrows its record codes from SDIF instead of inventing them: a file description, meet and team records, one record per individual swim, relay records and a terminator.²¹

That is why the two formats in a single Hy-Tek export are not two dialects of one thing. One is a nearly-SDIF file and the other is Hy-Tek’s own. A modern parser handles CL2 by reading it with an SDIF parser held to looser rules, which is about as exact as the relationship can be put.³

The checksum is a different calculation from HY3’s, published in the same 2010 post that cracked that one.²

Older, but not retired¶

Hy-Tek’s own user guide is what establishes the order of the two formats. Describing the contents of a Hy-Tek export archive, it calls the CL2 the old format and the .hy3 the newer one.⁴ Both are still written: every export contains both, so a program that reads only CL2 has not been cut off.

The changeover is pinned to a program version rather than a date. Hy-Tek states that the CL2 is the file Team Manager releases before 4.0G will use and the HY3 the one 4.0G and later will take, and that the HY3 carries things the CL2 cannot, among them results by division, semi-finals and swim-offs.⁵ One filter on the export screen gives the asymmetry away: an option to export semi-final results only applies to the CL2, because the HY3 always carries every round regardless.⁵

A record read¶

The post that published the checksum also printed a CL2 header record, the A0 that opens a file and describes it. It carries no personal data, only the vendor’s own details, which makes it the right example to reproduce:²

A01V3      02Meet Results                  Hy-Tek, Ltd         WMM 3.0Cl Hy-Tek, Ltd         866-456-511112052009                                    MM40    N42

Reading it: the file is a version 3 export of meet results, written by a Hy-Tek program identifying itself as WMM 3.0Cl and dated 5 December 2009. SDIF writes dates as MMDDYYYY, so the 12052009 in the record is December, not May.⁶ The name and telephone number alongside it are SDIF’s contact fields, identifying whoever supplied the data rather than whoever the copy is licensed to. The last four characters, " N42", are the checksum.

One caveat about that line. The newsreader it was posted through wrapped it across three lines, so where exactly the runs of spaces fell inside it cannot be recovered. What is reproduced above restores the length to 160 and puts the missing spaces back at the wrap points. The internal padding may not be where Hy-Tek put it, and because every space has the same character code, the checksum cannot tell the difference.

The two formats are hard to tell apart by their contents, since both are plain text full of names and times, but the line length gives them away immediately.

Checking the arithmetic¶

The published algorithm can be tested on that line, and it holds. Summing the character codes of the first 156 columns, without the positional weighting HY3 applies, gives 7,861, which is the figure the original post states. Dividing by 19 and discarding the remainder gives 413; adding 211 gives 624; the last two digits written backwards give 42; and the two-character prefix, a space and an N for any record not beginning D0, completes " N42".²

That is a weaker result than the one on the HY3 page and the difference is worth stating. The HY3 algorithm was run against 4,617 lines of real Meet Manager output and reproduced every checksum. This one has been checked only against the worked example its own author supplied, because no CL2 file could be found in public to test it on. The arithmetic is internally consistent; whether Hy-Tek’s software actually computes it this way remains unconfirmed here.

One known gap in the published rule: a later poster reported that the NN prefix applies to D0 records only in results files, that entry files use the space-and-N form throughout, and that some results files carry YN instead. So the prefix rule as published is known to be incomplete.²

Conversion to SDIF¶

Meet Manager will convert a CL2 to the published SDIF standard, under File, Export, and a menu item naming the conversion directly. The output is an .sd3 file named on a fixed pattern that embeds the database name and a sequence number.⁴

That utility is the only official bridge from Hy-Tek’s formats to the open one, and which of the two it serves is worth noticing. It converts the older CL2. Nothing read here documents the same conversion from the newer HY3, so the format with a way out is the one Hy-Tek itself calls old.

References¶

Swim Community, Understanding swimming file formats (community discussion; roster and entry content, proprietary status). ↩ ↩²
jwh, HY-TEK CL2 and HY3 checksum algorithms, rec.sport.swimming, 28 October 2010. ↩ ↩² ↩³ ↩⁴ ↩⁵
dmanusrex, swimlib (reads CL2 through a relaxed SDIF parser). ↩
HY-TEK, Convert a Hy-Tek Export CL2 File to SDIF (Meet Manager 8 user guide). ↩ ↩²
HY-TEK, Export results for TEAM MANAGER or SWIMS (Meet Manager 8 user guide; the CL2 and HY3 pair and the Team Manager 4.0G cutover). ↩ ↩²
USA Swimming, Swimming Data Interchange Format version 3 (28 April 1998), DATE fields as MMDDYYYY. ↩

Last updated September 25, 2026.