EBCDIC to ASCII OPTCD=Q? (JCL)
in [Cobol]
|
From: Howard Brazee on 18 Sep 2006 13:05 On Mon, 18 Sep 2006 13:02:14 GMT, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >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. How do people write CDs from the mainframe?
From: Clark F Morris on 18 Sep 2006 14:25 On Mon, 18 Sep 2006 16:35:40 +0000 (UTC), docdwarf(a)panix.com () wrote: >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? You also might want to look at the ALPHABET clause in the CONFIGURATION SECTION of the ENVIRONMENT DIVISION. It has ASCII of some flavor and the 7 bit ISO 646 ASCII. I just downloaded all of the Enterprise COBOL manuals as PDF's. High speed Internet is great. > >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: Arnold Trembley on 18 Sep 2006 14:38 Howard Brazee wrote: > On Mon, 18 Sep 2006 13:02:14 GMT, Clark F Morris > <cfmpublic(a)ns.sympatico.ca> wrote: > > >>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. > > > How do people write CDs from the mainframe? Well, In my shop we use Hummingbird Host Explorer to download the mainframe file to a PC, and then burn a CD there. As most people are aware, if the mainframe file is "text", you can have the FTP program do an automatic conversion from EBCDIC to ASCII. We have a new Z9 mainframe, but I'm not sure if it even has a CD burner directly attached. -- http://arnold.trembley.home.att.net/
From: William M. Klein on 18 Sep 2006 16:06 A couple of answers (to you and other posts). 1) IBM mainframe (currently) only supports CODESET and OPTCD=Q for TAPE datasets. I *think* that if you use BOTH CODESET clause and OPTCD=Q, then you SHOULD be able to produce an ASCII TAPE output. 2) My best guess from the symptoms reported is that this MIGHT be a "label records standard" issue. I think COBOL OPTCD=Q files. Check out: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/1.9.7 3) Current COBOL supports producing ASCII output (after processing in EBCDIC) without using USAGE NATIONAL but using DISPLAY-OF and NATIONAL-OF intrinsic functions. Check out: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/1.6.6.4 4) Will you have any COMP-3 or non-USAGE DISPLAY output (with sign is separate). If so, make certain that you (or the person who signs your check) knows what is REALLY wanted. 5) All of this assumes a COBOL application. If you want a DFSort answer, I can make certain that Frank Yeager knows about your post and he can probably provide additional DFSort information. -- Bill Klein wmklein <at> ix.netcom.com <docdwarf(a)panix.com> wrote in message news:eem3rk$sqc$1(a)reader1.panix.com... > > 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 >
From: on 18 Sep 2006 18:41
In article <huotg2h5d7di2k6rclpmplarqorrjvucui(a)4ax.com>, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >On Mon, 18 Sep 2006 16:35:40 +0000 (UTC), docdwarf(a)panix.com () wrote: >>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: [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. [snip] >You also might want to look at the ALPHABET clause in the >CONFIGURATION SECTION of the ENVIRONMENT DIVISION. It has ASCII of >some flavor and the 7 bit ISO 646 ASCII. I just downloaded all of the >Enterprise COBOL manuals as PDF's. High speed Internet is great. I've stumbled across that, Mr Morris, and am slogging my way through as merrily as one might. Thanks much! DD |