SWA is above as is UCB, but it's the same for both the SMS and non-SMS volumes, there are no active SMS exits at the site. I'll create an lpar with the UCBs below and see if that makes a difference. I can set the Com-Plete region to be SWA below as well and see if that makes a difference as well, but I don't think either one is an issue.
I'm not sure what a GTF trace will do for me in this case. It's not my code and SAG isn't going to do anything to assist in this case. Brian On Sun, 18 Feb 2018 15:32:06 -0700, Lizette Koehler <[email protected]> wrote: >Okay, just going to throw things out in left field. May not even apply > >Do you have SWA above or SWA Below? > >Do you have UCB above or UCB Below > >Are the TCBs being resolved correctly? > >Do you have any SMS exits or z/OS exits that affect UCBs or Volumes/ > >These are things over the years that have bit me and created issues where I >looked in one direction and it was actually somewhere else > >Perhaps it is not the Volume but something else at play? > >Have you run a GTF trace on the SMS volumes? > >Lizette > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Brian Westerman >> Sent: Saturday, February 17, 2018 7:22 PM >> To: [email protected] >> Subject: Re: SMS dataset oddity with COM-Plete >> >> No, the volumes are identical (same raid, same channels, etc.) except that >> the one (that results in an s0C1) is in an SMS pool and the other is not. >> The data got to the pool because we sent it there via a dfdss batch job to >> move all of the development datasets to a "new" 48 volume development pool >> instead of just a few development 3390-3's. >> >> The only difference between them via 3.4 seems to be that one has a storage >> class and management class (no dataclass) and the other doesn't (because it's >> not on an SMS volume. >> >> The vendor (SAG) is no help at all, as they feel that since Com-Plete 6.8.1 >> works fine with it on either volume that we should just migrate to the new >> version now. Unfortunately, that's not a viable option because they have to >> upgrade Natural and Adabas first and that project has just started (that's >> why the Com-Plete cutover is January of 2019). >> >> Strangely enough, we have another customer, at the same level of Com-Plete, >> exactly same PTF level and compile dates on the programs, and they have no >> problem editing dataset from the SMS volumes. >> >> I have compared the sites com-plete (s) and they are not just virtually >> identical, they are exactly identical. >> >> One site though (the site that works) is z/OS 1.8 (in the process of moving >> to z/OS 2.3), but the other (the one where it fails) is at z/OS 2.2. >> >> I have no real doubts that the issue is something within SMS under z/OS 2.2 >> (or something that changed between 1.8 and 2.2), but the problem is to locate >> and neutralize it before the site that is currently converting to 2.3 ends up >> with the same issue. They have no plans to upgrade their Software AG >> environment (it's slowly disappearing). >> >> Brian >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, send email to >> [email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
