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

Author

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

Alistair

2006-09-27, 6:55 pm

Doc, did you try this jcl with the OPTCD=Q on an IEFBR14 allocate and
leaving it off of the actual write DD?

It niggles me that I can not recall how we did it but we certainly did
not use any of that new-fangled Rexx stuff.

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

2006-09-27, 6:55 pm

In article <1159387774.411836.170220@e3g2000cwe.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>Doc, did you try this jcl with the OPTCD=Q on an IEFBR14 allocate and
>leaving it off of the actual write DD?

I can't recall at all, Mr Maclean... foolish pragmatist I can be, I found
a solution and then did my best to forget anything that didn't work.

>
>It niggles me that I can not recall how we did it but we certainly did
>not use any of that new-fangled Rexx stuff.

I'm not sure how newfangled the TSO OCOPY command is... but if something
can be solved with a direct TSO command then I'd say the solution is
sufficiently well-grounded for Prod implementation.

DD

Sponsored Links