Double Convesion.

[FireStarter1]

It may confuse people a bit, but read carefully.
I am a Cobol Programmer developing an application on the Mainframe. My project is formatting records in a file that is going to be FTPed to Workstation. There was an application that was doing everything on the workstation but right now as it is getting migrated to Mainframe I need to do the same.
This may be a worst case scenario programmers are going to face in another 2 years, the applications which is developed in C++ was developed by a German company. Right now what we have is only a part of their documentation which is ofcourse is in German and no source code is available.
I have figured out what the application is doing by a data viewer which supplied by the German company except for one field. Which is declared as a Double. I COBOL this is declared as a COMP-2 but the viewer shows it as different. Here are details.
This is the actual value I am passing into the COMP-2 variable: 93128765
This is stored in the variable as this value: -.41104670346953626E 69
This is the value the viewer is showing up: -1.76575968696798E+260 when it should have shown up 93128765. Can anyone tell me how to get the right values in the viewer.
If you need more info please e-mail me at FIRESTARTER@mainframer.net
Thanks.

 

[JOLESEN]

I know a few German words, so if required we could do some translation service here !

I don't know if a COMP-2 in any way is compatible with a double, but have you verified that the actual content of the COMP-2 datatype is transferred to the workstation without any conversion taking place (Thinking of EBCDIC -> ASCII) ?

/JOlesen

 

[lionelhill]

How many bits are dedicated to mantissa, how many to exponent?
Floating point numbers can be the same length, but have different formats...

 

[FireStarter1]

I tried the EBCDIC to ASCII conversion before but it did not worked.
I believe the bits dedicated to Mantissa is 52. 1 bit for the sign and 11 for the exponent.
Looks like the viewer is shuffling the bits around or does some sort of conversion. As I am a cobol programmer I don't know how C++ treats data. That is why I thought of asking the question here.

 

[JOLESEN]

Don't do EBCDIC to ASCII Conversion on binary data !!

Make sure the ftp xfer is in binary mode.

Assuming the two data types are compatible, it should be easy to verify the transfer is successful, simply by dumping the content of the COMP-2 type and the file being transferred.

/JOlesen

 

[FireStarter1]

I tried it. Still not working.

 

[JOLESEN]

I guess that the ftp-transfer is successful with no conversion of data ?

You wrote in your first post that the pc-program handled everything.
Did 'everything' also include an ftp-filetransfer - or how was data injected into this program ?


This is from MSDN :
Double precision values with double type have 8 bytes. The format is similar to the float format except that it has an 11-bit excess-1023 exponent and a 52-bit mantissa, plus the implied high-order 1 bit. This format gives a range of approximately 1.7E–308 to 1.7E+308 for type double.

Microsoft Specific —>

The double type contains 64 bits: 1 for sign, 11 for the exponent, and 52 for the mantissa. Its range is +/–1.7E308 with at least 15 digits of precision.

END Microsoft Specific

/JOlesen

 

[ArkM]

I think you have byte order problem. x86 station and (IBM?)mainframe are diff at this aspect. IBM COMP-2 is IEEE doubles, as double type in x86 C++ (IEEE std too) but with revert byte seq. Alas, it's hard to say where byte resampling may be added in your app...

 

[lionelhill]

You mean like between macs and PCs?

 

[FireStarter1]

Hi,
I have hours to find a fix. But my question is if we need to do the resampling(whatever this means) what should I do.

 

[ArkM]

I don't know where you may revert byte order of 8-bytes representations of doubles in your transferred from mainframe binary files. The best way to exchange data between different platforms is text (formatted, for example), not a binary files. Try convert records on mainframe (it's so easy in Cobol), then send file via ftp, then read and make conversion in PC binary form (simple fscanf, or C++ stream input). No byte order problems.
Yes, this conversion layer seems cumbersome, but binary representation (and alignment) problems are much more cumbersome (as you see), especially when you have not full control over one side application source.

 

[NashPatel]

Guys,

I am writing an EBCDIC to ASCII converter and vice versa. I need to get a good handle on what constitute an EBCDIC data. i.e. How do I know it is an EBCDIC data that I am converting? I am writing in c++. any help in either c or c++ is much appreciated

 

[JOLESEN]

You can't tell if it is EBCDIC, unlees you know something about data.

If it is supposed to be readable text, you can watch the content using notepad before the conversion. If it doesn't look like text, it is prob. EBCDIC. A conversion to ASCII should make readable.

Further there are many different EBCDIC codepages. You need to know which one you are dealing with.

You should be able to convert in both directions using UNICODE as intermediate codepage :
MultiByteToWideChar converts from ASCII or EBCDIC to UNICODE, and WideCharToMultiByte converts back to ASCII/EBCDIC

This will require that the EBCDIC codepage is installed on the system.

/JOlesen