Hi.  I have a need to generate an EBCDIC file on a Unix platform to FTP
up to a mainframe.  The file will then be read by COBOL modules on the
mainframe.  I have a specific file layout that I need to create which
contains some packed fields.  My question is how to create an EBCDIC
based file on a Unix platform that contains packed data fields?  Is
this even possible?  Thank you.

"eric" <eric.roelofs@ubs.com> writes:

> Hi.  I have a need to generate an EBCDIC file on a Unix platform to FTP
> up to a mainframe.  The file will then be read by COBOL modules on the
> mainframe.  I have a specific file layout that I need to create which
> contains some packed fields.  My question is how to create an EBCDIC
> based file on a Unix platform that contains packed data fields?  Is
> this even possible?  Thank you.

Does "dd conv=ebcdic" do anything useful?

-- 
M�ns Rullg�rd
mru@inprovide.com

"M�ns Rullg�rd" <mru@inprovide.com> wrote in message news:yw1xwtvlj1f4.fsf@ford.inprovide.com...
: "eric" <eric.roelofs@ubs.com> writes:
:
: > Hi.  I have a need to generate an EBCDIC file on a Unix platform to FTP
: > up to a mainframe.  The file will then be read by COBOL modules on the
: > mainframe.  I have a specific file layout that I need to create which
: > contains some packed fields.  My question is how to create an EBCDIC
: > based file on a Unix platform that contains packed data fields?  Is
: > this even possible?  Thank you.
:
: Does "dd conv=ebcdic" do anything useful?

No - it translates EBCDIC to ascii (and there are two ways to do that and some
IBM EBCDIC symbols have NO matching representation in ASCII) and it
converts fixed width fields to linefeed terminated lines,  stripping trailing spaces.
It will trash packed fields.

Dan Mercer

:
: -- 
: M�ns Rullg�rd
: mru@inprovide.com

"Dan Mercer" <dmercer@mn.rr.com> writes:

> "M�ns Rullg�rd" <mru@inprovide.com> wrote in message news:yw1xwtvlj1f4.fsf@ford.inprovide.com...
> : "eric" <eric.roelofs@ubs.com> writes:
> :
> : > Hi.  I have a need to generate an EBCDIC file on a Unix platform to FTP
> : > up to a mainframe.  The file will then be read by COBOL modules on the
> : > mainframe.  I have a specific file layout that I need to create which
> : > contains some packed fields.  My question is how to create an EBCDIC
> : > based file on a Unix platform that contains packed data fields?  Is
> : > this even possible?  Thank you.
> :
> : Does "dd conv=ebcdic" do anything useful?
>
> No - it translates EBCDIC to ascii

My "man dd" tell me this:

        Conversions:
              ascii  Convert EBCDIC to ASCII.
              ebcdic Convert ASCII to EBCDIC.
              ibm    Convert ASCII to alternate EBCDIC.

(and a bunch of others)

> (and there are two ways to do that and some IBM EBCDIC symbols have
> NO matching representation in ASCII)

I'm not doubting that.

> and it converts fixed width fields to linefeed terminated lines,
> stripping trailing spaces.

That would be conv=unblock.

> It will trash packed fields.

Would you care to elaborate a little on the structure of the input
data, and the required structure of the output file?  I'm pretty sure
there's a simple way to get the job done, as long as the output is
representable as a sequence of bytes.

-- 
M�ns Rullg�rd
mru@inprovide.com

M�ns Rullg�rd <mru@inprovide.com> writes:

> "eric" <eric.roelofs@ubs.com> writes:
> 
> > Hi.  I have a need to generate an EBCDIC file on a Unix platform to FTP
> > up to a mainframe.  The file will then be read by COBOL modules on the
> > mainframe.  I have a specific file layout that I need to create which
> > contains some packed fields.  My question is how to create an EBCDIC
> > based file on a Unix platform that contains packed data fields?  Is
> > this even possible?  Thank you.
> 
> Does "dd conv=ebcdic" do anything useful?

I doubt it. conv=ebcdic converts text, ie non packad data.
You will have to distinguish text encoded in EBCDIC and binary data.
Some binary data are plain 2-complement binary integers like usual.

Decimal Packed data consists in writting the number in base ten, then
substituting sixteen for ten:

 123456 = 1*10^5 + 2*10^4 + 3*10^3 + 4*10^2 + 5*10^1 + 6*10^0

          1*16^5 + 2*16^4 + 3*16^3 + 4*16^2 + 5*16^1 + 6*16^0 = 1193046

The trick is that when you hex-dump binary 1193046 you read it
as 123456, on big-endian machines like EBCDIC ones use to be.  
If you use 32-bit fields, you must ensure that the data is written
in big-endian (in C use htonl).


(defun write-32-bit-big-endian (val out)
    (write-byte (ldb (byte 8 24) val) out)
    (write-byte (ldb (byte 8 16) val) out)
    (write-byte (ldb (byte 8  8) val) out)
    (write-byte (ldb (byte 8  0) val) out))

(progn (with-open-file (out "/tmp/out" :element-type '(unsigned-byte 8)
                          :direction :output :if-exists :supersede) 
   (write-32-bit-big-endian (parse-integer "123456" :radix 16) out))
(ext:shell "od -tx1 /tmp/out"))

0000000 00 12 34 56
0000004

There is the problem of the sign, with several encoding possible.
A common encoding for the sign is to add a low order digit equal
to 12 for + or 13 for -. 
12(dec) = C(hex) = credit
13(dec) = D(hex) = debit

So -123456 (dec) would be stored as 01 23 45 6D (hex)
and 123456 (dec) would be stored as 01 23 45 6C (hex)

But you'd better refer to the specifications of the main frame file
format to learn the details of the encoding used.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.