IBM z/OS Management Facility (z/OSMF)

Another query from this first timer... 

My z/OS 3.1 install expects to use SC 'SCCPTS9'. So, I set this up with some volumes and ran the jobs. OK. But I thought I'd try it again using some non-SMS volumes and try to get the target volumes allocated roughly how I'd want them to look eventually. So, I went back into the configuration screens and specified my non-SMS volumes, un ticking 'SMS managed' and re-generating the jobs, which I then ran. No mention of SCCPTS9 in any of the jobs, but... everything is allocated on those original SMS-managed volumes again, with nothing on my lovely (empty) non-SMS volumes...

Thanks

Grant

Grant, does the re-generated Unzip job (IZUDnnUZ) identify your lovely non-SMS volumes as the location for the new data sets?  For example, do the <ARCHDEF> statements in the GIMUNZIP job step contain the volume="volser" operand?  Did the DELCATDS job step run and did it delete existing data sets?  If so, then I am unsure why the data sets were not allocated on the specified volume.  Perhaps the ACS routines in your driving system's SMS configuration are getting in the way and overriding the volume specification?

As a by the way and for your information, z/OSMF does not necessarily "expect to use" storage class SCCPTS9.  That is a storage class defined on the z/OS system used by the IBM manufacturing process and is the storage class used by the originating, or source, data sets for your portable software instance.  The deployment configuration may be initialized using the locations from the source data sets, but as you have since discovered you can certainly change those to specify a storage class that is already defined to your SMS subsystem, or you can tell z/OSMF to locate the new data sets on a volume that you identify instead.  That is, you don't have to use the source storage class SCCPTS9.

Another query from this first timer... 

My z/OS 3.1 install expects to use SC 'SCCPTS9'. So, I set this up with some volumes and ran the jobs. OK. But I thought I'd try it again using some non-SMS volumes and try to get the target volumes allocated roughly how I'd want them to look eventually. So, I went back into the configuration screens and specified my non-SMS volumes, un ticking 'SMS managed' and re-generating the jobs, which I then ran. No mention of SCCPTS9 in any of the jobs, but... everything is allocated on those original SMS-managed volumes again, with nothing on my lovely (empty) non-SMS volumes...

Thanks

Grant

Hi Kurt, thanks for the quick reply, I thought I had responded but I can't see where so hopefully this isn't a duplicate. 

So... the DELCAT step (in IZUD04UZ) did indeed run. The unzip output was as follows:

However, the job output shows:

So, I guess you must be right, an errant ACS routine for me to check.

Per your point on SCCPTS9, yes I can see how the system was built using the SC used on the IBM system and could have been overridden just as I'd specified those non SMS volumes I created. As I'm using the COD system to drive this there wasn't anything set up so I set up SCCPTS9 to align with the jobs (maybe a mistake?).

Full disclosure - I haven't done this for about 20 years so a steep learning curve on this method of deployment (!), and your assistance is greatly appreciated.

Grant, does the re-generated Unzip job (IZUDnnUZ) identify your lovely non-SMS volumes as the location for the new data sets?  For example, do the <ARCHDEF> statements in the GIMUNZIP job step contain the volume="volser" operand?  Did the DELCATDS job step run and did it delete existing data sets?  If so, then I am unsure why the data sets were not allocated on the specified volume.  Perhaps the ACS routines in your driving system's SMS configuration are getting in the way and overriding the volume specification?

As a by the way and for your information, z/OSMF does not necessarily "expect to use" storage class SCCPTS9.  That is a storage class defined on the z/OS system used by the IBM manufacturing process and is the storage class used by the originating, or source, data sets for your portable software instance.  The deployment configuration may be initialized using the locations from the source data sets, but as you have since discovered you can certainly change those to specify a storage class that is already defined to your SMS subsystem, or you can tell z/OSMF to locate the new data sets on a volume that you identify instead.  That is, you don't have to use the source storage class SCCPTS9.

Another query from this first timer... 

My z/OS 3.1 install expects to use SC 'SCCPTS9'. So, I set this up with some volumes and ran the jobs. OK. But I thought I'd try it again using some non-SMS volumes and try to get the target volumes allocated roughly how I'd want them to look eventually. So, I went back into the configuration screens and specified my non-SMS volumes, un ticking 'SMS managed' and re-generating the jobs, which I then ran. No mention of SCCPTS9 in any of the jobs, but... everything is allocated on those original SMS-managed volumes again, with nothing on my lovely (empty) non-SMS volumes...

Thanks

Grant

Grant, you replied to me privately, hence you don't see that response here in the public forum.  In any case, good luck adjusting your SMS configuration.  In case you haven't seen them yet, here's a link to a set of tutorial videos on how to install (Deploy) software using z/OSMF.
https://mediacenter.ibm.com/playlist/dedicated/101043781/1_mzzf31vy/1_f1qhec1j

Feel free to reach out if you have further problems or questions.

Hi Kurt, thanks for the quick reply, I thought I had responded but I can't see where so hopefully this isn't a duplicate. 

So... the DELCAT step (in IZUD04UZ) did indeed run. The unzip output was as follows:

However, the job output shows:

So, I guess you must be right, an errant ACS routine for me to check.

Per your point on SCCPTS9, yes I can see how the system was built using the SC used on the IBM system and could have been overridden just as I'd specified those non SMS volumes I created. As I'm using the COD system to drive this there wasn't anything set up so I set up SCCPTS9 to align with the jobs (maybe a mistake?).

Full disclosure - I haven't done this for about 20 years so a steep learning curve on this method of deployment (!), and your assistance is greatly appreciated.

Grant, does the re-generated Unzip job (IZUDnnUZ) identify your lovely non-SMS volumes as the location for the new data sets?  For example, do the <ARCHDEF> statements in the GIMUNZIP job step contain the volume="volser" operand?  Did the DELCATDS job step run and did it delete existing data sets?  If so, then I am unsure why the data sets were not allocated on the specified volume.  Perhaps the ACS routines in your driving system's SMS configuration are getting in the way and overriding the volume specification?

As a by the way and for your information, z/OSMF does not necessarily "expect to use" storage class SCCPTS9.  That is a storage class defined on the z/OS system used by the IBM manufacturing process and is the storage class used by the originating, or source, data sets for your portable software instance.  The deployment configuration may be initialized using the locations from the source data sets, but as you have since discovered you can certainly change those to specify a storage class that is already defined to your SMS subsystem, or you can tell z/OSMF to locate the new data sets on a volume that you identify instead.  That is, you don't have to use the source storage class SCCPTS9.

Another query from this first timer... 

My z/OS 3.1 install expects to use SC 'SCCPTS9'. So, I set this up with some volumes and ran the jobs. OK. But I thought I'd try it again using some non-SMS volumes and try to get the target volumes allocated roughly how I'd want them to look eventually. So, I went back into the configuration screens and specified my non-SMS volumes, un ticking 'SMS managed' and re-generating the jobs, which I then ran. No mention of SCCPTS9 in any of the jobs, but... everything is allocated on those original SMS-managed volumes again, with nothing on my lovely (empty) non-SMS volumes...

Thanks

Grant

Grant, you replied to me privately, hence you don't see that response here in the public forum.  In any case, good luck adjusting your SMS configuration.  In case you haven't seen them yet, here's a link to a set of tutorial videos on how to install (Deploy) software using z/OSMF.
https://mediacenter.ibm.com/playlist/dedicated/101043781/1_mzzf31vy/1_f1qhec1j

Feel free to reach out if you have further problems or questions.

Hi Kurt, thanks for the quick reply, I thought I had responded but I can't see where so hopefully this isn't a duplicate. 

So... the DELCAT step (in IZUD04UZ) did indeed run. The unzip output was as follows:

However, the job output shows:

So, I guess you must be right, an errant ACS routine for me to check.

Per your point on SCCPTS9, yes I can see how the system was built using the SC used on the IBM system and could have been overridden just as I'd specified those non SMS volumes I created. As I'm using the COD system to drive this there wasn't anything set up so I set up SCCPTS9 to align with the jobs (maybe a mistake?).

Full disclosure - I haven't done this for about 20 years so a steep learning curve on this method of deployment (!), and your assistance is greatly appreciated.

Grant, does the re-generated Unzip job (IZUDnnUZ) identify your lovely non-SMS volumes as the location for the new data sets?  For example, do the <ARCHDEF> statements in the GIMUNZIP job step contain the volume="volser" operand?  Did the DELCATDS job step run and did it delete existing data sets?  If so, then I am unsure why the data sets were not allocated on the specified volume.  Perhaps the ACS routines in your driving system's SMS configuration are getting in the way and overriding the volume specification?

As a by the way and for your information, z/OSMF does not necessarily "expect to use" storage class SCCPTS9.  That is a storage class defined on the z/OS system used by the IBM manufacturing process and is the storage class used by the originating, or source, data sets for your portable software instance.  The deployment configuration may be initialized using the locations from the source data sets, but as you have since discovered you can certainly change those to specify a storage class that is already defined to your SMS subsystem, or you can tell z/OSMF to locate the new data sets on a volume that you identify instead.  That is, you don't have to use the source storage class SCCPTS9.

Another query from this first timer... 

My z/OS 3.1 install expects to use SC 'SCCPTS9'. So, I set this up with some volumes and ran the jobs. OK. But I thought I'd try it again using some non-SMS volumes and try to get the target volumes allocated roughly how I'd want them to look eventually. So, I went back into the configuration screens and specified my non-SMS volumes, un ticking 'SMS managed' and re-generating the jobs, which I then ran. No mention of SCCPTS9 in any of the jobs, but... everything is allocated on those original SMS-managed volumes again, with nothing on my lovely (empty) non-SMS volumes...

Thanks

Grant

My personal preference is to reply in the forum so others might benefit from the conversation.  But you do you.

Grant, you replied to me privately, hence you don't see that response here in the public forum.  In any case, good luck adjusting your SMS configuration.  In case you haven't seen them yet, here's a link to a set of tutorial videos on how to install (Deploy) software using z/OSMF.
https://mediacenter.ibm.com/playlist/dedicated/101043781/1_mzzf31vy/1_f1qhec1j

Feel free to reach out if you have further problems or questions.

Hi Kurt, thanks for the quick reply, I thought I had responded but I can't see where so hopefully this isn't a duplicate. 

So... the DELCAT step (in IZUD04UZ) did indeed run. The unzip output was as follows:

However, the job output shows:

So, I guess you must be right, an errant ACS routine for me to check.

Per your point on SCCPTS9, yes I can see how the system was built using the SC used on the IBM system and could have been overridden just as I'd specified those non SMS volumes I created. As I'm using the COD system to drive this there wasn't anything set up so I set up SCCPTS9 to align with the jobs (maybe a mistake?).

Full disclosure - I haven't done this for about 20 years so a steep learning curve on this method of deployment (!), and your assistance is greatly appreciated.

Grant, does the re-generated Unzip job (IZUDnnUZ) identify your lovely non-SMS volumes as the location for the new data sets?  For example, do the <ARCHDEF> statements in the GIMUNZIP job step contain the volume="volser" operand?  Did the DELCATDS job step run and did it delete existing data sets?  If so, then I am unsure why the data sets were not allocated on the specified volume.  Perhaps the ACS routines in your driving system's SMS configuration are getting in the way and overriding the volume specification?

As a by the way and for your information, z/OSMF does not necessarily "expect to use" storage class SCCPTS9.  That is a storage class defined on the z/OS system used by the IBM manufacturing process and is the storage class used by the originating, or source, data sets for your portable software instance.  The deployment configuration may be initialized using the locations from the source data sets, but as you have since discovered you can certainly change those to specify a storage class that is already defined to your SMS subsystem, or you can tell z/OSMF to locate the new data sets on a volume that you identify instead.  That is, you don't have to use the source storage class SCCPTS9.

Another query from this first timer... 

My z/OS 3.1 install expects to use SC 'SCCPTS9'. So, I set this up with some volumes and ran the jobs. OK. But I thought I'd try it again using some non-SMS volumes and try to get the target volumes allocated roughly how I'd want them to look eventually. So, I went back into the configuration screens and specified my non-SMS volumes, un ticking 'SMS managed' and re-generating the jobs, which I then ran. No mention of SCCPTS9 in any of the jobs, but... everything is allocated on those original SMS-managed volumes again, with nothing on my lovely (empty) non-SMS volumes...

Thanks

Grant