Tried to compile to V5R3 and 2. In both cases the compiler flags not 1 but 6
severe errors, but still does not provide any information about their nature
or location.
I also tried taking out all C++ strings and replacing them with C ones, as I
found messages on this list from a few years ago where that was a problem. I
also did a char rather than wchar_t version, but that gives the same
undisclosed error.

Thanks,
Erik



2009/9/1 Erik Olsson <erik.eo.olsson@xxxxxxxxx>

Thanks for your reply.

I'm compiling with CRTCPPMOD (as I'm using a bit of C++ strings and
vectors). The output is to an IFS file. I find them more reliable than
spoolfile output which sometimes cut off important data.

And thanks for the info about the compiling to previous releases. I'll try
that though my problem in this case isn't that an error is listed on the
wrong line but rather that it's not listed at all. All I get is that there
is a severe error somewhere, but no hint as to where. The search goes on.

Cordialement,
Erik

2009/9/1 Genyphyr Novak <genyphyr1@xxxxxxxxx>

Hi Erik,

How are you doing the compiles ? If you compile from the command line
there is always an option to send the compiler listing to *PRINT, but that
is not the default. Once the compile listing is in the iSeries spooled
files, then normally you can see the line by line the errors shown under the
line of code it complains about with letters indicating the exact point(s)
in the line it is complaining about. So on the CRTCMOD command you need to
do something like this CRTCMOD MODULE(xxx/xxx) SRCFILE(xxx/QILECSRC)
OUTPUT(*PRINT) OPTIMIZE(10) DBGVIEW(*ALL) to see the errors in the listing.
If you are using the IFS for source list the directory (this shows using
normal iSeries source files in libraries). If you are using a program on
your PC to send in the compiles to the server, normally there is some
preferences area (depending on the tool you are using) to set up the CL
command defaults that it will pass on to the server, and you'll have to
update those.

But I think starting on V5R3 or V5R4 (can't remember which now), the
compiler listing of the lines of code vs errors reported was off by random
numbers of lines (ie it would show an error that didn't relate to the code
written on that line at all and if you were lucky you could work out that it
was a few lines above or below but often it was just really really off) ...
complaints to IBM about this from me at that time did not result in fixes to
that, so often to get around the problem I compiled back towards an older OS
using the older compiler to find my error, then once fixed, recompiled on
the current OS level !! I believe I encountered the problem at V5R4 and had
to compile back to the lowest supported release to get a good listing but it
could have been V5R3 that started the problem. I can't test now to be sure
as I do not have access to a V5R4 or V5R3 box at the moment. To compile back
to a certain release add the option TGTRLS(VxRxMx) to the
command where the 'x' are the release version mod that you want (it must
be supported on your current release).

Take care,

Genyphyr Novak
iSeries Technical Consultant
France
+33 62 15 02 02





1. Expat and UTF-16 (Erik Olsson)


-----Inline Message Follows-----

I'm trying to use Expat with UTF-16 (ccsid 1200) encoded files.

Now, my issue is that I'm getting a compile error with 1 severe error, but
the compiler listing does not state exactly where that error occurs. The
Epilogue section at the bottom simply mentions that there is one severe
error, but not what nor where it is.
I currently have all relevant strings passed to Expat defined as wchar_t.
If
I don't have XML_UNICODE and XML_UNICODE_WCHAR_T (which changes XML_CHAR
from char to wchar_t) defined I rightly get errors verifying that the
prototypes does not match, so that should be ok. But somewhere I have
apparently missed something which the compiler isn't keen on informing me
about.

Expat include and macros:
#include <libexpat/expat/xmlparse.c>
#define XML_UNICODE
#define XML_UNICODE_WCHAR_T

And the prototypes:

void start(void * userdata, const wchar_t * elem, const wchar_t ** attr);
void end(void * userdata, const wchar_t * elem);

Before I post the whole thing, has anyone done something similar with
success? And any ideas on how to get the error to be pointed out on the
compiler listing (never had this issue before)?

Thank you,
Erik

--
--
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.




This thread ...

Follow-Ups:
Replies:

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].