table of expressions
Can this be written as a table of expression. For example declare accountclass = table of (...).
10 pic x(11) value "PC075080078".
10 pic x(11) value "RC065070068".
10 pic x(11) value "MC055060058".
05 SavingsInterestTable redefines InterestRateValues.
10 SavingsInterestArea occurs 3 times indexed by intcode-index.
15 SavingsInterestCode pic x(2).
15 InterestRateEntry occurs 3 times indexed by intrate-index.
20 InterestRate pic V9(3).
RE: 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 method that copies an array of InterestRateEntry objects into a COBOL group item of sufficient size
method-id PopulateInterestRateTable static.
*> This would probably be in a copybook
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 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
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.