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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
