On Thu, 22 Mar 2007 16:29:12 -0700, Frank Yaeger <[EMAIL PROTECTED]> wrote: >It's not clear to me what you're seeing here, but ... > >The main difference between DFSORT R14 and z/OS DFSORT V1R5 is that V1R5 >can use Memory Object Sorting, a completely new path. Perhaps what you're >seeing is caused by the difference in using that new path? Have you tried >turning off Memory Object Sorting to check that: > >//DFSPARM DD * > OPTION MOSIZE=0 >/* > >Have you opened PMR? If so, what's the number?
I have not opened a PMR since I cannot argue that DFSORT is working incorrectly given your reply to a previous post about a week ago and the documentation for the equals parm. I try not to abuse the PMR process and only open them when I think the fault is with the code or I don't think I have another choice. Right now I don't think SORT is working incorrectly, just incompatibly with our application as the vendor delivered it and we implemented it. What we are seeing is that z/OS 1.7 sort is working differently than 1.4 with respect to records with duplicate sort fields (I must admit based on too little testing but I can only do what I can do in the hours that I have) . As I noted before with one small JCL SORT test (31360 records, 28224000 bytes) run multiple times, the only way I get the same results out of the two systems is if I specify OPTION EQUALS in a DFSPARM DD on the 1.4 system or if I use a JOBLIB on the 1.7 system to point to the 1.4 libraries. I have tried this several times and received consistent results (with the over-rides the output matches, without them it doesn't). I even tried specifying EQUALS and NOEQUALS on the 1.7 systems as well as the default and all output files from the 1.7 system match each other consistently (EQUALS/NOEQUALS has no affect on 1.7 in this scenario I expect because it is such a small sort). I am asking if over-riding sort on the 1.7 system via JOBLIB to the 1.4 system libraries should work. I realize that I have tried this already but trying something on one small job is a lot different than setting up an entire batch cycle over the weekend that will run for several hours. I would like to know if this should work for my test before I put in my time and that of other departments necessary to get this set up. My other option would be to IPL back to 1.4 for the test but that has it's own issues and would reverse everything not just SORT and I really wanted to isolate one thing at a time as best I could. For some background on how this started. We used to be able to load our UAT DB2 tables from PROD image copies using DSN1COPY and copy over selected files from PROD that PROD was going to read into the nightly cycle and then run the UAT cycle the next day and compare the results. The compare would match on everything except a couple files that had date/timestamp information in the records and if that section of the record was excluded, then even those would match. This worked back to at least OS/390 2.10 and possibly 2.8. I set things up to run this process just before migrating z/OS 1.7 into production (thinking it was only a formality and all would be good with the world) and this time there were many mismatches that appeared to be SORT sequence issues (mostly matching delete/insert pairs) . Although these SORT sequence issues may be explainable and of no consequence to the business (we are still researching that) we have also had a couple records process incorrectly (out of hundreds of thousands). So far we have not been able to explain this. It may be that a sporadic problem has hit us in two out of two of these big tests that for some reason did not hit production using the exact same data/programs (which seems unlikely) or it may be that the difference in the SORT is causing issues and we really need to increase our SORT fields to get the records into a predictable order or it may be something else all together. I am grasping as straws and trying to eliminate just SORT by pointing to the old SORT via JOBLIB for a test this weekend. The hope is that we can isolate the cause down to the SORT differences which will tell us where to focus. If the run this weekend using the 1.4 libraries on the 1.7 system matches the prior nights production, we will restore everything back to the beginning and try again with the 1.7 libraries (DFSORT 1.5 I believe) and see if the issues come back. If it doesn't match, then we will probably need to examine the setup again. I fully realize we may have multiple problems so I am trying to find the easiest way to eliminate one thing at a time and the known difference at the moment is SORT (yes everything in the ServerPac is potentially different but I gota start somewhere). Even if this isn't causing both issues, by eliminating this, it may make finding the other easier. Sorry for the long reply and I hope you can answer my questions regarding pointing to the old sort for this test. Thank you in advance once again, Greg ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
