|
View previous topic :: View next topic
|
| Author |
Message |
Skolusu
Senior Member
Joined: 07 Dec 2007
Posts: 2205
Location: San Jose
|
|
|
|
Ronald Burr,
Correction. I did NOT assume that key is complete 381 bytes or neither it is my Invention. OP himself stated that complete 381 bytes needed to considered.
ibmmainframes.com/viewtopic.php?p=246581#246581
| CICS fan wrote: |
The number of AA records can be anything from equal to greater than zero.
And, yes, complete 381 bytes need to be considered. |
Thank You |
|
| Back to top |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Mr. Burr,
you missed a key ingredient - 381 that is what is compared.
yes, your code will possibly work (once you change from 255 to 381).
but what is there are 86 AA segments?
at some point, given the 'rather' flexible requirements by the TS,
providing the validation necessary will probably require- appending sequence numbers in a sort
- using COBOL internal tables to perform the validation and duplicate removal
- a final sort dropping the sequence numbers
But that is just my opinion, and like other things, everyone has one.
give it a #&@ rest. |
|
| Back to top |
|
|
CICS fan
New User
Joined: 03 Apr 2008
Posts: 82
Location: United States
|
|
|
|
| Thanks Ronald, I was designing something on your line and came back here and tok valuable inputs from your post. I guess I cannot thank you enough. |
|
| Back to top |
|
|
smijoss
Active User
Joined: 30 Aug 2007
Posts: 114
Location: pune
|
|
|
|
CICS fan,
dont take things to the heart,
we are just to find solutions to our requirements. You must agree by now that your requirement was unrealistic. |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| dbzTHEdinosauer wrote: |
| besides, you missed a key ingredient - 381 that is what is compared. |
Actually, it is YOU who missed the key ingredient - the entire BLOCK ( from one 'ZZ' record to the next 'ZZ' record or EOF ), not just 381 bytes, is what should be compared - and that is exactly what my program does.
| dbzTHEdinosauer wrote: |
| yes, your code will possibly work (once you change from 255 to 381). |
Possibly work? Once I change the VSAM KEY from 255 to 381 ( which, as Kolusu pointed out, is not possible )? Fact: My program DOES work - just the way it is. The VSAM key is just an easy way to filter out the records that do not match early on: if the blocks don't match on the first 247 bytes, then there is no point in further comparison - they don't match, period; if they DO match on the first 247 bytes but the segment counts do not match, likewise, there is no point in further comparison; but, if both the first 247 bytes AND the segment counts match, then further comparison (up to the full block length, if needed), is required to make a final determination.
| dbzTHEdinosauer wrote: |
| but what is there are 86 AA segments? |
If there are more than 84 'AA' segments, then the program will display an error message (with record counts), and terminate with an RC=16.
What do YOUR programs do if a subscript or index exceeds the the number of defined OCCURS for an element in a table or array?
By the way, since when does anyone other than an OP and his/her company decide whether a requirement is "nonsensical" or "unrealistic"? In the real world *stuff* happens all the time - and that can result in a file that has a lot of extraneous data in it that shouldn't be there. But if a "good" file cannot be created, and the corrupted file is the only file available to try to salvage the "good" data and get rid of the "bad", then a requirement to do that by whatever means are available is not only realistic but also makes sense.
Just because a DFSORT solution wasn't in the cards doesn't mean that the basic requirement is flawed. It would have been more appropriate in this case to simply state that no DFSORT solution was practical given the requirements as stated - and suggest that the thread be renamed and moved to the a different category.
As an aside, it should be quite easy to develop a DFSORT solution to find the maximum number of 'ZZ' blocks and the maximum number of 'AA' seqments contained within any 'ZZ' block.
As far as my program is concerned, if the maximum number of 'AA' blocks is more than 84, then, obviously, the code, as written, would not be able to handle the task - though it COULD be modified to handle larger blocks without too much trouble (e.g. spanned VSAM records ).
Likewise, if the number of 'ZZ' blocks would exceed the available capacity for the VSAM KSDS, then a method would have to be developed to process the input file in a different manner - e.g. break the original input file into two files (A and B) between an 'AA' and 'ZZ' record; process file A creating file C; process file B creating file D; then process the concatenation of files C and D creating the final output file. In any case, no "sorting" would be done to create the final file - all records would remain in their original order. |
|
| Back to top |
|
|
Skolusu
Senior Member
Joined: 07 Dec 2007
Posts: 2205
Location: San Jose
|
|
|
|
| Quote: |
| Possibly work? Once I change the VSAM KEY from 255 to 381 ( which, as Kolusu pointed out, is not possible )? Fact: My program DOES work - just the way it is. |
Ronald,
Please define a VSAM KSDS with keys(256 0) and let us all know if it does WORK. AFAIK I know the key can be a max of 255 bytes.
Here is a manual link for Define CLUSTER parameters. This is valid for z/OS V1R11.0
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2I280/14.1 |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Guys - this thread has gone "way over the top". I removed all of the "j'accuse" stuff and will continue to do so if people continue to post more. Let's keep it civil and helpful, please. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Frank,i love it when you talk dirty! |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
Well, I originally used the phrase "he said/she said" but realized there probably weren't any women participating in this thread. So I changed to "j'accuse" which seems to fit better anyway.
I don't understand why people are getting so argumentative and "personal" in these threads lately. I hate having to clean it all up. I wish it would stop! |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| Skolusu wrote: |
| Quote: |
| Possibly work? Once I change the VSAM KEY from 255 to 381 ( which, as Kolusu pointed out, is not possible )? Fact: My program DOES work - just the way it is. |
Ronald,
Please define a VSAM KSDS with keys(256 0) and let us all know if it does WORK. AFAIK I know the key can be a max of 255 bytes.
Here is a manual link for Define CLUSTER parameters. This is valid for z/OS V1R11.0
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2I280/14.1 |
Kolusu,
Why would I want to attempt to define a VSAM KSDS Key as 256 bytes when we all (should) know that the maximum keylength allowable is 255 bytes?
The obvious answer is: I wouldn't, and I didn't. In the code I posted, the VSAM File Record contained this definition of the KEY.
| Code: |
10 VSAM-SEG1-KEY.
15 VSAM-SEG1-ID PIC X(251).
15 VSAM-SEG1-SEQ PIC S9(9) COMP-5. |
When I studied COBOL a COMP-5 field with a picture of S9(9) took up 4 bytes. Add that to the SEG1-ID of 251 bytes and you get (surprise) just 255 bytes - a perfectly acceptable VSAM KSDS keylength.
Here is a manual link for the definition of COMPUTATIONAL Items:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR50/5.3.17.1?SHELF=&DT=20090821081020&CASE= |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Three cheers for Ronald Burr he had the last word! |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
No, you did.  (Now I did.) |
|
| Back to top |
|
|
|
|
