I believe the justification for Enterprise COBOL supporting the new options for
INITIALIZE is because one of the options for the new ALLOCATE statement is the
"INITIALIZED" clause. And example of this is:
identification division.
program-id. alloinit.
data division.
local-storage section.
01 mg-ptr pointer.
linkage section.
01 my-group.
05 with-value pic 9 value 1.
05 without-value pic 9.
05 filler pic 9 value 2.
05 filler pic 9.
procedure division.
allocate my-group initialized
returning mg-ptr
display my-group
free mg-ptr
goback.
end program alloinit.
ALLOCATE with the INITIALIZED clause is the same as if you had specified
ALLOCATE without the INITIALIZED clause but immediately followed it with
"INITIALIZE data-name-1 WITH FILLER ALL TO VALUE THEN TO DEFAULT".
That being said, I believe that the new clauses for the INITIALIZE statement
can be quite useful regardless of ALLOCATE being used. Especially "WITH FILLER
ALL TO VALUE THEN TO DEFAULT" (or slightly more concisely, "FILLER ALL VALUE
DEFAULT". The "un-enhanced" INITIALIZE statement, introduced with the COBOL
1985 standard, was not ideal in that 1) it "ignored" filler, and 2) it set all
of the other fields only to the "default" of the category for each data item.
That is, spaces for alphanumeric fields and zeroes for numeric fields. The
VALUES clauses of the data items had no effect. Given the new clauses, an
"INITIALIZE data-name" statement behaves in the same manner as "INITIALIZE
data-name DEFAULT".
On the other hand, if [WITH] FILLER, ALL [TO] VALUE, and [THEN] [TO] DEFAULT
are all supplied, 1) filler is not ignored, 2) all fields in the group that
have a VALUE clause are set to the value specified in that clause, and 3) all
others are set to the default value for their category.
I dare say, the latter is actually better performing than INITIALIZE with none
of the new clauses (or just the DEFAULT clause) and better than explicitly
setting each field by using a MOVE or SET. This is because filler fields are
not ignored, thus a single "literal" can be used to initialize the entire
record. Basically, given a reasonable set of items within a group, using
INITIALIZE data-name FILLER ALL VALUE DEFAULT does a single MVC from the
literal pool to the data item. (In the case above, since its a very simply
record of just 4 characters it simply does to "move immediate" (MVHHI)
instructions.)
Frank
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Clark Morris <[email protected]>
Sent: Sunday, July 23, 2017 10:39 AM
To: [email protected]
Subject: Re: Enterprise COBOL V6.2
[Default] On 23 Jul 2017 07:10:50 -0700, in bit.listserv.ibm-main
[email protected] (Steve Thompson) wrote:
>The use of INITIALIZE on a Linkage section element was the whole
>point of my posting.
>
>I know of no way to tell, from within a COBOL program, if the
>parm info is valid. A called program assumes that the storage it
>has defined is what has been passed.
>
>This is why IBM is telling people to check their calling programs
>and called programs to make sure they agree on the storage being
>passed between them. (Migration manual, whose number I have
>forgotten, but was a -00).
If you are talking about a PARM on an EXEC statement, I always checked
for the length (first half word, zero if no PARM passed) before using
it in my COBOL and Assembler programs. If this is being called from
another program then whatever checks you make to be sure things are as
expected still apply.
The main use I can see of this is for storage obtained and addressed
using a pointer.
Clark Morris
>
>Regards,
>Steve Thompson
>
>
>On 07/23/2017 07:47 AM, Clark Morris wrote:
>> [Default] On 22 Jul 2017 18:31:37 -0700, in bit.listserv.ibm-main
>> [email protected] (Steve Thompson) wrote:
>>
>>> And what happens when the program gets called with a "zero" parm?
>>
>> Unless an INITIALIZE statement were issued for that field, nothing
>> would happen. The VALUE clause on a data item in the FELE SECTION and
>> LINKAGE SECTION is used in conjunction with the INITIALIZE statement
>> and not to se an initial value.
>>
>> Clark Morris
>>>
>>> One would hope that it gets a S0C4-4 for attempting to initialize
>>> PSA, because if it manages to pickup a random value to base that
>>> 01, who knows what gets overlaid.
>>>
>>> But then, I don't have access to COBOL6.2 yet so I can test this.
>>>
>>> Regards,
>>> Steve Thompson
><SNIPPAGE>
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
