Re: RACF on an ADCD system
> And the DB2s are separately down-loadable from IBM-Dallas. So you can have > DB2 > V8 on 1.13. I agree that ADCD does not come with it directly, but it is > available. So basically what y'all are saying is that this rubbish is nice to have. I disagree, especially for remnants of userids that don't exist anymore. In my opinion, if someone wants to add outdated software (even if it is still supported) to their system, they better know how to set it up properly. We will certainly not run several DB2s or CICSs or WASs or IMSs, only the latest, if any. What I didn't mention was that I basically eliminated every activated IMS class, all classes dealing with Websphere and z/OSMF plus a few others. If we will run this sometime in the future, I'll be reading the books on how to set this up rather than deal with obsolete definitions that may or may not have an impact on something else. These ADCD systems are not set up for migration from one z/OS release to another at all, so data transfer from one system to the next appears to be a must. I understand that the ADCD comes with two releases of each (and I don't think we were missing volumes). I am also aware of the different load parms (one of the first things I checked). It is even mentioned on that website I cited (which is the only documentation I have for an ADCD system). >the ADCD has evolved over the years it hasn't been cleaned up properly and the >team that build it is quite small That's what I figured. An overworked, too small group that cannot keep up with the demands, so they do the best they can. Which falls far flat of IBMs propagated 'best practises'. As far as RACF is concerned, an ADCD system would never survive an audit, even with mild auditors. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on an ADCD system
As several other people have pointed out, the ADCD systems are mainly used by software vendors, mostly for zPDT systems, but sometimes others. And many of us HAVE to support old software: we still have customers that have not migrated for one reason or another. I agree that ADCD as delivered is not the best, but most of us do NOT worry about audits because we are not using these systems for production just for development and customer support. In fact, that is how the IBM contract for ADCD reads for us: the systems can only be used in development and support. Lloyd - Original Message From: ibmmain To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, January 3, 2013 12:38:36 PM Subject: Re: RACF on an ADCD system > And the DB2s are separately down-loadable from IBM-Dallas. So you can have > DB2 > > V8 on 1.13. I agree that ADCD does not come with it directly, but it is > available. So basically what y'all are saying is that this rubbish is nice to have. I disagree, especially for remnants of userids that don't exist anymore. In my opinion, if someone wants to add outdated software (even if it is still supported) to their system, they better know how to set it up properly. We will certainly not run several DB2s or CICSs or WASs or IMSs, only the latest, if any. What I didn't mention was that I basically eliminated every activated IMS class, all classes dealing with Websphere and z/OSMF plus a few others. If we will run this sometime in the future, I'll be reading the books on how to set this up rather than deal with obsolete definitions that may or may not have an impact on something else. These ADCD systems are not set up for migration from one z/OS release to another at all, so data transfer from one system to the next appears to be a must. I understand that the ADCD comes with two releases of each (and I don't think we were missing volumes). I am also aware of the different load parms (one of the first things I checked). It is even mentioned on that website I cited (which is the only documentation I have for an ADCD system). >the ADCD has evolved over the years it hasn't been cleaned up properly and the >team that build it is quite small That's what I figured. An overworked, too small group that cannot keep up with the demands, so they do the best they can. Which falls far flat of IBMs propagated 'best practises'. As far as RACF is concerned, an ADCD system would never survive an audit, even with mild auditors. Barbara -- 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: RACF on an ADCD system
On 3 January 2013 12:39, ibmmain wrote: > These ADCD systems are not set up for migration from one z/OS release to > another at all, so data transfer from one system to the next appears to be a > must. I'm puzzled. I haven't installed an ADCD for a while, but the layout used to be explicitly designed for z/OS migration, with a clear split between the volumes that would be expected to be replaced in a migration, and those that wouldn't. >>the ADCD has evolved over the years it hasn't been cleaned up properly and >>the team that build it is quite small > That's what I figured. An overworked, too small group that cannot keep up > with the demands, so they do the best they can. Which falls far flat of IBMs > propagated 'best practises'. As far as RACF is concerned, an ADCD system > would never survive an audit, even with mild auditors. I expect the IBM argument would be that the target market is very small, and doesn't pay IBM much money. They've clearly taken steps to reduce the cost of production (partly by outsourcing some of the work to India, where the team doubtless has much less experience than the Dallas folks). Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on an ADCD system
> I'm puzzled. I haven't installed an ADCD for a while, but the layout > used to be explicitly designed for z/OS migration, with a clear split > between the volumes that would be expected to be replaced in a > migration, and those that wouldn't. I disagree. It is set up so that you can customize it properly (by dividing your customization from what the system does), provided you know how to do that. When I got my hands on the 1.10 system, I first had to clean it up severely (get all of our datasets out of the master catalog into a user catalog) and then hope and pray that I have found all places someone (using IBMUSER) had changed the SMPE-maintained libraries instead of copying to USER.* libraries (before my time). It takes some knowledge about migration to be able to customize correctly. When switching to the new system, we lost the RACF database and the master catalog and were forced onto the new ones. I had to make sure that I had all of our own RACF definitions copied to the new system. Someone had in the past activated SMS to contain more than the minimum config ADCD comes with. Unfortunately (never having been a space admin before), I didn't know that I also had to copy over the SMS CDSs. That caused all kinds of problems. Maybe it is just our provider (who had apparently done something to the bare ADCD system), but we were not given the chance to 'just replace' the system volumes (as one would do in a 'normal' migration to a new release). Instead, we were thrown into a new, vanilla ADCD system (and no documentation to speak of) and forced to copy over all of our user data. The (old) volumes could get attached under VM to the new z/OS system, so that removed the necessity of ADRDSSU dumping, FTPing and restoring everything. Never mind that FTP apparently was broken. An ADRDSSU dump taken in the 1.10 system and FTP'd (in my case via IND$FILE) to 1.13 resulted in ADRDSSU in 1.13 telling me that this was not an ADRDSSU dump. When we ftp'd the transport copy of our user catalog, something else broke and I was unable to import connect the user catalog. When we ADRDSSU dumped the old usercat and restored it, we got abend0C4 in some catalog module or other. Eventually I first amatersed any catalog or ADRDSSU dump on the old system, ftp'd the amatersed copy to 1.13, and untersed it. *Then* it was recognized as a valid copy. I did not debug what went wrong, my assumption was lack of toleration maintenance for the new release. The other thing an ADCD system is not set up for is applying maintenance (never mind that we cannot order any via ShopZ because our provider has the ADCD licence. No customer number, no ShopZ). There is no extra set of system residences that can be used for SMPE, so everything would go directly into the live system. With all the problems like linklist libraries going into extents that would entail. So even installing toleration maintenance would be a pain. I was told by my predecessor that in the past they *always* had to ADRDSSU dump their own data, ftp them somehow to the new ADCD system and restore there. They went through P/390, FLEX/ES, with a stint of Hercules to ADCD at our current provider. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on an ADCD system
On Fri, Jan 4, 2013 at 2:44 AM, ibmmain wrote: > Never mind that FTP apparently was broken. An ADRDSSU dump taken in the 1.10 > system and FTP'd (in my case via IND$FILE) to 1.13 resulted in ADRDSSU in > 1.13 telling me that this was not an ADRDSSU dump. When we ftp'd the > transport copy of our user catalog, something else broke and I was unable to > import connect the user catalog. When we ADRDSSU dumped the old usercat and > restored it, we got abend0C4 in some catalog module or other. Eventually I > first amatersed any catalog or ADRDSSU dump on the old system, ftp'd the > amatersed copy to 1.13, and untersed it. *Then* it was recognized as a valid > copy. I did not debug what went wrong, my assumption was lack of toleration > maintenance for the new release. > > Barbara ADRDSSU uses large block sizes that FTP can't handle. Terse / unterse took care of that. -- 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: RACF on an ADCD system
> ADRDSSU uses large block sizes that FTP can't handle. Terse / unterse > took care of that. The ADRDSSU data sets had a blksize of less than 32K because I set the blksize via JCL. That blksize was honoured and the dataset preallocated in the target system. Also, the transport copy of the catalog was NOT generated via ADRDSSU, and it was unusable on the new system after being FTP'd. I still suspect some incompatibility. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on an ADCD system
You also need to make sure that you set the transfer type to binary and you MUST specify "STRUCTURE R" when you transfer or the DUMP will be useless on the receiving side. Most people forget to use the "STRUCTURE R" command. Your FTP step from z/OS system "A" to z/OS system "B" should have the following (minimum): USERID PASSWORD EBCDIC STRUCTURE R SITE CYL (however much space you need) PUT dsn (or GET dsn depending on which way you are going) Brian Westerman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FTP "ERRORS" [was: RACF on an ADCD system]
> ADRDSSU uses large block sizes that FTP can't handle. Terse / unterse > took care of that. The ADRDSSU data sets had a blksize of less than 32K because I set the blksize via JCL. That blksize was honoured and the dataset preallocated in the target system. Also, the transport copy of the catalog was NOT generated via ADRDSSU, and it was unusable on the new system after being FTP'd. I still suspect some incompatibility. Barbara Barbara: My apologies, I had not correctly recognized some of the issues you bring up. I think I've been hitting the same thing between different IBM Labs and levels of z/OS. I have been forced to use BINARY transfers to get around an issue with code pages when using FTP. And the other issue that is not being addressed straight on is, DFSMS made a change to their support and IOS(?) made a change to the device type information allowing 3490 type drives to now do LBI (that is, 256K blocks which is beyond the old 64K blocks). So if you picked up maint that solved that, you will get an ADRDSSU output that is greater than 64K blksize. I have forgotten which z/OS level initially implemented this (caused C:D for z/OS support some heartburn). I think this is why the terse/unterse is working for you. I also believe that unless you are doing BIN xfers with FTP, you are being tripped up with code page issues (the receiving system could not read XMIT files or other special format files because they had been "corrupted."). One of the circumventions for this ADDRDSSU LBI problem for FTP is to put in the exit that forces ADRDSSU to use 32K as the max blocksize. This may be something you want to consider as it will not be as efficient with your tapes. Knowing that I worked on C:D for z/OS, you might ask why I'm not using it. Well, in my new position, C:D for z/OS is not installed in the other labs (yet) where I work now. So I have to do FTP and I've been hitting problems that C:D already had to deal with, concerning ADRDSSU written tapes. And I realized this morning that some of the symptoms you have described were ones I had been battling in copying data between two labs. Regards, Steve Thompson IS Build group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RACF on an ADCD system - was: Re: DFSMRCL0 usermod
> In what classes and profiles? You can perhaps consolidate those profiles in
> fewer and more generic profiles if you have time to do that.
>
> (I know you previously said that you are learning to work with RACF)
I did that. I have about 20 jobs that completely rearrange RACF to something
that is meaningful to me and allows better administration in my opinion.
Just a few examples of the RACF database that comes with ADCD:
CLASS(TSOAUTH): has permits for userids that don't exist in the database: LWH,
TESTER, TESTEG, DSN1SPAS. Not to mention that every userid has its own permit -
no group permits for groups of users. Anywhere, not just in this class.
CLASS(TSOPROC): still has the DB2 V8 logon proc defined (DBSPROC8) - DB2 V8 is
not delivered in this ADCD anymore.
Userid DB8GRFSH belongs to DB2 V8, which doesn't exist.
A lot of address spaces are missing in the STARTED class - the default profile
** allows very high access to all system resources. For instance, there is no
profile specifically for DB2 (no matter which release), they all start on the
** profile. There also are a ton of obsolete profiles in that class (lots of
DCE* asids that don't get started).
There are a lot of nongeneric DB2 dataset profiles from DB2 Version 7, which
don't exist anymore (neither DB2 V7 nor those datasets).
CLASS(DSNR): Again a lot of DB2 V7 and V8 related profiles in addition to V9
and V10.
Same for class(SERVER).
CLASS(PROGRAM):
RALTER PROGRAM * DELMEM('DSN810.SDSNLOD2')
RALTER PROGRAM * DELMEM('DSN810.SDSNLOAD')
RALTER PROGRAM * DELMEM('DSN810.SDSNEXIT')
RALTER PROGRAM * DELMEM('DSN710.SDSNLOD2')
RALTER PROGRAM * DELMEM('DSN710.SDSNLOAD')
RALTER PROGRAM * DELMEM('DSN710.SDSNEXIT')
RALTER PROGRAM * DELMEM('WAS401.SBBOLOAD')
RALTER PROGRAM * DELMEM('BBO401.SBBOLOAD')
None of those data sets exists anymore. There is neither DB2 V7 nor V8 (ups, I
already said that) nor WAS V4.
RDELETE PROGRAM BPXOV
RDELETE PROGRAM BPXBINIT
RDELETE PROGRAM BPXEV003
RDELETE PROGRAM BPXOLVD
RDELETE PROGRAM BPXPLPKA
RDELETE PROGRAM BPXUCSNM
RDELETE PROGRAM BPXUEYI1
RDELETE PROGRAM BPXUI1EY
RDELETE PROGRAM BPXZ24
RDELETE PROGRAM RLOGIND
I was unable to find these programs in the SMPE-defined libraries.
CLASS(FACILITY): The WLM policy as delivered can only be administered by
IBMUSER and a non-existent userid DPACK.
There are two very obsolete groups still defined named SYSCTLG and VSAMDSET.
At this point, I can almost rival a RACF admin. What I haven't touched are all
these certificate things that come in upper and lower case.
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP "ERRORS" [was: RACF on an ADCD system]
Long ago I found the following details and sent it to my team. You may find the extra details useful: Use the following to FTP a DFDSS Dump. First, issue the QUOTE SITE command as follows, which will assure the receiving file will have the proper DCB attributes... QUOTE SITE BLKSIZE=27998 LRECL=0 RECFM=U PRI=xxx SEC=xxx TRACK Of course you much change the space parameters as necessary. Then, prior to issuing the actual PUT command, issue these commands. MODE B EBCDIC Mode B tells FTP to use block mode transfers. The result is a file DFDSS likes! Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 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 Steve Thompson Sent: Friday, January 04, 2013 8:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: FTP "ERRORS" [was: RACF on an ADCD system] I have been forced to use BINARY transfers to get around an issue with code pages when using FTP. And the other issue that is not being addressed straight on is, DFSMS made a change to their support and IOS(?) made a change to the device type information allowing 3490 type drives to now do LBI (that is, 256K blocks which is beyond the old 64K blocks). So if you picked up maint that solved that, you will get an ADRDSSU output that is greater than 64K blksize. I have forgotten which z/OS level initially implemented this (caused C:D for z/OS support some heartburn). I think this is why the terse/unterse is working for you. I also believe that unless you are doing BIN xfers with FTP, you are being tripped up with code page issues (the receiving system could not read XMIT files or other special format files because they had been "corrupted."). One of the circumventions for this ADDRDSSU LBI problem for FTP is to put in the exit that forces ADRDSSU to use 32K as the max blocksize. This may be something you want to consider as it will not be as efficient with your tapes. Knowing that I worked on C:D for z/OS, you might ask why I'm not using it. Well, in my new position, C:D for z/OS is not installed in the other labs (yet) where I work now. So I have to do FTP and I've been hitting problems that C:D already had to deal with, concerning ADRDSSU written tapes. And I realized this morning that some of the symptoms you have described were ones I had been battling in copying data between two labs. Regards, Steve Thompson IS Build group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN "Email Firewall" made the following annotations. -- 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
Re: FTP "ERRORS" [was: RACF on an ADCD system]
If you want a simple tool to FTP files between z/OS LPARs and also between other platforms check out my ISPF dialog FTPBATCH ( http://www.lbdsoftware.com/ftpb223.zip) which will: prompt for from/to dataset if a PDS you can send the entire PDS or just selected members optionally invoke DFDSS to unload the dataset at the from and restore at the target runs either in batch or interactively optionally generates batch JCL so you can repeat the process without using the ISPF dialog Hope this helps Lionel B. Dyck <>< z Client Architect IBM Corporation - West IMT Mobile Phone: 1-925-207-4518 E-mail: lionel.d...@us.ibm.com System z: www-03.ibm.com/systems/z/ Linux on z: http://www-03.ibm.com/systems/z/os/linux/ Destination z: http://www-03.ibm.com/systems/z/destinationz/index.html/ "Think Inside the z Box" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP "ERRORS" [was: RACF on an ADCD system]
On Fri, 4 Jan 2013 18:19:05 +, Jerry Whitteridge wrote: >Long ago I found the following details and sent it to my team. You may find >the extra details useful: > > > > >Use the following to FTP a DFDSS Dump. > > > First, issue the QUOTE SITE command as follows, which will >assure the receiving file will have the proper DCB attributes... > > QUOTE SITE BLKSIZE=27998 LRECL=0 RECFM=U PRI=xxx SEC=xxx >TRACK > > Of course you much change the space parameters as necessary. >Then, >prior to issuing the actual PUT command, issue these commands. > > MODE B > EBCDIC > > Mode B tells FTP to use block mode transfers. > > The result is a file DFDSS likes! > > Sounds like a dump to disk, not tape. I recall trying tape with default blocksize and it didn't work. Even with LRECL=X - even though that works for me for VB SMF data with BLKSIZE > 32760.If I need to FTP a full volume dump from tape, I just use FDR with "FORMAT=SPLIT" to force a max blksize of 32K. But like you wrote, "MODE B" and "TYPE E" (or EBCDIC) is required regardless. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP "ERRORS" [was: RACF on an ADCD system]
Yes - that was dump to disk. As you say it was the Mode B and Type E that was significant Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 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 Mark Zelden Sounds like a dump to disk, not tape. I recall trying tape with default blocksize and it didn't work. Even with LRECL=X - even though that works for me for VB SMF data with BLKSIZE > 32760.If I need to FTP a full volume dump from tape, I just use FDR with "FORMAT=SPLIT" to force a max blksize of 32K. But like you wrote, "MODE B" and "TYPE E" (or EBCDIC) is required regardless. "Email Firewall" made the following annotations. -- 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
Re: FTP "ERRORS" [was: RACF on an ADCD system]
Steve, > I think I've been hitting the same thing between different IBM Labs > and levels of z/OS. And here I wasn't even sure if I should mention it. Just to clarify: *All* ftp transfers were done binary. Our ADCD system certainly does not have tape drives (does anyones'?), so all ftp went DASD to DASD, with the receiving dataset preallocated. I realize that having no tape drives doesn't mean the support wouldn't be in 1.13. It would most probably not be in 1.10, given how old that maintenance level was. (An ADCD system is not really equipped to apply maintenance.) I would subscribe to the code page thing (after all - we had enough trouble with that in our own product), but you say that that only applies to non-binary transfers - ours were all binary, of course. Thanks also to Jerry and Lionel - I will check out FTPBATCH! Might help us to get our nightly backups off of the providers' system. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on an ADCD system - was: Re: DFSMRCL0 usermod
Barbara,
Make sure your not missing a volume on the install. There were optional volumes
listed on the documentation at IBM
Scott ford
www.identityforge.com
Tell me and I'll forget; show me and I may remember; involve me and I'll
understand. - Chinese Proverb
On Jan 3, 2013, at 1:33 AM, ibmmain wrote:
>> In what classes and profiles? You can perhaps consolidate those profiles in
>> fewer and more generic profiles if you have time to do that.
>>
>> (I know you previously said that you are learning to work with RACF)
>
> I did that. I have about 20 jobs that completely rearrange RACF to something
> that is meaningful to me and allows better administration in my opinion.
> Just a few examples of the RACF database that comes with ADCD:
> CLASS(TSOAUTH): has permits for userids that don't exist in the database:
> LWH, TESTER, TESTEG, DSN1SPAS. Not to mention that every userid has its own
> permit - no group permits for groups of users. Anywhere, not just in this
> class.
> CLASS(TSOPROC): still has the DB2 V8 logon proc defined (DBSPROC8) - DB2 V8
> is not delivered in this ADCD anymore.
> Userid DB8GRFSH belongs to DB2 V8, which doesn't exist.
> A lot of address spaces are missing in the STARTED class - the default
> profile ** allows very high access to all system resources. For instance,
> there is no profile specifically for DB2 (no matter which release), they all
> start on the ** profile. There also are a ton of obsolete profiles in that
> class (lots of DCE* asids that don't get started).
> There are a lot of nongeneric DB2 dataset profiles from DB2 Version 7, which
> don't exist anymore (neither DB2 V7 nor those datasets).
> CLASS(DSNR): Again a lot of DB2 V7 and V8 related profiles in addition to V9
> and V10.
> Same for class(SERVER).
> CLASS(PROGRAM):
> RALTER PROGRAM * DELMEM('DSN810.SDSNLOD2')
> RALTER PROGRAM * DELMEM('DSN810.SDSNLOAD')
> RALTER PROGRAM * DELMEM('DSN810.SDSNEXIT')
> RALTER PROGRAM * DELMEM('DSN710.SDSNLOD2')
> RALTER PROGRAM * DELMEM('DSN710.SDSNLOAD')
> RALTER PROGRAM * DELMEM('DSN710.SDSNEXIT')
> RALTER PROGRAM * DELMEM('WAS401.SBBOLOAD')
> RALTER PROGRAM * DELMEM('BBO401.SBBOLOAD')
> None of those data sets exists anymore. There is neither DB2 V7 nor V8 (ups,
> I already said that) nor WAS V4.
> RDELETE PROGRAM BPXOV
> RDELETE PROGRAM BPXBINIT
> RDELETE PROGRAM BPXEV003
> RDELETE PROGRAM BPXOLVD
> RDELETE PROGRAM BPXPLPKA
> RDELETE PROGRAM BPXUCSNM
> RDELETE PROGRAM BPXUEYI1
> RDELETE PROGRAM BPXUI1EY
> RDELETE PROGRAM BPXZ24
> RDELETE PROGRAM RLOGIND
> I was unable to find these programs in the SMPE-defined libraries.
> CLASS(FACILITY): The WLM policy as delivered can only be administered by
> IBMUSER and a non-existent userid DPACK.
> There are two very obsolete groups still defined named SYSCTLG and VSAMDSET.
>
> At this point, I can almost rival a RACF admin. What I haven't touched are
> all these certificate things that come in upper and lower case.
> Barbara
>
> --
> 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: RACF on an ADCD system - was: Re: DFSMRCL0 usermod
And the DB2s are separately down-loadable from IBM-Dallas. So you can have DB2 V8 on 1.13. I agree that ADCD does not come with it directly, but it is available. Lloyd - Original Message From: Scott Ford To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, January 3, 2013 8:05:43 AM Subject: Re: RACF on an ADCD system - was: Re: DFSMRCL0 usermod Barbara, Make sure your not missing a volume on the install. There were optional volumes listed on the documentation at IBM Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
