Compiles in test but not in production

[Denny]

The clients system has V5R3 test and production partitions, supposedly identical.

SQLRPGLE program compiles in test but fails to compile in production with a bunch of SQL0312 Position nn Variable xxxxxxxx not defined or not usable. All of the xxxxxxxx fields are in an externally defined printer file. The program can optionally write these same fields to an outfile in qtemp which is created in this same program via SQL Create Table.

Perhaps the question should be, "Why does it compile in test?". The only definitions of those fields is in the external printer file. No copy of the outfile exists on the test box. If I look at the precompiler source in qtemp I can see where SQL generates the work field definitions, but no clue where it is getting them.

I got tired of fighting with it, so I added D XXX.DS E DS EXTFILE(PRINTFILE:FORMATXXX:*ALL) to the source in production and it STILL WON'T COMPILE. WTF!

Yes, the library list is correct. There is only one copy of the external printer file. I FTPed the source twice.

Could SQL have cashed a copy somewhere during development? The outfile does not exist in qsys/qadfifld or qsys2/syscolums which makes sense because it never existed anywhere but qtemp.

[B.Hauser]

Re: Compiles in test but not in production

Is the library list correct?
Did you check if all compile options are identical?
My be you tried to compile to the previous release (for examples the precompiler cannot handle qualified data structures in release V5R2).
When using copy member especially check option RPGPPOPT.
The outfile might not be the problem, because if not exists you'll only get an warning.

Birgitta

[Denny]

Re: Compiles in test but not in production

Brigitta. Yes, Yes, No, no copy members, correct - outfile errors are severity 10.

At the moment, my best guess is that the test and production partitions are not at the same PTF level. I will have the sys admin check it out Monday. I googeled SQL0312 and got lots of hits including many PTFs but nothing that brought me joy. I do not believe this problem is in the carbon based interface.

On production if I change the source type from SQLRPGLE to RPGLE and compile it, it fails because of the SQL statemens but I can see the printer file with all the correct field definitions.

If I change the CRTSQLRPGI to OUTPUT(*PRINT) the precompiler prints the full source listing instead of the abbreviated error listing. In the cross reference section the external printer fields show but have no line reference or size definition.

If I do the same thing in test, the cross reference shows line # 5 as the source of the definition. Line 5 is the external printer file.

Footnote: I saved and restored the *pgm object to production and it works just fine.

[BenThurley]

Re: Compiles in test but not in production

Are the two machines set with the same CCSID? I work on an application that was originally an American creation (CCSID 37). We have a couple of German customers who have their AS400's set to German (CCSID 273). Some of the characters mean different things with these two encodings. If you want to see the correct characters when using greenscreen you generally have to set your interactive job to 273 but you have to remember to set it to 37 when compiling some programs.

[B.Hauser]

Re: Compiles in test but not in production

Are the two machines set with the same CCSID? I work on an application that was originally an American creation (CCSID 37). We have a couple of German customers who have their AS400's set to German (CCSID 273). Some of the characters mean different things with these two encodings. If you want to see the correct characters when using greenscreen you generally have to set your interactive job to 273 but you have to remember to set it to 37 when compiling some programs.

.... or replace @ with § in your source code before compiling
That's why I always insist in, never to use special characters in source codes.

Birgitta

[BenThurley]

Re: Compiles in test but not in production

We usually have the @ symbol soft coded in some configuration and the # symbol is advised against. It's just the old programs that catch us out occasionally.

[Denny]

Re: Compiles in test but not in production

Are the two machines set with the same CCSID? I work on an application that was originally an American creation (CCSID 37). We have a couple of German customers who have their AS400's set to German (CCSID 273). Some of the characters mean different things with these two encodings. If you want to see the correct characters when using greenscreen you generally have to set your interactive job to 273 but you have to remember to set it to 37 when compiling some programs.

Not the problem here, Ben. All partitions/files are CCSID 37. I ran into that issue a few years age when moving source from a US machine to a UK machine. The vendor's standard was to prefix all subroutine names with $ and all PLIST parms with @. Thousands of field names. As I remember it the vendors source files had a CCSID of 65535 and CRTSRCPF defaults to CCSID(*JOB). We created new source files with CCSID(37), copied the source to the new files and the problems went away.

The SQL precompiler simply does not see the external printer file definitions. I even created a D xxx E DS EXTNAME(printerfile:format:*all) spec and the precompiler still does not see it. I have used external DSs with DISK file to define fields on this partition and that works. The issue is specific to external printer files.