COMP-3 variables
ChinmaYT
This time I am facing a different issue in reading COMP-3 variable. I
have a file created on IBM system which contains PIC 9(9) COMP-3
variable. I am reading the file using PIC 9(9) COMP-3 variable and
moving it to PIC 9(9) variable on Tandem Cobol.
Input file Layout (IBM System file):
01 PACKED-DATA-REC.
03 PACKED-DATA PIC 9(9) COMP-3.
Output File Layout (Tandem):
01 UNPACKED-DATA-REC.
03 UNPACKED-DATA PIC 9(9).
Code:
READ PACKED-FILE.
MOVE PACKED-DATA TO UNPACKED-DATA.
WRITE UNPACKED-DATA-REC.
For some records in file, I am getting data error when i do MOVE
PACKED-DATA TO UNPACKED-DATA.
If we see COMP-3 Variable in binary, it is store in some different way
(not as in Packed BCD).
-UNPAK-D PACKED-DATA
PACKED-DATA-REC.PACKED-DATA = 1030421235
-UNPAK-D PACKED-DATA IN BINARY
PACKED-DATA-REC.PACKED-DATA = 10011100 10011101 10111010 10111101
01011110
-UNPAK-D PACKED-DATA IN HEX
PACKED-DATA-REC.PACKED-DATA = %H9C %H9D %HBA %HBD %H5E
-UNPAK-D UNPACKED-DATA
** Inspect warning 109 ** Non-numeric character in numeric string
UNPACKED-DATA-REC.UNPACKED-DATA = 0
-UNPAK-D UNPACKED-DATA IN BINARY
UNPACKED-DATA-REC.UNPACKED-DATA = 00100000 00100000 00100000 00100000
00100000 00100000 00100000 00100000 00100000
-UNPAK-D UNPACKED-DATA IN HEX
UNPACKED-DATA-REC.UNPACKED-DATA = %H20 %H20 %H20 %H20 %H20 %H20 %H20
%H20 %H20
Is this issue because of different storage systems (IBM vs Tandem) or
data error?
Thanks,
Chinmay
dimandja
> Is this issue because of different storage systems (IBM vs Tandem) or
> data error?
Last time I moved data from IBM to Tandem was over 25 years ago, so
excuse any inaccuracies here.
As far as I can remember, we unpacked data on IBM before feeding it to
Tandem. In other words, the program you wrote on Tandem to unpack the
data, should really be running on IBM. After you unpack everything on
IBM, you can then make it available to Tandem.
Clint Jensen
"ChinmaYT" <chin...@gmail.com> wrote in message
news:32f0d3b9-b207-4db2...@f14g2000vbn.googlegroups.com...
It looks to me as if the input data is not valid. Why IBM came up with a
packed data type is beyond me, but basically, a 12345 will be represented as
X'12345F' for an unsigned value, or X'12345C' for a positive value or
X'12345D' for a negative value. So, except for the trailing sign, each
nibble must have a valid numeric value.
The IBM mainframe is an EBCDIC machine and the Tandem is an ASCII machine.
You cannot just translate a file from the IBM mainframe from EBCDIC to ASCII
if it contains non text data (that is, it contains packed or binary data, or
signed display data), so, if you did that, it would distort the numeric
data. If you transfer the file as a binary file, then you would need to
selectively translate each field depending upon it's origin and destination
data type.
Good luck,
CJ
==
ChinmaYT
> "ChinmaYT" <chinma...@gmail.com> wrote in message
Thanks for your reply.
I have got IBM file as an ASCII file. I am using it as it is.
Also, I dont have access to IBM machine.
wbreidbach
wbreidbach
The problem really is the conversion from EBCDIC to ASCII. This
usually makes all non-display fields as comp or comp-3 unusable. There
are no problems with alphanumeric fields as long as the contain
displayable characters. If your file contains comp-3 fields only you
can use FUP to reconvert the data to EBCDIC. If you have a mixture of
comp-3 and text fields you will have to do it programmatically. But
this is no real problem you can use inspect ... converting to do that.
Just build 2 strings with the 256 ASCII-characters and their EBCDIC-
equivalents.
Keith Dick
The last time we had a question about this, I believe I raised a warning about attempting to fix this by translating from ASCII to EBCDIC, in the hope that this would return the packed decimal fields to their proper representation. The problem is that the mapping from EBCDIC to ASCII is not 1-to-1. Several EBCDIC characters map to the same ASCII character, so the reverse mapping is ambiguous.
The best approach to transferring from IBM to NonStop is to convert the file on the IBM system to make any numeric fields be display numeric (no COMP-n fields) with signed fields having a separate sign character, not embedded sign.
If you cannot do that, the next best approach probably is to get an unconverted file from the IBM system. The COMP-n fields will be correct in such a file, but all of the text and display numeric fields will still be EBCDIC. Such fields could be converted using INSPECT ... CONVERTING in the program, though one must be a little careful with signed COMP-1 fields.
If you do not want to convert the text and display numeric fields in the program, you could use FUP to translate the file from EBCDIC to ASCII and make the program read both the translated file and the untranslated file. The program should read a record from each file, then MOVE the text and display numeric fields from the translated record to the appropriate fields of the untranslated record, then use the fields from the untranslated record in the rest of the program logic. If the file has any numeric fields with embedded sign, that still would require special handling to get the encoding of the sign to be correct.
The last time we had a question like this, I believe someone presented some code that tried to fix up the numeric fields. I don't remember whether it was able to handle all possible cases.
Doug Miller
>The last time we had a question like this, I believe someone presented some
> code that tried to fix up the numeric fields. I don't remember whether it was
> able to handle all possible cases.
I believe you're thinking of the code that I posted to deal with numeric
fields that were usage display with an embedded sign. Different animal.
dimandja
>
> - Show quoted text -
If you cannot code on the IBM, let's try this.
Get the IBM file translated to ASCII by FUP:
FUP $INIBMTAPE, $OUTTANDEMDISC, EBCIDICIN
Try processing the result. At the moment, I have no access to IBM or
Tandem files to test the possible outcomes, but, hey, give it a whirl.
Doug Miller
>If you cannot code on the IBM, let's try this.
>
>Get the IBM file translated to ASCII by FUP:
>FUP $INIBMTAPE, $OUTTANDEMDISC, EBCIDICIN
That will not work. All fields that are USAGE DISPLAY are guaranteed to be
translated correctly, and all fields that are USAGE COMP, COMP-3, etc. are
guaranteed to be garbage.
The essence of the problem is that when converting from EBCDIC to ASCII, or
vice versa, all DISPLAY fields must be converted, and all binary fields (which
includes COMP-3) must *not* be. But FUP translates an entire record at once,
without regard to fields, and so everything is translated, including things
that should not be.
wbreidbach
> In article <f78256ed-eb8c-41bc-ba41-9a67a0fd2...@y12g2000vbr.googlegroups.com>, dimandja <demou...@yahoo.com> wrote:
>
> >If you cannot code on the IBM, let's try this.
>
> >Get the IBM file translated to ASCII by FUP:
> >FUP $INIBMTAPE, $OUTTANDEMDISC, EBCIDICIN
>
> That will not work. All fields that are USAGE DISPLAY are guaranteed to be
> translated correctly, and all fields that are USAGE COMP, COMP-3, etc. are
> guaranteed to be garbage.
>
> The essence of the problem is that when converting from EBCDIC to ASCII, or
> vice versa, all DISPLAY fields must be converted, and all binary fields (which
> includes COMP-3) must *not* be. But FUP translates an entire record at once,
> without regard to fields, and so everything is translated, including things
> that should not be.
I strongly agree to Doug and Keith, in fact to best way would be to
get an untanslated file from the IBM system, converting back from
ASCII to EBCDIC usually works but is the second best solution. My
impression was that there is no way to get the untranslated file.
Anyway some of the code conversion has to be done in the program and
inspect ... converting is a rather easy way to do that.
ChinmaYT
Thanks to all for sharing the information. :)
I got the file as ASCII and I am reading the file as it is.
One more thing I noticed, this is happening with only PIC 9(9) COMP-3
variables. The file has many COMP-3 variables like 9(3) COMP-3,
S9(11)V99 COMP-3 etc. But others are being read correctly.
In Data Build Manual for Tandem, I got a note - If a COMP or COMP-3
variable is greater than 9 digits, you must include an S in front of 9
in the source record descriptions, for example PIC S9(11) COMP. Is
this related to my problem?
I will check whether the guy sitting on IBM has converted the file
from EBCDIC to ASCII.
ChinmaYT
The representation of COMP-3 variables is -
12345 will be represented as
X'12345F' for an unsigned value, or X'12345C' for a positive value or
X'12345D' for a negative value. So, except for the trailing sign,
each
nibble must have a valid numeric value.
But I can see this structure only if the input file is in EBCDIC
mode.
If the original file is in ASCII, the structure is weird.
Which value is correct?
Keith Dick
Your description isn't completely clear to me, but my guess of what you mean is correct, the way you see the data when you look at the EBCDIC file is the correct way.
The problem I am pretty sure you are having is that when you pass COMP-3 fields though an EBCDIC to ASCII translation, it does not know that the COMP-3 fields should be left alone. The translation takes each byte and tries to find the ASCII character that corresponds to that byte, considered as an EBCDIC character. THE BYTES OF A COMP-3 FIELD ARE *NOT* EBCDIC CHARACTERS. That is the source of the problem.
If you look at the EBCDIC code chart, you will find that not all of the possible bit patterns in a COMP-3 field byte correspond to EBCDIC characters, so it is undefined what they get translated into. Also, even for bit patterns that do match EBCDIC characters, the bit patterns of the corresponding ASCII characters are not the same bit patterns, so the values of the nibbles are messed up by the translation.
*** One should not do an EBCDIC to ASCII translation on a file that contains COMP-1 or COMP-3 data. ***
Even display numeric fields are a bit of a problem if they have embedded sign.
It is technically possible to do the translation properly, but that requires a somewhat sophisticated translation program. You must give the program a description of the data type and size of the fields of the record. Then it would be possible to convert each data type properly (and just copy over those fields that do not need conversion). I'm sure such translation programs exist, but I don't know of any.
As I think I said earlier, the best solution is to convert the file on the IBM system to one that contains pure character data. That is, all numeric fields should be display numeric (no COMP, COMP-1, or COMP-3) and SIGN SEPARATE. After you have converted the original file to a pure character file, you can run that file through an EBCDIC to ASCII conversion, move it to the Tandem, and get correct data on the Tandem.
The next best solution probably is to take an unconverted EBCDIC file to the Tandem system and do an EBCDIC to ASCII conversion of the PIC X fields in the code of the program. For display numeric fields with embedded sign, a custom EBCDIC to ASCII conversion can be done that takes into account the way the embedded sign affects the high or low digit of the field. The COMP-1 and COMP-3 fields should be used as they are -- no conversion should be done.
If you can't use either of those approaches, you have a big problem.
MicroTech
X'12345S' (where S is F, C, or D) is the "correct" value. If this is
what you see on the TNS, you are looking at EBCDIC data. This cannot
be "straight converted" into ASCII (0x12, 0x34, and 0x5F/5C/5D would
translate to garbage).
If you have access to the ITUG library, download SASLIB (my now *very
old* library of TAL utility functions (written 1977, when I worked as
a systems programmer at SAS (the airline) in Sweden)). This library
contains a function name IBMCOMP3() (or something very similar, I
forgot...), which converts EBCDIC COMP-3 values to a format
understood by Tandem.
I lost the source decades ago, but it should still be present in the
ITUG collection of user uploaded stuff.
Have fun!
Henry Norman
MicroTech Consulting
http://groups.google.com/group/microtech_software
Keith Dick
The current COBOL compilers now understand COMP-3, as long as those fields have not been trashed by an ill-advised EBCDIC to ASCII translation of the whole record. I imagine your old library converts untrashed COMP-3 fields into some other numeric data type, and would not do anything helpful if the COMP-3 fields have been trashed. If the COMP-3 fields were untrashed, he would not be having the problem he is having. So I'm pretty sure digging up your old library would not help with this problem.
That library probably would be useful for someone programming in TAL or C and who has received a file that has not undergone an EBCDIC to ASCII translation.
ChinmaYT
Yes, that is the problem. During transmission of files other party
converted the original EBCDIC file to ASCII format and did not mention
to me that they did so. I was thinking that the data in the file is
untouched and ASCII and I was reading ASCII file as it is.
My program is doing same as you mentioned.
Converting EBCDIC--> ASCII for PIC X fields and
Direct MOVE for COMP-3 Fields to PIC 9 Fields.
And its working fine this time. Thank god and you all my friends. :)
wbreidbach
I have a little 15 years old TAL-subroutine converting EBCDIC strings
to ASCII and vice versa. If somebody is interested in the source code
feel free to contact me.
Rich S
There is a system procedure for this now. See CONVERTASCIIEBCDIC in
the Guardian Procedure Calls manual.
Keith Dick
As it seems we are cataloging the ways you can do EBCDIC/ASCII conversion, I'll play, too:
If the program is COBOL and the file contains only graphic characters, that is the data fields are only alphanumeric or display numeric with no sign or separate sign (no binary, packed decimal, or embedded sign), then the COBOL library will do EBCDIC/ASCII conversion for you in the input or output statement. You need only add CODE-SET EBCDIC to the File Description (and include ALPHABET EBCDIC IS EBCDIC in SPECIAL-NAMES). Isn't COBOL wonderful?
I think it would be even more wonderful if it would look at the field descriptions and translate only the character fields, move the binary and packed decimal fields unchanged, and fix the embedded sign for display numeric fields. In principle, that would not be hard to do, but I imagine there hasn't been enough demand for that level of automatic conversion, and I imagine the ISO Standard only requires that it work when the data is just plain character data. But full automatic conversion sure would prevent these kinds of problems from coming up over and over (or at least it would be a lot easier to tell people how to solve them!).