View previous topic :: View next topic
|
Author |
Message |
jimmybhandari
New User
Joined: 04 Jun 2009 Posts: 13 Location: bangalore
|
|
|
|
Is it possible to create an output dsn with the same dcb parameters as the input dsn, just like what happens in DMSsort.
I tried using the following but, some how this is not working out.
//Indsn dd dsn=input,DCB=(LRECL=560,BLKSIZE=0,RECFM=FB)....
//outdsn dd dsn=ouput,dcb=*.indsn,.......
Please let me know if there is a problem in above method or an alternative solution to above problem.
Thanks |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
Yeah, use DFSORT or SYNCSORT. |
|
Back to top |
|
|
jimmybhandari
New User
Joined: 04 Jun 2009 Posts: 13 Location: bangalore
|
|
|
|
superk wrote: |
Yeah, use DFSORT or SYNCSORT. |
Thanks for replying Kevin. But, i want to do this task without using sort as, i am not calling DFSORT or SYNCSORT in my PROC. |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
jimmybhandari wrote: |
Is it possible to create an output dsn with the same dcb parameters as the input dsn, just like what happens in DMSsort.
I tried using the following but, some how this is not working out.
//Indsn dd dsn=input,DCB=(LRECL=560,BLKSIZE=0,RECFM=FB)....
//outdsn dd dsn=ouput,dcb=*.indsn,.......
Please let me know if there is a problem in above method or an alternative solution to above problem.
Thanks |
The referback you show in your jcl does what you want. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
PS. I believe, using refer-back is not a good idea if the "indsn" and "outdsn" are not on similar storage device. Though I'm little skeptical about what if both are on tape? (it's around 9 PM in office, don't want experiment just now...) |
|
Back to top |
|
|
jimmybhandari
New User
Joined: 04 Jun 2009 Posts: 13 Location: bangalore
|
|
|
|
Anuj Dhawan wrote: |
PS. I believe, using refer-back is not a good idea if the "indsn" and "outdsn" are not on similar storage device. Though I'm little skeptical about what if both are on tape? (it's around 9 PM in office, don't want experiment just now...) |
What i specified in the jcl above seems to the correct solution but, i am getting abend for the time being.
SYSTEM COMPLETION CODE=013 REASON CODE=00000034
Though i havent checked with dissimilar storage devices till now.
Thanks everyone for your help.. ... |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
That was just a precautionary measure, that's why written in Post Script...
Quote: |
SYSTEM COMPLETION CODE=013 REASON CODE=00000034 |
If you are changing the length of the record in any way, shortening or extending the line length, or writing out a different format, i.e. from FB to VB, or VB to FB, then you can not use the same attributes for the output file as the input file.
So, what is your PROC (program of that step in which you get abend) doing? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
The more information you provide the earlier you can get solutions. An 013-34 has these meanings in the manual:
Quote: |
34
The system detected one of these conditions:
* The following combination was specified: QSAM, MACRF=GD or PD, and a RECFM value that is not VS, VBS, DS, or DBS.
* An OPEN macro instruction was issued for a data set with BLKSIZE and BUFL equal to 0. The system determined that it had to obtain buffers but was unable to do so.
* RECFM was specified with both the A and M attributes.
* The following combination was specified: QSAM, LRECL=0, and a RECFM value that is not V or VB.
* The following combination was specified: RECFM=V or VB and LRECL greater than the quantity BLKSIZE minus 4.
* The following combination was specified: QSAM and BLKSIZE=0. No nonzero BLKSIZE value was available from any source and the system could not determine one. Coding BLKSIZE=0 in the JCL never has an effect except when overriding a cataloged procedure variable.
* The following combination was specified: RECFM not variable or undefined and LRECL greater than BLKSIZE.
* The following combination was specified: BFTEK=A, RECFM=VBS, and LRECL=0. |
|
|
Back to top |
|
|
jimmybhandari
New User
Joined: 04 Jun 2009 Posts: 13 Location: bangalore
|
|
|
|
Robert Sample wrote: |
The more information you provide the earlier you can get solutions. An 013-34 has these meanings in the manual:
Quote: |
34
The system detected one of these conditions:
* The following combination was specified: QSAM, MACRF=GD or PD, and a RECFM value that is not VS, VBS, DS, or DBS.
* An OPEN macro instruction was issued for a data set with BLKSIZE and BUFL equal to 0. The system determined that it had to obtain buffers but was unable to do so.
* RECFM was specified with both the A and M attributes.
* The following combination was specified: QSAM, LRECL=0, and a RECFM value that is not V or VB.
* The following combination was specified: RECFM=V or VB and LRECL greater than the quantity BLKSIZE minus 4.
* The following combination was specified: QSAM and BLKSIZE=0. No nonzero BLKSIZE value was available from any source and the system could not determine one. Coding BLKSIZE=0 in the JCL never has an effect except when overriding a cataloged procedure variable.
* The following combination was specified: RECFM not variable or undefined and LRECL greater than BLKSIZE.
* The following combination was specified: BFTEK=A, RECFM=VBS, and LRECL=0. |
|
Thanks Rob,
I am trying to implement this in an instream EZTtieve code.
Reading and writing the files as below
FILE INFILE FB (0 0)
........
FILE OUTFILE FB (0 0)
........
SO, THIS SHOULD PICKUP THE LRECL FROM JCL ITSELF AND TAKE BLOCKSIZE SET BY SMS AND THE BLOCKSIZE MAY WELL BE THE REASON FOR THIS ABEND AS, THE INPUT DSN MAY NOT BE SMS MANAGED.
I AM NOT SURE HOW I CAN COPY BLOCKSIZE ALSO FROM JCL IN AN EASYTRIEVE CODE.
pPLEASE SEE IF YOU CAN HELP. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
Have you ever done this successfully? The JCL Language Reference manual says
Quote: |
12.16.3 Completing the Data Control Block
The system obtains data control block information from the following sources, in override order:
* The processing program, that is, the DCB macro instruction in assembler language programs or file definition statements or language-defined defaults in programs in other languages.
* The DCB subparameter of the DD statement.
* The data set label.
Therefore, if you supply information for the same DCB field in your processing program and on a DD statement, the system ignores the DD DCB subparameter. If a DD statement and the data set label supply information for the same DCB field, the system ignores the data set label information. |
So by specifying the DCB in your program, you are explicitly telling the system not to use the JCL or the file as DCB source. I suspect setting the LRECL to 0 in your code is not a wise thing to do. |
|
Back to top |
|
|
jimmybhandari
New User
Joined: 04 Jun 2009 Posts: 13 Location: bangalore
|
|
|
|
Robert Sample wrote: |
Have you ever done this successfully? The JCL Language Reference manual says
Quote: |
12.16.3 Completing the Data Control Block
The system obtains data control block information from the following sources, in override order:
* The processing program, that is, the DCB macro instruction in assembler language programs or file definition statements or language-defined defaults in programs in other languages.
* The DCB subparameter of the DD statement.
* The data set label.
Therefore, if you supply information for the same DCB field in your processing program and on a DD statement, the system ignores the DD DCB subparameter. If a DD statement and the data set label supply information for the same DCB field, the system ignores the data set label information. |
So by specifying the DCB in your program, you are explicitly telling the system not to use the JCL or the file as DCB source. I suspect setting the LRECL to 0 in your code is not a wise thing to do. |
Rob,
Specifying file filname FB (0 0)
is not setting lelrecl to 0 but, is refering the program to take the same from JCL parameters.
I also tried giving just
File filename.
That too is giving same abend. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Can you read the input file successfully in Easytrieve? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
I (obviously) don't know Easytrieve, so I don't think I'll be much help. The referback as you originally presented will work and copy the DCB attributes from the input file to the output file -- as long as they are in the sequence you showed. Your problem therefore becomes application related since the JCL will do what you want.
You probably need to post the full JCL and program (unless they're ridiculously long). |
|
Back to top |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
|
|
|
|
For my easytrieve files I leave the "FB (0 0)" off both the input and output files. I guess I had not tried using a refer back to the input because I am now getting the same result without the "FB (0 0)" that you are getting with it, If I do not put the DCB of the input file in my JCL (letting the system get it off of the file), which is my normal practice. But if I put the DCB in the JCL on the input file and the refer back on the output file it is working. |
|
Back to top |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
|
|
|
|
Upon farther testing without the "FB (0 0)" gives blksize=lrecl. (I thought I had found that not to be true in the past). So I will now just leave it off of the input not the output file.
Also only the LRECL is needed in the JCL on the input with the refer back on the output. Or no DCB on the input and just the LRECL on the output.
Strange, this is not what I would have expected. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
Have a look on this very similar earlier thread, that does not provide a solution but yes, tells the same that there is something to do with your program-logic. For an experiment, please try coding DCB=LRECL=?? for your output DSN and let us know if that works. |
|
Back to top |
|
|
jimmybhandari
New User
Joined: 04 Jun 2009 Posts: 13 Location: bangalore
|
|
|
|
Anuj Dhawan wrote: |
Have a look on this very similar earlier thread, that does not provide a solution but yes, tells the same that there is something to do with your program-logic. For an experiment, please try coding DCB=LRECL=?? for your output DSN and let us know if that works. |
The logic DCB=LRECL= is not working out Anuj. This gives the below error
---CAY6049E BACK REFERENCE NOT VALID FOR "LRECL" PARAMETER OF "DCB"---
Douglous, i went through your posts... yes, this is strange that we need to specify DCB at least for one of Input/ output files to make back reference work with EZT. But, then i dont think this would be really useful as, i want to reduce the user inputs for my PROC. As, this is not working out, i will get the input file's DCB parameters as input from user and put the same for output.
The logic i have coded is not making any changes to blksize, lrecl's etc. Its a big code so, cant paste it here.
But, i think the abend is not because of the logic in the EZT coding but, may be while reading from the input file or writing to output file, EZT changes these parameters.
For now, i will manually control this thing........if i do find any solution, will update here...
Thanks Everybody for your help |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
Quote: |
i will get the input file's DCB parameters as input from user |
What does this mean? . File is on Mainframes, so DCBs are with you... |
|
Back to top |
|
|
CaptBill
New User
Joined: 28 May 2009 Posts: 20 Location: Oklahoma City, OK USA
|
|
|
|
I believe the best solution to your problem is to try what you had in your question. If that does not work, then post the results and ask a question. |
|
Back to top |
|
|
|