EBCDIC to ASCII OPTCD=Q? (JCL)
in [Cobol]
|
From: on 19 Sep 2006 12:57 In article <cu70h2pcmcnk927bhj7goibd970pnubioj(a)4ax.com>, Howard Brazee <howard(a)brazee.net> wrote: Once again, thanks to all... but I can't even get a tape mounted, the SMC0043 tells me that the unit cannot be allocated. DD [top post, nothing new below] >That is correct. This is from the "Macro Instrucionns for Data Sets" >manual; see the last paragraph and note that LABEL=(,AL) assumes >OPTCD=Q > >Q > requests conversion of the tape records between what is stored on > tape and what is supplied from/to the problem program. For input > requests, conversion is done after the data is read from tape. For > output requests, conversion is done just before the record is > written to tape. > > The Q option implies that the character representation of the data > on tape differs from that seen by the problem program. Data > management converts records according to one of the following > techniques: > > O CCSID Conversion > > If CCSIDs are supplied from any source for ISO/ANSI V4 tapes, > records are converted between the CCSID which represents the > data on tape and the CCSID as seen by the problem program. You > can also prevent conversion by supplying a special CCSID. > > O Default Character Conversion > > If you are using non-ISO/ANSI V4 tapes or if CCSIDs are not > supplied by any source, data management converts the records > between ASCII code (which represents the data on tape) to > EBCDIC code (which is seen by the problem program) using > specific tables defined for this default character conversion. > > > Refer to z/OS DFSMS: Using Data Sets, SC26-7410, for a complete > description of CCSID conversion and default character conversion. > > Refer to z/OS DFSMS: Using Magnetic Tapes for more information > about ISO/ANSI labels. > > Q is supported only for a magnetic tape that does not have IBM > standard labels. If the tape has ISO/ANSI/FIPS labels > (LABEL=(,AL)), the system assumes OPTCD=Q. > >-- >Bruce A. Black >=============================== >IIRC, even if you code LABEL=(1,NL), OPEN checks to see if a label >does in >fact exist. And, if it does, OPEN will do some verfication of the >content, which could still lead to problems. It's been a long time >since >I messed with tape labels, so I could be mistaken. > > > >John Kington <john.kington(a)CONVERGYS.COM> >======================== >If you say NL but the tape that is mounted has labels (standard or >ANSI) >the mount is rejected > >-- >Bruce A. Black >======================
From: Alistair on 19 Sep 2006 19:01 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.) > > 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.
From: Clark F Morris on 19 Sep 2006 20:59 On Tue, 19 Sep 2006 12:50:14 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <s%CPg.28511$jS4.18972(a)fe03.news.easynews.com>, >William M. Klein <wmklein(a)nospam.netcom.com> wrote: >>A couple of answers (to you and other posts). >> >> much snipped, I think I kept the right attributions >> >>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. > >Not necessarily DFSORT, *any* JCL/utility stream which will not require >the creating of a special program full of obscure constructs and arcane >references. The reason for this is, of course, that the less 'stuff' one >needs to get past folks in order to get Prod implementation the less stuff >there is for someone to look at and say 'I don't understand this... so it >doesn't go in.' > >(for some reason folks here are more willing to let utilities/JCL >constructs with which they are unfamiliar into Prod - I've put in the >first jobs using things like referbacks and ICETOOL that this shop seems >to have seen - than they are willing to let unfamiliar COBOL constructs >pass in a similar manner) I have noticed the same syndrome. Somehow those in charge don't realize that JCL (OCL/shell script/command language of choice or affliction), utility control statements and similar artifacts are code that may be making business decisions. In the case of sort control statements like INCLUDE/OMIT, the decisions can be made in a really obscure way. If companies really cared about documentation and auditablity, they would have only COBOL/PL1/other language sorts and not an easily changed and obscure bunch of control statements running the sorts. > >Thanks much! > >DD
From: William M. Klein on 19 Sep 2006 21:44 Doc, I don't think this has made it back to comp.lang.cobol yet. Hope this helps. -- Bill Klein wmklein <at> ix.netcom.com <Efinnell15(a)ibm-main.lst> wrote in message news:3f2.9b25b13.3241a329(a)aol.com... > > In a message dated 9/19/2006 2:39:01 P.M. Central Standard Time, > mark.zelden(a)ZURICHNA.COM writes: > > There are various reasons you might get that message. It is from the > SMC component of Sun/STK that is used with their tape robotic > software. Without getting into a lot of detail, the easiest way > to bypass SMC (which handles all the tape allocations) is to specify > a unit address in the JCL instead of an estoeric / generic. > > Example: //TAPEDD DD DSN=MY.DSN,DISP=SHR,VOL=123456,UNIT=/5200 > > (slash needed for 4 digit addresses) > > > >>> > Can we just FTP to the tape drive as txt and let FTP do the conversion? > Don't have this setup, but seems more straightforward. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to listserv(a)bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >
From: on 20 Sep 2006 07:45
In article <9941h29gn81nmi1oa5fora5u822eqv1863(a)4ax.com>, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >On Tue, 19 Sep 2006 12:50:14 +0000 (UTC), docdwarf(a)panix.com () wrote: [snip] >>(for some reason folks here are more willing to let utilities/JCL >>constructs with which they are unfamiliar into Prod - I've put in the >>first jobs using things like referbacks and ICETOOL that this shop seems >>to have seen - than they are willing to let unfamiliar COBOL constructs >>pass in a similar manner) > >I have noticed the same syndrome. Ah yes... once again, every place is different so every place is the same. DD |