There seems to be a difference between AIX and Linux in ENDIAN when passing data to a C language subroutine using Easytrieve's B type field.
It is possible to convert BIG to LITTLE on the C language side, but is this a limitation of Easytrieve Linux?
What was found to be the problem:
The subroutine receives the string to be checked as the first argument and the length of the characters as the second argument, and loops through that length to check each character one by one, but because it loops beyond the specified length, it ends up checking an incorrect area.
After debugging, it was found that a difference in ENDIAN was the cause.
The code for calling and called by chkZenginChar is as follows.
Easytrieve source:
For example:
CALL chkZenginChar USING(W-CHK_STR, W-CHK_STR_LEN) RETURNS W-RC
W-CHK_STR W 40 A
W-CHK_STR_LEN W 4 B
Common function (C) source:
For example:
int chkZenginChar(char* inStr, int* inLen)
The second argument inLen is passed in BIG ENDIAN. The C function assumes LITTLE ENDIAN in RHEL, so the correct length cannot be obtained.
For example:
EASY (W-CHK_STR_LEN=1) => C (*inLen = 0x 00 00 00 01(=16,777,216))
Environment : Linux
Release : R11.6
There two binary numeric types in Easytrieve:
1. "B" ... always big-endian on all platforms
2. "I" ... native endianness (i.e. little-endian on x86, big-endian on Power and Z)
It will be little endian in the x86 environment, and big endian in Power or z environments.
If you need to native endianness (e.g. in the C subprogram), they may need to use the "I" type instead of the "B" type.
So, you can also address this by changing the field type of the argument parameter defined in Easytrieve from type B to type I.
See the manual for more details - DEFINE Statement.