Archive for June, 2011

Using 32-bit ODBC drivers on 64-bit Windows

Tuesday, June 28th, 2011

When you start the ODBC configuration tool from the menu or the control panel on 64-bit Windows, it starts the 64-bit version of the tool.  All well and good.  Unfortunately, this only shows the 64-bit ODBC drivers that are installed on your system.  What if you need to use a 32-bit ODBC driver?

It turns out the quite simple once you know the trick.  You simply need to run the 32-bit version of the ODBC configuration tool.  To do this just browse to c:\windows\syswow64 and double click odbcad32.exe.  This will allow you to configure the 32-bit ODBC data sources that you need.

TFrame Displaying as TForm in Designer

Wednesday, June 15th, 2011

I came across an interesting quirk in the Delphi 2010 IDE today.  I was working in a project that uses a lot of TFrame components.  To make life easy on myself, or so I thought, I created a custom TFrame descendant and used that in place of the default TFrame.

Everything was working well until I displayed one of the frames as text, made some silly change and then redisplayed the frame’s visual designer.  At this point, the IDE started treating my TFrame as a TForm.  It displayed as a TForm in the visual designer, all of TForm’s properties appeared in the object inspector, all of TForm’s properties were being saved in the .DFM file.  I didn’t notice this right away.  Not until I recompiled everything and tried to run the application.  At this point I started to get ‘ClientHeight property not found’ errors when I tried to instantiate the TFrame.

This little gotcha cost me most of an afternoon.  I guess the rule is:

If you are designing a TFrame descendant use the visual designer only.  Do not try to edit the .DFM file as text.

Converting Native Fujitsu Cobol Numeric Fields to / from Decimal

Monday, June 13th, 2011

There are any number of bizarre syntax rules concerning the interaction of native Cobol data types and .Net data types.  One of the stranger ones is this:  If you want to convert a .Net Decimal value to a native Cobol numeric field, that field must be signed.  Oddly enough, the inverse is not true.  You can convert unsigned Cobol fields to .Net Decimal values.  So, to convert Decimal to Cobol you must do something like this:

01  WS-TEMP PIC S9(5)V99.
01  WS-VALUE PIC 9(5)V99.
01  WS-DECIMAL OBJECT REFERENCE CLASS-DECIMAL.

SET WS-TEMP TO WS-DECIMAL.
MOVE WS-TEMP TO WS-VALUE.

What at PITA!

Global Compiler Options for Fujitsu Cobol

Monday, June 13th, 2011

There are certain compiler options that must be applied to Fujitsu Cobol projects that must be the same for all projects if things are to work properly.  For example, there is an option that controls the internal representation of signed USAGE DISPLAY numbers.  If different programs use different options then they are going to misinterpret each other’s numeric fields. Fortunately, it is possible to specify options to the Cobol compiler that will be used by all projects.

There is a file named cobol.rsp in the Net Cobol for .Net installation directory that holds the global compiler options.  Simply add a new line to this file for each compiler option that you wish to specify.  For example, to specify 88 Consortium signed numeric field handling, add a line with /wc:”Decimal(88)” to cobol.rsp.

Using RM/Cobol Indexed Files with Fujitsu Cobol

Friday, June 3rd, 2011

We are migrating an application from RM/Cobol to Fujitsu Net Cobol for .Net.  As part of this, we want to be able to access indexed files from RM and Fujitsu programs concurrently.  Since the Fujitsu indexed file handler appears to have been licensed from RM back in the misty depths of time, this would appear to be a no-brainer.  Unfortunately, this turns to not be the case.  While RM files are compatible with Fujitsu programs, there are restrictions.  Here is what I have been able to find out so far: (more…)