I notice this in the Debugger also:

If I do: (*pDhr).PHN_OR_PIN = 2147483647 ==> I get (*pDhr).PHN_OR_PIN =
2147483647 = 2147483647

If I do: (*pDhr).PHN_OR_PIN = 2147483648 ==> I get (*pDhr).PHN_OR_PIN =
2147483648 = -2147483648

It looks like somehow the program is thinking that this PHN_OR_PIN field is
a int/Long. But the compile list seems to show that this field is Long
Long.







"Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote in message
news:mailman.7821.1265835385.2580.c400-l@xxxxxxxxxxxxxxx
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" <joakim.lindbom@xxxxxxxxxxxxx> wrote in message
news:<mailman.7816.1265834913.2580.c400-l@xxxxxxxxxxxx>...
Can you send the file declaration and the definitions of pDhr?

/Joakim

10 feb 2010 kl. 21.41 skrev
"c400-l-bounces+joakim.lindbom=capgemini.com@xxxxxxxxxxxx
" <c400-l-bounces+joakim.lindbom=capgemini.com@xxxxxxxxxxxx>:

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)








--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.


Capgemini is a trading name used by the Capgemini Group of companies which
includes Capgemini Sverige AB, a company registered in Sweden (number
556092-3053) whose registered office is at Gustavslundsvägen 131 Box 825 -
S-161 24 Bromma.






This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the
intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this
message.

----------



This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact [javascript protected email address].