Chapter 37: Advantages - No Checksum Overhead |
In Brief |
For internal systems that already implement robust error-checking at the database level, the optional checksum character in Code 39 can be safely omitted. This saves exactly one character per barcode---a seemingly minor economy that, when multiplied across millions of scans in high-volume industrial environments, translates into meaningful gains in printing efficiency, label density, and scanning speed. More importantly, this choice reflects a fundamental architectural decision: trusting the database, rather than the barcode itself, to serve as the ultimate arbiter of data integrity. This chapter explores how this technical characteristic of Code 39 influences its adoption across multiple industries and why, for many closed-loop applications, the checksum remains an unnecessary luxury. |
|
1. The Self-Checking Nature of Code 39 |
Before we can appreciate the significance of omitting the checksum, we must first understand why Code 39 can afford to make this optional in the first place. Unlike many other barcode symbologies that absolutely require a check digit for reliable operation, Code 39 possesses an intrinsic property known as 'self-checking.' |
1.1 The Nine-Element Structure |
Every character in a Code 39 barcode is constructed from nine elements: five bars and four spaces. Among these nine elements, exactly three are wide, and six are narrow. This 'three wide out of nine' pattern is the very reason for the symbology's name---Code 3 of 9, or Code 39. The bars and spaces alternate, beginning and ending with a bar, and the position of the wide elements within each character uniquely identifies that character. |
This fixed pattern of exactly three wide elements per character provides a powerful form of built-in error detection. If a single bar or space is misread---say, a narrow bar is mistaken for a wide one, or vice versa---the resulting character would almost certainly not have the required three-wide-element configuration. The decoder can immediately recognize that the character is invalid and either reject it or signal an error. |
1.2 Self-Checking vs. Checksum |
It is crucial to distinguish between self-checking and a checksum. Self-checking operates at the level of individual characters; it detects errors within the character being decoded. A checksum, by contrast, operates at the level of the entire message, detecting errors that might involve whole characters being misread or transposed, even if each individual character is valid. |
Code 39's self-checking property catches a large class of common errors, particularly those caused by poor print quality, minor damage to the label, or inconsistencies in the scanning process. In many practical applications, this character-level error detection is sufficient. A single erroneously interpreted bar simply cannot generate another valid character. This is not merely a theoretical property; it is a robust safeguard that has contributed to Code 39's long-standing reliability in demanding environments. |
1.3 The Optional Check Digit |
The Code 39 specification does define an optional checksum, sometimes referred to as Code 39 mod 43. This involves assigning a numeric value to each of the 43 characters in the Code 39 character set (0 through 42), summing the values of the data characters, dividing by 43, and appending the character corresponding to the remainder. This is a modulo 43 checksum. |
However, this feature is optional by design. Many applications never use it. As one industry guide notes, Code 39 is self-checking and 'it is not normally necessary to provide a checksum'. The checksum becomes relevant only in applications requiring an 'extremely high level of accuracy,' and even then, it adds an additional character to the barcode, increasing its length. In the vast majority of deployments, especially internal systems where the database itself performs validation, this checksum character is simply redundant overhead. |
|
2. The Database as the Ultimate Check |
The decision to skip the Code 39 checksum rests on a fundamental architectural principle: the database is the ultimate source of truth. In a well-designed internal system, the barcode serves as a key---a pointer to a record stored in a structured database. The barcode's purpose is to retrieve information, not to carry it in its entirety. |
2.1 Client-Server Validation |
Consider how a typical barcode scanning system operates in an enterprise environment. When a user scans a barcode, the scanner transmits the encoded data to a client application. This application then queries a central database using the scanned value as the primary key. The database either returns a record (the data is valid, the key exists) or returns nothing (the key is invalid). At this point, the application logic can handle the 'not found' condition, whether by displaying an error, sounding an alarm, or requiring the user to re-scan. |
This approach provides a far more comprehensive form of error checking than any checksum character could offer. The checksum only verifies that the barcode's characters were decoded according to a mathematical rule. It does not verify that the decoded value corresponds to a valid item in inventory, an authorized employee, a legitimate work order, or a trackable asset. The database check does all of this and more. |
2.2 The Meaning of 'One Character Saved' |
The title of this chapter references saving 'one character per barcode.' At first glance, one character seems trivial. Code 39's low data density is well-known; it requires more space to encode a given amount of data compared to denser symbologies like Code 128. Adding a checksum character only exacerbates this limitation. |
In a single barcode, one character is, indeed, negligible. But consider a high-volume operation printing millions of labels each year. Each label requires a certain amount of thermal transfer ribbon, a certain amount of label stock, and a certain amount of time on the printer. Saving one character per label, across millions of labels, reduces material consumption and speeds up printing. The aggregate effect is measurable and meaningful. |
Moreover, label real estate is often at a premium. Barcodes must be printed clearly enough to be scanned reliably, which imposes minimum size constraints based on the printer's resolution and the scanner's capability. A shorter barcode can be printed smaller while maintaining the same bar width, allowing more information to fit on smaller labels or leaving more space for human-readable text and other markings. |
|
2.3 Closed-Loop vs. Open-Loop Systems |
The decision to forgo the checksum is most appropriate in closed-loop systems. A closed-loop system is one in which the barcodes are generated, printed, and scanned entirely within a single organization's controlled environment. The barcode format is standardized internally, the database is maintained internally, and all scanning devices are configured consistently. |
In such an environment, the organization controls the entire data chain. The barcode's data originates from a known source---the database---and returns to that same source for verification. There is no external party whose decoding software might behave differently or expect a different format. The cost of an occasional scanning error is borne internally and can be managed through procedural controls. |
By contrast, open-loop systems involve barcodes that are exchanged between different organizations or across public supply chains. In these cases, the barcode may be decoded by any number of scanning devices and software packages controlled by different parties. A checksum provides a universal, mathematically verifiable guarantee of data integrity that does not rely on any external database access. This is why standards like GS1-128 (which is based on Code 128) mandate check digits. In open-loop environments, the checksum is essential. |
|
3. Industry Applications: Where No Checksum Shines |
The optional checksum has influenced Code 39's adoption patterns across diverse industries. In each case, the decision to accept or reject the checksum reflects the specific operational realities and risk tolerances of that industry. |
3.1 United States Department of Defense (LOGMARS) |
Perhaps the most famous adoption of Code 39 is the LOGMARS (Logistics Applications of Automated Marking and Reading Symbols) system developed by the U.S. Department of Defense. The military standardized on Code 39 for identifying and tracking supplies, equipment, and assets across its vast logistics network. |
In this environment, the robustness of Code 39's self-checking mechanism was considered sufficient for most applications. The military's supply chain is a highly controlled, closed-loop system. Bar-coded items move through military depots, onto military vehicles, and into military installations---all within the Department of Defense's purview. The database is authoritative; if a barcode decodes to a value that is not in the system, that item is flagged for investigation. The optional checksum added unnecessary length to labels that needed to be read reliably under challenging field conditions without imposing the overhead of an additional character. |
|
3.2 Automotive Manufacturing |
The automotive industry is another stronghold for Code 39. From component manufacturing to final assembly, parts and assemblies are tracked using Code 39 labels. Each part receives a unique barcode that encodes a part number, serial number, or work-in-process identifier. This barcode accompanies the part through painting, welding, assembly, and quality control. |
The 'one character saved' is particularly meaningful in this context. Automotive parts come in all shapes and sizes. Some small components have very little surface area for a label. A shorter barcode can fit where a longer one cannot. Furthermore, the manufacturing environment is fast-paced; assembly line workers need to scan parts quickly and move on. The reduced data length marginally speeds up scanning, though the real benefit is in label placement flexibility. |
The self-checking property of Code 39 is also well-suited to this industry. Labels may be exposed to oil, grease, heat, and abrasion. A damaged bar or space is more likely to produce a decoding error that the scanner recognizes immediately, rather than a false positive that passes validation. When a worker sees an error, they can quickly re-scan or replace the label. The system's database provides the final validation once the part is scanned into the next station. |
|
3.3 Healthcare |
Healthcare applications, including hospital asset tracking, laboratory specimen identification, and patient wristbands, often use Code 39. In this sector, accuracy is paramount; misidentifying a patient or a medication can have life-or-death consequences. |
Paradoxically, the optional checksum is sometimes skipped even in this high-stakes environment. This is not an oversight. Many healthcare systems are closed-loop. A hospital creates wristbands for patients when they are admitted. The barcode on the wristband encodes a patient identifier---typically a medical record number. When a nurse scans the wristband, the scanner queries the hospital's Electronic Health Record (EHR) system. The EHR returns the patient's name, allergies, blood type, scheduled procedures, and other critical information. |
In this workflow, the barcode is simply a key. The database check is not just an error check; it is the primary means of pulling up the correct patient record. If a barcode decodes to a number that does not correspond to any patient, the EHR returns an error. The nurse knows immediately that something is wrong. The optional checksum would add a character to the wristband, making it slightly longer and potentially more difficult to fit on a narrow wristband, without adding any safety benefit that the database check does not already provide. |
|
3.4 Library Systems |
Public and university libraries were among the earliest adopters of barcode technology, and Code 39 is widely used for book labeling. Each book receives a barcode that encodes its accession number or unique identifier. The library's catalog system uses this number to look up the book's title, author, location, and circulation status. |
Libraries are the quintessential closed-loop system. The barcodes are printed by the library, applied to books in the library's collection, and scanned by library staff using library-owned scanners. The catalog database is the authoritative source. If a barcode does not decode to a valid catalog entry, the staff member is alerted. The checksum is entirely redundant, and saving one character per label means more books can be labeled from the same roll of adhesive labels, a modest but non-trivial cost savings for a budget-conscious institution. |
|
3.5 Industrial Automation and Equipment Tracking |
In industrial automation, Code 39 barcodes are used to track equipment, tools, and components across a facility. Each asset receives a unique barcode that identifies its type, location, maintenance history, and operational status. |
In this environment, speed and reliability are paramount. The self-checking nature of Code 39 provides immediate error detection at the scanner level, while the database ensures that the decoded asset ID is valid and provides the current status. The optional checksum is often omitted to keep barcodes short, enabling the use of small labels that fit on tools and equipment without obscuring other markings. |
|
4. When the Checksum is Worth the Overhead |
While this chapter emphasizes the advantages of skipping the checksum, it is equally important to recognize when the checksum is a prudent addition. There are scenarios where the extra character of overhead is justified. |
4.1 Open-Loop Supply Chains |
As previously mentioned, any system where barcodes are shared across organizational boundaries is a candidate for a checksum. If a manufacturer ships products to a distributor, who then ships to a retailer, who then ships to a consumer, the barcode may be scanned by multiple parties using different equipment and software. A checksum provides a layer of independent verification that ensures the barcode was correctly printed and decoded, regardless of the receiving party's database connectivity. |
4.2 Hand-Entered Data |
Some systems, whether by necessity or by workflow design, involve manual data entry in addition to barcode scanning. If an employee reads a barcode and types the human-readable digits into a computer, the checksum provides a mechanism to catch typing errors. The system can recompute the checksum from the entered digits and compare it to the checksum digit printed on the label. If they do not match, the user is alerted to re-enter the data. |
4.3 Mission-Critical Applications with No Database Fallback |
In some specialized applications, the barcode may be the only storage medium for the data. If the database is inaccessible or non-existent, a barcode error cannot be corrected by a lookup. In this scenario, a checksum is essential. This is rare in modern enterprise systems but can occur in legacy applications or in standalone devices where connectivity is not available. |
|
5. Implementation Considerations |
For system designers and developers, the decision to enable or disable the checksum is a simple configuration choice. Most barcode generation libraries and font packages allow the checksum to be toggled. For example, the Code39Extended constructor in many libraries includes an 'enableCheckSum' boolean parameter. The default may vary; some libraries enable it by default for safety, others leave it off for backward compatibility. It is critical to set this option correctly and to ensure that the scanners used to read the barcodes are configured consistently---a scanner expecting a checksum will not correctly decode a barcode without one, and vice versa. |
5.1 The Modulo 43 Algorithm |
For those who do choose to implement the checksum, the algorithm is straightforward. Each of the 43 characters in the standard Code 39 character set is assigned a value from 0 to 42. This includes the uppercase letters, digits, and the seven special characters (space, -, ., $, /, +, %). The start and stop characters (asterisk, *) are not included in the checksum calculation. |
The data characters (everything between the start and stop characters) are converted to their numeric values. These values are summed. The sum is divided by 43. The remainder is the value of the checksum character, which is then appended to the data string before the stop character. The scanner, when configured for checksum verification, performs the same calculation and checks that the decoded checksum character matches the expected value. |
5.2 Consistency Across Readers and Writers |
The most common implementation error is inconsistency. If the software generating the barcode includes a checksum, but the scanners are configured to read Code 39 without a checksum, the scanners will fail to decode the barcode correctly because they will interpret the checksum character as part of the data. Conversely, if the generators skip the checksum but the scanners expect it, the scanners will reject the barcode as invalid. In both cases, the system will appear broken. The solution is rigorous documentation and configuration management, ensuring that all components in the system agree on the checksum setting. |
|
6. The Bigger Picture: Trusting Your System |
The decision to skip the Code 39 checksum is not merely a technical footnote. It is an expression of a broader architectural philosophy. In a well-designed internal system, the barcode is not the carrier of truth; it is a key to a database that is the carrier of truth. The database is more powerful, more flexible, and more reliable than any checksum. |
The database can validate not just format, but business logic. It can ensure that a scanned part number corresponds to an active product, that a scanned employee ID corresponds to a current employee, that a scanned location corresponds to an authorized inventory bin. The checksum, by contrast, can only validate that the barcode's characters were correctly decoded. It knows nothing about the business context in which that decoded value will be used. |
This is why the 'one character saved' is so significant. That one character is not just a character; it is a symbol of a system that trusts its database more than its barcodes. It is a choice to favor efficiency, simplicity, and elegance over an outdated and redundant safeguard. |
6.1 Historical Context and Legacy |
Code 39 was developed in 1974, a time when databases were expensive, connectivity was unreliable, and dedicated mainframes were the norm. In that era, a barcode's self-checking capability and an optional checksum were important compensations for limited backend capabilities. The scanner and the label had to bear more of the burden of correctness because the system to which they connected could not always be trusted to be online or up-to-date. |
Today, the landscape is vastly different. Databases are ubiquitous, reliable, and fast. Network connectivity is assumed. Even mobile devices can query cloud-hosted databases with sub-second latency. The arguments for a checksum are weaker than they were fifty years ago. The self-checking nature of Code 39 remains a robust safeguard, but the additional checksum has become, in many contexts, an anachronism. |
6.2 Modern Alternatives |
It is also worth noting that for new systems, designers often choose more modern symbologies. Code 128 offers higher data density and includes a mandatory check digit. GS1-128 adds Application Identifiers for structured supply chain data. Two-dimensional codes like Data Matrix and QR Code pack far more data into a smaller space and include powerful error correction capabilities. These are often better choices for new applications, especially where space is limited or data requirements are complex. |
Nevertheless, Code 39 persists. It remains in wide use because it is simple, reliable, and supported by virtually every barcode reader ever manufactured. Its ease of implementation---simply printing the data in a Code 39 font---makes it appealing for internal systems where developers do not want to deal with the complexities of checksum algorithms and application identifiers. The optional checksum is a feature, not a requirement, and the freedom to omit it is one of the reasons Code 39 continues to be a viable and popular choice for many applications. |
|
7. In Summary |
This chapter has examined the advantages of omitting the optional checksum in Code 39 barcodes for internal systems that implement error-checking at the database level. The key points are as follows: |
The Self-Checking Nature of Code 39: Every character in Code 39 consists of nine elements, exactly three of which are wide. This pattern allows the scanner to detect many errors at the character level. The optional checksum provides additional protection at the message level but is not required for reliable operation in many environments. |
Database as Ultimate Check: In a closed-loop internal system, the barcode serves as a key to a database record. The database lookup provides a more powerful and comprehensive validation than any checksum, verifying not only data integrity but also business context and business rules. |
One Character Saved, Millions of Times: While saving a single character per barcode may seem trivial, across millions of printed labels in high-volume operations, the economy in materials, printing time, and label real estate becomes significant. A shorter barcode can fit on smaller labels and is faster to print. |
Industry Applications: The decision to skip the checksum is reflected in Code 39's widespread use in the U.S. Department of Defense (LOGMARS), automotive manufacturing, healthcare, library systems, and industrial automation. In each of these closed-loop environments, the database check is considered sufficient, and the overhead of the checksum is unnecessary. |
Appropriate Use of the Checksum: The optional checksum remains valuable in open-loop supply chains where barcodes are shared across organizations, in systems that involve manual data entry, and in rare scenarios where a database fallback is unavailable. System designers should carefully consider their environment and risk tolerance. |
The Broader Architectural Philosophy: The choice to omit the checksum reflects a modern architectural approach that trusts the database as the authoritative source of truth. The barcode is a key, not the data itself. |
|
In conclusion, the optional checksum in Code 39 is a feature that can be safely skipped in a large and important class of applications. The self-checking nature of the symbology, combined with the power of modern database systems, provides all the data integrity that most internal systems require. The one character saved per barcode is a tangible benefit that, over time and across large volumes, translates into real operational efficiencies. Code 39's enduring legacy is not diminished by the absence of a checksum; on the contrary, the symbology's flexibility in allowing users to decide is one of its strengths. It is a reminder that in technology, as in many things, the right answer depends on the context. For many organizations, the right answer is to skip the checksum, trust the database, and enjoy the modest but meaningful efficiency gains that come from printing shorter barcodes. |
cs@easiersoft.com