DFSORT from z/OS 1.4 on LPAR running z/OS 1.7
Can I run the version of DFSORT that is installed on my z/OS 1.4 system on my z/OS 1.7 system via JOBLIB in the batch jobs? If so, which libraries would I need to add to the JOBLIB (both JCL sort and program invoked sort are used in the application if that matters) and are there any APF requirements? For those curious why: We have been seeing inaccurate results in the testing of the batch cycle for one of our applications when testing on z/OS 1.7. We know that sort is producing different results on 1.7 than our z/OS 1.4 system (related to records with duplicate sort keys). Both are using the default of EQUALS=VLBLKSET so we understand why but we don't know how that could be causing the issues we are seeing. On one test of JCL sort (relatively small sort) 1.7 results only match 1.4 if we over-ride with EQUALS on the 1.4 system. Anyway, we would like to change only SORT instead of all ServerPac installed software and test the batch part of the application to see if this is the entire cause of our issues or if perhaps we also have a test environment setup problem (or something else). Thank you in advance for your assistance, 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
Re: DFSORT from z/OS 1.4 on LPAR running z/OS 1.7
Greg Saccomanno wrote on 03/22/2007 03:40:51 PM: > Can I run the version of DFSORT that is installed on my z/OS 1.4 system on > my z/OS 1.7 system via JOBLIB in the batch jobs? > > If so, which libraries would I need to add to the JOBLIB (both JCL sort and > program invoked sort are used in the application if that matters) > and are there > any APF requirements? > > For those curious why: > We have been seeing inaccurate results in the testing of the batch cycle for > one of our applications when testing on z/OS 1.7. We know that sort is > producing different results on 1.7 than our z/OS 1.4 system (related to > records with duplicate sort keys). Both are using the default of > EQUALS=VLBLKSET so we understand why but we don't know how that could > be causing the issues we are seeing. On one test of JCL sort > (relatively small > sort) 1.7 results only match 1.4 if we over-ride with EQUALS on the 1.4 > system. Anyway, we would like to change only SORT instead of all ServerPac > installed software and test the batch part of the application to see > if this is > the entire cause of our issues or if perhaps we also have a test environment > setup problem (or something else). 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? Frank Yaeger - DFSORT Team (IBM) - [EMAIL PROTECTED] Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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
Re: DFSORT from z/OS 1.4 on LPAR running z/OS 1.7
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 t
Re: DFSORT from z/OS 1.4 on LPAR running z/OS 1.7
Greg, I've forwarded your question about using DFSORT R14 on z/OS 1.7 to Vicky Vezinaw, our installation person, and asked her to reply to you offline. (I'm on vacation today.) Frank Yaeger - DFSORT Team (IBM) - [EMAIL PROTECTED] Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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
Re: DFSORT from z/OS 1.4 on LPAR running z/OS 1.7
On Fri, 23 Mar 2007 08:09:46 -0700 Frank Yaeger <[EMAIL PROTECTED]> wrote: :>Greg, :> :>I've forwarded your question about using DFSORT R14 on z/OS 1.7 to Vicky :>Vezinaw, our installation person, and asked her to reply to you offline. :>(I'm on vacation today.) :>Frank Yaeger - DFSORT Team (IBM) - [EMAIL PROTECTED] Then why the h*ll are you reading these emails? I don't think Friday should count as a vacation day for you. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
