Easytrieve ACCESS Statement

Most beginner Easytrieve programs live entirely in FILE and READ—payroll FB datasets on JCL DD statements. Enterprise programs also pull rows from DB2 tables, reference IDMS databases, or use extended access paths documented for Easytrieve Plus. The ACCESS statement opens that door: it establishes the runtime connection or access context so subsequent SQL, GET, or database verbs can retrieve and update rows. ACCESS does not replace FILE for sequential extracts; it complements Library definitions when your activity must reach relational data. Syntax, parameters, and authorization differ by data manager and release—DB2 integration chapter versus base Report Generator manual. This page teaches when ACCESS applies, typical placement in Activity setup, relationship to DEFINE fields hosting column values, error handling after failed connect, contrast with ordinary OPEN READ, and checklist steps before coding database access in production batch or online SCREEN activities.

Progress0 of 0 lessons

When You Need ACCESS

Use ACCESS when program requirements explicitly reference database tables, SQL SELECT, or vendor database verbs—not when a flat file DD suffices. Merge job combining master file with DB2 rate table is classic pattern: READ employee from file, ACCESS rate table or open once at job start, fetch rate by key, compute pay. Inquiry SCREEN showing customer balance from DB2 may ACCESS at screen initiation. Pure sequential sort-report jobs never need ACCESS—avoid complexity until business data leaves file-only realm.

ACCESS Versus FILE and OPEN

ACCESS compared to file I/O
AspectFILE / READACCESS
Data sourceSequential or VSAM dataset via DDDB2 IDMS or extended store
DeclarationFILE in LibraryACCESS parameters in Activity or setup
Typical verbREAD GET WRITESQL GET per integration guide
Product needBase Report GeneratorOften Plus or Integrating option

Typical Placement in Program Flow

ACCESS often runs once at activity start—before loop reading driver file—or at SCREEN INITIATION PROC before displaying data. Repeated ACCESS inside every record loop wastes connect overhead unless documentation requires per-request scope. Pair with CLOSE or documented disconnect at activity end when connection pooling not automatic. Job restart mid-run may require idempotent ACCESS handling—coordinate with operations.

text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
* Illustrative pattern—verify syntax on your release JOB INPUT EMPFILE PERFORM DB-CONNECT DO WHILE EOF EQ N READ EMPFILE PERFORM FETCH-RATE-FROM-DB PERFORM CALC-PAY PRINT PAY-RPT END-DO PERFORM DB-DISCONNECT STOP DB-CONNECT. PROC ACCESS ... END-PROC

Field Definitions for Database Columns

DEFINE working fields matching column types—character, decimal, date—as host variables receiving fetch results. Length and scale mismatch causes truncation or SQL conversion errors. Nullable columns need indicator handling per integration guide—separate indicator fields or special null constants. Do not reuse FILE record buffer for DB columns unless layout intentionally unified.

Authorization and Environment

DB2 plans, packages, and GRANT authority live outside Easytrieve source but block runtime ACCESS. Test region IDs may differ from production—ACCESS succeeds in dev and fails in prod with -922 or authorization codes. Document required DB privileges beside ACCESS statement in program readme. JCL may need STEPLIB and DB2 subsystem parameters beyond ordinary batch Easytrieve proc.

Error Handling After ACCESS

Failed ACCESS should not fall through to SQL or GET assuming connection live. DISPLAY SQLCODE or status, increment error counter, ABEND or route to exception when policy requires. Retry logic for timeout differs from permanent auth failure—do not infinite loop ACCESS on bad password. See lifecycle error handling and file functions for status patterns parallel to database return codes.

ACCESS in SCREEN Activities

Online transactions may ACCESS during INITIATION or BEFORE-SCREEN PROC, hold connection for session, disconnect on TERMINATION. Long-held connections affect DB2 thread limits— follow shop standard for pool versus per-transaction ACCESS. AFTER-SCREEN validation may re-query database to confirm update committed.

Performance Considerations

  • Open ACCESS once per job when rate table shared across all employees.
  • Fetch by key indexed on DB side—avoid full table scan per detail row.
  • Batch commit intervals when updating many DB rows—transaction scope per manual.
  • Compare DB path cost versus pre-extracted flat file when run window tight.

Common ACCESS Mistakes

  • Using ACCESS on site without database option licensed.
  • Skipping ACCESS before first SQL or DB GET.
  • Column DEFINE mismatch with table DDL.
  • No error branch on failed connect.
  • ACCESS inside tight loop without caching lookup results.
  • Confusing ACCESS with VSAM OPEN—different verbs and status.

Explain It Like I'm Five

FILE and READ are like reading a book on your desk. ACCESS is like calling the library and asking them to bring a special reference book you do not keep at home. You still need to know how to read the pages—DEFINE fields—but first you must connect to the library system. Not every Easytrieve program needs the library; many only read the book already on the desk.

Exercises

  1. Explain when FILE alone suffices versus when ACCESS may be needed.
  2. Sketch job flow with one ACCESS at start and READ loop on driver file.
  3. List three prerequisites outside source code—DB grants JCL plan.
  4. Describe error handling if ACCESS fails before loop.
  5. Contrast ACCESS placement in batch JOB versus SCREEN activity.

Quiz

Test Your Knowledge

1. ACCESS statement typically appears in:

  • Activity section for database or extended I/O
  • JCL only
  • REPORT TITLE
  • Link-edit

2. ACCESS differs from FILE because:

  • FILE declares layout; ACCESS opens access path per grammar
  • They are identical
  • ACCESS is Library only
  • FILE is online only

3. Before ACCESS on DB2 tables you usually:

  • Define fields matching column layout and verify Plus/SQL option
  • Skip Library section
  • Use only REPORT
  • Disable PARM

4. ACCESS without error handling may:

  • ABEND or leave program in bad state on connect failure
  • Always continue silently
  • Compile only never run
  • Sort file automatically

5. Batch-only Report Generator sites may:

  • Lack ACCESS to relational databases—verify product level
  • Require ACCESS on every program
  • Replace READ with ACCESS always
  • Use ACCESS in TITLE only
Published
Read time15 min
AuthorMainframeMaster
Reviewed by MainframeMaster teamVerified: Broadcom Easytrieve Integrating and Plus database ACCESS patterns; site-specific syntaxSources: Broadcom Easytrieve 11.6 Integrating, EZT Plus database chaptersApplies to: Easytrieve ACCESS statement for database and extended access