MicroFocus NetExpress to Fujitsu Version 6(Enterprise) Conversion 1

[Nekon]

I am new to Tek-Tips, so be gentle!

We will soon be required to convert our Microfocus NetExpress code to Fujitsu Version 6 (Enterprise Ed. compiler). Does anyone have any experience with this and the issues/differences involved? Any input would be much appreciated.

Thank You!

 

[MKuiper]

Nekon,

I have done this about half a year ago. In fact, our sources compile and run both in Net Express and Fujitsu Cobol now.
I could write the entire evening about the differences, I think you must ask some specific questions in this forum.

My experience is, Fujitsu is more strictly using ANSI standards than Net Express does.

The main differences are:

- Fujitsu doesn't know COMP-X fields. Change all your COMP-X to COMP.

- FUJITSU stores COMP and COMP-5 fields in 2, 4 or 8 bytes depending on the picture clause. Net Express stores those fields in 1, 2, ... 7 or 8 bytes. Fortunately, Fujitsu knows the BINARY(BYTE) compiler option, which changes this Fujitsu behaviour to the same as Net Express. I must strongly advise you to use this option in Fujitsu.

- In Net Express, you can have alphanumeric comp-5 fields, eg PIC X(02) COMP-5. Fujitsu doesn't like this. If you declare a field like PIC X(02) COMP-5, you have a two-byte field which can hold any unsigned number which fits into two bytes, so 0 .. 65535. These fields are very important if you call the Windows API's or C(++) routines directly from Cobol. In Fujitsu, you must declare them as 9(04) COMP-5. The behaviour of those fields is exactly like the PIC X(02) COMP-5, but only if you use the BINARY(BYTE) compiler option. If you move 12345 to such a field, you get a compiler warning (numeric overflow), but in spite of the warning, the execution goes right. If you use a value-clause, there is no warning but an error, and no object is generated. So: 01 FIELD-NAME PIC X(02) COMP-5 VALUE 12345 can not be translated to 01 FIELD-NAME PIC 9(04) COMP-5 VALUE 12345. Instead, you must make: 01 FIELD-NAME PIC 9(04) COMP-5, and MOVE 12345 TO FIELD-NAME in the initialization of the program.

- All fields without a value-clause are initialized to spaces in Net Express and to low-values in Fujitsu.

These are the main differences, if you need more information, please post another question in this forum. Marcel

 

[Nekon]

Thanks, Marcel for the helpful information! I do have a few specific questions.
1. What is the difference between 'Organization Line Sequential' and 'Organization Record Sequential'? We always used just 'Organization is sequential" in NetExpress. When do you use each?
2. Isn't there an issue with using signed fields that are not Comp-5, Comp-3 or Sign Separate?
3. What about the use of Low-Values terminator?
4. Something about handling of the PROGRAM-ID clause?
5. What about avoiding use of ADVANCING clause on WRITE statements for ORGANIZATION LINE SEQUENTIAL files?

These are from a general list of differences that I received, but I am not sure that I understand all of them.

 

[MKuiper]

Nekon,

1. Don't know. We also only use sequential and line sequential, not record sequential. I've looked in Net Express documentation, looks the same as sequential to me. If somebody else knows better, please respond. But there is one issue with LINE SEQUENTIAL in Fujitsu (not with SEQUENTIAL or other organizations): The space for the record for LINE SEQUENTIAL files seems to be allocated dynamically in Fujitsu. It is accessible after opening the file, until the file is closed. Trying to access the line sequential record if the file is closed terminates the program with an access violation.
Example:
SELECT XXX ASSIGN ... ORGANIZATION IS LINE SEQUENTIAL ...

FD XXX RECORD CONTAINS ...
01 XXX-RECORD PIC ...

OPEN OUTPUT XXX.
MOVE "ABC" TO XXX-RECORD.
* The above MOVE goes well in Fujitsu as well as NE

CLOSE XXX.
MOVE "XYZ" TO XXX-RECORD.
* The above MOVE will cause an access violation with Fujitsu

This difference is easy to overcome, because it makes no sense doing things with the record if the file is not open. Most likely these constructions don't exist in your programs.

2. I know of one thing: signed numeric items (PIC 9(..)) store the sign in the last byte as does NE. Only, NE does not change the numeric value if it is a positive number, but Fujitsu does. So, if you have a PIC 9(3) field containing 1, NE stores it as "001" and Fujitsu as "00Q". If you display or print such a field, it looks very strange. But, it is only cosmetic, all processing of the field goes right. If you do print or show only unsigned numeric fields and/or numeric edited fields, no problem.

3. Sorry, don't understand the question.

4. We had some problems with the PROGRAM-ID. XXX IS EXTERNAL-clause. I did not research it, but changed our precompiler to deal with it.

5. Sorry, don't know. All of our I-O is done by C++-routines.

Marcel

 

[Nekon]

Thanks, again, for the info Marcel.
Does anyone know if Fujitsu has problems with PCL strings for special printing effects(i.e. bold, italics, elite, proportional, etc.)? We have many PCL strings in our programs in working storage. I am hoping Fujitsu will handle it just like NetExpress.