Re: SMS dataset oddity with COM-Plete

[Brian Westerman]

I had conditional space release, but I just changed it to "N" and activated it, 
and it didn't help anything.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Brian Westerman]

It's a Software AG program, so IBM will just laugh at me.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Brian Westerman]

Yes,

It appears to be trying to get the SYSDSN, it has the volser and the dsn in the 
buffer, but the entire area is in 31bit storage.  I don't know why in this 
case.  

I don't know why the data would be 31-bit for the same dataset on a SMS volume 
that is is (apparently) 24bit when it's not on an SMS volume.

Brian

Brian.

 On Mon, 19 Feb 2018 13:45:15 +, Pew, Curtis G 
 wrote:

>On Feb 19, 2018, at 1:01 AM, Brian Westerman  
>wrote:
>> 
>> Changing SWA and keeping the UCB below the line had not effect, the problem 
>> still exists.
>
>Have you examined *UDUMP to try to firure out what it’s trying to do when the 
>ABEND occurs?
>
>-
 
>Pew, Curtis G
>curtis@austin.utexas.edu
>ITS Systems/Core/Administrative Services
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Brian Westerman]

Not active on either site.

Brian

On Mon, 19 Feb 2018 07:40:25 +, Savor, Thomas (Alpharetta) 
<thomas.sa...@fiserv.com> wrote:

>Hardware Compression ??
>
>Thanks,
>
>Tom Savor
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Brian Westerman
>Sent: Monday, February 19, 2018 2:02 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: SMS dataset oddity with COM-Plete
>
>Changing SWA and keeping the UCB below the line had not effect, the problem 
>still exists.
>
>Brian
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
>lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Ron hawkins]

Binyamin,

Does the Management class have space release YI?

Decades ago I had a problem with SAS (V6 I think) doing an Open/Close/Open
on its datasets that would trigger space release, and then the EXCP would
point to a location beyond the EOF. This did not result in an SOC1, but
rather a x37 and pinned data in the storage.

Altering the space release in the Management class fixed the problem. Just
an "out there" suggestion for you to look at.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Monday, February 19, 2018 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] SMS dataset oddity with COM-Plete

As it is a S0C1, I would look to a branch to low core and if so, look at the
calling module for some link error.

On Sat, 17 Feb 2018 20:21:59 -0600 Brian Westerman
<brian_wester...@syzygyinc.com> wrote:

:>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).

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Binyamin Dissen]

As it is a S0C1, I would look to a branch to low core and if so, look at the
calling module for some link error.

On Sat, 17 Feb 2018 20:21:59 -0600 Brian Westerman
 wrote:

:>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).

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

Re: SMS dataset oddity with COM-Plete

[Tim Deller]

I would get a dump, logrec, syslog and open an issue with IBM.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Pew, Curtis G]

On Feb 19, 2018, at 1:01 AM, Brian Westerman  
wrote:
> 
> Changing SWA and keeping the UCB below the line had not effect, the problem 
> still exists.

Have you examined *UDUMP to try to figure out what it’s trying to do when the 
ABEND occurs?

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Savor, Thomas (Alpharetta)]

Hardware Compression ??

Thanks,

Tom Savor

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Monday, February 19, 2018 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS dataset oddity with COM-Plete

Changing SWA and keeping the UCB below the line had not effect, the problem 
still exists.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Brian Westerman]

Changing SWA and keeping the UCB below the line had not effect, the problem 
still exists.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Brian Westerman]

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 <stars...@mindspring.com> 
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:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Brian Westerman
>> Sent: Saturday, February 17, 2018 7:22 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> 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
>> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Lizette Koehler]

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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Westerman
> Sent: Saturday, February 17, 2018 7:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Seymour J Metz]

No, NOTE and POINT work just fine on conventional SMS managed datasets. Were 
you thinking of BLOCKTOKENSIZE=LARGE for large format datasets?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Peter Hunkeler <p...@gmx.ch>
Sent: Saturday, February 17, 2018 3:40 AM
To: IBM-MAIN@listserv.ua.edu
Subject: AW: SMS dataset oddity with COM-Plete


Not knowing Com-Plete, I can only guess: Edit/Browse might use NOTE and POINT, 
do they?
These services work with the TTR of the records on the disk. For this to work 
with SMS managed data sets, they need to be EXTENDED format data sets.

In a previous job I was working with some home written software which had just 
this dependency. I can't remember thought, if defining the data sets as 
EXTENDED format, was all there had to be done.

You might give it try, or read about NOTE & POINT in the DFSMS manuals.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Allan Staller]

Install the latest and greatest, and then just hope the problem is fixed?

I think *NOT*



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Saturday, February 17, 2018 8:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Mike Schwab]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idas200/rovars.htm

Check what  you handle in your ACS Storage Group routine for
the affected DSNs (Filter list, mask).

Normal creation (DISP=NEW) is ALLOC.  Your batch move job could be
RECALL, RECOVER, or RENAME.

On Sat, Feb 17, 2018 at 8:21 PM, Brian Westerman
 wrote:
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Brian Westerman]

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

Re: SMS dataset oddity with COM-Plete

[Scott Barry]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: SMS dataset oddity with COM-Plete

[Peter Hunkeler]

Not knowing Com-Plete, I can only guess: Edit/Browse might use NOTE and POINT, 
do they?
These services work with the TTR of the records on the disk. For this to work 
with SMS managed data sets, they need to be EXTENDED format data sets.

In a previous job I was working with some home written software which had just 
this dependency. I can't remember thought, if defining the data sets as 
EXTENDED format, was all there had to be done.

You might give it try, or read about NOTE & POINT in the DFSMS manuals.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMS dataset oddity with COM-Plete

[Mike Schwab]

I'm thinking you need to update the ACS routines for when a dataset is
reallocated or recalled from ML1/2.  Didn't code it myself so very
hazy on the details.

On Fri, Feb 16, 2018 at 8:47 PM, Brian Westerman
 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

SMS dataset oddity with COM-Plete

[Brian Westerman]

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