Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Mon Oct 22, 2018 5:36 am Post subject: Dynamically allocating/freeing DL/1 DB
Not sure if this can even be done, but I'll explain the background first.
Due to GDPR requirements here in Europe, we have to log any access to production databases (eg, when copying a specific insurance policy from prod to a private database).
Private databases always have the same naming standard, 'userid.DIALDBDT.DBNAME' (where DBNAME is the database name). Every time the user/developer copies from prod, we log this in a DB2 table.
Every so often (14 days or so), the idea is to loop through this table and delete copied prod data from the private databases (WITHOUT deleting other segments). For example, as usera, I might copy prod ID's 10 and 20, and userb might copy ID's 20 and 30.
The program so far reads the DB2 table, allocates the 'userid.DIALDBDT.DBNAME' databases and calls an existing program (progB) that then deletes all ID's created in a file (for userA 10 & 20, for userb, 20 & 30).
The program works fine first time round for usera inasmuch as usera's databases are allocated as SHR, progB is called that reads the databases and processes them.
My problem is that I can never loop round and process userb. I try freeing usera's databases (after the call to progb) via a simple free dd(DBNAME) but I get bpxwdyn return code 69206016 (hex 0420 0000) which according to the manual is
Quote:
0420 Meaning: Specified ddname or dsname associated with an open data set. (ddname allocation, concatenation, deconcatenation, unallocation, dsname allocation)
My question is, is there any way of "closing/releasing" the existing DL/1 databases (yes, I realize that "closing" a DL/1 database is a bit of an oxymoron). _________________ Michael
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
Posted: Mon Oct 22, 2018 8:13 am Post subject:
misi01,
Why not schedule a batch job that every runs every other week ( twice/thrice in a month) which unloads the private database and then run thru a utility to drop off all the unwanted records and then reload it back? _________________ Kolusu
www.linkedin.com/in/kolusu
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Mon Oct 22, 2018 9:13 am Post subject:
That could work but would be rather kludgy (IMHO).
One of the main arguments against it would be the fact that there already exists a program that deletes the segments in the databases.
I supose one way to do it would be to have the various databases allocated with a variable as the HLQ, something like
Code:
//DAA01 DD DISP=SHR,DSN=&HLQ..DIALDBDT.DAA01
and then run the JCL with user1, user2, user3 etc etc as &HLQ. That way, the loop would be based on the JCL rather than within the cobol program.
(I suppose one way to do it would be to use Rexx to access the DB2 table, extract the unique userids that need to be cleaned up, and then simply create the JCL via skeletons and submit each one. That way, you're using the existing program without doing more work than necessary, as well as never having to change anything if a new userid comes along.)
I'll look into that variation. _________________ Michael
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Wed Oct 24, 2018 5:44 am Post subject:
Thought I'd update our resulting solution.
We went with a Rexx script that reads the DB2 table sorted on userid. For each unique userid, the script creates a file containing the arguments needed for the program to run, allocates a skeleton, creates the JCL and then submits the job that reads the file and processes it..
That way, we have one job per unique userid selected from the DB2 table.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
