The original file is in EBCDIC so the UNIX system doesn't understand it.

I can place the file in a location on our system where data warehouse
can come get the file using a vendor tool but I am told that the tool
doesn't handle packed fields. This may sound silly but we do quite a
bit of copying a file from our production library to the staging library
and unpacking the fields so data warehouse can pull the data. In this
particular case the information is not necessary.

I'm waiting to hear back from data warehouse about obtaining a file
layout and receiving the file directly without it stopping on the UNIX
box first.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tom Liotta
Sent: Wednesday, March 05, 2008 2:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Replacing packed fields in record

Rick.Chevalier@xxxxxxxxxxxxxxx wrote:

The packed fields don't have to be replaced with blanks, just handled
in a way that the UNIX system can handle them. The values aren't
required by the data warehouse group so preserving the data isn't a
concern. At least not yet.

What is the particular problem with the 'packed' fields? That is, why is
it necessary to do anything with them at all if they're not actually

I'd think in terms of hex patterns that were interpreted as delimiters
as a potential problem category. But, so far, I don't recall seeing what
the "problem" actually is, particularly if these fields aren't used.

One other possibly minor question -- are we talking about 'packed'
fields as we normally think of them where a sign-nibble is at the right?
Or are these more of a BCD representation where there is no sign? E.g.,
a numeric value of 123 is x'123F' in our normal world, but might be
x'0123' in a basic BCD representation.

And one off-the-wall possibility -- Could the lines be fed to a REXX
procedure for conversion? I've used REXX to handle hex-to-character
conversions in some useful ways in the past. Nowadays, ILE HLLs have
easy access to lots of system and C procs; so, REXX isn't as useful.
But it still fits in some places.

Tom Liotta

Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788 x313
Fax 253-872-7904
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at

Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].