×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 28/08/2009, at 2:08 PM, Scott Klement wrote:
Interestingly, I tried the program that Jon is having trouble with.
My job's CCSID is set to 37, and Jon's code fails with ECONVERT (the
same message he posted)
However, if I change the last parameter of open() to 37 (instead of 0
which means "take it from my job's default") it works without error.
I hadn't tried the code but I just ran it on VRM540. If I remove
O_TEXT_CREAT or specify O_CCSID instead of O_CODEPAGE then it works
with the last parameter set to 0.
This seems strange to me, because they should result in the exact same
values. The only difference seems to be that open() doesn't have to
figure out what my job is.
Possibly the fact that 0 has the POTENTIAL to be non-SBCS is all it
takes to make it fail.
If so then I would consider that a defect. The value is determined at
run-time when the open occurs. If it resolves to a suitable non-mixed
byte value then it should be successful.
I wonder if the test for "not strictly single-byte or double-byte" is
being performed before resolving what 0 (i.e., job CCSID) really is?
From InfoCentre:
:quote.
If O_TEXTDATA is specified, but O_CCSID is not:
• open() fails when the file CCSID and open CCSID are not the same
and one of them is not strictly single-byte or double-byte.
:equote.
For a new file O_CREATE causes the conversion ID (4th parm) to become
both the "file CCSID" and the "open CCSID" which should result in no
data conversion (hence the old open-to-create, close, and reopen trick).
With O_TEXT_CREAT specified the conversion ID (4th parm) is the "file
CCSID" and the text conversion ID (5th parm) is the "open CCSID". In
this case the file and open CCSIDs are different (819 and 0
respectively). Perhaps 0 has not yet been resolved and since it is not
STRICTLY single-byte or double-byte ECONVERT is returned?
I reckon that's just wrong and can't be how it was intended. I suggest
Jon opens a PMR.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
