Re: RNF3826 - A subfield cannot be of type Object

Thanks Scott. I'm going to go for the good old array for now (painful).

D connList DS qualified dim(10)
D INTID 3
D campusID 5 0 inz(0)
D lastUsedTime z

D groupServerDBConn...
D s dim(10) like(Connection)
D addressUpdatePS...
D s dim(10) like(preparedStatement)
D addressInsertPS...
D s dim(10) like(preparedStatement)
D addressDeletePS...
D s dim(10) like(preparedStatement)
D addressSelectPS...
D s dim(10) like(preparedStatement)
D relationshipUpdatePS...
D s dim(10) like(preparedStatement)
D relationshipInsertPS...
D s dim(10) like(preparedStatement)
D relationshipSelectPS...
D s dim(10) like(preparedStatement)
D relationshipDeletePS...
D s dim(10) like(preparedStatement)


"Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx> wrote in message
news:mailman.38909.1279130551.2580.rpg400-l@xxxxxxxxxxxxxxx

On 7/14/2010 11:54 AM, Rory Hewitt wrote:

Ooh go on Scott - post it :)

I've already (more or less) told you what it is... RPG's O data type is
just a 10i 0 under the covers. 10i 0 can be stored in a data structure.
To extract the integer from the object, or put the integer back into an
object, you can use a mismatched PR/PI.

Example... simple routine to convert Obj to/from int:

D CopyIntObj PR 10i 0
D Obj 10i 0
.
.
P CopyIntObj B export
D CopyIntObj PI 10i 0
D Obj 10i 0
c return Obj
P E


To call it with the object data type, you have to deceive the compiler.
You need an alternate prototype where the O data type replaces the 10i 0.
For example (sorry, about any incorrect text wrapping):

D Int2Obj PR O CLASS(*JAVA:'java.lang.Object')
D ExtProc('COPYINTOBJ')
D int 10i 0 const


D Obj2Int PR 10i 0 ExtProc('COPYINTOBJ')
D obj O CLASS(*JAVA:'java.lang.Object')
D const

These routines use EXTPROC to call the same procedure I showed above, but
they "deceive" the compiler, by passing the O data type where the
subprocedure is expecting the 10i 0 data type. Since in reality the O
data type is the same thing as 10i 0, this should not cause any
problems... until IBM changes something, at any rate!

Now you can change your data structure to look like this:

D iConnection s 10i 0
D iPreparedStatement...
D s 10i 0
.
.

d connAry ds dim(10) likeds(conn)

D conn DS qualified based(conn_p)
D INTID 3a
D campusID 5s 0
D groupServerDBConn...
D like(iConnection)
D addressUpdatePS...
D like(iPreparedStatement)
D addressInsertPS...
D like(iPreparedStatement)
D addressDeletePS...
D like(iPreparedStatement)
D addressSelectPS...
D like(iPreparedStatement)
D relationshipUpdatePS...
D like(iPreparedStatement)
D relationshipInsertPS...
D like(iPreparedStatement)
D relationshipSelectPS...
D like(iPreparedStatement)
D relationshipDeletePS...
D like(iPreparedStatement)
D lastUsedTime z

The DS subfields are no longer defined as O data type. They are 10i0,
which _is_ allowed in a DS, and also in a DS array, so the above code
should now compile.

With that in mind, you can use the subprocedures to populate (or extract
data from) the subfields of the DS


connAry(1).groupServerDbConn =
Obj2Int( JDBC_Connect( 'com.mysql.jdbc.Driver'
: 'jdbc:mysql://example.com/myDB'
: 'klemscot'
: 'bigboy' ));

connAry(1).addressUpdatePS =
Obj2Int( JDBC_PrepStmt( Int2Obj(connAry(1).groupServerDbConn)
: 'select * from Entry' ));

rs = JDBC_ExecPrepQry( int2Obj( connAry(1).addressUpdatePS ) );


I wish IBM had made this easier, but they didn't. It's the only way I know
of to put Java obj refs into an RPG array.

Like I said, I really hesitate to post this publicly, because I'm
deceiving the compiler. There's a chance that this will cause things to
fail in a future release, or even PTF level. Personally, I think thats
unlikely, but... it's still a risk.