[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::sql

Title:	SQL notes

Moderator:	NOVA::SMITHI

Created:	Wed Aug 27 1986
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3895
Total number of notes:	17726

3889.0. "SQLMOD, DECC structures and alignment" by NLVMS3::MWILLEMS (Das ganze Leben ist ein Quiz) Thu May 22 1997 10:18

    Hello,
    
    A customer of mine has the following structure defined in C:
    
typedef long Date[2];

typedef struct
{
   char   vmsId[14];
} UserKey;

typedef struct 
{
   char      name[21];
   char      department[21];
   char      extension[5];
   char      discipline[2];
   int       createUser;
   Date      createDate;
   int       modUser;
   Date      modDate;
} UserBody;

typedef struct
{
   int          id;
   UserKey      key;
   UserBody     body;
} DbUser;

int main( void )
{   
    DbState	dbState;
    DbUser	user;
    
    IN SQLMOD he has defined:
    
 
   Module	db$user

language	c
parameter	colons

declare user_fetch_all_crs cursor 
    for select	 *
	from	 sys_user
	order by vms_id 
	
procedure DbUserFetchAll(
	sqlstate,
	:sys_user record
		user_id		object_id_dom,
                vms_id		vms_id_dom,
		user_name	descr_tiny_dom,
		department	descr_tiny_dom,
		extension	extension_dom,
		discipline	tag_dom,
                create_user     object_id_dom,
		create_date	date_dom,
                mod_user        object_id_dom,
		mod_date	date_dom
	end record
	);
	fetch user_fetch_all_crs into :sys_user;

    When compiling this in DECC with the /NOMEMBER switch all is well if he
    uses the /NOALIGN in SQLMOD. also the /ALIGN works ok.
    With /MEMBER it looks like the fields department until create_date are
    put 2 bytes to the left. The create_date is on the right position.
    This happens with /ALIGN and with /NOALIGN in SQLMOD.
    Has anybody seen this before and/or is it expected behaviour because of
    differences in alignment in SQLMOD and DECC?
    
    I'm investigating this further and I'll come back when I know more.
    
    Marcel Willems

T.R	Title	User	Personal Name	Date	Lines
3889.1	alignment differences	NOVA::HERRE		`Thu May 22 1997 13:05`	13
	It looks like there are two different problems here. The first is that DECC is longword aligning the field 'body' in struct DbUser, and SQL isn't. DECC seems to align a structure based on the size of its largest element; SQLMOD aligns based on the first element of the structure. The second problem is caused by date types being a vector of longwords in DECC and a quadword in SQL. This makes DECC longword align dates and SQL quadword align dates. In this case, it happened to re-synch the fields at createDate. I would bug this.
3889.2	Found out how it works	NLVMS3::MWILLEMS	Das ganze Leben ist ein Quiz	`Mon May 26 1997 10:46`	41
	I investigated it further and I found out the adresses of the fields in the different situations. Only the last 3 digits of the adresses are relevant. In the situations NOALIGN and NOMEMNER all fields are put behind each other. In the situation MEMBER in DECC the structures start at the boundary at which the biggest type is aligned. The first structure containts the longword id and is therefore aligned at a longword boundary at 424. The second structure is a character field and is aligned on a byte boundary, this means right behind id at 428. The third structure contains character fields and longwords and is therefore longword aligned on 444. name, department, extension and discipline are put behind each other because they are byte aligned. The last byte of these characters is on 492. createUser starts on the first longword boundary after 492. This is 496. The rest are also longwords, so they all are put behind each other. In SQLMOD there are no structures, so the character fields are byte aligned, the longwords longword aligned and the quadwords quadword aligned. id starts at the longword boundary 424 and the character fields are put right behind that. The last byte is at 490. The longword createUser starts at the first longword after that at 492. The createDate quadword at the quadword boundary 496. The longword moduser fits right behind createDate, but the quadword ModDate must start at the quadword boundary 512. field type nomem mem align noalign ----- ---- ----- --- ----- ------- id long 424 424 424 424 ______ vmsId char(13+1) 428 428 428 428 ______ name char(20+1) 442 444 442 442 department char(20+1) 463 465 463 463 extension char(4+1) 484 486 484 484 discipline char(1+1) 489 491 489 489 createUser long 491 496 492 491 createDate long(2) 495 500 - - C createDate quadword - - 496 495 SQLMOD moduser long 503 508 504 503 modDate long(2) 507 512 - - C modDate quadword - - 512 507 SQLMOD Marcel Willems