View previous topic :: View next topic
|
Author |
Message |
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
I have a requirement wherein I have to create GDG bases and flat files dynamically. That means the names of the GDG bases and flat files will be changed dynamically by a COBOL program and acordingly the GDG bases and flat files would be created.
Now via COBOL program I can create control cards for defineing GDG bases which will be used by a successor step in my JCL which will execute the IDCAMS utility. So defining GDG bases is done. But once it comes to creating a flat file then I dont think IDCAMS would help me or neither any other IBM utility. The reason being the file name is dynamically decided.
Can anybody suggets me a way via which I can realise this reqiuirement? |
|
Back to top |
|
|
ofer71
Global Moderator
Joined: 27 Dec 2005 Posts: 2358 Location: Israel
|
|
|
|
hmmmm.. what's wrong with TSO ALLOCATE command?
O. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Do the same sort thing for the files as the GDG bases. . .
Generate the needed jcl and submit this via the internal reader to be run as a new job rather than a successor step. |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
Need to check whether the use of INTRDR is allowed with my current client or not.
But via REXX also, can we allocate datasets with their space parameters, dataclas and disposition etc? |
|
Back to top |
|
|
ofer71
Global Moderator
Joined: 27 Dec 2005 Posts: 2358 Location: Israel
|
|
|
|
Yes, it could be done from REXX, as well as from within COBOL (using TSO services).
O. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
mlp wrote: |
But once it comes to creating a flat file then I dont think IDCAMS would help me or neither any other IBM utility. The reason being the file name is dynamically decided. |
Then obviously you have not taken the time to read the IDCAMS manual.
If you can generate control statements to allocate a GDG base, you can also generate the statements to allocate datasets.
I assume this is what you want to do as your original post is not specific. |
|
Back to top |
|
|
ofer71
Global Moderator
Joined: 27 Dec 2005 Posts: 2358 Location: Israel
|
|
|
|
But why adding steps if can get it all from within single REXX/COBOL?
O. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
Ofer, I prefer that way, as it leaves an easily followed audit trail of what the job has done. I have had cases where datasets were dynamically allocated within programs and hated following up the next JCL error for duplicate dsn.
If it's easy to follow it's easy to fix |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
Thanks for your help.
With IDCAMS ALLOCATE it is possible to allocate the flat file (PS). |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
Now there is a different problem.
I am doing more than 3000 dataset operations in one go via IDCAMS. It gives me below error.
IKJ56220I MAXIMUM NUMBER OF DATA SET ALLOCATIONS ALLOWED BY YOUR
IKJ56220I SESSION HAS BEEN REACHED, YOU SHOULD FREE UNUSED DATA SETS
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
I specified DYNAMNBR=3273 (maximum) at the IDCAMS step, but it gives me MAXCC 12 after 10 dataset operations.
When I specify DYNAMNBR=500 then it processes more dataset operations. I am not getting why the DYNAMNBR=500 processing more operations than that of the maximum DYNAMNBR (3273).
I need to decide the maximum number of dataset operations those can be executed by IDCAMS without MAXCC 12 (with success). So what can be the value of DYNAMNBR parameter that can be used over here?
Also, if there is any other option then please let me know. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Are you running IDCAMS in a TSO session? |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
No. I am executing IDCAMS via a JCL. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
So why the IKJ messages?
A TSO batch job? |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
Yes a TSO batch job and it gave me these messages in the SYSPRINT. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
My idea is feeding 3000 datasets to idcams to be allocated dynamically
is a bit to much for the batch session. Idcams doesnt do a free for those datasets. Maybe you could do loop to run idcams multiple times for a certain amount of datasets. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Why does someone believe it is proper to allocate 3000+ datasets at one time. . . |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
Instead of invoking IDCAMS from a batch TSO environment, run IDCAMS directly as a utility program. Your error is due to limitations set in your installation's TSO adress space definitions. |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
Are you trying to say that I should invoke IDCAMS from COBOL prog?
If that so, can anybody provide me the interface of IDCAMS? So that I can incorporate the same in my COBOL module. |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
mlp wrote: |
Are you trying to say that I should invoke IDCAMS from COBOL prog?
If that so, can anybody provide me the interface of IDCAMS? So that I can incorporate the same in my COBOL module. |
That was not what I meant.
You stated in an earlier post that you were running IDCAMS in a batch environment, but from the error messages we could tell that you were running TSO (EXEC PGM=IKJEFTxx).
I merely suggested that your JCL should execute IDCAMS directly, with EXEC PGM=IDCAMS.
I am mistaken, please provide more details on the IDCAMS execution, like your JCL. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Running IDCAMS in a batch TSO session suggests to me that the TS
creates the input for IDCAMS (by Rexx/CLIST). So thats why i stated
in a previous comment, to divide the IDCAMS input in parts and execute
IDCAMS in a loop for all those parts. So after termination of every IDCAMS call the necessary de-allocations will be done. |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
I came to know that I can execute maximum 400 allocation of datasets via IDCAMS in one go in current mainframe TSO session. So as above post suggets, I am going to break the large number of allocations into multiple small number of allocations.
Thaks for the help. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
it would be nice to know how You did determine the 400!
what abend/message(s) did You get ? |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
It was with trial and error method and I found out that the limit is DYNAMNBR = 500 (476 to be specific). So if I feed the control card with say 600 dataset allocation instructions to IDCAMS then on 476th Instance I get the errors in sysprint.
IKJ56220I MAXIMUM NUMBER OF DATA SET ALLOCATIONS ALLOWED BY YOUR
IKJ56220I SESSION HAS BEEN REACHED, YOU SHOULD FREE UNUSED DATA SETS
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
So to be on safer side I have kept the DYNAMNBR as 400 in my JCL now. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
it would be nice to review the general understanding and interpretation of allocation
allocation is commonly used to describe different situations
1) allocate as build the control blocks chain that lets a program access a dataset thru a ddname
2) allocate as reserve some space on dasd storing into the relevant system dataset ( VTOC, CATALOGs ) the related info
case one has specific and documented limitations
case two has none if things have been done properly
( it behaves for a short instant as 1 )
if the issue is related to allocate as in 1[+2] then restrictions apply
otherwise after each allocation free the related ddname and You will have none |
|
Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005 Posts: 91
|
|
|
|
Follwoing is the sequence of control statements which are being executed via IDCAMS.
1) DEFINE GENERATIONDATAGROUP
2) DEFINE GENERATIONDATAGROUP
3) DEFINE GENERATIONDATAGROUP
4) DEFINE GENERATIONDATAGROUP
5) ALLOC DSNAME
6) REPRO using above allocated dataset
6) ALLOC DSNAME
7) REPRO using above allocated daatset
These statements are getting repeated for different datasets. Also before each "set" I am deleting each dataset (4 GDG bases and 2 PS datsets) using DELETE.
So I am allocating datasets using ALLOC DSNAME which is fed to IDCAMS and there is no DDNAME association. So I think 2nd option is applicable over here. |
|
Back to top |
|
|
|