can you write an ebcdic file with packed decimal with se ds

[flashgordon]

we are in a situation where we are trying to provide a mainframe file just as it is provided today with a Unix SE Datastage installation. Today one mainframe is sending another mainframe an ebcdic file with some packed decimal fields in it.

First things first. We all agree CFF can't be used as an output stage? I tried it and it didn't work.

The ebcdic part doesn't scare me. I'm pretty sure I've seen ebcdic functions in se datastage. Are there any functions that will write a packed decimal number? Even the packed decimal part doesn't scare me. I think I have an approach that would do it. Scan 2 chararacters of a display format number at time from the left and assign the appropriate hex combination in the output byte. Are there 2 to the 10th combinations? Large but doable.

I would obviously have to send this file to the mainframe as "binary". This makes carriage returns problematic. I think I would have to write a perl or c++ program to get the recfm=fb I need. But the blocking on the unix side going through sftp or ndm seems problematic.

What do people think?

Flash Gordon

[roy]

Hi,
In the project I'm in right now were using a utility, from HITACHI to move files from windows to a FS that MF sees, that converts the ebcidic part. There for building a routine that builds a comp-3 from a regular ascii based number representation is useless.
Instead were using the load to DB2 as the conversion to comp-3 and moving the ascii based numbers to a comp-3 numbers in cobol programs when ever the imidiate target is not a DB2 table.

IHTH (I Hope This Helps),

[chulett]

My experience in this arena is more years older than I care to admit and predates my DataStage career, but mirrors what Roy posted. MF systems always seemed to have specific utilities that they used to transfer files to and from the 'Big Iron'. They handled the ASCII - EBCDIC (and vice versa) conversions during that process and the last one I used compressed and decompressed on-the-fly as well.

Having packed decimal fields in your transferring file became problematical in that case because (as we all know) packed is packed regardless of code page and if you 'convert' it, it becomes garbage. We handled that back in my Wang Days by having to build control files the transfer process used there, noting which ranges of bytes were display and could thus be converted and which were packed and should thus be transferred as-is. It was a total pain in the patootie.

The solution was always the same - don't transfer packed fields and build 'normal' ASCII files. We preferred that on our side and the MF folks preferred it on theres as well. Any extracts they performed converted all packed fields to display and the transfer turned it into ASCII, they expected all load files to be handled in the same fashion. This way the transfer program would handle the code page conversions in-flight with no futzing required and the MF loads could pack the fields however they wanted without having to worry about COMP-1 versus COMP-3, signed, unsigned, yada yada yada.

Not sure how much that helps. Flash, have you been told you must provide a packed / EBCDIC file or is this an assumption on your part? In your shoes, I'd push this back to the consumer side and let them handle all that, something that should be very typical for them.

IHTH.

[flashgordon]

"My experience in this arena is more years older than I care to admit ". Boy can I relate. I tell some people I work with now "I was working with Unix and Oracle and having too active a social life when you were in your crib". But right now this large organization requires that I sometimes deal with historic Operating Systems. So this is definitely ITTH. I just wanted to make sure writing a ebcdic file with packed fields wasn't a natural act and clearly the answer is no. I know we should ask the receiving groups to code for a valid ascii only extract. Part of the way we sold this project was that other groups wouldn't have to change anything they're doing now. Part of it is professional pride. If you can do something that's hard to do, that's satisfying. Thanks guys. I will digest it all and figure out something.

... Flash Gordon

[chulett]

:D

Don't get me wrong, the answer to your original question *is* 'yes'. I was mostly just wondering if you really needed to do all that. The issue is that, with a UNIX based product like this, what's included with the tool out of the box are routines to unpack fields, not pack them. And yes, there are both ASCII to EBCDIC and EBCDIC to ASCII transforms under the sdk\DataType branch of the repository, so you are covered there. Probably won't be the world's speediest process but it should be a workable one for you.

So, in order to build your EBCDIC file with packed fields, it seems that all you'd need to whittle up would be some routines to populate your packed fields. Shouldn't be all that bad, your 'scan two characters' logic can be automagically handled by the MP conversion code when used with IConv. Or so I've read.