Re: New to RACF

[Anthony Thompson]

Thanks for pointing out %08X (pad 8-character field with zeroes to exceed 
default precision). I'm not that big on C/C++ as yet, still learning. So are 
IBM z/UNIX programmers, apparently. 

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Friday, 22 April 2016 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

Or they could use "%08X" to tell printf to tag on the leading zeros - no 
counting needed.

Here's one that always looks strange to me:

"You have 1 records"

I think that *does* take some extra C coding to fix unless someone can tell me 
some printf tricks.

Years ago I wrote some assembler macros and subroutines to simulate C string 
routines, including printf.  I seem to remember having logic that would scan 
the next word in the source string looking for a trailing S, and would drop it 
if the number displayed was 1.  For example:

   #PRINTF 'You have %d records',COUNT

... would result in good grammar no matter what number was displayed.

Anthony Thompson wrote:
> The error reason is actually 0B7F1C00, it's the C/C++ library functions being 
> called from within copytree command (like printf, fprint, etc) that drop 
> leading zeroes. I've seen it many times in error messages from z/UNIX 
> commands . It is fixable in C/C++ code, but the programmer needs to count the 
> number of digits to be output and manually add their own leading zeros. Not 
> many can be bothered.

--
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: New to RACF

[Tony Harminc]

On Apr 21, 2016 9:33 PM, "Anthony Thompson" 
wrote:
>
> The error reason is actually 0B7F1C00, it's the C/C++ library functions
being called from within copytree command (like printf, fprint, etc) that
drop leading zeroes. I've seen it many times in error messages from z/UNIX
commands . It is fixable in C/C++ code, but the programmer needs to count
the number of digits to be output...

So X'1C'  = 28 = SAF RC = revoked.

Seriously, the failure to display the proper reason code should be APARed.

Tony H.

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

Re: New to RACF

[Tom Brennan]

Or they could use "%08X" to tell printf to tag on the leading zeros - no 
counting needed.


Here's one that always looks strange to me:

"You have 1 records"

I think that *does* take some extra C coding to fix unless someone can 
tell me some printf tricks.


Years ago I wrote some assembler macros and subroutines to simulate C 
string routines, including printf.  I seem to remember having logic that 
would scan the next word in the source string looking for a trailing S, 
and would drop it if the number displayed was 1.  For example:


  #PRINTF 'You have %d records',COUNT

... would result in good grammar no matter what number was displayed.

Anthony Thompson wrote:

The error reason is actually 0B7F1C00, it's the C/C++ library functions being 
called from within copytree command (like printf, fprint, etc) that drop 
leading zeroes. I've seen it many times in error messages from z/UNIX commands 
. It is fixable in C/C++ code, but the programmer needs to count the number of 
digits to be output and manually add their own leading zeros. Not many can be 
bothered.


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

Re: New to RACF

[Anthony Thompson]

The error reason is actually 0B7F1C00, it's the C/C++ library functions being 
called from within copytree command (like printf, fprint, etc) that drop 
leading zeroes. I've seen it many times in error messages from z/UNIX commands 
. It is fixable in C/C++ code, but the programmer needs to count the number of 
digits to be output and manually add their own leading zeros. Not many can be 
bothered.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Friday, 22 April 2016 2:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

On 21 April 2016 at 12:01, Tracy Adams  wrote:
> seteuid 0
> Error codes: 0 -1 A4 B7F1C00
> EMVSSAF2ERR: SAF/RACF error
>
> Dubious nothing has changed in the RACF world and this use to work.  The only 
> thing I can find is that the userid needs acc(read) to bpx.superuser which it 
> does.  Where do I begin to debug this RACF error?

Are you sure the line with the error codes was copied accurately? I would 
expect the last piece to have 8 hex digits; it's the errno2 value. The A4 
(EMVSSAF2ERR) is saying it's a RACF error encountered by the UNIX seteuid() 
service. The last two bytes (4 digits) of that 8 character hex string should be 
the RACF return and reason codes from the RACF IRRSEU00 callable service, 
described in the RACF Callable Services book.

If it's really coming out as 7 digits, then I'd call IBM and complain.
If it got mangled or typo'd, then look up the corrected version in the Callable 
Services book and see if that leads you further. All this seems to have to do 
with authorization to change the effective UID.

Tony H.

--
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: Example of ACS Environment of SPMGCLTR

[Glenn Wilcock]

Hi, 

I believe that the problem is that my original presentations on this topic 
showed using the existing classes/group to determine the new class/group.  
Unfortunately, that was function that did not make shipped support.  (I have 
updated the examples in my most recent presentations).  For clients who need 
that support, I have been requesting that they open an RFE.  We definitely have 
on our roadmap the addition of that functionality.

Since the existing management class is not being passed in, your logic that 
sets the new management class based on the current management class is skipped, 
meaning that the management class is not changed.  Same for the SC and SG.  
Since none of the classes/groups change, that is why you are getting the 
message that you are.  A data set is only eligible to transition if at least 
there is one change.

I believe that if you remove the check for the existing class and just set the 
class/group to a specific value, that it will get around this problem.

Glenn Wilcock

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

My Assembler Text

[John Ehrman]

Some materials that may be useful to teachers of IBM mainframe Assembler 
Language are now available on the Marist College web site, along with the 
text itself.

The two items are PDFs with  (1) lecture slides for Chapters 1-8 (sorry, I 
ran out of time before I could do the rest), and (2) pages with 
mini-slides (also ch. 1-8) followed by some notes lines where a lecturer 
can jot notes for use when projecting the full-size slides.

They are available at 
http://idcp.marist.edu/enterprisesystemseducation/assemblerlanguageresources-1.html
 


and if you want to access them by a different route, try 
http://idcp.marist.edu and then hover over "enterprise systems education" 
to get a drop down where you can hover over "technical resources" which 
will display another drop down where you can click on "assembler 
resources" - that will take you to the URL page above. 

Many thanks to Angelo Corridori of Marist College for hosting the 
materials, and to the many readers of these forums for their helpful and 
generous comments.

As I noted earlier, I'll be retiring from IBM at the end of May, so if you 
have any comments or suggestions, please send them to me at  
johnehrm...@gmail.com  .

I hope to do some consulting, so if you know of anyone who can use help 
with Assembler Language training, consulting, or advice, please let me 
know.  Thanks.

Regards... John 



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

Re: New to RACF

[Mark Zelden]

On Thu, 21 Apr 2016 18:29:26 +, Tracy Adams  wrote:

>Awesome!  Yes, who would think to check the Z/OS (jes) log for a failure in 
>USS (I did check
>the /var/logs but since the REXX was being invoked via batch I should have 
>looked! 
>
>There was a glowing message that bpxroot was revoked.  Unrevoked it and the 
>seteuid
> now works :-) 
>
>Thanks!! 

You're welcome.  Good thing you found that before your next IPL.   That userid 
should
be protected so that can't happen.

Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New to RACF

[Tracy Adams]

Awesome!  Yes, who would think to check the Z/OS (jes) log for a failure in USS 
(I did check the /var/logs but since the REXX was being invoked via batch I 
should have looked!

There was a glowing message that bpxroot was revoked.  Unrevoked it and the 
seteuid now works :-)

Thanks!!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Thursday, April 21, 2016 1:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

On Thu, 21 Apr 2016 16:50:20 +, Tracy Adams  wrote:

> Yes, I am allowed to su with no complaints

Ok.  And I saw in another post you confirmed the Reason code (errnojrs) that is 
being displayed back to you (although it doesn't look correct).   Did you
check syslog at the time of the error to see if there are any hints there?

If it were me, I'd probably copy "copytree" and turn on some rexx tracing also. 

I have used copytree, but I also use this exec (typically in batch) to copy 
from one file system (or dir) to another.  It has the "from" and "to" 
directories hard coded.  Mostly I used this when migrating everything from HFS 
to zFS years ago.  I assume it would have the same error, but maybe adding a 
TRACE I or TRACE R would confirm you are getting the same reason code as 
displayed in copytree.  



 /* rexx */
 /*=*/ 
   fromdir = '/etc/'   
   todir   = '/service/'   
 /*=*/ 
   call syscalls 'ON'  
   address syscall 'geteuid'   
   uidval = retval 
   say 'Current UID = 'uidval  
   if uidval <> 0 then do  
 say 'Attempting to set to UID=0'  
 address syscall 'setreuid 0 0'
   /* address syscall 'seteuid 0' */   
 uidval2 = retval  
 if uidval2 <> 0 then do   
   say 'Unable to set to UID=0'
   exit 12 
 end   
 Else say 'New UID = 'uidval2  
   end 
   address syscall 'chdir' fromdir 
   say 'Copying files from' fromdir 'to' todir 
   call bpxwunix 'pax -rwvCMX -p eW . ' todir  



Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
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: Respack Volume Size Challenge

[John Eells]

Nims,Alva John , Al wrote:

You think 3 packs was crazy, for a time I worked with up to 10 packs, now it 
did include the entire SMPe data sets, but what we did there was include the 
primary res volume ID as part of the data set name, yep, the copy job was huge 
process.  Eventually the SMPe data sets were converted to being SMS managed, so 
the number of actual res volumes dropped to 3.  The zFS data sets used the 
primary volser in the DSN. So just as Lucas wrote, we use system symbols for 
the volser in the catalog.



I am not sure what you mean by "SMPe data sets."  The SMP/E CSI data 
sets should occupy a small fraction of a volume...nowhere near seven 
volumes!  The SMPPTS could grow to be fairly large, depending on your 
APPLY/ACCEPT gap practices, but it's associated with the global zone and 
not the target zone (i.e., it need not be placed on the sysres volume set).


Can you elaborate a bit?

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Respack Volume Size Challenge

[Nims,Alva John (Al)]

You think 3 packs was crazy, for a time I worked with up to 10 packs, now it 
did include the entire SMPe data sets, but what we did there was include the 
primary res volume ID as part of the data set name, yep, the copy job was huge 
process.  Eventually the SMPe data sets were converted to being SMS managed, so 
the number of actual res volumes dropped to 3.  The zFS data sets used the 
primary volser in the DSN. So just as Lucas wrote, we use system symbols for 
the volser in the catalog.

The symbols can be setup like this,  is assigned by default the volser of 
the volume IPL'd from:
SYSDEF SYMDEF(='(1:4).S(6:1)')
SYSDEF SYMDEF(='(1:4).T(6:1)')

The system I currently work with uses a primary IPL volumes of MVSIP1, MVSIP2, 
MVSIP3
So when we IPl from MVSIP1, then  = MVSIS1 &  = MVSIT1
If IPLd from MVSIP2, then  = MVSIS2 &  = MVSIT2

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, April 21, 2016 7:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Respack Volume Size Challenge

Lucas Rosalen wrote:
> As far as I have seen, it's quite simple: create a  symbol 
> (using
>  and changing last char from 1 to 2, for example) and update 
> MCAT accordingly.
> Once I've worked for a client that had 3-volumes respack. It indeed worked.
> We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st 
> volumes though...


That's exactly what it was designed to do, and why we did it at the time.  Note 
that SYS1.NUCLEUS (and IPL text) must be on the first volume, as must the 
SYS1.SVCLIB data set.

Generally, if you can get enough on the volume to IPL, start JES, and log on, 
you are far ahead of the game should you have to recover the system at some 
point (including DR).

ServerPac's Recommended System Layout (RSL) automatic volume assignment process 
will put NUCLEUS and SVCLIB on the first volume and "try" meet the second 
objective too (assuming a local 3270 SNA terminal).

But it's certainly better to get a big enough volume to put all the target data 
sets (yes, the version root and SMP/E target CSI too) on one volume, all 
together.  ServerPac's RSL function will let you play with volume sizes to see 
how large a volume you need very quickly and you can see the effects by 
displaying what's on each volume if you have more than one.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
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: New to RACF

[Mark Zelden]

On Thu, 21 Apr 2016 16:50:20 +, Tracy Adams  wrote:

> Yes, I am allowed to su with no complaints 

Ok.  And I saw in another post you confirmed the Reason code (errnojrs) that is 
being displayed back to you (although it doesn't look correct).   Did you
check syslog at the time of the error to see if there are any hints there?

If it were me, I'd probably copy "copytree" and turn on some rexx tracing
also. 

I have used copytree, but I also use this exec (typically in batch) to copy
from one file system (or dir) to another.  It has the "from" and "to" 
directories
hard coded.  Mostly I used this when migrating everything from HFS to zFS
years ago.  I assume it would have the same error, but maybe adding
a TRACE I or TRACE R would confirm you are getting the same reason 
code as displayed in copytree.  



 /* rexx */
 /*=*/ 
   fromdir = '/etc/'   
   todir   = '/service/'   
 /*=*/ 
   call syscalls 'ON'  
   address syscall 'geteuid'   
   uidval = retval 
   say 'Current UID = 'uidval  
   if uidval <> 0 then do  
 say 'Attempting to set to UID=0'  
 address syscall 'setreuid 0 0'
   /* address syscall 'seteuid 0' */   
 uidval2 = retval  
 if uidval2 <> 0 then do   
   say 'Unable to set to UID=0'
   exit 12 
 end   
 Else say 'New UID = 'uidval2  
   end 
   address syscall 'chdir' fromdir 
   say 'Copying files from' fromdir 'to' todir 
   call bpxwunix 'pax -rwvCMX -p eW . ' todir  



Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New to RACF

[Tracy Adams]

Yes, I am allowed to su with no complaints

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Thursday, April 21, 2016 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

On Thu, 21 Apr 2016 16:01:25 +, Tracy Adams  wrote:

>I am new to RACF so I apologize for stupid questions...
>
>I am running a REXX script under USS to clone the HFS/ZFS files from one 
>system to another.  IBM provides a nice sample called copytree in the 
>/samples/ dir of USS.  This utility has run fine for us in the past.  Now when 
>I execute it with the -s flag it generates and error:
>
>seteuid 0
>Error codes: 0 -1 A4 B7F1C00
>EMVSSAF2ERR: SAF/RACF error
>
>Dubious nothing has changed in the RACF world and this use to work.  The only 
>thing I can find is that the userid needs acc(read) to bpx.superuser which it 
>does.  Where do I begin to debug this RACF error?
>

Those codes all seem to point to not having access to bpx.superuser.  Can you 
get into a shell (TSO OMVS) and issue the su command without a failure?

 From the code copytree code:

   'Error codes:' rc retval errno errnojr

errno A4 = SAF/RACF error

Is that B7F1C00 missing a digit?   

Best regards ,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
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: New to RACF

[Tracy Adams]

Thanks,  I will join that list as well :-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, April 21, 2016 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

If you were not aware, there is a list for RACF

To join, if you have not done so, use this URL

RACFhttp://www.listserv.uga.edu/archives/racf-l.html

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tracy Adams
> Sent: Thursday, April 21, 2016 9:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: New to RACF
> 
> I am new to RACF so I apologize for stupid questions...
> 
> I am running a REXX script under USS to clone the HFS/ZFS files from 
> one system to another.  IBM provides a nice sample called copytree in 
> the /samples/ dir of USS.  This utility has run fine for us in the 
> past.  Now when I execute it with the -s flag it generates and error:
> 
> seteuid 0
> Error codes: 0 -1 A4 B7F1C00
> EMVSSAF2ERR: SAF/RACF error
> 
> Dubious nothing has changed in the RACF world and this use to work.  
> The only thing I can find is that the userid needs acc(read) to 
> bpx.superuser which it does.  Where do I begin to debug this RACF error?
> 
> TIA,
> 
> Tracy
> 

--
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: New to RACF

[Mark Zelden]

On Thu, 21 Apr 2016 16:01:25 +, Tracy Adams  wrote:

>I am new to RACF so I apologize for stupid questions...
>
>I am running a REXX script under USS to clone the HFS/ZFS files from one 
>system to another.  IBM provides a nice sample called copytree in the 
>/samples/ dir of USS.  This utility has run fine for us in the past.  Now when 
>I execute it with the -s flag it generates and error:
>
>seteuid 0
>Error codes: 0 -1 A4 B7F1C00
>EMVSSAF2ERR: SAF/RACF error
>
>Dubious nothing has changed in the RACF world and this use to work.  The only 
>thing I can find is that the userid needs acc(read) to bpx.superuser which it 
>does.  Where do I begin to debug this RACF error?
>

Those codes all seem to point to not having access to bpx.superuser.  Can you 
get
into a shell (TSO OMVS) and issue the su command without a failure?

 From the code copytree code:

   'Error codes:' rc retval errno errnojr

errno A4 = SAF/RACF error

Is that B7F1C00 missing a digit?   

Best regards ,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New to RACF

[Tracy Adams]

Thanks, I confirm that that line is copied correctly I guess that narrows 
it down to 16 different possibilities :-)  I will pull up the c00x codes to see 
where it leads me, probably to a call to IBM.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, April 21, 2016 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

On 21 April 2016 at 12:01, Tracy Adams  wrote:
> seteuid 0
> Error codes: 0 -1 A4 B7F1C00
> EMVSSAF2ERR: SAF/RACF error
>
> Dubious nothing has changed in the RACF world and this use to work.  The only 
> thing I can find is that the userid needs acc(read) to bpx.superuser which it 
> does.  Where do I begin to debug this RACF error?

Are you sure the line with the error codes was copied accurately? I would 
expect the last piece to have 8 hex digits; it's the errno2 value. The A4 
(EMVSSAF2ERR) is saying it's a RACF error encountered by the UNIX seteuid() 
service. The last two bytes (4 digits) of that 8 character hex string should be 
the RACF return and reason codes from the RACF IRRSEU00 callable service, 
described in the RACF Callable Services book.

If it's really coming out as 7 digits, then I'd call IBM and complain.
If it got mangled or typo'd, then look up the corrected version in the Callable 
Services book and see if that leads you further. All this seems to have to do 
with authorization to change the effective UID.

Tony H.

--
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: New to RACF

[Lizette Koehler]

If you were not aware, there is a list for RACF

To join, if you have not done so, use this URL

RACFhttp://www.listserv.uga.edu/archives/racf-l.html

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tracy Adams
> Sent: Thursday, April 21, 2016 9:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: New to RACF
> 
> I am new to RACF so I apologize for stupid questions...
> 
> I am running a REXX script under USS to clone the HFS/ZFS files from one
> system to another.  IBM provides a nice sample called copytree in the
> /samples/ dir of USS.  This utility has run fine for us in the past.  Now when
> I execute it with the -s flag it generates and error:
> 
> seteuid 0
> Error codes: 0 -1 A4 B7F1C00
> EMVSSAF2ERR: SAF/RACF error
> 
> Dubious nothing has changed in the RACF world and this use to work.  The only
> thing I can find is that the userid needs acc(read) to bpx.superuser which it
> does.  Where do I begin to debug this RACF error?
> 
> TIA,
> 
> Tracy
> 

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

Re: New to RACF

[Tony Harminc]

On 21 April 2016 at 12:01, Tracy Adams  wrote:
> seteuid 0
> Error codes: 0 -1 A4 B7F1C00
> EMVSSAF2ERR: SAF/RACF error
>
> Dubious nothing has changed in the RACF world and this use to work.  The only 
> thing I can find is that the userid needs acc(read) to bpx.superuser which it 
> does.  Where do I begin to debug this RACF error?

Are you sure the line with the error codes was copied accurately? I
would expect the last piece to have 8 hex digits; it's the errno2
value. The A4 (EMVSSAF2ERR) is saying it's a RACF error encountered by
the UNIX seteuid() service. The last two bytes (4 digits) of that 8
character hex string should be the RACF return and reason codes from
the RACF IRRSEU00 callable service, described in the RACF Callable
Services book.

If it's really coming out as 7 digits, then I'd call IBM and complain.
If it got mangled or typo'd, then look up the corrected version in the
Callable Services book and see if that leads you further. All this
seems to have to do with authorization to change the effective UID.

Tony H.

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

Re: EXTERNAL: Re: Respack Volume Size Challenge

[Jerry Whitteridge]

We use  through  to have a 5 pack resvol set (note these include 
OMVS related HFS/ZFS - hence the number/sizes) and have no issues. Biggest 
problem I have is folks inadvertently recataloging the datasets from their 
indirect values while doing maintenance so we locked down the Master Cat such 
that even the Sysprogs have restrictions on what they can change.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: Thursday, April 21, 2016 2:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Respack Volume Size Challenge

As far as I have seen, it's quite simple: create a  symbol (using
 and changing last char from 1 to 2, for example) and update MCAT
accordingly.
Once I've worked for a client that had 3-volumes respack. It indeed worked.
We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st volumes
though...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-04-21 10:45 GMT+02:00 Jake Anderson :

> Hello,
>
> From the z/OS 2.1, I have started using Mod-27 as the Load address(Respack)
> for IPLing the z/OS 2.1 LPAR. I am curious how the other Shops are managing
> when they do not options of using Mod-27 and they have to survive with
> Mod-9. I believe the Extended Indirect cataloging is one Options.
>
> What kind of challenges are there when the Respack is divided into two
> Volumes ?
>
> Jake
>
> --
> 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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

New to RACF

[Tracy Adams]

I am new to RACF so I apologize for stupid questions...

I am running a REXX script under USS to clone the HFS/ZFS files from one system 
to another.  IBM provides a nice sample called copytree in the /samples/ dir of 
USS.  This utility has run fine for us in the past.  Now when I execute it with 
the -s flag it generates and error:

seteuid 0
Error codes: 0 -1 A4 B7F1C00
EMVSSAF2ERR: SAF/RACF error

Dubious nothing has changed in the RACF world and this use to work.  The only 
thing I can find is that the userid needs acc(read) to bpx.superuser which it 
does.  Where do I begin to debug this RACF error?

TIA,

Tracy

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

Re: Setting up z/OSMF under 2.1

[Greg Dyck]

On 4/20/2016 7:25 PM, Steve Beaver wrote:

DISASM is a nice little "gimme" but I don't think it's been updated in
years.  You might find yourself
Doing a lot of coding of DISASM to get it functional for 32 and 64 bit code


I believe you are thinking about a different "DISASM" than the support 
in ISRDDN.


The DISASM command support in ISRDDN uses High Level Assembler module 
ASMADOP ( 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.f54mc00/isrdd035.htm 
)to decode the instructions, which means that this support understands 
*ALL* of the instructions that the version of HLASM on the system 
understands.

Greg

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

Re: was I in a coma when this was discussed: z/OS FBA Services

[Mike Schwab]

http://www.amazon.com/Complaint-Department-Grenade-PINEAPPLE-CD-4/dp/B00APBED0C

On Wed, Apr 20, 2016 at 6:36 PM, Chris Hoelscher  wrote:
> Take a number .
>
> Chris Hoelscher
> Technology Architect, Database Infrastructure Services
> Technology Solution Services
> : humana.com
> 123 East Main Street
> Louisville, KY 40202
> Humana.com
> (502) 714-8615, (502) 476-2538
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Porowski, Ken
>> Sent: Wednesday, April 20, 2016 4:26 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: [IBM-MAIN] was I in a coma when this was discussed: z/OS FBA
>> Services
>>
>> If that song gets stuck in my head I will hunt you down, I will find you, 
>> and I
>> will personally fold, bend, spindle and mutilate you.
>>
>>
>>
>> CIT | Ken Porowski | VP Mainframe Engineering | Information Technology |
>> +1 973 740 5459 (tel) | ken.porow...@cit.com
>>
>>
>>
>>
>> This email message and any accompanying materials may contain proprietary,
>> privileged and confidential information of CIT Group Inc. or its 
>> subsidiaries or
>> affiliates (collectively, “CIT”), and are intended solely for the 
>> recipient(s)
>> named above.  If you are not the intended recipient of this communication,
>> any use, disclosure, printing, copying or distribution, or reliance on the
>> contents, of this communication is strictly prohibited.  CIT disclaims any
>> liability for the review, retransmission, dissemination or other use of, or 
>> the
>> taking of any action in reliance upon, this communication by persons other
>> than the intended recipient(s).  If you have received this communication in
>> error, please reply to the sender advising of the error in transmission, and
>> immediately delete and destroy the communication and any accompanying
>> materials.  To the extent permitted by applicable law, CIT and others may
>> inspect, review, monitor, analyze, copy, record and retain any
>> communications sent from or received at this email address.
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Chris Hoelscher
>> Sent: Wednesday, April 20, 2016 3:31 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: [IBM-MAIN] was I in a coma when this was discussed: z/OS FBA
>> Services
>>
>> Would that make you a coma coma  coma coma coma chameleon ??
>>
>> Chris Hoelscher
>> Technology Architect, Database Infrastructure Services Technology Solution
>> Services
>> : humana.com
>> 123 East Main Street
>> Louisville, KY 40202
>> Humana.com
>> (502) 714-8615, (502) 476-2538
>>
>>
>>
>> The information transmitted is intended only for the person or entity to
>> which it is addressed and may contain CONFIDENTIAL material.  If you receive
>> this material/information in error, please contact the sender and delete or
>> destroy the material/information.
>>
>>
>> --
>> 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
>
> The information transmitted is intended only for the person or entity to 
> which it is addressed
> and may contain CONFIDENTIAL material.  If you receive this 
> material/information in error,
> please contact the sender and delete or destroy the material/information.
>
>
> --
> 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: Respack Volume Size Challenge

[Lizette Koehler]

At one shop I worked at a long time ago, we had a 6 pack Sysres system.  


They were all 3390 Mod9s.  It worked quite well.

Currently our only issue is the OMVS datasets needed.  We have put those on a 
Sysres volume that is a 3390 Mod54 with all other SYSRES volumes being a 3390 
Mod27.  We may need to loo, at using a 3390 Mod-A (The extend volume) to allow 
for the growth of some of the OMVS Files for z/OS we ship on the Sysres volumes.


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Thursday, April 21, 2016 1:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Respack Volume Size Challenge
> 
> Hello,
> 
> From the z/OS 2.1, I have started using Mod-27 as the Load address(Respack)
> for IPLing the z/OS 2.1 LPAR. I am curious how the other Shops are managing
> when they do not options of using Mod-27 and they have to survive with Mod-9.
> I believe the Extended Indirect cataloging is one Options.
> 
> What kind of challenges are there when the Respack is divided into two Volumes
> ?
> 
> Jake
> 

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

Re: Setting up z/OSMF under 2.1

[Tom Marchant]

On Wed, 20 Apr 2016 21:25:48 -0500, Steve Beaver wrote:

>DISASM is a nice little "gimme" but I don't think it's been updated in
>years.  You might find yourself
>Doing a lot of coding of DISASM to get it functional for 32 and 64 bit code

I just looked at it for the first time. It seems to correctly disassemble 
instructions that were introduced on the z13.

-- 
Tom Marchant

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

Re: Java on z bitness

[Tom Marchant]

On Tue, 19 Apr 2016 21:06:21 -0400, Phil Smith III wrote:

>Tom Marchant wrote:
>
>>Why not make your STC run AMODE 64, at least part of the time?
>
>Yeah, that's an option, but it's a lot more work and has other possible
>impacts

It's not that hard.

 STMG  R2,R15,SAVE64save 64-bit registers   
 LLGTR BASE1,BASE1  clear bits 0-32 of first base register
 LLGTR BASE2,BASE2  clear bits 0-32 of second base register
 ...clear bits 0-32 of more base registers
 SAM64 ,switch to AMODE 64
 GETMAIN ...get storage to copy the data to
 STR1,WORKADDR  save the address of the area obtained
 ...set up regs for MVCL
 MVCL  ...  copy it below the line
 SAM31 ,back to AMODE 31
 LMG   R2,R15,SAVE64restore the high halves of the registers

Now the Java data is all below the line. Yeah, I know, there will probably be a 
bit more work as you will have to adjust pointers, for example.

-- 
Tom Marchant

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

Re: Respack Volume Size Challenge

[John Eells]

Lucas Rosalen wrote:

As far as I have seen, it's quite simple: create a  symbol (using
 and changing last char from 1 to 2, for example) and update MCAT
accordingly.
Once I've worked for a client that had 3-volumes respack. It indeed worked.
We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st volumes
though...



That's exactly what it was designed to do, and why we did it at the 
time.  Note that SYS1.NUCLEUS (and IPL text) must be on the first 
volume, as must the SYS1.SVCLIB data set.


Generally, if you can get enough on the volume to IPL, start JES, and 
log on, you are far ahead of the game should you have to recover the 
system at some point (including DR).


ServerPac's Recommended System Layout (RSL) automatic volume assignment 
process will put NUCLEUS and SVCLIB on the first volume and "try" meet 
the second objective too (assuming a local 3270 SNA terminal).


But it's certainly better to get a big enough volume to put all the 
target data sets (yes, the version root and SMP/E target CSI too) on one 
volume, all together.  ServerPac's RSL function will let you play with 
volume sizes to see how large a volume you need very quickly and you can 
see the effects by displaying what's on each volume if you have more 
than one.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Respack Volume Size Challenge

[Lucas Rosalen]

As far as I have seen, it's quite simple: create a  symbol (using
 and changing last char from 1 to 2, for example) and update MCAT
accordingly.
Once I've worked for a client that had 3-volumes respack. It indeed worked.
We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st volumes
though...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-04-21 10:45 GMT+02:00 Jake Anderson :

> Hello,
>
> From the z/OS 2.1, I have started using Mod-27 as the Load address(Respack)
> for IPLing the z/OS 2.1 LPAR. I am curious how the other Shops are managing
> when they do not options of using Mod-27 and they have to survive with
> Mod-9. I believe the Extended Indirect cataloging is one Options.
>
> What kind of challenges are there when the Respack is divided into two
> Volumes ?
>
> Jake
>
> --
> 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

Respack Volume Size Challenge

[Jake Anderson]

Hello,

>From the z/OS 2.1, I have started using Mod-27 as the Load address(Respack)
for IPLing the z/OS 2.1 LPAR. I am curious how the other Shops are managing
when they do not options of using Mod-27 and they have to survive with
Mod-9. I believe the Extended Indirect cataloging is one Options.

What kind of challenges are there when the Respack is divided into two
Volumes ?

Jake

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

Re: Setting up z/OSMF under 2.1

[Edward Finnell]

It's gonna run in the mode of the TSO issuer  As a supported command  it 
should be updated to recognize the new ARCHLVL's for the new machine  
instructions but it doesn't have to execute them.
 
 
 
In a message dated 4/20/2016 9:26:03 P.M. Central Daylight Time,  
st...@stevebeaver.com writes:

You  might find yourself
Doing a lot of coding of DISASM to get it functional  for 32 and 64 bit code



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

Re: Example of ACS Environment of SPMGCLTR

[Richard Marchant]

Theo,

OK found the description for ARC1220I Reason Code 36

*The MIGRATE DATASETNAME command is issued with TRANSITION keyword, but the
ACS routines return a management class, storage class, [image: Start of
change]and storage group that match the existing assigned constructs or
management class, storage class or storage group specified by the optional
parameters of TRANSITION keyword are the same as the current SMS construct
of this data set.*

I think the best way to check this out would be to run a TEST in ISMF.
Specify  as SPMGCLTR, SC as the current SC, MC as current MC, and
see what SC, MC and Storage Group are given as outputs.

Richard
073 289 9246





On Wed, Apr 20, 2016 at 3:18 PM, Buckton, T. (Theo) 
wrote:

> OK Richard, come let me show how I set it up:
>
>
>
> Mgmtclas: USRTIER1
>
> Class Transition Criteria
>
>   Time Since Creation Years  :
>
>   Months :
>
>   Days . :
>
>
>
>   Time Since Last use Years  :
>
>   Months :
>
>   Days . : 2
>
>
>
>
>
> Storage Class: USRSCTR1
>
> Availability . . . . . . . . . . . . : NOPREF
>
> Accessibility  . . . . . . . . . . . : NOPREF
>
> Guaranteed Space  . . . . . . . . : NO
>
> Guaranteed Synchronous Write  . . : NO
>
> Multi-Tiered SGs  . . . . . . . . :
>
> Parallel Access Volume Capability : NOPREF
>
> Cache Set Name  . . . . . . . . . :
>
> CF Direct Weight  . . . . . . . . :
>
> CF Sequential Weight  . . . . . . :
>
> Lock Set Name . . . . . . . . . . :
>
> Disconnect Sphere at CLOSE  . . . : NO
>
>
>
>
>
> STORGRP
>
> Primary pool UMGG9000 (Tier1)
>
> Auto Migrate . . . . . . . . : YES
>
> Auto Backup  . . . . . . . . : NO
>
> Auto Dump  . . . . . . . . . : NO
>
> Overflow . . . . . . . . . . : NO
>
> Migrate Sys/Sys Group Name . : S0M0
>
> Backup Sys/Sys Group Name  . : S0M0
>
> Dump Sys/Sys Group Name  . . :
>
> Extend SG Name . . . . . . . :
>
> Copy Pool Backup SG Name . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Allocation/Migration Threshold - High  . : 70
>
>  Low . . : 35
>
> Alloc/Migr Threshold Track-Managed - High: 70
>
>  Low : 35
>
> Total Space Alert Threshold %  . . . . . : 30
>
> Track-Managed Space Alert Threshold %  . : 0
>
> Guaranteed Backup Frequency  . . . . . . :
>
> BreakPointValue  . . . . . . . . . . . . :
>
> Processing Priority  . . . . . . . . . . : 50
>
>
>
> STORGRP: UMGG9001 - Tier2
>
>
>
> Auto Migrate . . . . . . . . : YES
>
> Auto Backup  . . . . . . . . : NO
>
> Auto Dump  . . . . . . . . . : NO
>
> Overflow . . . . . . . . . . : NO
>
> Migrate Sys/Sys Group Name . : S0M0
>
> Backup Sys/Sys Group Name  . :
>
> Dump Sys/Sys Group Name  . . :
>
> Extend SG Name . . . . . . . :
>
> Copy Pool Backup SG Name . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Allocation/Migration Threshold - High  . : 85
>
>  Low . . : 1
>
> Alloc/Migr Threshold Track-Managed - High: 85
>
>  Low : 1
>
> Total Space Alert Threshold %  . . . . . : 0
>
> Track-Managed Space Alert Threshold %  . : 0
>
> Guaranteed Backup Frequency  . . . . . . :
>
> BreakPointValue  . . . . . . . . . . . . :
>
> Processing Priority  . . . . . . . . . . : 50
>
>
>
>
>
> SCACS
>
> FILTLIST USRSCTR1 INCLUDE(
>
> N058725.TEST0.CLTRNS*
>
> )
>
>
>
> IF  = 'SPGMCLTR' THEN
>
>  SELECT ()
>
>   WHEN ('USRSCTR1')
>
>   SET  = 'USRSCTR2'
>
>   OTHERWISE SET  = 
>
>   END
>
>
>
> MCACS
>
> FILTLIST USRTIER1 INCLUDE(
>
> N058725.TEST0.CLTRNS*
>
> )
>
>
>
> IF  = 'SPGMCLTR' THEN
>
> SELECT ()
>
> WHEN ('USRTIER1')
>
>  SET  = 'USRTIER2'
>
>  OTHERWISE SET  = 
>
>   END
>
>
>
>
>
> SGACS
>
> IF  = 'SPGMCLTR' THEN
>
> SELECT  ()
>
>  WHEN ('USRSCTR1') SET  = 'UMGG9001'
>
>  OTHERWISE SET  = 
>
> END
>
>
>
> So now I need the current data set to be transitioned to UMGG9002 which is
> Tier-2 at the Primary Level using the HSEND MIGRATE DSN(data.set.name)
> TRANSITION
>
>
>
> Data Set Name . . . . : N058725.TEST0.CLTRNS1
>
>
>
> General Data   Current Allocation
>
>  Management class . . : USRTIER1Allocated tracks  . : 1
>
>  Storage class  . . . : USRSCTR1Allocated extents . : 1
>
>   Volume serial . . . : UMGG13
>
>   Device type . . . . : 3390
>
>  Data class . . . . . : USERS
>
>   Organization  . . . : PS Current Utilization
>
>   Record format . . . : FB  Used tracks . . . . : 0
>
>   Record length . . . : 80  Used extents  . . . : 0
>
> 

Re: Example of ACS Environment of SPMGCLTR

[Richard Marchant]

Theo,

I see you have posted this on IBMMAIN.

What we need to know is what is  ARC1220I  reason code 36

Reason Code 36 is not listed in the Message and Codes manual.

Richard
073 289 9246

On Wed, Apr 20, 2016 at 3:18 PM, Buckton, T. (Theo) 
wrote:

> OK Richard, come let me show how I set it up:
>
>
>
> Mgmtclas: USRTIER1
>
> Class Transition Criteria
>
>   Time Since Creation Years  :
>
>   Months :
>
>   Days . :
>
>
>
>   Time Since Last use Years  :
>
>   Months :
>
>   Days . : 2
>
>
>
>
>
> Storage Class: USRSCTR1
>
> Availability . . . . . . . . . . . . : NOPREF
>
> Accessibility  . . . . . . . . . . . : NOPREF
>
> Guaranteed Space  . . . . . . . . : NO
>
> Guaranteed Synchronous Write  . . : NO
>
> Multi-Tiered SGs  . . . . . . . . :
>
> Parallel Access Volume Capability : NOPREF
>
> Cache Set Name  . . . . . . . . . :
>
> CF Direct Weight  . . . . . . . . :
>
> CF Sequential Weight  . . . . . . :
>
> Lock Set Name . . . . . . . . . . :
>
> Disconnect Sphere at CLOSE  . . . : NO
>
>
>
>
>
> STORGRP
>
> Primary pool UMGG9000 (Tier1)
>
> Auto Migrate . . . . . . . . : YES
>
> Auto Backup  . . . . . . . . : NO
>
> Auto Dump  . . . . . . . . . : NO
>
> Overflow . . . . . . . . . . : NO
>
> Migrate Sys/Sys Group Name . : S0M0
>
> Backup Sys/Sys Group Name  . : S0M0
>
> Dump Sys/Sys Group Name  . . :
>
> Extend SG Name . . . . . . . :
>
> Copy Pool Backup SG Name . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Allocation/Migration Threshold - High  . : 70
>
>  Low . . : 35
>
> Alloc/Migr Threshold Track-Managed - High: 70
>
>  Low : 35
>
> Total Space Alert Threshold %  . . . . . : 30
>
> Track-Managed Space Alert Threshold %  . : 0
>
> Guaranteed Backup Frequency  . . . . . . :
>
> BreakPointValue  . . . . . . . . . . . . :
>
> Processing Priority  . . . . . . . . . . : 50
>
>
>
> STORGRP: UMGG9001 - Tier2
>
>
>
> Auto Migrate . . . . . . . . : YES
>
> Auto Backup  . . . . . . . . : NO
>
> Auto Dump  . . . . . . . . . : NO
>
> Overflow . . . . . . . . . . : NO
>
> Migrate Sys/Sys Group Name . : S0M0
>
> Backup Sys/Sys Group Name  . :
>
> Dump Sys/Sys Group Name  . . :
>
> Extend SG Name . . . . . . . :
>
> Copy Pool Backup SG Name . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Dump Class . . . . . . . . . . . . . . . :
>
> Allocation/Migration Threshold - High  . : 85
>
>  Low . . : 1
>
> Alloc/Migr Threshold Track-Managed - High: 85
>
>  Low : 1
>
> Total Space Alert Threshold %  . . . . . : 0
>
> Track-Managed Space Alert Threshold %  . : 0
>
> Guaranteed Backup Frequency  . . . . . . :
>
> BreakPointValue  . . . . . . . . . . . . :
>
> Processing Priority  . . . . . . . . . . : 50
>
>
>
>
>
> SCACS
>
> FILTLIST USRSCTR1 INCLUDE(
>
> N058725.TEST0.CLTRNS*
>
> )
>
>
>
> IF  = 'SPGMCLTR' THEN
>
>  SELECT ()
>
>   WHEN ('USRSCTR1')
>
>   SET  = 'USRSCTR2'
>
>   OTHERWISE SET  = 
>
>   END
>
>
>
> MCACS
>
> FILTLIST USRTIER1 INCLUDE(
>
> N058725.TEST0.CLTRNS*
>
> )
>
>
>
> IF  = 'SPGMCLTR' THEN
>
> SELECT ()
>
> WHEN ('USRTIER1')
>
>  SET  = 'USRTIER2'
>
>  OTHERWISE SET  = 
>
>   END
>
>
>
>
>
> SGACS
>
> IF  = 'SPGMCLTR' THEN
>
> SELECT  ()
>
>  WHEN ('USRSCTR1') SET  = 'UMGG9001'
>
>  OTHERWISE SET  = 
>
> END
>
>
>
> So now I need the current data set to be transitioned to UMGG9002 which is
> Tier-2 at the Primary Level using the HSEND MIGRATE DSN(data.set.name)
> TRANSITION
>
>
>
> Data Set Name . . . . : N058725.TEST0.CLTRNS1
>
>
>
> General Data   Current Allocation
>
>  Management class . . : USRTIER1Allocated tracks  . : 1
>
>  Storage class  . . . : USRSCTR1Allocated extents . : 1
>
>   Volume serial . . . : UMGG13
>
>   Device type . . . . : 3390
>
>  Data class . . . . . : USERS
>
>   Organization  . . . : PS Current Utilization
>
>   Record format . . . : FB  Used tracks . . . . : 0
>
>   Record length . . . : 80  Used extents  . . . : 0
>
>   Block size  . . . . : 8000
>
>   1st extent tracks . : 1
>
>   Secondary tracks  . : 1  Dates
>
>   Data set name type  : Creation date . . . : 2016/04/16
>
> Referenced date . . : 2016/04/16
>
> Expiration date . . : ***None***
>
>   SMS Compressible  . : NO
>
>
>
>
>
> And it is not migrating saying:
> ARC1001I N058725.TEST0.CLTRNS1 MIGRATE FAILED, RC=0020,