HP3000-L Archives

September 1999, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stephen Douglass <[log in to unmask]>
Reply To:
Date:
Tue, 28 Sep 1999 14:08:14 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (87 lines)
John -

If you have to convert a packed field to zoned (a.k.a. decimal or, in your
case, ASCII), you need two field definitions: one for the input packed field
and the other for the output unpacked field.  Keep in mind that a packed
field occupies only about half as many bytes as a zoned field.  Therefore,
if you unpack any packed fields, your output record will be longer than the
input record.

Using your hex value '049484071C' (which occupies 5 bytes), if it is
unpacked the receiving field must be at least 9 digits in length.  (The 9
digit size is a combination of significant and decimal digits.  So a field
definition of 9(5)V9(4) (5-significant + 4-decimal = 9 total digits) would
work as well as 9(9).  To figure how large the receiving field has to be
just count the number of digits you see in the packed field's hex value.)
If the receiving field is less than 9 digits in total size you risk
high-order truncation.

For example:

        01  INPUT-RECORD.
                03  INPUT-FIELD     PIC S9(9) COMP-3.

        01  OUTPUT-RECORD.
                03  OUTPUT-FIELD  PIC S9(9).

        MOVE INPUT-FIELD TO OUTPUT-FIELD.

This will unpack the input field and put it into the output field.  A hex
view of OUTPUT-FIELD after the move would show '3034393438343037A1'.  Note
that the last byte is 'A1', not '31'.  This is because your receiving field
is defined as being signed.  If you don't want the sign, your OUTPUT-FIELD
definition should read PIC 9(9).  (See HP Data Types Conversion Programmer's
Guide for further explanation of packed and zoned data fields.)

Now, if what you want is the output to be edited (i.e., with commas, decimal
point, etc.), your OUTPUT-FIELD definition might read PIC ZZ,ZZZ,ZZ9.99-.

Anyway, hope this helps.

Steve Douglass
BFGoodrich Aerospace



-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of [log in to unmask]
Sent: Monday, September 27, 1999 2:53 PM
To: [log in to unmask]
Subject: COBOL Program Help Needed - Part 2


Hey Listers,

With Kevin Miller's help and the use of the IBMVBS utility from the CSL I
have
been able to deblock the IBM mainframe tape which contains variable length
records (in EBCDIC, of course) on a tape that has variable length blocks
into a
disk file containing variable length records readable by the HP still in
EBCDIC.

The current problem that I'm having is that the program properly translates
all
character fields that are in EBCDIC to ASCII but does NOT properly translate
ANY
of the packed decimal fields in EBCDIC to numeric-edited fields in ASCII.
Using
FCOPY I have verified that the fields I'm looking for are still in the
proper
packed decimal EBCDIC form.  My mainframe people are convinced that this
situation is a compiler bug.  I'm not sure.  I have tried both the 74 and 85
COBOL compilers giving the same results.

A example of a field is below:

Input field defined as PIC S9(9) COMP-3 in HEX:  049484071C
Output field defined as PIC +9(9) in ASCII:           +9<6=647?1

Any help is greatly appreciated.

John Hornberger
Sr. Systems Programmer
SPX Corporation
[log in to unmask]

ATOM RSS1 RSS2