Case Study 1: Designing a Customer Account Record at Continental Savings Bank
Background
Continental Savings Bank (CSB) is a mid-sized financial institution with 1.2 million retail customers and 340,000 commercial accounts. Their core banking system runs on an IBM z15 mainframe under z/OS, processing an average of 8 million transactions daily across checking, savings, money market, and certificate of deposit accounts.
In 2024, CSB undertook a modernization initiative to redesign their customer master file. The existing file had been in production since 1991 and suffered from several data representation problems: account numbers stored as alphanumeric fields wasted disk space and slowed comparisons, monetary amounts used DISPLAY format instead of packed decimal, and date fields were stored as six-digit fields without century digits -- a remnant of a hasty Y2K patch that simply added a separate century byte rather than properly redesigning the date layout.
Rachel Okonkwo, a senior COBOL architect, was tasked with designing the new customer account record layout. Her mandate was clear: choose the most appropriate PICTURE clause, USAGE, and data representation for every field in the record, optimizing for storage efficiency, processing speed, and long-term maintainability.
The Problem
Rachel's team identified the following requirements for the new customer master record:
-
Account Number -- A 10-digit numeric identifier. Must support direct comparison and sorting. Leading zeros are significant (account 0000000001 is valid and distinct from account 0000000010).
-
Customer Name -- Last name (up to 25 characters), first name (up to 20 characters), middle initial (1 character). Must be stored in a way that supports both individual field access and full-name display.
-
Address -- Street (up to 30 characters), city (up to 20 characters), state (2-character code), ZIP code (5-digit base plus optional 4-digit extension).
-
Account Type -- A single-character code: C (checking), S (savings), M (money market), D (certificate of deposit), L (loan). Must support condition-name testing.
-
Account Balance -- Signed monetary amount up to $999,999,999.99. Must be stored in packed decimal (COMP-3) for efficient arithmetic and minimal storage.
-
Interest Rate -- Annual percentage rate from 0.000% to 99.999%. Three decimal places required for precision.
-
Date Fields -- Account open date, last transaction date, and last statement date. All dates must include full four-digit year, two-digit month, and two-digit day. Must support both numeric comparison and formatted display.
-
Transaction Counters -- Number of deposits and withdrawals in the current month. Maximum 9,999 transactions per counter.
-
Status Flags -- Account active/inactive, overdraft protection enrolled, paperless statement preference, foreign national indicator.
-
Reserved Space -- 20 bytes reserved for future expansion, initialized to spaces.
The design must minimize record size (the file holds 1.5 million records, so every byte matters) while ensuring that arithmetic fields use the most efficient internal representation.
The Solution: Record Layout Design
Design Decisions
Rachel began by categorizing each field by its primary purpose and choosing the appropriate PICTURE clause and USAGE:
| Field | Purpose | PIC Clause | USAGE | Rationale |
|---|---|---|---|---|
| Account Number | Identifier, sort key | 9(10) | DISPLAY | Readable in dumps, used as file key |
| Name fields | Display text | X(n) | DISPLAY | Alphanumeric, no arithmetic needed |
| State Code | Code lookup | X(2) | DISPLAY | Two-letter abbreviation |
| ZIP Code | Identifier | 9(5), 9(4) | DISPLAY | Numeric but no arithmetic needed |
| Account Balance | Arithmetic | S9(9)V99 | COMP-3 | Packed decimal for efficient math |
| Interest Rate | Arithmetic | 9(2)V9(3) | COMP-3 | Packed decimal for rate calculations |
| Date fields | Comparison, display | 9(8) | DISPLAY | YYYYMMDD for natural sort order |
| Counters | Arithmetic | S9(4) | COMP-3 | Packed decimal, small footprint |
| Flags | Boolean testing | X(1) | DISPLAY | Single character with 88-levels |
| Reserved | Future use | X(20) | DISPLAY | Spaces for expansion |
Key design principle: Use COMP-3 (packed decimal) for every field that participates in arithmetic operations. Use DISPLAY for fields that are identifiers, codes, or text. This rule is simple, consistent, and produces optimal results on z/OS where packed decimal instructions are implemented in hardware.
Storage Analysis
Rachel calculated the storage impact of her design choices:
Account Balance: DISPLAY vs. COMP-3
PIC S9(9)V99 DISPLAY= 12 bytes (one byte per digit, including sign as overpunch)PIC S9(9)V99 COMP-3= 7 bytes (two digits per byte, plus half byte for sign)
Savings per record: 5 bytes. Across 1.5 million records: 7.5 megabytes saved on this one field alone.
Interest Rate: DISPLAY vs. COMP-3
PIC 9(2)V9(3) DISPLAY= 5 bytesPIC 9(2)V9(3) COMP-3= 3 bytes
Savings per record: 2 bytes. Across 1.5 million records: 3 megabytes saved.
Total record size with COMP-3 optimization: 168 bytes. What it would have been in all-DISPLAY: 185 bytes. Overall savings: 17 bytes per record, or 25.5 megabytes across the file.
The Complete COBOL Program
The following program demonstrates the full record layout, loads sample customer data, performs arithmetic operations on the packed-decimal fields, and displays formatted output. It validates each design decision by exercising every field in the record.
IDENTIFICATION DIVISION.
PROGRAM-ID. CUSTMAST.
AUTHOR. RACHEL OKONKWO.
DATE-WRITTEN. 2024-09-15.
*================================================================
* PROGRAM: CUSTMAST
* PURPOSE: Demonstrate the customer master record layout
* for Continental Savings Bank. This program
* populates sample records, performs balance
* calculations, and produces formatted output
* showing all field types and representations.
*================================================================
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
DECIMAL-POINT IS COMMA.
DATA DIVISION.
WORKING-STORAGE SECTION.
*----------------------------------------------------------------
* CUSTOMER MASTER RECORD LAYOUT
* Total record length: 168 bytes
*----------------------------------------------------------------
01 WS-CUSTOMER-RECORD.
* --- Account Identification ---
05 WS-ACCOUNT-NUMBER PIC 9(10).
* --- Customer Name ---
05 WS-CUSTOMER-NAME.
10 WS-LAST-NAME PIC X(25).
10 WS-FIRST-NAME PIC X(20).
10 WS-MIDDLE-INIT PIC X(1).
* --- Customer Address ---
05 WS-CUSTOMER-ADDRESS.
10 WS-STREET PIC X(30).
10 WS-CITY PIC X(20).
10 WS-STATE PIC X(2).
10 WS-ZIP-CODE.
15 WS-ZIP-BASE PIC 9(5).
15 WS-ZIP-EXT PIC 9(4).
* --- Account Classification ---
05 WS-ACCOUNT-TYPE PIC X(1).
88 ACCT-CHECKING VALUE 'C'.
88 ACCT-SAVINGS VALUE 'S'.
88 ACCT-MONEY-MARKET VALUE 'M'.
88 ACCT-CD VALUE 'D'.
88 ACCT-LOAN VALUE 'L'.
88 ACCT-DEPOSIT-TYPE VALUE 'C' 'S'
'M' 'D'.
88 ACCT-VALID-TYPE VALUE 'C' 'S'
'M' 'D' 'L'.
* --- Monetary Fields (COMP-3 for efficiency) ---
05 WS-ACCOUNT-BALANCE PIC S9(9)V99 COMP-3.
05 WS-INTEREST-RATE PIC 9(2)V9(3) COMP-3.
* --- Date Fields (YYYYMMDD for natural sort order) ---
05 WS-ACCOUNT-OPEN-DATE.
10 WS-OPEN-YEAR PIC 9(4).
10 WS-OPEN-MONTH PIC 9(2).
10 WS-OPEN-DAY PIC 9(2).
05 WS-LAST-TRANS-DATE.
10 WS-LTRANS-YEAR PIC 9(4).
10 WS-LTRANS-MONTH PIC 9(2).
10 WS-LTRANS-DAY PIC 9(2).
05 WS-LAST-STMT-DATE.
10 WS-LSTMT-YEAR PIC 9(4).
10 WS-LSTMT-MONTH PIC 9(2).
10 WS-LSTMT-DAY PIC 9(2).
* --- Transaction Counters (COMP-3) ---
05 WS-DEPOSIT-COUNT PIC S9(4) COMP-3.
05 WS-WITHDRAWAL-COUNT PIC S9(4) COMP-3.
* --- Status Flags ---
05 WS-ACCOUNT-STATUS PIC X(1).
88 ACCT-ACTIVE VALUE 'A'.
88 ACCT-INACTIVE VALUE 'I'.
88 ACCT-CLOSED VALUE 'X'.
88 ACCT-FROZEN VALUE 'F'.
05 WS-OVERDRAFT-FLAG PIC X(1).
88 OVERDRAFT-ENROLLED VALUE 'Y'.
88 OVERDRAFT-NOT-ENROLLED VALUE 'N'.
05 WS-PAPERLESS-FLAG PIC X(1).
88 PAPERLESS-YES VALUE 'Y'.
88 PAPERLESS-NO VALUE 'N'.
05 WS-FOREIGN-NATIONAL PIC X(1).
88 IS-FOREIGN-NATIONAL VALUE 'Y'.
88 IS-DOMESTIC VALUE 'N'.
* --- Reserved for Future Expansion ---
05 WS-RESERVED PIC X(20).
*----------------------------------------------------------------
* FORMATTED DISPLAY FIELDS
*----------------------------------------------------------------
01 WS-DISPLAY-BALANCE PIC $ZZZ,ZZZ,ZZ9.99-.
01 WS-DISPLAY-RATE PIC Z9.999.
01 WS-DISPLAY-DATE PIC X(10).
01 WS-DISPLAY-ACCT-TYPE PIC X(15).
*----------------------------------------------------------------
* CALCULATION WORK FIELDS
*----------------------------------------------------------------
01 WS-INTEREST-AMOUNT PIC S9(9)V99 COMP-3.
01 WS-NEW-BALANCE PIC S9(9)V99 COMP-3.
01 WS-DAILY-RATE PIC 9V9(8) COMP-3.
*----------------------------------------------------------------
* REPORT COUNTERS
*----------------------------------------------------------------
01 WS-RECORD-COUNT PIC S9(5) COMP-3
VALUE ZERO.
01 WS-TOTAL-DEPOSITS PIC S9(11)V99 COMP-3
VALUE ZERO.
PROCEDURE DIVISION.
0000-MAIN-CONTROL.
PERFORM 1000-INITIALIZE
PERFORM 2000-LOAD-SAMPLE-DATA
PERFORM 3000-DISPLAY-RECORD
PERFORM 4000-CALCULATE-INTEREST
PERFORM 5000-DISPLAY-RESULTS
PERFORM 9000-FINALIZE
STOP RUN
.
1000-INITIALIZE.
INITIALIZE WS-CUSTOMER-RECORD
INITIALIZE WS-INTEREST-AMOUNT
INITIALIZE WS-NEW-BALANCE
DISPLAY "==========================================="
DISPLAY " CONTINENTAL SAVINGS BANK"
DISPLAY " CUSTOMER MASTER RECORD DEMONSTRATION"
DISPLAY "==========================================="
.
2000-LOAD-SAMPLE-DATA.
* --- Populate a sample customer record ---
MOVE 0012345678 TO WS-ACCOUNT-NUMBER
MOVE "MARTINEZ" TO WS-LAST-NAME
MOVE "ELENA" TO WS-FIRST-NAME
MOVE "R" TO WS-MIDDLE-INIT
MOVE "1247 OAK VALLEY DRIVE"
TO WS-STREET
MOVE "SPRINGFIELD" TO WS-CITY
MOVE "IL" TO WS-STATE
MOVE 62704 TO WS-ZIP-BASE
MOVE 3182 TO WS-ZIP-EXT
SET ACCT-SAVINGS TO TRUE
MOVE 45872.35 TO WS-ACCOUNT-BALANCE
MOVE 04.250 TO WS-INTEREST-RATE
* --- Account opened: March 15, 2018 ---
MOVE 2018 TO WS-OPEN-YEAR
MOVE 03 TO WS-OPEN-MONTH
MOVE 15 TO WS-OPEN-DAY
* --- Last transaction: January 22, 2025 ---
MOVE 2025 TO WS-LTRANS-YEAR
MOVE 01 TO WS-LTRANS-MONTH
MOVE 22 TO WS-LTRANS-DAY
* --- Last statement: December 31, 2024 ---
MOVE 2024 TO WS-LSTMT-YEAR
MOVE 12 TO WS-LSTMT-MONTH
MOVE 31 TO WS-LSTMT-DAY
* --- Counters and flags ---
MOVE 7 TO WS-DEPOSIT-COUNT
MOVE 3 TO WS-WITHDRAWAL-COUNT
SET ACCT-ACTIVE TO TRUE
SET OVERDRAFT-ENROLLED TO TRUE
SET PAPERLESS-YES TO TRUE
SET IS-DOMESTIC TO TRUE
MOVE SPACES TO WS-RESERVED
.
3000-DISPLAY-RECORD.
DISPLAY " "
DISPLAY "--- CUSTOMER RECORD DETAILS ---"
DISPLAY " "
* --- Format and display account number ---
DISPLAY "ACCOUNT NUMBER: " WS-ACCOUNT-NUMBER
* --- Display name fields individually and as group ---
DISPLAY "LAST NAME: " WS-LAST-NAME
DISPLAY "FIRST NAME: " WS-FIRST-NAME
DISPLAY "MIDDLE INITIAL: " WS-MIDDLE-INIT
* --- Display address ---
DISPLAY "STREET: " WS-STREET
DISPLAY "CITY: " WS-CITY
DISPLAY "STATE: " WS-STATE
DISPLAY "ZIP CODE: " WS-ZIP-BASE "-"
WS-ZIP-EXT
* --- Display account type using condition names ---
EVALUATE TRUE
WHEN ACCT-CHECKING
MOVE "CHECKING" TO WS-DISPLAY-ACCT-TYPE
WHEN ACCT-SAVINGS
MOVE "SAVINGS" TO WS-DISPLAY-ACCT-TYPE
WHEN ACCT-MONEY-MARKET
MOVE "MONEY MARKET" TO WS-DISPLAY-ACCT-TYPE
WHEN ACCT-CD
MOVE "CERTIFICATE" TO WS-DISPLAY-ACCT-TYPE
WHEN ACCT-LOAN
MOVE "LOAN" TO WS-DISPLAY-ACCT-TYPE
WHEN OTHER
MOVE "*** UNKNOWN ***" TO WS-DISPLAY-ACCT-TYPE
END-EVALUATE
DISPLAY "ACCOUNT TYPE: " WS-DISPLAY-ACCT-TYPE
* --- Format and display balance (COMP-3 to edited) ---
MOVE WS-ACCOUNT-BALANCE TO WS-DISPLAY-BALANCE
DISPLAY "BALANCE: " WS-DISPLAY-BALANCE
* --- Format and display interest rate ---
MOVE WS-INTEREST-RATE TO WS-DISPLAY-RATE
DISPLAY "INTEREST RATE: " WS-DISPLAY-RATE "%"
* --- Format dates for display ---
STRING WS-OPEN-MONTH DELIMITED BY SIZE
"/" DELIMITED BY SIZE
WS-OPEN-DAY DELIMITED BY SIZE
"/" DELIMITED BY SIZE
WS-OPEN-YEAR DELIMITED BY SIZE
INTO WS-DISPLAY-DATE
END-STRING
DISPLAY "ACCOUNT OPENED: " WS-DISPLAY-DATE
* --- Display transaction counters ---
DISPLAY "DEPOSITS MTD: " WS-DEPOSIT-COUNT
DISPLAY "WITHDRAWALS MTD:" WS-WITHDRAWAL-COUNT
* --- Display status flags using condition names ---
DISPLAY " "
DISPLAY "--- STATUS FLAGS ---"
IF ACCT-ACTIVE
DISPLAY "ACCOUNT STATUS: ACTIVE"
ELSE
DISPLAY "ACCOUNT STATUS: INACTIVE"
END-IF
IF OVERDRAFT-ENROLLED
DISPLAY "OVERDRAFT PROT: ENROLLED"
ELSE
DISPLAY "OVERDRAFT PROT: NOT ENROLLED"
END-IF
IF PAPERLESS-YES
DISPLAY "STATEMENT TYPE: ELECTRONIC"
ELSE
DISPLAY "STATEMENT TYPE: PAPER"
END-IF
IF IS-FOREIGN-NATIONAL
DISPLAY "RESIDENCY: FOREIGN NATIONAL"
ELSE
DISPLAY "RESIDENCY: DOMESTIC"
END-IF
.
4000-CALCULATE-INTEREST.
* --- Demonstrate COMP-3 arithmetic ---
* Calculate daily interest rate
DIVIDE WS-INTEREST-RATE BY 365
GIVING WS-DAILY-RATE ROUNDED
END-DIVIDE
* Calculate 30-day interest on current balance
MULTIPLY WS-ACCOUNT-BALANCE BY WS-DAILY-RATE
GIVING WS-INTEREST-AMOUNT ROUNDED
END-MULTIPLY
MULTIPLY WS-INTEREST-AMOUNT BY 30
GIVING WS-INTEREST-AMOUNT ROUNDED
END-MULTIPLY
* Compute new balance
ADD WS-ACCOUNT-BALANCE WS-INTEREST-AMOUNT
GIVING WS-NEW-BALANCE
END-ADD
.
5000-DISPLAY-RESULTS.
DISPLAY " "
DISPLAY "--- INTEREST CALCULATION ---"
MOVE WS-ACCOUNT-BALANCE TO WS-DISPLAY-BALANCE
DISPLAY "CURRENT BALANCE: " WS-DISPLAY-BALANCE
MOVE WS-INTEREST-AMOUNT TO WS-DISPLAY-BALANCE
DISPLAY "30-DAY INTEREST: " WS-DISPLAY-BALANCE
MOVE WS-NEW-BALANCE TO WS-DISPLAY-BALANCE
DISPLAY "PROJECTED BAL: " WS-DISPLAY-BALANCE
DISPLAY " "
* --- Demonstrate the deposit-type group condition ---
IF ACCT-DEPOSIT-TYPE
DISPLAY "This is a deposit account. Interest "
"will be credited."
ELSE
DISPLAY "This is a loan account. Interest "
"will be charged."
END-IF
* --- Display storage analysis ---
DISPLAY " "
DISPLAY "--- STORAGE ANALYSIS ---"
DISPLAY "Total record length: 168 bytes"
DISPLAY " Account number (DISPLAY 9(10)): 10 bytes"
DISPLAY " Customer name (group): 46 bytes"
DISPLAY " Address (group): 61 bytes"
DISPLAY " Account type (DISPLAY X): 1 byte"
DISPLAY " Balance (COMP-3 S9(9)V99): 7 bytes"
DISPLAY " Interest rate (COMP-3 9(2)V999): 3 bytes"
DISPLAY " Three dates (DISPLAY 9(8)): 24 bytes"
DISPLAY " Two counters (COMP-3 S9(4)): 6 bytes"
DISPLAY " Four flags (DISPLAY X): 4 bytes"
DISPLAY " Reserved: 20 bytes"
.
9000-FINALIZE.
DISPLAY " "
DISPLAY "==========================================="
DISPLAY " END OF DEMONSTRATION"
DISPLAY "==========================================="
.
Design Walkthrough
Why PIC 9(10) DISPLAY for the Account Number?
Account numbers are numeric identifiers, not quantities. You never add two account numbers together or compute the average of account numbers. They are used for comparison (matching a transaction to its master record), sorting, and display.
Storing the account number as PIC 9(10) in DISPLAY usage means each digit occupies one byte, making it directly readable in hex dumps and file listings. If it were stored as COMP-3, it would save 5 bytes per record but would require conversion every time someone needed to read it in a dump or use it as a key in a VSAM file (where keys are compared byte-by-byte).
The rule Rachel established: Identifiers and keys stay in DISPLAY format. Only arithmetic fields go to COMP-3.
Why COMP-3 for the Balance?
The account balance field PIC S9(9)V99 COMP-3 stores each digit in a half-byte (nibble), with the sign in the rightmost half-byte. The IBM z/Architecture processor includes hardware instructions (AP, SP, MP, DP) that operate directly on packed-decimal data, making COMP-3 arithmetic faster than DISPLAY arithmetic (which requires conversion to packed format before every operation).
The value 45872.35 is stored as the hex bytes 04 58 72 35 0C (7 bytes), where C in the final nibble indicates a positive sign. In DISPLAY format, the same value would occupy 12 bytes.
Why a Hierarchical Date Structure?
The date fields use a two-level hierarchy:
05 WS-ACCOUNT-OPEN-DATE.
10 WS-OPEN-YEAR PIC 9(4).
10 WS-OPEN-MONTH PIC 9(2).
10 WS-OPEN-DAY PIC 9(2).
This design allows the program to reference the full date as a single 8-byte field (WS-ACCOUNT-OPEN-DATE for comparisons and moves) or to access individual components (WS-OPEN-YEAR, WS-OPEN-MONTH, WS-OPEN-DAY for validation and formatting). The YYYYMMDD format ensures that a simple alphanumeric comparison of the group item produces correct chronological ordering -- a date of "20250122" is naturally greater than "20180315".
Why 88-Level Condition Names for Every Flag and Code?
Every single-character code field in the record has corresponding 88-level condition names. The account type field demonstrates both specific conditions (ACCT-CHECKING, ACCT-SAVINGS) and grouped conditions (ACCT-DEPOSIT-TYPE for all deposit accounts, ACCT-VALID-TYPE for validation).
This means the PROCEDURE DIVISION never contains magic-value comparisons like IF WS-ACCOUNT-TYPE = 'S'. Instead, it reads IF ACCT-SAVINGS, which any business analyst can understand. The grouped condition ACCT-DEPOSIT-TYPE means adding a new deposit account type in the future requires changing only the 88-level VALUE clause, not every IF statement in every program that tests for deposit accounts.
The Reserved Field
The 20-byte WS-RESERVED field, initialized to spaces, is a deliberate design choice. In a file that holds 1.5 million records, adding a new field later means rewriting every record. By reserving space now, future enhancements can use the reserved bytes without changing the record length, avoiding a massive file conversion project.
Rachel specified 20 bytes based on her experience: enough for a medium-length field (such as an email indicator, a mobile phone flag, and a preferred language code) but not so much that it wastes significant space.
Lessons Learned
1. Data Design Is Architecture
The PICTURE clause is not a minor syntactic detail -- it is a fundamental architectural decision. The choice between DISPLAY and COMP-3 affects storage costs, processing speed, and debugging ease. Rachel's team spent two full weeks on the record layout before writing a single line of PROCEDURE DIVISION code.
2. COMP-3 Is for Arithmetic, DISPLAY Is for Everything Else
This simple rule, consistently applied, eliminates the most common data representation mistakes in COBOL programs. The only exception at CSB is COMP (binary) for subscripts and counters used as subscripts, where the hardware comparison instructions favor binary.
3. Condition Names Pay for Themselves
The time spent defining 88-level condition names is repaid many times over. Every program that processes the customer master file can use the same condition-name vocabulary. When a new account type is added, only the copybook containing the record layout needs to change.
4. Hierarchical Group Items Provide Flexibility
By nesting date components under a group item, the record layout supports both full-date operations (comparison, moves) and component-level operations (extracting the year for age calculations) without REDEFINES or reference modification.
5. Plan for the Future
The reserved field is a small investment that prevents enormous future costs. In mainframe environments where files contain hundreds of millions of records, a record layout change that alters the record length triggers a full file conversion -- often a weekend-long batch process requiring coordination across dozens of programs.
Discussion Questions
-
The account number is stored as
PIC 9(10)in DISPLAY format. If CSB needed to support alphanumeric account numbers (containing letters), what changes would be required to the PICTURE clause, and what downstream impacts would this have on programs that use the account number as a sort key? -
The balance field uses
PIC S9(9)V99 COMP-3, which supports values up to $999,999,999.99. What would happen if a high-net-worth customer's combined balance exceeded this amount? How would you redesign the field, and what would the storage impact be? -
Rachel chose DISPLAY format for the date fields. What would be the trade-offs of storing dates as
PIC 9(8) COMP-3instead? Consider both storage savings and the impact on date comparisons and component extraction. -
The record includes four separate single-character flag fields. An alternative design would pack all four flags into a single byte using individual bits. Why did Rachel choose separate fields? In what situations might bit-packing be preferable?
-
The
ACCT-DEPOSIT-TYPEcondition name groups checking, savings, money market, and CD accounts. If the bank adds a new account type "H" for health savings account, what is the minimal change required? Compare this to a design without grouped condition names. -
The reserved field is 20 bytes. What is the cost of this reservation across 1.5 million records? At what point does reserved space become wasteful rather than prudent? How would you decide the appropriate size?
-
Why does the program use
DECIMAL-POINT IS COMMAin the SPECIAL-NAMES paragraph? What populations or regions would require this, and what impact does it have on the PICTURE clause editing symbols used throughout the program?