table of expressions

Not really, I think, because the underlying type is a COBOL group item using picture clauses (i.e. classic COBOL data types), rather than managed types.

In managed code, classic COBOL types are implemented as (portions of) byte arrays. So in theory it might be possible to do something like

declare accountclass = table of binary-char unsigned occurs 33
    (
    table of binary-char unsigned ( "P" "C" "0" ... )
    ...
    )

But obviously that's not going to be a good way to do it.

Sometimes, depending on the use case, it's worth creating a class that maps to your classic COBOL data structure and supports marshaling to it. For example:

class-id InterestRateEntry.

*> Class method that copies an array of InterestRateEntry objects into a COBOL group item of sufficient size
method-id PopulateInterestRateTable static.
linkage section.
*> This would probably be in a copybook
01  Interest-Rate-Table-Entry.
    05  Interest-Rate-Value pic x(11) occurs 1000 times. *> or whatever the max is
procedure division using by reference entries as type InterestRateEntry occurs any
                         by reference Interest-Rate-Table.
    declare idx as binary-long
    perform varying idx from 1 by 1 until idx > entries::Count
        move entries(idx)::InterestRateValue to Interest-Rate-Value(idx)
    end-perform
end method PopulateInterestRateTable.

1 interestRateValue string property as "InterestRateValue" with no set.

method-id new(string value).
    set interestRateValue to value
end method new.

end class InterestRateEntry.

Then you can define your table using managed syntax:

declare accountclass = table of type InterestRateEntry
    (
    new InterestRateEntry("PC075080078")
    new InterestRateEntry("RC065070068")
    new InterestRateEntry("MC055060058")
    )

and to use it in its classic COBOL form:

invoke type InterestRateEntry::PopulateInterestRateTable(accountclass, InterestRateValues)

and then on with your classic COBOL code for referring to SavingsInterestCode, etc. It might also be useful to have properties such as SavingsInterestCode in the InterestRateEntry class. Personally, for all new code I'd use managed types and OO constructs, and only use the existing COBOL structure when interfacing with old code.