How to complete a mass datadictionary update for multiple IDEAL users' access change

[David Butler]

I am creating a Production clone environment that I wish then to change to access levels for some of our IDEAL users (specifically Application Programmers) to allow development work to take place there. In Production they have read access to the IDEAL systems but in development they have update access for most / control access for some. The only way I can see to do this is to run a large batch job as per below example.

 

000031 +UPD PERSON,AP9XY1(PROD)

000032 1003 UNRL,SYSTEM,BATCH-DATA-TRAN(PROD),PER-SYS-ACCESS

000033 1003 RELT,SYSTEM,BATCH-DATA-TRAN(PROD),PER-SYS-ACCESS

000034 1003 DATA,BD4#

000035 -END

 

000055 +UPD PERSON,AP9XY1(PROD)

000056 1003 UNRL,SYSTEM,DIRECT-PRD(PROD),PER-SYS-ACCESS

000057 1003 RELT,SYSTEM,DIRECT-PRD(PROD),PER-SYS-ACCESS

000058 1003 DATA,DR4#

000059 -END

 

Can you suggest a better way of doing this as it stands it's almost 100 lines of datadictionary updates per user id I need to run it for (50-100 users). This issue here is that this will not be a once off run but likely a process that will need to be run on multiple environments, be maintained as users come and go so would like something similar/smarter if possible.

[Don Johnson]

Hi David, I am searching for a better answer here, but one thing you could do to shorten the input file is to group all the activity for a user together in a single update, rather than have each as a separate command. It will run a little faster, too, as there will be less processing.

 

For example, you could group all the un-relates together for a user, and all the relates, like this:

-COM ---------------------------------------------------- AP9XY1
+UPD PERSON,AP9XY1(PROD)
-COM --------------------> UNRELATE <-------------------
1003 UNRL,SYSTEM,BATCH-DATA-TRAN(PROD),PER-SYS-ACCESS
1003 UNRL,SYSTEM,DIRECT-PRD(PROD),PER-SYS-ACCESS
-COM --------------------> RELATE <-------------------
1003 RELT,SYSTEM,BATCH-DATA-TRAN(PROD),PER-SYS-ACCESS
1003 DATA,BD4#
1003 RELT,SYSTEM,DIRECT-PRD(PROD),PER-SYS-ACCESS
1003 DATA,DR4#
-END

 

Or, you could group each system together in the same manner you had above, but all in the same UPD, like this:

-COM ----------------------------------------------------- AP9XY1
+UPD PERSON,AP9XY1(PROD)
-COM -------------------------------------- BATCH-DATA-TRAN
1003 UNRL,SYSTEM,BATCH-DATA-TRAN(PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,BATCH-DATA-TRAN(PROD),PER-SYS-ACCESS
1003 DATA,BD4#
-COM -------------------------------------- DIRECT-PRD
1003 UNRL,SYSTEM,DIRECT-PRD(PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,DIRECT-PRD(PROD),PER-SYS-ACCESS
1003 DATA,DR4#
-END

 

This will save you some lines, and the comments make it easier to see. 

 

As I find more information, I will let you know.

[Don Johnson]

Hi David, I have discussed this with our R&D team, and there does not appear to be any other way to easily accomplish this. You might be able to group some of the input records into separate PDS members so they can be reused (like the UNRL, RELT and DATA for a single system), but overall, the process to use DDUPDATE is how they will all be processed.

[David Butler]

Hi Don,

 

I've tried the suggestions about but I don't get the same results (despite appearing to process okay), the test id I ran them against in both methods didn't get updated. However the answer is still correct as running the ddupdate statements as I did before so this is still the approach I have to take.

 

We will look to create a program that will generate the JCL dynamically for each user in an input file and run the ddupdate statements (also stored in another dataset). That way I think as new systems get added or new users we just have to update two different datasets instead of maintaining x numbers of JCLs themselves.

 

Thanks for looking at this,

David

[Don Johnson]

Hi David, I am concerned that this did not work correctly for you. I tested it a few different ways on both PROD and test version (0003)  users, and all tests were successful.

Some things to check (as these happened to me on my first pass):

* Be sure the -UPD PERSON is correct with the Person name from Datadictionary, and with the correct version

* Be sure your relationship is using PROD status with PER-SYS-ACCESS

* Be sure that the value for the DATA record is correct and in the correct column - the IDEAL short ID is in columns 11-13, and the access value is in 14. If you need the reference for these access values, please refer to the CA Ideal documentation for Defining and Maintaining Users.

 

If you do not see the problem right away. feel free to open a support case and we can dig into it further. For verification of my changes, I ran my job in 3 steps:

1. Ideal Display of the user to be updated

2. DDUPDATE process of transactions

3. Ideal Display of the user that was updated

If you open a case, please run something like this so we can verify the before/after against the DDUPDATE results.

 

Here are the tests I ran:

1. With each system as a separate set of transactions in a separate -UPD

2. With one -UPD and each system's UNRL and RELT together

3. With one -UPD and all the UNRL transactions followed by all the RELT/DATA transactions

 

This is what the three tests looked like (I replaced the unprintable access character with a lowercase "x"):

//SYSIN DD *
-USR DATACOM-INSTALL,NEWUSER
-COM ------- EACH SYSTEM SEPARATELY
-COM HERE > < IS THE HEX BYTE FOR AUTHORIZATION
-UPD PERSON,JOHNSON (PROD)  or (0003)
1003 UNRL,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 DATA,$IDx
-END
-UPD PERSON,JOHNSON (PROD)  or (0003)
1003 UNRL,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 DATA,S01x
-END
-UPD PERSON,JOHNSON (PROD)  or (0003)
1003 UNRL,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 DATA,S02x
-END
/*


//SYSIN DD *
-USR DATACOM-INSTALL,NEWUSER
-COM ------ EACH SYSTEM, ALL GROUPED
-COM HERE > < IS THE HEX BYTE FOR AUTHORIZATION
-UPD PERSON,JOHNSON (PROD) or (0003)
-COM -------------------------------
1003 UNRL,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 DATA,$IDx
1003 UNRL,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 DATA,S01x
1003 UNRL,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 DATA,S02x
-END
/*


//SYSIN DD *
-USR DATACOM-INSTALL,NEWUSER
-COM ------ ALL UNRELATES THEN RELATES
-COM HERE > < IS THE HEX BYTE FOR AUTHORIZATION
-UPD PERSON,JOHNSON (PROD) or (0003)
1003 UNRL,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 UNRL,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 UNRL,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
-COM -------------------------------
1003 RELT,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 DATA,$IDx
1003 RELT,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 DATA,S01x
1003 RELT,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 DATA,S02x
-END
/*

[David Butler]

Hi Don,

Thanks again for all that I replicated your tests and I managed to find out what the issue was....with some luck!

In my test I was trying to unrel a user from a system they did not already have a relationship with in the first place.

So with the first syntax below (where you issue the update and end for each single system to user), if "Johnson" didn't already have a relationship with the $IDEAL system it continues on and takes care of the update for the SYSTEM1 and so on. However using the other two syntax examples, if the relationship doesn't exist with the first system in the list (as was in the case in my test) then all other subsequent ddupdates are ignored. It makes sense that it behaves like that but it should give an error or warning in that case if it can but it gave the successfully processed message...however I could see the output it was missing the statements that show the changes being carried out.

 

-UPD PERSON,JOHNSON (PROD)  or (0003)
1003 UNRL,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 DATA,$IDx
-END
-UPD PERSON,JOHNSON (PROD)  or (0003)
1003 UNRL,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 DATA,S01x
-END
-UPD PERSON,JOHNSON (PROD)  or (0003)
1003 UNRL,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 RELT,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 DATA,S02x
-END

 

My resolution has been to complete a tidyup of the user access for the set of users that I am looking to carry out the mass update of so I can apply the same set of ddupdates against using this form of the syntax.

I am storing similar to the below in dataset so I only have one dataset to maintain but can apply it easily to many systems.

 

//SYSIN DD *
-USR DATACOM-INSTALL,NEWUSER
-COM ------ ALL UNRELATES THEN RELATES
-COM HERE > < IS THE HEX BYTE FOR AUTHORIZATION
-UPD PERSON,JOHNSON (PROD) or (0003)
1003 UNRL,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 UNRL,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 UNRL,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
-COM -------------------------------
1003 RELT,SYSTEM,$IDEAL (PROD),PER-SYS-ACCESS
1003 DATA,$IDx
1003 RELT,SYSTEM,SYSTEM1 (PROD),PER-SYS-ACCESS
1003 DATA,S01x
1003 RELT,SYSTEM,SYSTEM2 (PROD),PER-SYS-ACCESS
1003 DATA,S02x
-END
/*

[Don Johnson]

HI David, I wanted to let you know that I have contacted our R&D team about the lack of an error message for the notfound relationship record, and about the flushed input with no message, and they will be looking into it further to determine if a program modification is needed.

[David Butler]

Thanks Don!

[David Butler]

Hi Don,

 

I might open a call for this but will ask here first just in case you are free to pick it up again. I am unsure what value I need to put in place to change a user's access in batch from "UPDATE" to "READ and RUN-PROD". When setting the access to UPDATE I use the # character for the access byte.

 

Example below:

 

000053 1003 RELT,SYSTEM,BATCH-PRD(PROD),PER-SYS-ACCESS

000054 1003 DATA,BT4x

 

What value should x be?

The guides list the following:

 

/--- AUTH IN SYS: TYPE:             HEX   CHAR

|                 ---------------   ---   ----

|                 CTL + RUN-PROD     F3     3

|                 CTL                            E3     T

|                 UPD + RUN-PROD    7B     #

|                 UPD                            6C     %

|                 READ + RUN-PROD  30      

|                 READ                          20      

|                 RUN-PROD                10    

 

Also can I remove DVW admin access via batch, it is added by the below?

000025 -UPD PERSON,AP9TS1(PROD)

000026 1010 ADD ££ID-DVW

000027 -END

 

But is there an option to remove this via the same method, I want to change the user back to being a simple IDEAL user (££ID-USE).

[Don Johnson]

In the section of the manual just above the sample you listed, the bit settings show each of the accesses you need to use (combined together as appropriate). For example, Update access would have x'40' (or x'43' for Update and Update-panel and update-report). To have read and run-prod, you would need x'30' for the access byte. Here is the full list again:

 
1... .... - Control
.1.. .... - Update
..1. .... - Read
...1 .... - Run-Prod
.... 1... - Not Used
.... .1.. - Not Used
.... ..1. - Update-Report
.... ...1 - Update-Panel

 

In your sample, the use of # is x'7B', which indicates Update, Read, Run-Prod, Update-Report, and Update-Panel. As you can see, you have great flexibility to set the levels as you want them.

 

For the authorization, please try these under the UPD transaction set.

1003 UNRL,AUTHORIZATION,$$ID-DVW(PROD),PER-ATZ-AUTH

1003 RELT,AUTHORIZATION,$$ID-USE(PROD),PER-ATZ-AUTH

[David Butler]

So trying that Don

 

1003 UNRL,AUTHORIZATION,$$ID-DVW(PROD),PER-ATZ-AUTH

1003 RELT,AUTHORIZATION,$$ID-USE(PROD),PER-ATZ-AUTH

 

Works well, I only need to issue the UNRL for the DVW access and no need to additional relate as the user is already an IDEAL user.

Not making much progress on the authorization byte, converting x30 to ASCII that gives me 0 (https://www.rapidtables.com/convert/number/hex-to-ascii.html) as the character to use.However when I run the RELT with 0 as the authorization byte the actual effect gives the user Control, Update, Read and Run-Prod access as opposed to Read and Run-Prod.

Testing with x20 for the access byte (leave a blank spaced based on the conversion) which should do Read access (only) it gives the user Update access only.

 

 

 

 

[Don Johnson]

David, if your ASCII value of x'30' is a numeric zero, then yes, when converted to EBCDIC, zero becomes x'F0' which will give you all four bits in the top nibble as you saw. The ASCII x'20' (space) becomes EBCDIC x'40' (space), which is only the Update.

 

If you are converting from EBCDIC x'30' to the appropriate ASCII value, bear in mind that there are multiple code pages involved, and the results could be different for different pages. The hex value I gave you earlier is the EBCDIC value expected in the DDUPDATE input. I am not sure why you need to work in ASCII on this mainframe EBCDIC JCL, but whenever you deal with this sort of conversion, it is very difficult, and your only sure alternative might be to create the 1003 Data records programmatically on the mainframe, or to have pre-defined records there with the values you want.

[David Butler]

Hi Don,

 

I got sorted with this one now, once I went into hex mode and entered 30 as I wanted and it is working perfectly now. I was making the mistake of trying to convert the value myself instead of letting the mainframe do the work with the hex value.

Thanks for your assistance here!

 

Regards,

David