RE: Getting compile error: *RNF5343 30 21 002100 Array hastoomanyomitted indexes; specification is ignored.

Some background of what I'm doing:
1) I'm trying to write a program to programmatically execute a manual
option on a paging terminal console screen.
2) I'm using Albert's TNAPI program as an example for this.
3) Instead of writing a program that do everything, I'm trying to create
all the VT100 function into a service program.  One of the procedure in
this service program is to convert the VT100 data stream from the server
into a regular readable form.  Apparently, VT100 protocol doesn't send
the entire screen back to the client every time the client requests
something from the server.  Instead, it only sends what need to overlay
on the current screen (It could also send esc sequence to clear screen.)

Because of #3, I need the array (VT100 screen) in this procedure to be
static.  This will allow me to overlay the data from each response that
client gets back from the server.  

Yes, VT100 allow different screen mode.  But because I'm the client, I
choose 24x80.

The only thing the I'm not sure of on the return value is below:
4) If a local variable is declared as static.  What is the effect to use
that as the return value?  Is return value return the pointer of this
static variable?  If so, I don't really want that because that means the
caller can change the value of this static variable.  That is the reason
that I create a non-static variable and use it to return the data.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, March 17, 2006 3:46 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Getting compile error: *RNF5343 30 21 002100 Array
hastoomanyomitted indexes; specification is ignored.


> If I need the internal procedure array to be static, would I still get

> better performance by passing the array in as param?  See below:

The memory of a (by-reference) parameter isn't allocated by the
subprocedure that receives the parms.  So, declaring it static wouldn't
make sense.

Also, you can eliminate the need for pointer logic by making myScreen a
data structure, and making prScreenAry a subfield of that data
structure.

Also, I don't think VT100 screens are fixed at 80 x 24. I think you can
change the number of rows and columns at will.  I suppose the original
VT100 dumb terminals probably had fixed columns & rows, but nowadays,
people who use VT100 emulation are almost always using a PC program of
some sort, and they can all change the number of columns and rows by
dragging the window edge.  (Just something to think about.)
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.