Vision:Report (Quikjob)

VISION:Report is a language almost nobody chose to write in and a great many people wrote in anyway. It began in the middle of the 1970s as QUIKJOB, a report writer and file utility for IBM mainframes sold by Systems Software Support, Inc., at a moment when the alternative to a one-off COBOL program was another one-off COBOL program. It was bought, renamed, bought, renamed again and bought again - Goal Systems, Sterling Software, Computer Associates, Broadcom; QUIKJOB II, QUIKJOB III, DYL-QUIKJOB, Sterling QUIKJOB, ANSWER:Report, VISION:Report, Advantage VISION:Report - and through all of it the thing you put in your JCL never changed:

//STEP1   EXEC  PGM=QUIKJOB,REGION=512K

Fifty years and four owners later, the load module is still called QUIKJOB. That line, printed in a Computer Associates manual whose sample output is dated 2002, is the most honest summary of the product’s history available.

What it was for

The pitch was time. A COBOL program that copies a tape to disk needs an IDENTIFICATION DIVISION, an ENVIRONMENT DIVISION, a FILE SECTION with an FD and an 01 record layout for both files, a PROCEDURE DIVISION, a compile, a link and a go. The QUIKJOB equivalent, reproduced verbatim from the reference guide’s first example, is five lines:

010  GET
     MOVE  INF1-352      TO  OFA1
     WRITE OFA
     GOTO 010
9999 END

There is no file description because there is no need for one: INF is the input area, OFA is the first output area, and their sizes come from the JCL. A field is a byte range. GET with no operand reads the primary input file. The statement numbered 9999 ends the program. The manual’s claim - “first time users can be up and running after less than eight hours of training” - is a vendor claim, but it is not an unreasonable one for a language of this shape.

That economy is the whole design. As CA’s guide puts it, “because VISION:Report requires you to define only those fields to be used, time-consuming COBOL file definition activity is eliminated.” You describe the parts of the record you care about and ignore the other three hundred bytes.

The storage model

VISION:Report has no variables. It has areas, each with a fixed name and a fixed role, and a field is a named window onto one of them:

Fields are cut out of those areas by EQU:

EQU PLANT     INF1-2
EQU DEPT      INF3-5
EQU EMP-NAME  INF10-25
EQU HR-RATE   INF46-49    2C
EQU GROSS-PAY INF54-58-P  2C
EQU SAVE-DEPT WST1-3      SPACES

INF46-49 2C is bytes 46 to 49 of the input record, treated as a number with two decimals and edited as ZZZ,ZZZ,ZZ9.99 on output. The -P suffix says packed decimal; -B says binary; 2E gives the European edit mask ZZZ.ZZZ.ZZ9,99. This is a language in which data representation is something you spell out per field, in the field definition, because the files it was built to read were laid out by somebody else long ago.

VAL deserves a note of its own. It is a several-hundred-byte communication area whose every offset is documented in the manual: VAL67-70 holds the ABEND code you want issued, VAL180 tells you whether you are at grand-total time, offsets 240 through 260 are the VSAM feedback block, 273-280 hold the literal SQLCA, and 285-288 are the DB2 return code. Programs poke it and peek at it. It is the API.

The report writer

The other half of the language is declarative, and it is the half the product was sold on. You describe the report and the control-break structure; the runtime does the headings, the spacing, the page breaks, the subtotals and the grand totals. From the manual’s twenty-fifth example:

SORT FILE INF ON PLANT DEPT

TITLE1 'COMPUTER ASSOCIATES'
TITLE2 'PAYROLL DISTRIBUTION FOR PLANT $PLANT$'

REPORT DEPT (DEPT-NAME)                /* FIELD 1
       SPACE9
       SAVE-DEPT (DEPT-NO)
       HR-WORKED (HOURS-WORKED)        /* FIELD 2
       GROSS-PAY                       /* FIELD 3
       AVG-RATE (AVERAGE-HOURLY.RATE)  /* FIELD 4
       NR-EMP (NUMBER-OF-EMPLOYEES)    /* FIELD 5

BREAK 1 DEPT  SB 1 SA 1 PRINT C'DEPT TOTAL'
BREAK 2 PLANT SB 1 SA E PRINT C'PLANT TOTAL'

010 GET INF ATEND EOJ
    CHECKBREAKS ON BREAKS PERFORM 100 THRU 200
    MOVE  DEPT TO SAVE-DEPT
    ACCUM HR-WORKED IN A 4 BYTE CTA
    ACCUM GROSS-PAY IN A 5 BYTE CTB
    ACCUM NONE      IN A 3 BYTE CTC
    ACCUM ONE       IN A 3 BYTE CTD
    PRINT REPORT SUMMARY
    GOTO 010

100  DIVD CTB4-8-P 2D BY CTA5-8-P 0D GIVING CTC6-8-P 2D
     IF VAL180 EQ C'F'
        MOVE C'DIVISION TOTALS' TO PRT1.
200  EXIT
     GOTO EOJ
9999END

Several idioms of the language are visible at once. Column headings come from the parenthesised names, with a period standing in for a space in a heading word (AVERAGE-HOURLY.RATE prints as two stacked lines). $PLANT$ interpolates a field’s value into a title. BREAK levels are numbered, with SB/SA giving lines to space before and after and SA E meaning eject. ACCUM ONE counts records; ACCUM NONE reserves an accumulator that nothing feeds, so a control-break routine can compute into it - which is how the weighted average above gets calculated. And the trailing period on the MOVE is not punctuation: per Rule K of the manual’s general rules, a period ends true-condition processing and marks the next statement as the start of the false branch.

Changing PRINT REPORT to PRINT REPORT SUMMARY suppresses every detail line and leaves only the totals. One word, one line, a different report - which is about as compact a demonstration of what a 4GL was for as the era produced.

What else is in there

For a language with no block structure, VISION:Report accumulated a large surface. IF takes compound conditions, nests, has ELSE and ENDIF, and supports class tests - NUMERIC, ALPHA, SPACES, ZEROS, HIVALUES, LOVALUES - plus ONTABLE for table lookup and test-under-mask operands for bit work, alongside AND, OR, XOR, TRAN and TRNT. Arithmetic is ADD/SUB/MULT/DIVD ... GIVING with per-operand decimal counts. SORT AREA with RELEASE and RETURN runs an internal sort inside the same pass. CALL invokes Assembler or COBOL subroutines, and a shelf of supplied ones covers date arithmetic (QUIKDATE), tables (QUIKTABL), timing (QUIKTIME), ASCII/EBCDIC translation (QUIKTRAN), PDS access (QUIKPDS), random numbers and more. QUIKVSAM wraps VSAM; optional interfaces reach CA-IDMS/DB, IMS and DL/I, DB2 and SQL/DS, ADABAS, TOTAL and DBOMP. Source can be pulled from PDS members, CA-Librarian or CA-Panvalet.

The claimed efficiency argument was the single pass: “conditional record selection, sorting, translating, matching, and merging can all occur with only one read of the master file.” On a machine where the master file was on tape and the tape was the bottleneck, that was the argument that mattered. It is worth being precise about what is and is not claimed here - the manual asserts the single-pass structure, not any measured throughput figure, and no benchmark comparing VISION:Report against COBOL or against its rivals has been found.

Per the reference guide, VISION:Report runs under z/OS, OS/390, MVS/SP/XA/ESA, VSE/SP/ESA and VM/CMS. No implementation outside the IBM mainframe environment is documented in any source found.

The ownership chain

The product’s corporate history is more eventful than its technical one.

Systems Software Support, Inc. sold QUIKJOB through the 1970s, and the QUIKJOB trademark filed in September 1979 carries Goal Systems International of Columbus, Ohio as its owner of record - a data-centre software house that Legent acquired in 1992. Exactly when the product passed from Systems Software Support to Goal is not documented in any source found; the trademark record does not settle it, since ownership fields there are updated on assignment. What is dated is the next step: Sterling Software bought QUIKJOB from Goal in 1988 and dropped it into the product line it had built around Dylakor, the Woodland Hills company behind the DYL-260 and DYL-280 report writers. That put QUIKJOB in the same catalogue as the report writers it had spent more than a decade competing against, which is why the 1997 Sterling catalogue lists VISION:Report (ex-QUIKJOB), VISION:Sixty (ex-DYL-260), VISION:Eighty (ex-DYL-280) and VISION:Results (ex-DYL-280 II) as four separate products doing broadly the same job.

Sterling renamed everything twice - first to ANSWER: prefixes, then in the mid-1990s to VISION: - and Computer Associates bought Sterling in 2000 and applied its own Advantage prefix on top. Broadcom acquired CA in 2018. Four renames and four owners produced no visible change in the language, and the JCL still says PGM=QUIKJOB.

Where it stands

VISION:Report is dormant, and has been for roughly two decades. Release 16.1’s reference guide, with sample output dated September 2002, is the last public documentation; the product is absent from Broadcom’s current mainframe portfolio pages and from its mainframe product lifecycle table, though the manual is still served from Broadcom’s own documentation host and independent trackers still record the product as supported. Customers were being answered about it on CA’s forums as recently as 2014.

What activity there is now is mostly the activity of leaving. Pacific Systems Group sells a Quikjob-syntax-compatible version of its own report writer on the explicit promise that existing programs and JCL need no changes. UV Software publishes a guide for converting QuikJob programs to Unix utilities. mLogica has a case study on translating about 150 QUICKJOB programs - some 33,000 lines - to Micro Focus COBOL for an insurer, and its framing is telling: QUICKJOB was “initially perceived as an ancillary system component” and turned out to be the thing that blocked the cutover.

Why it matters

QUIKJOB belongs to a family of products - Easytrieve, DYL-280, Mark IV, RPG’s various descendants - that solved the same problem in the same decade and were collectively far more consequential than their obscurity suggests. Between them they wrote a large fraction of the reports that businesses ran on for thirty years, and they did it by making a bet that has been made repeatedly since: that most data processing is the same handful of shapes, and that a small language which knows those shapes will beat a general-purpose one that has to be told them each time.

The bet paid. It also produced exactly the situation that “legacy” now means. The programs were quick to write, which meant a lot of them got written, which meant they were still running when the language stopped being sold. Nothing in a five-line QUIKJOB program tells you it is doing something important; the one-shot job that “often became regular production”, as UV Software’s guide puts it, is the characteristic artefact of the whole genre.

Its last distinction is the one it never lost. Systems Software Support named the program QUIKJOB sometime around 1975, and in 2026 the name survives in every JCL deck that still runs it - outliving the company that wrote it, the three companies that resold it and the brands that were painted over it.