Re: 10B 0 type is file as Long Long type in the program

I am not sure if for the given DDS whether the alignment is an issue, but often it is necessary to use the "_P" conversion option to effect a "typedef _Packed struct", because the default so-called ¿natural? alignment is atypically correct to map directly over a database file buffer. Not to imply that has anything to do with the original issue [e.g. for the debug results], just that I noticed the lack of the _Packed which had in my experience very often led to programming errors or difficulties [mostly usage errors in trigger programs trying to map the buffer]. I do not recall if\what the listing showed for the misaligned cases, so am not sure what transpired for the given record format to variable mapping. Since what is included was noted as "compile source", perhaps another portion of the listing would show the fully resolved listing portion with some unnamed /filler/ variables taking storage when alignment had modified the layout of the variables.

Regards, Chuck

Lim Hock-Chai wrote:

The file is created thru DDS:
The DDS looks like below:
A R RECDHDR A SUB 4H A XMITEPOCH 4H A TCAPCODE 4H A LW5 4H A LW6 4H A LW7 4H A LW8 4H A LW9 4H A LW10 4H A PHN_OR_PIN 10B 0 A TID 2B 0 A K PHN_OR_PIN

In the C program, there is a copy book and it looks like this:
#pragma mapinc("F1","*LIBL/ECDHDR(RECDHDR)","both"," ","","F1") #include "F1" #define MHR F1_RECDHDR_both_t

In the compile source, I see this:
15 |#pragma mapinc("F1","*LIBL/ECDHDR(RECDHDR)","both"," ","","F1") 16 |#include "F1" 1 |/* ------------------------------------------------------- * 2 |// PHYSICAL FILE : PALHC/ECDHDR 3 |// FILE LAST CHANGE DATE : 2010/02/09 4 |// RECORD FORMAT : RECDHDR 5 |// FORMAT LEVEL IDENTIFIER : 449D33759180A 6 | * ------------------------------------------------------- */ 7 |typedef struct { 8 | char SUB[4]; 9 | char XMITEPOCH[4]; 10 | char TCAPCODE[4]; 11 | char LW5[4]; 12 | char LW6[4]; 13 | char LW7[4]; 14 | char LW8[4]; 15 | char LW9[4]; 16 | char LW10[4]; 17 | long long PHN_OR_PIN; 18 | short int TID; 19 |} F1_RECDHDR_both_t; 20 | 21 | 17 |#define MHR F1_RECDHDR_both_t


"Lindbom, Joakim" wrote:
Can you send the file declaration and the definitions of pDhr?

Lim.Hock-Chai wrote:

I'm looking at this line of code in debug mode:

iofb=_Rwrite(pFhr,pDhr,HDR_RL);

When I do: EVAL (*pDhr).PHN_OR_PIN :x ==>
I get 00000000 0015942D

But once it wrote to the file and I use SQL to query it and the
Hex(PHN_OR_PIN) is showing 000000D000000000. Couldn't quite understand why.


So, I ran the program again and this time, before it executes
that line of code I did below in Debug:
==> (*pDhr).PHN_OR_PIN =3333333333 ==> The debugger is showing me
(*pDhr).PHN_OR_PIN =3333333333 = -961633963 (Don't know why)

So I did:
EVAL (*pDhr).PHN_OR_PIN :x ==> I get FFFFFFFF C6AEA155
(Don't know why either)