On Wed, Dec 21, 2016 at 6:33 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 21 Dec 2016 13:53:11 +0100, Massimo Biancucci wrote:
>
>
>
> >If you have DFSORT or similar, you could use TRAN=ATOE.
>
> >
>
> Which ASCII? Which EBCDIC? The page at:
>
> z/OS
On Wed, 21 Dec 2016 13:53:11 +0100, Massimo Biancucci wrote:
>If you have DFSORT or similar, you could use TRAN=ATOE.
>
Which ASCII? Which EBCDIC? The page at:
z/OS 2.2.0
z/OS DFSORT
z/OS DFSORT: Getting Started
Learning to write JCL and DFSORT control statements
Reformatting records with
If you have DFSORT or similar, you could use TRAN=ATOE.
Sort utilities usally are very good at I/O and CPU.
Regards.
Massimo
2016-12-19 16:47 GMT+01:00 Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu>:
> On Mon, 19 Dec 2016 08:35:33 -0600, Peter Vander Woude wrote:
> >
> >Our
It is built in to lots of places.
The idiocy arises (or only should arise) with the idea of transferring of
"non-character" data between systems - packed-decimal, binary, even, for
supreme idiocy, floating-point - so that a "field-level" translation is
required of the "character" data. Then
equ...@listserv.ua.edu>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Mon, Dec 19, 2016 4:47 pm
Subject: ASCII<->EBCDIC (was: convince programmer something else is better.)
On Mon, 19 Dec 2016 08:35:33 -0600, Peter Vander Woude wrote:
>
>Our programmers used to use a cobol to read in a f
On Mon, Dec 19, 2016 at 9:47 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 19 Dec 2016 08:35:33 -0600, Peter Vander Woude wrote:
> >
> >Our programmers used to use a cobol to read in a file, for ebcdic to
> ascii translation, and then this subprogram would
On Mon, 19 Dec 2016 08:35:33 -0600, Peter Vander Woude wrote:
>
>Our programmers used to use a cobol to read in a file, for ebcdic to ascii
>translation, and then this subprogram would be called for each record to
>convert from ebcdic to ascii. The job steps calling that routine spent over
