Address Label

This program collects mailing address data for up to 100 entries and prints formatted address labels to a printer using LPRINT. Each record stores four fields — name, address, city/state, and ZIP code — in a two-dimensional string array A$(100,4), with a companion array B$(4) holding the field prompt labels. A validation check at line 232–238 enforces a 30-character maximum on the name field, though the loop logic contains a bug: on a validation failure the GOTO 220 re-enters the inner loop at INPUT without re-prompting the correct field label, and J will advance past 1. After all entries are collected, the program iterates through the array and sends each field to the printer via LPRINT.

---

Program Analysis

Program Structure

The program is divided into three logical phases:

1. Setup (lines 110–180): Prompts for the number of entries, dimensions the data array A$(100,4) and prompt array B$(4), and populates B$ with field names.
2. Data Entry (lines 190–240): Nested FOR loops (outer over records I, inner over fields J) collect input into A$(I,J), with a name-length validation guard.
3. Output (lines 310–380): A second nested loop sends each stored field to a printer via LPRINT.

Data Structures

Variable	Type	Purpose
A$(100,4)	2D string array	Stores up to 100 records × 4 fields each
B$(4)	1D string array	Field prompt labels (NAME, ADDRESS, etc.)
N	Numeric	Number of address entries to collect
I, J	Numeric (loop counters)	Record index and field index respectively
X	Numeric	Temporary holder for name field length

Key BASIC Idioms

• A companion label array B$(4) is used to drive prompt text dynamically inside the loop at line 210 (PRINT "INPUT";B$(J)), avoiding four separate input prompts.
• LPRINT at line 350 sends output directly to a connected printer rather than the screen, which is the standard approach for hard-copy label generation.
• Line 121 echoes N back to the screen immediately after input — a simple confirmation technique.

Validation Logic and Bug

Lines 232–238 implement a name-length check. After the inner FOR J loop body executes for J=1 (the NAME field), LEN(A$(I,1)) is stored in X. If the name exceeds 29 characters, execution jumps back to line 220 (INPUT A$(I,J)).

However, this introduces a logic bug: the GOTO 238 re-enters at the INPUT statement mid-loop without resetting J or re-printing the correct prompt. On a validation failure, J is still 1, so the re-input will overwrite A$(I,1) correctly — but without re-displaying the “INPUT NAME” prompt (line 210 is bypassed). If the user then passes validation and NEXT J at line 240… wait, line 240 is actually NEXT I. The inner loop’s NEXT J is at line 230. The validation block at lines 232–238 sits between NEXT J (line 230) and NEXT I (line 240), meaning it only ever checks the field collected in the last iteration of the J loop (field 4, ZIP CODE), not the name field. The intent was clearly to validate the name, but the check is misplaced after the inner loop closes.

Notable Anomalies

• The DIM A$(100,4) at line 130 allocates space for 100 records unconditionally, regardless of the value of N entered by the user. This wastes memory if N is small, and if N exceeds 100 the program will generate a subscript error at runtime.
• There is no upper-bound check on N before the DIM statement; entering a value greater than 100 will cause an out-of-bounds error during data entry.
• Lines 390–400 (SAVE and RUN) appear after STOP at line 380 and are only reachable by direct GO TO or manual execution — a common pattern for embedding a re-save/restart facility at the end of a program.
• Line 250 contains a bare PRINT (blank line) that serves as visual spacing between the input phase and the print phase on screen.