DEF 2068

This program is a simple inventory database manager that stores up to ten records in a two-dimensional string array, each record holding fields such as stock number, description, supplier, quantity, unit price, retail price, low limit, and back-order quantity. Records are entered through a custom character-by-character input routine at line 1500 that supports backspace (CHR$ 12) and fixed-width field formatting with both zero-padded numeric and space-padded text fields. A calculated extended price field is derived automatically by multiplying the unit price by quantity using string-to-value conversion. The program supports searching by stock number, deleting records with array compaction, and saving or loading the data file with an auto-start line. Screen$ reads are used to retrieve displayed field values for the low-stock warning comparison rather than storing them in separate variables.

---

Program Analysis

Program Structure

The program is organized into distinct subroutine blocks, each starting at a recognizable line number boundary, with a main menu loop at line 9040 dispatching via GO SUB to each module:

Lines	Module
1001–1080	Add Records
1500–1535	Character-by-character field input subroutine
3001–3190	Search / Display record
5001–5025	Delete record
8000–8055	Load / Save file
9040–9090	Main menu loop

Line 5 initializes the record pointer p to 1, and line 10 immediately jumps to the main menu at 9040. Line 2 allocates the record array e$(10,100), providing storage for up to ten records of 100 characters each.

Data Storage Format

Each record is serialized into a single string slot of e$. Fields are concatenated into a$ with * as an inter-field delimiter and / appended at the end of a complete record (line 1060). The stock number field (row 2, x=2) is zero-padded to 9 characters using b$="000000000"; text fields at x>=4 are space-padded to field width using c$ (20 spaces). This means the first 9 characters of each record are always the zero-padded stock number, enabling the direct substring comparison at line 3027.

Custom Input Routine (Lines 1500–1535)

Rather than using the built-in INPUT for field data, the program implements its own keystroke loop. PAUSE 0 followed by INKEY$ at line 1500 is a standard efficient keypress-wait idiom. Key behaviors include:

• CHR$ 13 (ENTER) accepts the field when at least one character has been entered (k<>0).
• CHR$ 12 (DELETE/backspace) steps back one position and restores the dash placeholder, trimming k$.
• Characters below CHR$ 32 (control codes) are ignored.
• Printable characters are echoed to screen and appended to k$; the field auto-accepts when the cursor reaches the field length l.

The field descriptors are loaded via READ from the DATA statement at line 1015, supplying the field width l and label l$ for each of the eight fields. The loop variable x tracks screen row (incrementing by 2 per field) and y=11 is the starting column for input areas.

Automatic Extended Price Calculation

Lines 1532–1533 implement an automatic extended price calculation. When the unit price field is entered (x=8), its value is saved in f$. When either the quantity (x=10) or another price field (x=12) is processed, the product VAL f$ * VAL k$ is computed, converted back to a string with STR$, left-padded to 9 characters, and appended to the record as an extra *-delimited field. This stores the extended price without requiring a separate variable in the record layout.

Record Display and SCREEN$ Trick

The search/display module (lines 3060–3145) walks the stored record string character by character, printing non-delimiter characters to a two-column display. Rather than storing the quantity or low-limit values in variables for the reorder warning, the program uses SCREEN$ (lines 3120–3140) to read the displayed digits directly back from the screen — quantity from row 8 and low limit from row 14. If the quantity string is not blank and the low limit is greater than or equal to the quantity, the low-limit value is flashed on screen (line 3145) as a reorder alert.

Record Deletion and Array Compaction

Deletion (lines 5001–5025) first calls GO SUB 3000 (the search routine) to locate and display the record, then prompts for confirmation. On confirmation, it clears the target slot with LET e$(x)=c$ and shifts all subsequent records down by one position in a FOR loop, decrementing p to maintain the record count. The condition at line 5023 contains a logical bug: IF x$<>"Y" OR x$<>"y" is always true (a string cannot equal both “Y” and “y” simultaneously), so the loop to add more deletions at line 5025 is never reached.

File Save and Load

The save/load module at line 8000 uses plain LOAD k$ and SAVE k$ LINE 9040, saving the program with an auto-start at the main menu (line 9040). Because the array e$() is part of the program variables, it is preserved in the saved file, effectively implementing persistent data storage.

Notable BASIC Idioms

• VAL "number" is used pervasively in GO TO, GO SUB, and arithmetic contexts as a memory-saving technique, storing a string token rather than a floating-point number in the program.
• The DATA statement at line 1015 mixes numeric literals written as VAL "n" with string literals, which is valid since READ accepts both forms.
• Line 3075 uses the expression 3100+(20*(e$(x,z+1)="/")) to compute a branch target — multiplying the boolean result of a string comparison by 20 to select between line 3100 and line 3120.
• The RESTORE calls before looping back to line 1001 reset the DATA pointer so the field descriptors can be re-read on each new record entry.

Bugs and Anomalies

• Line 9050: calls GO SUB 1000, but the add-records module starts at line 1001. Line 1000 does not exist; the interpreter will fall through to line 1001, so this works in practice but is technically targeting a non-existent line.
• Line 3027: references GO TO 3060 without VAL, inconsistent with the rest of the program’s style but functionally correct.
• Line 3185: GO TO 3000 targets a non-existent line; execution falls through to 3001, the search module — an intentional well-known technique.
• Line 5023: the condition x$<>"Y" OR x$<>"y" is a tautology (always true), meaning the loop for repeated deletions at line 5025 is unreachable. The intended logic was likely AND rather than OR.
• Line 3100: the compound IF condition IF y=10 AND b=10 OR y=12 AND b=10 relies on operator precedence; AND binds tighter than OR, so this evaluates as (y=10 AND b=10) OR (y=12 AND b=10), which is the likely intended meaning.