Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Packed field conversion 1

Status
Not open for further replies.

S3066

Technical User
Aug 1, 2001
66
US
I have a ".dat" text file, produced from a mainframe source and then opened at my PC.

Does anyone know why such a file would show non-numeric chars at the end of a packed field?

For example:

A negative number "16.35-" appears as "163N" in the ".dat" file on the PC.

A positive "4.35" appears as "43E".

A positive number "67.20" appears as "672{".

Something to do with the way the packed field was converted from the mainframe level to the PC?

I was trying to figure out a specific explanation; maybe there isn't one?

Thanks for your time ... Sue.
 
Sue,

There is an explanation.

The programmer converted the packed decimal fields into USAGE DISPLAY fields; that's the good news.

The bad news is that the programmer failed to use SIGN IS SEPARATE. What you are seeing in the last character is a digit value combined with a sign.

Your first choice might be to ask the mainframe programmer to fix it!

If you have to convert the stuff yourself, here is the most likely conversion table:

POSITIVE NUMBER
{ = 0
A = 1
B = 2
C = 3
D = 4
E = 5
F = 6
G = 7
H = 8
I = 9

NEGATIVE NUMBER
} = 0
J = 1
K = 2
L = 3
M = 4
N = 5
O = 6
P = 7
Q = 8
R = 9


Tom Morrison
 
Hi Tom,

Am I missing something (it wouldn't be the 1st time)? :) I would think Sue would need the sign overpunch if she intends to process them as packed fields in her COBOL pgm. This would produce an algebraically correct result when they're used.

If she wants to print/display them, they can be moved to a numeric edited field.

Regards, Jack.
 

Many thanks to both Tom (k5tm) and Jack.

To answer Jack's response, what I'm trying to do is take the text file info into something like Microsoft Access to perform subtotaling and other reporting needs.

I'm going to use Tom (k5tm's) handy chart to see if I can't use Visual Basic (VB) to convert the unwanted characters into the appropriate signed numerics.

The file, though is fairly large (5752 KB!!), so if push comes to shove and VB can't handle it memory-wise, then I'll take Tom's other advice and ask the COBOL programmer to use sign separate.

Thanks, everyone! --Sue.
 
Sue,

Here is a function to convert the numbers on the fly (warning - not checked for errors, but adapted from some code I had):

Code:
Function CombinedValue(TheNum As String) As Long
    Dim C As String * 1, i As Integer, s as string
    Dim OperationalSign as integer

    C = Right$(TheNum, 1)
    if len(TheNum) > 1 then
        s = left$(TheNum, Len(TheNum) - 1)
    else
        s = "0"
    end if
    i = InStr("{ABCDEFGHI}JKLMNOPQR", C)
    If i = 0 Then 
        ' You have an error
        CombinedValue = -999999999
    else
        OperationalSign = 1
        i = i - 1
        if i > 9 then
            OperationalSign = -1
            i = i - 10
        end if
        CombinedValue = OperationalSign * (CLng(s) * 10 + i)
    End If
End Function

Of course, Long can not handle 18 decimal digits of precision. You can modify this function to return a string after you have converted the trailing, combined sign/digit, instead of returning a Long.
Tom Morrison
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top