EBCDIC to ASCII OPTCD=Q? (JCL)
in [Cobol]
|
From: Clark F Morris on 18 Sep 2006 09:02 On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf(a)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.) The ASCII tape option is there but I would suggest looking into the codeset options within COBOL. I THINK (haven't looked at the recent manuals within the last couple of years) that there is a way to say that a field has a different code set. USAGE NATIONAL comes to mind. This has the advantage of handling disk (which OPTCD=Q doesn't) and possibly direct communication with the partner. It also has the advantage of being tweakable in the program. > >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
From: on 18 Sep 2006 09:51 In article <pv5tg2lck4ba54k7vkhj2fknrpprcjc1r9(a)4ax.com>, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf(a)panix.com () wrote: > >> >>All righty... I've been asked about having a job on an IBM mainframe >>(z/OS) produce ASCII output. [snip] >The ASCII tape option is there but I would suggest looking into the >codeset options within COBOL. I THINK (haven't looked at the recent >manuals within the last couple of years) that there is a way to say >that a field has a different code set. USAGE NATIONAL comes to mind. Ahhhh... this involves the NSYMBOL compiler option, if I'm reading the manual correctly. Time to do a bit of digging and see if it can be made to jump through the hoops I've been told are needed. Thanks much! DD
From: Arnold Trembley on 18 Sep 2006 11:37 docdwarf(a)panix.com wrote: > In article <pv5tg2lck4ba54k7vkhj2fknrpprcjc1r9(a)4ax.com>, > Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: > >>On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf(a)panix.com () wrote: >> >> >>>All righty... I've been asked about having a job on an IBM mainframe >>>(z/OS) produce ASCII output. > > > [snip] > > >>The ASCII tape option is there but I would suggest looking into the >>codeset options within COBOL. I THINK (haven't looked at the recent >>manuals within the last couple of years) that there is a way to say >>that a field has a different code set. USAGE NATIONAL comes to mind. > > > Ahhhh... this involves the NSYMBOL compiler option, if I'm reading the > manual correctly. Time to do a bit of digging and see if it can be made > to jump through the hoops I've been told are needed. > > Thanks much! > > DD Hey Doc, does the person who signs your timesheets want even-parity ASCII, odd-parity ASCII, or no parity ASCII? With kindest regards, -- http://arnold.trembley.home.att.net/
From: on 18 Sep 2006 12:35 In article <e3zPg.61827$QM6.49268(a)bgtnsc05-news.ops.worldnet.att.net>, Arnold Trembley <arnold.trembley(a)worldnet.att.net> wrote: > > >docdwarf(a)panix.com wrote: >> In article <pv5tg2lck4ba54k7vkhj2fknrpprcjc1r9(a)4ax.com>, >> Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >> >>>On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf(a)panix.com () wrote: >>> >>> >>>>All righty... I've been asked about having a job on an IBM mainframe >>>>(z/OS) produce ASCII output. [snip] >> Ahhhh... this involves the NSYMBOL compiler option, if I'm reading the >> manual correctly. Time to do a bit of digging and see if it can be made >> to jump through the hoops I've been told are needed. >> >> Thanks much! > >Hey Doc, does the person who signs your timesheets want even-parity >ASCII, odd-parity ASCII, or no parity ASCII? I barely know what *I* want, let alone anyone else... but no parity has been specified so none's what'll be offered. DD
From: Howard Brazee on 18 Sep 2006 13:04
On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf(a)panix.com () wrote: >(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.) It's quite possible that I've had bosses even more clueless. But you've got to do what you've got to do. |