DTAUS with C#

I needed to export Lastschriften (instructions for direct debit) for our german office, and after looking for some solutions, I realised that it is not that hard to write it yourself...

Here is the result: http://download.pokorra.de/coding/Dtaus.cs
Please feel free to use the code any way you like.
I read the input data from an XML file, of course this needs to be modified to your specific situation.

A good help was this documentation of the german DTAUS bank file format:
http://www.infodrom.org/projects/dtaus/dtaus.html

Another useful tool was the JDTAUS editor, a java editor that can process and create DTAUS files:
http://www.jdtaus.de/de/
I use this to validate and test the files written with my C# program.

Building a mono 2.0 RPM for RHEL4/CentOS4

When I noticed that Novell does not offer RPMS of Mono 2.0 for RedHat Linux, I had a look at the Fedora 10 Beta and found that there is a Mono 2.0 Source RPM:
mono-2.0-6.fc10.src.rpm
Update: mono-2.0.1-12.fc10.src.rpm

Because we work with CentOS4/RedHat Enterprise Linux 4, I installed the source package on that system, and tried to build the rpms.

Building the code was fine after I deactivated a couple of dependencies.
But I ran into some problems at the file checking stage. I wondered if I can prevent the build stage to happen again and again. That way I should be able to debug the file list check etc.

Reading the man page, these parameters are interesting:

--short-circuit
--nobuild
-bi
-bl

So with rpmbuild -bl mono.spec I was able to just run the file checking stage.

The errors I got were like this:
rpm build errors: File not found: /var/tmp/mono-2.0-6-root-root/usr/bin/certmgr/usr/bin/chktrust/usr/bin/gacutil/usr/bin/gmcs/usr/bin/mcs/usr/bin/mcs1

But the files do exist in the /var/tmp/mono-2.0-6-root-root/ directory

I finally realised that the problem was caused by the Macros.
see also http://rpm.org/wiki/PackagerDocs/Macros
I had to first add curly brackets to each Macro call:
%{macro parameters}
But even then only the first line of the Macro had an effect.
This command was helpful in the files section to see that the Macros just were not resolved correctly:
%{echo: %{your_macro_here}}

In the end, I ended up adding the missing files to my own mono.spec file.
I also had a look at the last available RedHat spec file from Novell for Mono 1.9.x, and I guess there is a different rpm version for RHEL 4 and RHEL 5.

Here is my modified mono.spec file that works for RHEL4/CentOS4 for Mono 2.0:
http://download.pokorra.de/mono/mono.spec

Please download the src.rpm file from the Fedora 10 Beta, or later, and install it:
rpm -i mono-2.0-6.fc10.src.rpm
Then copy my modified mono.spec to /usr/src/redhat/SPECS, and build the packages:
rpmbuild -ba mono.spec

Alternatively, here is a zip file with the compiled RPM files for CentOS4/RHEL4:
mono-2.0-6.i386.rhel4.rpm.zip
I cannot guarantuee that it actually works, but feel free to use it for your own experiments!

Use Progress and ODBC on CentOS with Japanese

This is related to my previous blog about using Chinese characters with Progress, .Net and Mono: Allow Chinese characters on a Client-Server application

Now the next challenge was to get Japanese characters to work.

I first converted the Progress database to shift-jis.
I set the environment variable: SQL_CLIENT_CHARSET=SHIFT-JIS

I then experimented with several locales, e.g. ja_JP.UTF8 and ja_JP (which is an alias for ja_JP.eucjp).

I used Wikipedia to get some sample words in Japanese characters, see http://en.wikipedia.org/wiki/Japanese_writing_system.

I soon realised that with some words I would get an ODBC error:
eg. with Kanji script 金魚 (Goldfish)
and with Hiragina script, きんぎょ
If I left out the last letter, it worked.

The ODBC error was:

Saving of data failed!
Reasons:
* [[ODBC]] [unixODBC][DataDirect-Technologies][ODBC 20101
driver][20101]Internal error -4 (unknown nls services error) in SQL from
subsystem NLS SERVICES function nlsCountChars called from nc_get_strlen
on . for . Save log for Progress technical support.

A helpful person from Progress Support gave me some suggestions, and I got it to work with Progress 9.1D in the end!
I had to use another locale, ja_JP.SJIS, which did not exist by default on my CentOS 4.6 (locale -a | grep JP).

According to http://kbase.redhat.com/faq/FAQ_80_1256.shtm
you can create the locale ja_JP.SJIS with this command:
localedef -f SHIFT_JIS -i ja_JP ja_JP.SJIS

This resolved the internal ODBC error.

Another issue was that I was not aware how to properly set the font in the ini file. Finally I found a hint in the Progress manuals, to check the prolang directory for the file progress.ini which is available for each language on the client side; this has a sample font. For the Japanese, this is a font with Japanese characters. I just copied it, and it worked.