E1 9.2.3 with 64-bit for client and server

craig_welton

Legendary Poster
Hi John,

I'm referring to using a table handle DD item (like HF4101) in an NER. The generated C stores the table handle in an ID.

Code:
*****************************************************************
*  Variable declarations
*****************************************************************/
ID idRtnVal = ER_SUCCESS;
ID evt_HandleF4101 = 0;
JDEDB_RESULT iRtnJDB = JDEDB_ERROR;

…


 /* VA evt_HandleF4101 = F4101.Open Handle */
 pAppVars->iTableRetCode = RTK_CER_FIOOpenHandle( hEnv, hUser ,
      _J("F4101") , pszDataSrc , 1 ,  0 , &evt_HandleF4101 );
 

BOster

Legendary Poster
Maybe I didn't do it right or misunderstood. I did use a DD item for the table I/O or at least I attempted to - see screen shot.
 

Attachments

  • TableHandleCapture.JPG
    TableHandleCapture.JPG
    63 KB · Views: 6

BOster

Legendary Poster
If you look through the rest of the generated code it uses evt_HandleF4101 to get table info in zHndlInfo

Code:
if ( RTK_CER_FIOGetHandleInfo( evt_HandleF0101 , &zHndlInfo ) )

but all table I/O operations appear to happen using zHndlInfo.
Code:
JDB_FetchKeyed( zHndlInfo.hReqest

The only other time evt_HandleF0101 is used is to close the evt_HandleF0101 handle...

Code:
pAppVars->iTableRetCode = RTK_CER_FIOCloseHandle( evt_HandleF0101 );
pAppVars->iTableRetCode = RTK_CER_FIOCloseHandle( evt_HandleF0101 );

...why it calls it twice is a seperate mystery...
 

craig_welton

Legendary Poster
So the 32bit table IO handle is actually an abstraction from the request handle. This allows BSFNS to pass the handle around as an ID which will work in 32 and 64. RTK_CER_FIOGetHandleInfo will expose the true request handle to pass to the JDB APIs and will be the arch VOID* size. Pretty well thought out.

The question remains about the cursor handle. Hopefully, I'll get some time to test that out.

Craig
 
Call Orchestrations From Excel – The Easy Way to Make the Orchestrator Work for You.

craig_welton

Legendary Poster
Looks like the cursor handle is a 64bit pointer, not truncated to 32bit. See the values below straight from the debug log.

Code:
Open Cursor Success - hCursor:[0000014A3FBB4290] hCache:[0000014A3F430EA0]

So any code storing the cursor in an ID(32bit) will truncate and fail. We will have to use jdeStoreDataPtr to work with the 64bit address.
 
Top