SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Fri, 13 Feb 2004 16:30:17 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: PL/I most important statement (was: call(TZ) ? - PL/I)

Content Type: text/plain

"I use BEGIN blocks in another way. I do a lot of matrix
crunching, so I look at the input data, determine how big the
matrix should be, then start a BEGIN block and allocate the
matrix. ..."

I gave you the two historical reasons for the BEGIN statement.
You offer me one unnecessary instance of its use. You want
to read through the input data to get a count of the number
of instances. Then you want to dynamically allocate space
for a matrix based on that count. In short, you want
something like the following:

dcl funky file input;
dcl rotor fixed bin (31) init (0) static;
dcl value ptr static;
dcl eofswitch char(1) init('0') static;
on endfile(funky) begin;
eofswitch = '1';
end;
read file(funky) set(value);
do while(eofswitch = '0');
rotor += 1;
read file(funky) set(value);
end;
close file(funky);
dcl matrix (*,2) fixed dec (7,2) based(voom);
dcl voom ptr static;
if rotor != 0
then do;
allocate matrix (rotor, 2);
.
.

The only use for the "begin" block here is to handle the
endfile condition for the input file. There's no need for a
"begin" block to allocate space for the matrix.

Before PL/Id had the "based" storage attribute it had "static",
"automatic", and "control". You could have allocated space
for an input record using the control storage attribute. You
would have to allocate it for each input read. That would
have created a stack of input records, only the last of which
available to the program. If you had maintained your count,
you could then allocate your matrix dynamically as control
storage. The you only had to transfer the current input on
top of the stack to the matrix, deallocate that entry on the
stack, which would have "popped" the stack so that the next
entry was available, continuing this process until you had
exhausted the stack.

In short the "allocate" statement in PL/I works the same for
"controlled" and "based" storage in terms of supporting
dynamic allocation at runtime. They are the only means of
doing so, neither of which require the prior use of a "begin"
statement.

In fact as you cannot pass parameters to a "begin" block, as it
does not function as a subroutine, only as an inline code
segment within a procedure, you would have to have its
dimension outside the "begin" segment and declare the matrix
as an 'automatic' storage variable to have PL/I automatically
allocate it on entry to the "begin" segment. All your
processing of the matrix would have to occur within the
"begin" segment as PL/I would automatically deallocate it
upon exit, i.e. reaching the "end" statement for the "begin"
block. I don't know why you would go to all this trouble
when you could simply allocate it dynamically in the first
place using either the "controlled" or "based" storage
attribute.

For others who have come this far the reason for using the
"read file(funky) set(value);" was to avoid having to move
data from the input buffer to a defined input record area. In
this instance you would declare the input record structure as
a variable "based" on the pointer 'value'. Each 'read' then
would set the input record structure template to the next
input record in the buffer.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 13 | February | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.