Vendor's technical support would be an idea to consider. Otherwise what else is unique about the "target" DASD volume, possibly EAV/EAS type (though consider you mentioned 3390-3) - inquire with Stg Mgmt for additional insight on DASD environment consideration.
Sometimes a simple TSO ISPF DSLIST 3.4 "V" command against the two volumes (and datasets) may reveal uniqueness for follow-up with vendor. Scott Barry SBBWorks, Inc. On Fri, 16 Feb 2018 20:47:48 -0600, Brian Westerman <[email protected]> wrote: >Hi, > >One of our customers is running an old(er) version of Software AG's Com-Plete >(version 6.4.1) along with testing version 6.8.1, and we have found that when >a dataset (any sequential or PDS) is moved from a regular 3390-3 to a 3390-3 >that is part of a storage group (same raid box, and close to the same address >(in this case the non-SMS volume is on x'0309', and the SMS pool starts at >x'0310'), they get an S0C1 when they try to edit or browse that dataset from >within Com-Plete, but when we move it back to any non-SMS 3390-3 (or even a >3390-9 or 3390-27) it can be accessed with no problems at all. The problem >doesn't happen with com-plete 6.8.1, and Software AG is telling us >simultaneously that a) there should be no difference in the edit component >between the two releases, and b) they no longer support 6.4.1 so they can't >look into it, and even if they did, they would not be able provide a "fix" any >more for that level. > >The client is okay with not moving the datasets to SMS until after the new >version of Com-Plete is in production (currently not planned until January >2019), but it bothers me that this is happening and I have no explanation for >it. It's also throwing a wrench into my SMS conversion for them. I have a >"feeling" that it has something to do with the control blocks that are built >in a different place for SMS datasets and non-SMS datasets, but since SMS has >been around since Com-Plete 6.1.1 (8 years before 6.4.1), there appears to be >no logical reason why it should fail just because the dataset is on an SMS >volume. > >Does anyone have any ideas on how to address this? > >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
