Re: Question regarding RACF migration.
Don't know what an SME is. Subject Matter Expert. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
G'day All, Thanks a lot for all your responses. It was really really useful. Thanks Sridhar K Veena Accenture - Bangalore Host Centric Capability +91-80-39170641 (Direct) +91-9242-227797 (Mobile) AIM: Sridhar Veena From: Veena, Sridhar K. Sent: Tuesday, November 20, 2007 12:08 PM To: 'IBM-MAIN@BAMA.UA.EDU' Subject: Question regarding RACF migration. G'day, I want to know from a technical perspective if some one needs to migrate an existing system from an older version of OS (say MVS/ESA, OS/390 etc to Z/Os) what is the impact on RACF?. Would migrating the RACF to a newer version be a big enough Project(like a 6 months to 1 year kind of project)?. Or as in any migration from one version to another, RACF is also automatically handled?. Please advice. Thanks in advance for your response. Thanks Sridhar K Veena Accenture - Bangalore Host Centric Capability +91-80-39170641 (Direct) +91-9242-227797 (Mobile) AIM: Sridhar Veena This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
In a message dated 11/22/2007 5:26:26 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Thanks a lot for all your responses. It was really really useful. I had a PHB presentation, but can't find it. Long story short the big conversion was RACF 1.8 to 1.9. After that there are incremental levels of the DB added by using the extended fields in data base records. These fields are examined by newer releases. So theoretically you can share DB's from 1.9 on with just about any level. This always scared me, so for production I always copied the old databases to new and ran the template update. **Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop000301) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
snip--- I had a PHB presentation, but can't find it. Long story short the big conversion was RACF 1.8 to 1.9. After that there are incremental levels of the DB added by using the extended fields in data base records. These fields are examined by newer releases. So theoretically you can share DB's from 1.9 on with just about any level. This always scared me, so for production I always copied the old databases to new and ran the template update. -unsnip--- I just ran the template update and shared the databases between old and new level. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
In a message dated 11/22/2007 10:27:00 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I just ran the template update and shared the databases between old and new level. Fritzy ol' auditors mandated 'electronic separation' between test and production LPARs so many habits were carryovers from that environment. **Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop000301) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
Rick makes a good point. Once the great 1.9 divide has been crossed, we've never found any reason not to share the RACF data base in each plex. Even when templates had to be applied to the data base itself, lower releases always tolerated them. I know everyone does migration differently, but we have kept the same data base allocations and content since at least the early 90s. RACF *data* is never migrated along with ServerPac. Rick Fochtman [EMAIL PROTECTED] T To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: Question regarding RACF migration. 11/22/2007 08:24 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU snip--- I had a PHB presentation, but can't find it. Long story short the big conversion was RACF 1.8 to 1.9. After that there are incremental levels of the DB added by using the extended fields in data base records. These fields are examined by newer releases. So theoretically you can share DB's from 1.9 on with just about any level. This always scared me, so for production I always copied the old databases to new and ran the template update. -unsnip--- I just ran the template update and shared the databases between old and new level. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
In a message dated 11/22/2007 9:33:56 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Fritzy ol' auditors do NOT mandate anything! Don't know what an SME is. There are internal and external auditors as well as Federal Inspection teams. They were between us and the CFO and they truly did mandate. Guess everybody was part of the compliance team. Like make it work or hit the road They also audited the trash, by room and bag. So if you discarded part of your coffee maker by accident you could go to the bowels and the trash retention room(s) and walk to your bag for up to eight days! **Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop000301) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
---snip- Fritzy ol' auditors mandated 'electronic separation' between test and production LPARs so many habits were carryovers from that environment. -unsnip- We all have our opinions about auditors. Good manners prevent me from expressing my opinion here. G -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
Fritzy ol' auditors mandated Fritzy ol' auditors do NOT mandate anything! All they can do is report on compliance based on SME recommendations. Are you following it or not? Anything else is a conflict of duty. SME's recommend. Auditors report. Compliance teams enforce. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
Sridhar, Theoretically, you could just apply the templates for the target z/OS release to the old database and reIPL with it. This assumes the database in the restructured format introduced with RACF 1.9 (MVS/ESA). However, there are many other factors that would determine whether your system would run effectively such as (just to name a few) whether there are exits involved (both RACF and other products calling RACF), what resource classes and profiles are defined, what release of CICS are you migrating from/to (there was a significant change in CICS transaction security at release 4.1), and what release of z/OS you are migrating to (for instance, FACILITY class profiles to allow the use of HSM commands are required in z/OS 1.6 and later). Depending on the size of the RACF database and the span of releases, you may need 2 to 4 weeks or more just to analyze the possible impacts and plan the creation of new profiles needed to accommodate the requirements of the target z/OS release. Regards, Bob Robert S. Hansel RACF Specialist RSH Consulting, Inc. www.rshconsulting.com 617-969-8211 -Original Message- Date:Tue, 20 Nov 2007 12:07:58 +0530 From:Sridhar K Veena [EMAIL PROTECTED] Subject: Question regarding RACF migration. G'day, I want to know from a technical perspective if some one needs to migrate an existing system from an older version of OS (say MVS/ESA, OS/390 etc to Z/Os) what is the impact on RACF?. Would migrating the RACF to a newer version be a big enough Project(like a 6 months to 1 year kind of project)?. Or as in any migration from one version to another, RACF is also automatically handled?. Please advice. Thanks in advance for your response. Thanks Sridhar K Veena Accenture - Bangalore Host Centric Capability +91-80-39170641 (Direct) +91-9242-227797 (Mobile) AIM: Sridhar Veena -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
On Wed, 21 Nov 2007 06:37:32 -0500, Robert S. Hansel (RSH) [EMAIL PROTECTED] wrote: Theoretically, you could just apply the templates for the target z/OS release to the old database and reIPL with it. This assumes the database in the restructured format introduced with RACF 1.9 (MVS/ESA). However, there are many other factors that would determine whether your system would run effectively such as (just to name a few) whether there are exits involved (both RACF and other products calling RACF), what resource classes and profiles are defined, what release of CICS are you migrating from/to (there was a significant change in CICS transaction security at release 4.1), and what release of z/OS you are migrating to (for instance, FACILITY class profiles to allow the use of HSM commands are required in z/OS 1.6 and later). Depending on the size of the RACF database and the span of releases, you may need 2 to 4 weeks or more just to analyze the possible impacts and plan the creation of new profiles needed to accommodate the requirements of the target z/OS release. Good points, Bob. Additionally, one needs to consider the kind of migration. The migration might involve a complete cutover to the new system, without ever sharing the data or falling back to the old level. Or it might involve running the new system in test mode, then falling back to the old system, but using the updated data sets. Or it might involve a test system and a production system sharing data sets simultaneously. The considerations and problems may be different for all three of these cases, especially when performing a migration that's not within the allowed three release range. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
Even if you are not on a supported migration path, you can always try to copy the database over and apply the new templates. The worst that will happen is it doesn't work. In that case, you can use the brute force method. Run the RACF DBSYNC freebie comparing your current database to an empty file. It will produce a reasonably complete set of RACF commands to make your new database look like the old one. (Users created in the new database will have default passwords which they must change at first logon.) In any case, the effort should be measured in days, definitely not months. -Original Message- From: Sridhar K Veena [mailto:snip] Sent: Monday, November 19, 2007 10:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Question regarding RACF migration. G'day, I want to know from a technical perspective if some one needs to migrate an existing system from an older version of OS (say MVS/ESA, OS/390 etc to Z/Os) what is the impact on RACF?. Would migrating the RACF to a newer version be a big enough Project(like a 6 months to 1 year kind of project)?. Or as in any migration from one version to another, RACF is also automatically handled?. Please advice. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
I dimly recall (hey, it's all pretty dim these days) a long ago chasm crossing where we had to 'reformat' the RACF data base. I can't imagine anyone still running such an ancient release. Unless you're resurrecting a copy of a decades old data base, a 'template refresh' should be sufficient to get the old coot running. That process used require a utility run before IPLing a new level. For several OS releases now an in-storage update is done dynamically, and the utility--if you bother to run it at all--is done after IPLing a new level. Just remember that a RACF data base is quintessentially a bunch of ones and zeroes until it becomes the 'primary' data base in a running system. At that point, what you got is what you have. An old data base that may be 'usable' with updated templates may lack so many profiles and modern options that it's useless for your normal operation. In other words, you can try this at home, but don't try it at work in a production environment. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Schwarz, Barry A barry.a.schwarz@ To BOEING.COM IBM-MAIN@BAMA.UA.EDU Sent by: IBM cc Mainframe Discussion List Subject [EMAIL PROTECTED] Re: Question regarding RACF .EDU migration. 11/20/2007 11:35 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Even if you are not on a supported migration path, you can always try to copy the database over and apply the new templates. The worst that will happen is it doesn't work. In that case, you can use the brute force method. Run the RACF DBSYNC freebie comparing your current database to an empty file. It will produce a reasonably complete set of RACF commands to make your new database look like the old one. (Users created in the new database will have default passwords which they must change at first logon.) In any case, the effort should be measured in days, definitely not months. I want to know from a technical perspective if some one needs to migrate an existing system from an older version of OS (say MVS/ESA, OS/390 etc to Z/Os) what is the impact on RACF?. Would migrating the RACF to a newer version be a big enough Project(like a 6 months to 1 year kind of project)?. Or as in any migration from one version to another, RACF is also automatically handled?. Please advice. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question regarding RACF migration.
--snip-- I want to know from a technical perspective if some one needs to migrate an existing system from an older version of OS (say MVS/ESA, OS/390 etc to Z/Os) what is the impact on RACF?. Would migrating the RACF to a newer version be a big enough Project(like a 6 months to 1 year kind of project)?. Or as in any migration from one version to another, RACF is also automatically handled?. Please advice. ---unsnip- I think you meant advise, the verb, rather than advice, what comes from that verb. :-) Mr. Robinson was quite correct in his advice. In every respect. I've been in that unfortunate situation more times than I'd care to admit. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
