I have a file with record length of 156. In between the record there are comp-3 (packed) fields at positions 25,51,59,72,77,80,85,88-----as below. and remaing fields are alphanumeric.
Now, how should i handle the output file length in dsn??? should i calculate manually and add the length in dsn??? or else the starting position of remaining fields will be handle by dfssort automatically.
more over the below is not working could you please help me in this regard...
As well as that, and subsequent, can you show the output messages you get from your run? Unless you are now using DFSORT, you'll not get further in this forum.
ITS PROMPTING syntax error...
Code:
JOBNAME: P715448S , STEPNAME: SORT01
BLOCKSET TECHNIQUE IN CONTROL
BLOCKSET COPY TECHNIQUE SELECTED
VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AND MORE
- CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 22:49 ON FRI JUL 27, 2
SORT FIELDS=COPY 00001
INREC BUILD=((02,5,PD,EDIT=(STTTTTTTTTT),SIGNS=(+,-)),
$
SYNTAX ERROR
(25,5,PD,EDIT=(STTTTTTTTTT),SIGNS=(+,-)),
$
SYNTAX ERROR
(51,8,PD,EDIT=(STTTTTTTTTTTTTTTT),SIGNS=(+,-)),
$
SYNTAX ERROR
(59,4,PD,EDIT=(STTTTTTT),SIGNS=(+,-)),
$
1 SYNTAX ERROR
0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E7-K70685
3 END OF DFSORT
at the end....its prompting as
1 SYNTAX ERROR
0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E7-K70685
3 END OF DFSORT
what could be the reason...and another thing is suppose for s9(13)v99 should i need to take 17 or 18 ((51,8,PD,EDIT=(STTTTTTTTTTTTTTTT),SIGNS=(+,-)) because for to get unpacked should i
count decimal also???
i don't know how to post as code...thats the reason i'm posting like that. after that some moderators are changing as it has to be. i totally agree on what u said...
Is that by selecting code option should we can post as it was to be so????
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
Ram,
I suggest you remove your DCB parms from the SORTOUT DD statement.
DFSORT will calculate the appropriate LRECL,
and if you have provided a DCB-LRECL parm that is 'inaccurate',
DFSORT will give you a message.
In the event that you have some production 'rules'
that state the complete DCB parm be included,
suggest that after you have tested your control cards,
you code your LRECL parm according to DFSORT's calculation.
That way it will be correct,
and you can pass the muster of production turnover requirements.
but since as I said before today I am in a really good mood
but hell will freeze before considering any friendship between us
the misuse of double parenthesization was evident at first reading
but to convince the TS I just run a simple test
( values and offsets different but enough for a POC )
********************************* TOP OF DATA **********************************
+0000000001+0000000002+0000000003
-0000000001-0000000002-0000000003
******************************** BOTTOM OF DATA ********************************
naturally the TS will complain about something
no reason to waste time commenting on the TS behavior and attitude
but really... if the TS is not willing/capable of analyzing himself such stupid errors
or search for hints ( I did before commenting )
a career change is warmly recommended
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
ram_vizag,
Please don't take that condescending tone with the people who are trying to Guide/help you. Not everyone has the time or patience to provide complete solutions.
but since as I said before today I am in a really good mood
but hell will freeze before considering any friendship between us
the misuse of double parenthesization was evident at first reading
but to convince the TS I just run a simple test
( values and offsets different but enough for a POC )
********************************* TOP OF DATA **********************************
+0000000001+0000000002+0000000003
-0000000001-0000000002-0000000003
******************************** BOTTOM OF DATA ********************************
naturally the TS will complain about something
no reason to waste time commenting on the TS behavior and attitude
but really... if the TS is not willing/capable of analyzing himself such stupid errors
or search for hints ( I did before commenting )
a career change is warmly recommended
hi enrico,
thanks a lot...but even then my requirement is not only that...here in need to handle as following:
1.i have some 10 fieelds strating from 10, 25, 36, respectively...the rest being normal redable fields (unpacked oNLY)
suppose i want to convert pac to unpac from field length 6 to 2 and also i want the former field in my output file
examlpe:
---------(cols)
12345..7899..89989..
then i want the first 5 length of data in my output file and the 6,7 legth flds to be converted to unpac and again 8,9,10,11 length flds (as above) to be in output file and again 12,13 pac flds to be unpacked and shud b added in the output file: i have written the code in below but its giving some
Code:
INCONSISTENT REFORMATTING ERROR. THE CODE AND RESULT ARE BELOW:
H RECORD TYPE IS F - DATA STARTS IN POSITION 1
1 JOBNAME: P715448S , STEPNAME: SORT01
0 BLOCKSET TECHNIQUE IN CONTROL
0 BLOCKSET COPY TECHNIQUE SELECTED
0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AN
1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 20:36 ON MON JU
SORT FIELDS=COPY
OUTREC FIELDS=(1:1,5,6,2,PD,EDIT=(STTTT),SIGNS=(+,-),
8:11,14,25,5,PD,EDIT=(STTTTTTTTTT),SIGNS=(+,-))
H RECORD TYPE IS F - DATA STARTS IN POSITION 1
2 INCONSISTENT REFORMATTING FOR *OUTREC : REASON CODE 04, IFTHEN 0
0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E7-K70685
3 END OF DFSORT
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Your 1,5 gives you five bytes. Your EDIT gives you five bytes. You then use column 8, which would be overwriting some of your edited field. You can't do that with FIELDS/BUILD.
If you look at the error message you got (why you or "something" chops the most useful bit off, I don't know) you should have been able to get to that.
Your 1,5 gives you five bytes. Your EDIT gives you five bytes. You then use column 8, which would be overwriting some of your edited field. You can't do that with FIELDS/BUILD.
If you look at the error message you got (why you or "something" chops the most useful bit off, I don't know) you should have been able to get to that.
Or just by counting.
hi,
even if i give from 9th position the same is coming...i think it need to be handled differently...because no syntax error
H RECORD TYPE IS F - DATA STARTS IN POSITION 1
1 JOBNAME: P715448S , STEPNAME: SORT01
0 BLOCKSET TECHNIQUE IN CONTROL
0 BLOCKSET COPY TECHNIQUE SELECTED
0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AN
1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 20:59 ON MON JU
SORT FIELDS=COPY
OUTREC FIELDS=(1:1,5,6,2,PD,EDIT=(STTTT),SIGNS=(+,-),
9:11,14,25,5,PD,EDIT=(STTTTTTTTTT),SIGNS=(+,-))
H RECORD TYPE IS F - DATA STARTS IN POSITION 1
2 INCONSISTENT REFORMATTING FOR *OUTREC : REASON CODE 04, IFTHEN 0
0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E7-K70685
3 END OF DFSORT
Your 1,5 gives you five bytes. Your EDIT gives you five bytes. You then use column 8, which would be overwriting some of your edited field. You can't do that with FIELDS/BUILD.
If you look at the error message you got (why you or "something" chops the most useful bit off, I don't know) you should have been able to get to that.
Or just by counting.
hi,
even if i give from 9th position the same is coming...i think it need to be handled differently...because no syntax error
H RECORD TYPE IS F - DATA STARTS IN POSITION 1
1 JOBNAME: P715448S , STEPNAME: SORT01
0 BLOCKSET TECHNIQUE IN CONTROL
0 BLOCKSET COPY TECHNIQUE SELECTED
0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AN
1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 20:59 ON MON JU
SORT FIELDS=COPY
OUTREC FIELDS=(1:1,5,6,2,PD,EDIT=(STTTT),SIGNS=(+,-),
9:11,14,25,5,PD,EDIT=(STTTTTTTTTT),SIGNS=(+,-))
H RECORD TYPE IS F - DATA STARTS IN POSITION 1
2 INCONSISTENT REFORMATTING FOR *OUTREC : REASON CODE 04, IFTHEN 0
0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E7-K70685
3 END OF DFSORT
and in the file 10 bytes was being redfined 3 times and in that redefines part every time 5 bytes at different positions was being used as comp-3...and this is also not working if i test it individually...could you please suggest...
now again i need to copy the data from 8 to 24 to output file which is unpacked already and need to convert data starting 25th position to some 5 bytes data from pack to unpack and again need to write to output file...this should be followed upto 156 length of recod data...
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
enrico, missed that whilst I was typing.
Ram,
The only thing I can think is that you are confused about what all those those positions mean on FIELDS.
Since FIELDS and BUILD are the same (wait for a step-on from Kolusu or sqlcode1 if I'm wrong) I prefer BUILD.
All the source fields you specify are from the "current" record at that stage.
Code:
BUILD=(30X,1,10)
This will give you 30 blanks, then position 1 for a length of 10 from the current input.
After the build, if you want to refer to what was at 1,10, you have to specify 31,10.
When specifying a column you are specifying a position in the new record. With BUILD/FIELDS you cannot "overlap" fields, you cannot destroy anything that you have placed in the new record with BUILD/FIELDS.
After such an amount of time on this, it turns out to be something very basic you have a problem with.
I will shortly follow enrico's advice.
EDIT. Except I left the door open for Kolusu/others to comment, so I can't... later today then.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
ram_vizag wrote:
Hi enrico/bill,
how can this be hadled to get done automatically???
Stop specifying the output positions and let sort calculate it automatically. Alternatively you can count the digits in the edit mask and specify the position.