Re: EBCDIC to ASCII OPTCD=Q? (JCL)

docdwarf@panix.com wrote:
> All righty... I've been asked about having a job on an IBM mainframe
> (z/OS) produce ASCII output.
>
> (To those who think to inquire 'Why don't you produce EBCDIC output and
> then have ftp translate it during transfer to the target?' my response is
> 'I have made this suggestion and someone who signs my timesheet responded
> 'That will be considered a possibility; right now you should look into
> making the ASCII files on the mainframe.''... and yes, all fields are
> either text or display numerics w/ sign leading separate.)
>
> I recall - but my memory is, admittedly, porous - something about the DCB
> parameter OPTCD=Q being able to accomplish this but it will require more
> jiggery-pokery than I can come up with; when I code an IEBGENER or a
> DFSORT with DD statements like:
>
> //INDD     DD    DISP=SHR,
> //         DSN=INPUT.DATASET.INEBCDIC
> //OUTDD    DD DSN=OUTPUT.DATASET.INASCII,
> //            DISP=(,CATLG,CATLG),
> //            UNIT=TAPE,RETPD=0,
> //            DCB=(*.INDD,BUFNO=30,OPTCD=Q)
>
> ... I get an ABEND (in the case of DFSORT it is IEC141I 013-70, a problem
> with the OPEN macro... but the QW text for Return Code 70 (for V=IBM
> P=Z/OS SYSTEM MSGS R=V1R4 I=IEC141I) reads:
>
> --begin quoted text:
>
> An OPEN macro instruction was issued for a data set on magnetic tape. A
> conflict exists between LABEL parameters on the DD statement, and the
> DCBRECFM, DCBOPTCD, DCBBUFOF, and DCBUSASI fields, which give the
> appearance of mixed ASCII and EBCDIC attributes for the data set; or TRTCH
> was specified for a 9-track tape.
>
> Some examples of conflicts are that for AL tapes the BLKSIZE must be less
> than 2048, RECFM=V,U and VB cannot be used. For details about AL tape
> restrictions see z/OS DFSMS: Using Magnetic Tapes . Note that most
> utilities (except for IEHINITT) do not support ASCII.
>
> --end quoted text
>
> (changing UNIT=TAPE,RETPD=0 to UNIT=SYSDA,SPACE=(TRK,(6000,500),RLSE) does
> not change the error but the salient text for 70 then appears to be 'An
> OPEN macro instruction was issued for a data set not on magnetic tape.
> Either OPTCD=Q was specified, or OPEN was issued for an ISAM data set
> using QSAM.')
>
> It appears obvious that under the conditions of my experiment DFSORT is
> falling into the category of 'most utilities'.  Might someone be so kind
> as to point me towards a resource from which I may be able to glean a
> solution?
>
> Thanks much.
>
> (Oh... and among a bunch of Other Stuff a Google search for '"EBCDIC ASCII
> translation" jcl' (no ', " included) returns
> http://www.dbforums.com/archive/index.php/t-327313.html ; this informs,
> among other things, that 'answering a question with a question is no
> answer at all'... it's on the Web, it's gotta be right, right?)
>
> DD

Sadly, you have proven to me how porous my memory is. I worked on an
invoicing system for 8 years where we had one job with an output of
tape ascii. So I should have been able to answer this one.

1. Try to remove the refer back used to pickup the input datasets DCB
parameters.

2. Check with ops whether you need to have the tape preformatted to be
in ascii output.

3. Add the label statement (that one rings a bell but all I hear are
faint echoes).

4. Do not create the ascii output in the DFSORT but add a copy step
(IEFBR14/IEBCOPY?).

I guess it ain't just my boozy chums' brain which has become addled
with alcohol.

In article <1158706861.008406.85620@b28g2000cwb.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>docdwarf@panix.com wrote:

[snip]
 

[snip]

>Sadly, you have proven to me how porous my memory is. I worked on an
>invoicing system for 8 years where we had one job with an output of
>tape ascii. So I should have been able to answer this one.
>
>1. Try to remove the refer back used to pickup the input datasets DCB
>parameters.

Done, no change in results.

>
>2. Check with ops whether you need to have the tape preformatted to be
>in ascii output.

In progress... they'll be getting back to me Any Day Now.

>
>3. Add the label statement (that one rings a bell but all I hear are
>faint echoes).

Done, see below.

>
>4. Do not create the ascii output in the DFSORT but add a copy step
>(IEFBR14/IEBCOPY?).

I used IEBGENER... and

//SYSUT2   DD DSN=VDA1WSX.TEST.ASCII,
//            DISP=(,CATLG,CATLG),
//            UNIT=TAPE,EXPDT=98000,
//             DCB=(LRECL=6000,RECFM=D,OPTCD=Q),LABEL=(
1,NL)

... which resulted in an SMC0043 message about 'STEP1 not allocatable at
MINLVL=2; failing DD SYSUT2'

>
>I guess it ain't just my boozy chums' brain which has become addled
>with alcohol.

As my Drill Sergeant used to bark at us, lo, those many years ago, 'You
think you know more'n me, Airman?  I've forgotten more than you'll ever
learn!'

There are military offices in the building in which I now work and
sometimes I'll see a four-, five- or six-stripe Air Force Sergeant (Staff
Sergeant, Technical Sergeant or Master Sergeant, respectively) on the
elevator... seems like folks are earning rank at a younger age every year.

DD