IBM Mainframe Forum

I've been building REXX jobs to push access out from one system through system selection, but there's still a big need to verify the access. Any suggestions on how to verify that access without having to go out to that system? I want to start with dataset access, so my first step would be to verify whether the covering profile exists, or what the covering profile would be so I can clone it. I'm thinking the best bet would be LISTDSD and store it locally, then XMIT it back, but that wouldn't be seemless. Does anyone have any approaches of verifying a dataset profile's existance from another system?

Also, I need this information to be stored locally...If I can send a request for a covering profile, and store it locally, then I can pull it into a Stem, pull the covering profile, and spit it back out as a FGEN command to clone a new one, or just apply the access that is needed.

Thanks for the help in advance!

This is not a query that can be answered in this forum. Many installations use one RACF data base for all of their systems. They may also attempt to keep their data bases in sync, but if the RACF process works as well as the Top Secret process, well. don't bet on it. You must find out from your support what you should do.

Yes, this would be across multiple RACF databases. As far as working across these systems, I don't need help with that. Let's break it down into steps then.

1. Is there any way to store the data that is normally printed to screen from LISTDSD? there is the AT attribute, but I'm not sure of it's purpose/structure. It references AT('node'.hlq), but I've tried from other systems, and it doesn't recognize the other sys names.

2. Is there a syntax for RECEIVE that would keep it from prompting for dataset names when it attempts to store it locally?

1. The easiest way is to run the LISTDSD command in a batch job, with the output routed to a data set.
   Select all

   //        JOB  ...
   //        EXEC PGM=IKJEFT01
   //SYSTSPRT DD  DISP=OLD,DSN=...
   //SYSTSIN  DD  *
    LISTDSD DA(...) GENERIC AUTHUSER
   /*
   The GENERIC parameter is usually required if the actual profile is generic and you are giving LISTDSD a data set name. On the other hand if the data set is "covered" by a discrete profile, you won't get anything useful. It might be better to run LISTDSD twice, once with GENERIC, and once without GENERIC.
   
   A better solution might be to write SYSTSPRT to JES, route the output to your system and use your SDSF to create the data set.
   Select all

   //        JOB  ...
   //        EXEC PGM=IKJEFT01
   //SYSTSPRT DD  SYSOUT=...,DEST=your-system
   //SYSTSIN  DD  *
    LISTDSD DA(...) GENERIC AUTHUSER
   /*
2. Yes, but I don't know how to do it.

or...something I just read about...would IEBUPDTE be a better option? what would the syntax be? continuing to read about it, but any help would be great!

IEBUPDTE SYSUT1, SYSUT2 & SYSIN data sets specify card image data sets or PDS data sets defined with RECFM=Fx, LRECL=80. I don't see what good IEBUPDTE would do for you.

Yeah, it actually creates a dataset on the target system with the LD command as the contents instead of executing it...useful but not here. So what would the syntax be for //SYSTSPRT be if I want to direct it to XXXX.AUDIT? It won't already exist, so this is what I had, and then how I modified it:



Changed to:

I have to be close, but the SYSOUT=RJYW.AUDIT,DEST=DEV is not working...

Hello,

Maybe i'm missing something, but this:
//SYSTSPRT DD SYSOUT=RJYW.AUDIT,DEST=DEV
is like nothing i've seen before.


Suggest you try:
//SYSTSPRT DD DSN=RJYW.AUDIT,DISP=(CATLG,DELETE),blah, blah, blah

and have another step to IEBGENER it to the proper SYSOUT.

Then delete RJYW.AUDIT if it is no longer needed.

Maybe i'm missing something, but this:
//SYSTSPRT DD SYSOUT=RJYW.AUDIT,DEST=DEV
is like nothing i've seen before.

Is that JES3? I also am not familiar with it.