Easytrieve Report Generator does not provide a PARSE statement. The Broadcom 11.6 alphabetical statements list jumps from PARM and PERFORM to POINT—there is no PARSE/ENDPARSE pair like CA Ideal, and no REXX-style PARSE ARG template. Production shops still need to “parse” data constantly: comma-separated extracts from distributed feeds, pipe-delimited vendor files, free-form name lines, and QUERY_STRING style name=value pairs in CGI samples. This page treats PARSE as a skill topic— how to split and validate delimited alphanumeric data using real Easytrieve verbs: MOVE with length overrides and FILL, DEFINE overlays, INDEX on OCCURS byte arrays, DO WHILE loops, IF edits, and DISPLAY or exception-file handling when tokens are missing. Beginners who paste Ideal or REXX PARSE into an Easytrieve JOB will get compile errors; use the patterns below instead.
| Product / feature | Role |
|---|---|
| Easytrieve MOVE | Copy bytes with optional send/receive lengths and FILL pad |
| Easytrieve INDEX + OCCURS | Walk characters to locate delimiters |
| Easytrieve assignment / overlays | Map fixed positions inside a buffer |
| CA Ideal PARSE/ENDPARSE | Different language — not valid Easytrieve syntax |
| REXX PARSE | Different language — template parsing outside Easytrieve |
Before writing delimiter scanners, check whether the feed is actually fixed layout wearing a delimited costume. Many mainframe partners still send FB records with columns. DEFINE fields at known positions—or overlay a group—and you need no scan loop at all:
12345678910FILE INFILE FB(80 800) RAW-LINE 1 80 A EMP-ID 1 5 A EMP-NAME 6 20 A EMP-DEPT 26 3 A JOB INPUT INFILE PRINT RPT REPORT RPT LINE EMP-ID EMP-NAME EMP-DEPT
True delimited files vary token lengths, so fixed DEFINE alone fails. Use fixed overlays only when LRECL and column map are guaranteed.
MOVE Format 1 copies data left to right as alphanumeric without conversion. You can override send and receive lengths with fields or literals. That is the core extract mechanic once you know where a token starts and how many bytes it spans:
12345678DEFINE SOURCE W 80 A DEFINE TOKEN W 20 A DEFINE TOK-LEN W 2 N DEFINE START-AT W 2 N * After computing START-AT and TOK-LEN for the current piece: MOVE SPACES TO TOKEN MOVE SOURCE START-AT TOK-LEN TO TOKEN TOK-LEN
Exact MOVE length-parameter order follows your compiler’s Programming Guide examples—always verify against a tiny unit test on your release. Conceptually you specify which bytes leave the send area and how wide the receive area is. Longer send truncates on the right; longer receive pads with spaces or FILL fill-character. Clearing TOKEN with MOVE SPACES before each extract prevents a short new token from leaving trailing garbage from a longer previous value.
| Technique | Why it matters |
|---|---|
| MOVE SPACES TO token-field | Reset before each extract so short tokens do not keep old tails |
| MOVE source TO target FILL * | Pad remainder with a visible character when debugging layouts |
| MOVE ZEROS TO counters | Reset start index, length, and token count each record |
Define a one-byte OCCURS field INDEXED over the work buffer. Set the index to 1 through length, compare each character to the delimiter, and record the position when found. For one-byte OCCURS, the index maps directly to the byte offset. Keep the index inside the defined length or you read past storage.
12345678910111213141516171819DEFINE LINE-BUF W 80 A DEFINE CH W 1 A OCCURS 80 INDEX CX DEFINE DELIM W 1 A VALUE ',' DEFINE POS W 2 N * Find first comma in LINE-BUF (CH overlays LINE-BUF — site-specific DEFINE style) CX = 1 POS = 0 DO WHILE CX LE 80 IF CH = DELIM POS = CX * leave loop per your DO/LEAVE style END-IF CX = CX + 1 END-DO IF POS = 0 DISPLAY 'MISSING DELIMITER' GOTO JOB END-IF
Overlay syntax (whether CH is redefined over LINE-BUF with a relative DEFINE or assigned through site macros) varies by shop standards—match your Library conventions. The algorithm stays the same: walk bytes, note delimiter index, compute token length as position minus start, MOVE the slice, then set start to position plus one for the next token.
Put the scan in a PROC such as NEXT-TOKEN. PROC keeps the JOB body readable and lets PERFORM drive one token at a time into working fields. For many delimiters, a small state machine in the PROC is clearer than nested IF trees.
Quoted CSV with embedded commas is a frequent research gap on classic Report Generator: there is no standard library routine. Prefer upstream cleanup, or document a shop macro if one exists. Log uncertain quote-state edge cases rather than inventing half-tested parsers for production payroll.
After extracting an alphanumeric token that should be numeric, assign into an N or P field and guard with IF token NOT NUMERIC before arithmetic. MOVE alone does not convert packed edits the way typed assignment does—know which verb you are using. Damaged tokens should DISPLAY and GOTO JOB rather than corrupt totals.
123456789DEFINE AMT-TOKEN W 12 A DEFINE AMT W 7 P 2 * after parse into AMT-TOKEN: IF AMT-TOKEN NOT NUMERIC DISPLAY 'BAD AMOUNT ' AMT-TOKEN GOTO JOB END-IF AMT = AMT-TOKEN
Broadcom CGI examples accept QUERY_STRING style parameters where pairs use = and separate with &. That is still not a PARSE statement—you scan for & then for = inside each pair, or CALL a small C/LE helper that returns a ready buffer. Keep HTTP decoding (plus-to-space, percent encodings) out of Easytrieve when possible; normalize in the helper.
Easytrieve does not have a magic “open the gift” PARSE button. A delimited line is a string of beads with colored separators. You look at each bead (INDEX), and when you see a red separator you scoop the beads since the last separator into a cup (MOVE). Then you keep walking. If you expected three cups and only found one separator, you raise your hand (DISPLAY) instead of pretending the cups are full.
1. Does Easytrieve Report Generator 11.6 define a PARSE statement?
2. MOVE with send and receive length overrides is useful for parsing because:
3. INDEX on a 1-byte OCCURS field helps parsing by:
4. When a delimiter is missing in input you should typically:
5. REXX PARSE or Ideal PARSE/ENDPARSE: