Re: Free format H, F, D and P specs

Henrik

You have the "advantage" of working in more of a multiple-language
environment. I have to admit that I believe we in the US don't think
about this much - we can merrily put anything in our source, believing
it will always be just good-old-American!

When I worked at an ISV, we sometimes got requests from other countries - and there were ways similar to yours that were put in place. Of
course, the effort taken is likely driven by potential revenue - always a trade-off there.

Cheers
Vern

On 10/10/2013 10:38 AM, Henrik Rützou wrote:

The character/binary problem is actual a little opposite.

Yes, we have EBCDIC source files in JAVA and C - but these source files are
probably converted into ASCII before they are compiled since neither JAVA
nor C is EBCDIC native languages/compilers.

The RPG compiler is probably EBCDIC native and don't convert source files
but read them as binaries (CCSID 65535/ (no conversion) – example:

In US (CCSID 37) you can have a field name $myfield where $ is x'5B'

In Denmark (CCSID 277) the same field must be name Åmyfield where Å is x'5B'

If you convert the source file from 37 > 277 the $ shifts to x'67' that is
not allowed in field names.

But in a Danish system if you use $ as a constant you will expect it to be
x'67' and there you want the conversion.

In powerEXT that reads and generates JSON I have a lot of {} constants in
my RPGLE code and because of that the installation procedure converts all
source files and recompile all the programs to the machines CCSID.

And I do not use special characters in my field names such as $ # Å Æ
because it would never work.

There is of course other ways to come around the problem (e.g. constants
defined as UCS-2 fields) but it makes code much harder to code and read.


On Thu, Oct 10, 2013 at 5:04 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

On 2013-10-10, at 10:39 AM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

The fact is, if EBCDIC can be "worked around" with C and C++, there is
no technical reason they couldn't be worked around with RPG.

"The fact is" that IBM have no incentive to make life difficult for the
many people that such an incompatible change would introduce. And I'm cool
with that.

If I feel an overwhelming need for { } the I'll write myself a
pre-processor.

More to the point though - this boat sailed 10 years ago with /Free - that
would have been the time to do it. To rehash it now is a waste of energy.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com




--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.