Home > Archive > Cobol > September 2006 > [OT] EBCDIC to ASCII OPTCD=Q? (JCL)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[OT] EBCDIC to ASCII OPTCD=Q? (JCL)
|
|
|
|
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
| |
| Clark F Morris 2006-09-18, 7:55 am |
| On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), 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.)
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
| |
|
| In article <pv5tg2lck4ba54k7vkhj2fknrpprcjc1r9@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf@panix.com () wrote:
>
[snip]
[color=darkred]
>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
| |
| Arnold Trembley 2006-09-18, 6:55 pm |
|
docdwarf@panix.com wrote:
> In article <pv5tg2lck4ba54k7vkhj2fknrpprcjc1r9@4ax.com>,
> Clark F Morris <cfmpublic@ns.sympatico.ca> 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.
>
> 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/
| |
|
| In article <e3zPg.61827$QM6.49268@bgtnsc05-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>
>
>docdwarf@panix.com wrote:
[snip]
[color=darkred]
>
>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
| |
| Howard Brazee 2006-09-18, 6:55 pm |
| On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf@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.
| |
| Howard Brazee 2006-09-18, 6:55 pm |
| On Mon, 18 Sep 2006 13:02:14 GMT, Clark F Morris
<cfmpublic@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?
| |
| Clark F Morris 2006-09-18, 6:55 pm |
| On Mon, 18 Sep 2006 16:35:40 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <e3zPg.61827$QM6.49268@bgtnsc05-news.ops.worldnet.att.net>,
>Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>
>[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.[color=darkred]
>
>I barely know what *I* want, let alone anyone else... but no parity has
>been specified so none's what'll be offered.
>
>DD
| |
| Arnold Trembley 2006-09-18, 6:55 pm |
|
Howard Brazee wrote:
> On Mon, 18 Sep 2006 13:02:14 GMT, Clark F Morris
> <cfmpublic@ns.sympatico.ca> wrote:
>
>
>
>
> 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/
| |
| William M. Klein 2006-09-18, 6:55 pm |
| 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-.../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-...gy3pg31/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@panix.com> wrote in message news:eem3rk$sqc$1@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
>
| |
|
| In article <huotg2h5d7di2k6rclpmplarqorrjvucui@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Mon, 18 Sep 2006 16:35:40 +0000 (UTC), docdwarf@panix.com () wrote:
[snip]
[color=darkred]
[snip]
[color=darkred]
>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
| |
|
| In article <s%CPg.28511$jS4.18972@fe03.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>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.
Gah. Thanks much, Mr Klein; I am trying to do this entirely by
utilities/JCL and I hope to avoid a dedicated COBOL program... if my hopes
are in vain then I'll start down this path.
>
>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-.../igy3pg31/1.9.7
Most valuable... thanks much!
[snip]
>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.
'Victory's father is the guy who signs the timesheet, defeat's daddy is
The Consultant'... or something like that.
>
>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)
Thanks much!
DD
| |
| Howard Brazee 2006-09-19, 7:55 am |
| On Tue, 19 Sep 2006 12:50:14 +0000 (UTC), docdwarf@panix.com () wrote:
>Gah. Thanks much, Mr Klein; I am trying to do this entirely by
>utilities/JCL and I hope to avoid a dedicated COBOL program... if my hopes
>are in vain then I'll start down this path.
In that case, I can post your request on the IBM-Main listserver,
which is copied to the IBM-Main newsgroup. Shall I go ahead and do
that?
| |
|
| In article <93svg25kdd3k99p7enqouh5v6ulqug1mue@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Tue, 19 Sep 2006 12:50:14 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>In that case, I can post your request on the IBM-Main listserver,
>which is copied to the IBM-Main newsgroup. Shall I go ahead and do
>that?
Sure, why not... I've been told to RTFM by better folks than they, I'm
sure!
Thanks much.
DD
| |
| Howard Brazee 2006-09-19, 6:55 pm |
| On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf@panix.com () wrote:
>
>All righty... I've been asked about having a job on an IBM mainframe
>(z/OS) produce ASCII output.
================
Howard, where is your LABEL parameter on the output tape DD statement.
IIRC
you need to specify LABEL=(1,AL) or somesuch.
Jim McAlpine
======================
Howard,
Try adding LABEL=(1,AL) or LABEL=(1,NL). I think you are getting the
default of 1,SL which
does not work with OPTCD=Q.
Regards,
John
| |
|
| In article <4q00h2ppgvk5g8t847f06ojqr1mokdod7s@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Mon, 18 Sep 2006 12:36:04 +0000 (UTC), docdwarf@panix.com () wrote:
>
>================
>Howard, where is your LABEL parameter on the output tape DD statement.
>IIRC
>you need to specify LABEL=(1,AL) or somesuch.
>
>Jim McAlpine
>======================
>
>Howard,
>
>Try adding LABEL=(1,AL) or LABEL=(1,NL). I think you are getting the
>default of 1,SL which
>does not work with OPTCD=Q.
Well, it does... *something*, that's for sure, and the results of this
'something' seem to toss it back into the laps of Ops. When the JCL is
coded:
//SORTOUT DD DSN=hinode.TEST.ASCII,
// DISP=(,CATLG,CATLG),
// UNIT=TAPE,EXPDT=98000,
// DCB=(OPTCD=Q),LABEL=(1,NL)
.... I get an error message of 'SMC0043 Job CNVASCI1 step STEP1 not
allocatable at MINLVL=2; failing DD SORTOUT'.
According to the QuickWeference for SMC0043 the 'allocation component
detected that the job is not allocatable at the specified minimum
exclusion level (MINLVL)' and the User Response should be to 'Correct the
JCL, or change the MINLVL for the specified job.' ... and according to the
Web (using Google to search on 'jcl minlvl' (no ') or 'jcl "minimum
exclusion level"' (no ', " included) there isn't much out there.
To all involved... thanks much!
DD
| |
| Clark F Morris 2006-09-19, 6:55 pm |
| On Tue, 19 Sep 2006 12:50:14 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <s%CPg.28511$jS4.18972@fe03.news.easynews.com>,
>William M. Klein <wmklein@nospam.netcom.com> wrote:
>
>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
| |
|
| In article <9941h29gn81nmi1oa5fora5u822eqv1863@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Tue, 19 Sep 2006 12:50:14 +0000 (UTC), docdwarf@panix.com () wrote:
[snip]
>
>I have noticed the same syndrome.
Ah yes... once again, every place is different so every place is the same.
DD
| |
| Howard Brazee 2006-09-20, 6:55 pm |
| > 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
>
I think the SMC messages come from SUN/STK SILO (HSC/SMC) software.
I don't know how it decides what units are available for allocation,
but
maybe this will give you a place to look.
Richard
==================================
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)
See the SMC manuals for more details.
Mark
========================================
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.
========================================
==========
On 19 Sep 2006 19:51:25 -0700, giltjr@ibm-main.lst (John S. Giltner,
Jr.) wrote:
[color=darkred]
>Does the output have to be tape? Does it have to be written in ASCII
>from the Cobol program?
He said it has to be done using a utility (according to those who
write his paycheck).
>What about doing OCOPY under TSO to a HFS file?
I'll pass this reply on, along with the others.
| |
|
| In article <80q2h25igcbgcpdlrqokfbm4pik36paepc@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:[color=darkred]
[snip of ones already answered]
[color=darkred]
No idea how OCOPY is configured at this site... but entering a TSO OCOPY
from the command line gives me
ENTER INPUT DDNAME -
NODE1.NODE2.DSNAME
INVALID INPUT DDNAME, NODE1.NODE2.DSNAME
REENTER THIS OPERAND+ -
'NODE1.NODE2.DSNAME'
INVALID INPUT DDNAME, 'NODE1.NODE2.DSNAME'
REENTER THIS OPERAND+ -
SYSUT1
ENTER OUTPUT DDNAME -
SYSUT2
FILE INFO-RETRIEVAL NOT PERFORMED, IS NOT ALLOCATED
***
.... but it was fun while it lasted!
DD
| |
|
| docdwarf@panix.com () wrote:
>Well, it does... *something*, that's for sure, and the results of this
>'something' seem to toss it back into the laps of Ops. When the JCL is
>coded:
>
>//SORTOUT DD DSN=hinode.TEST.ASCII,
>// DISP=(,CATLG,CATLG),
>// UNIT=TAPE,EXPDT=98000,
>// DCB=(OPTCD=Q),LABEL=(1,NL)
>
>... I get an error message of 'SMC0043 Job CNVASCI1 step STEP1 not
>allocatable at MINLVL=2; failing DD SORTOUT'.
Who's issuing SMC messages? It's not OS/390, and Syncsort messages
start with WER while IBM sort starts with ICE.
Have you tried the LABEL=(1,AL) ?
--
Ron
(user ron
in domain spamblocked.com)
| |
|
| In article <k4m5h21p71cngl8dnj6n68s0jufoo0nm7n@4ax.com>,
Ron <ron@address.below> wrote:
>docdwarf@panix.com () wrote:
>
>Who's issuing SMC messages? It's not OS/390, and Syncsort messages
>start with WER while IBM sort starts with ICE.
According to QuickWeference the vendor is Storage Tec. and the product is
SMC Messages, either V6 or V6R1.
>
>Have you tried the LABEL=(1,AL) ?
Nope... and I have no need to now, either, since... somebody whose posting
Mr Brazee relayed recommended using the OCOPY utility.
Thanks much!
DD
|
|
|
|
|