Alternatives to INCLUDE=MEMBER statement



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Alternatives to INCLUDE=MEMBER statement

Postby jcllearner5 » Sat Jan 23, 2016 1:09 am

Hi,

Do we have any Alternatives to 'INCLUDE=MEMBER' statement that can be used in JCL to pass dataset names dynamically? Here is my problem.

I trigger a job to read IMS log files whenever an IMS log dataset is created. This job could run anywhere from 60 to 100 times in a day depending on how many IMS log datasets are created on any given day.

In Step1, I run IDCAMS to extract specific cataloged datasets and isolate the latest dataset and store it in a PDS member named 'XXXX' to be used as an INCLUDE MEMBER.
In Step2, I use INCLUDE MEMBER=XXXX in the place of INPUT DD statement to read that IMS log dataset and create an output dataset by just changing the HLQ of the original IMS log file.

What happens is the IMS log dataset name from the current execution of job gets stored in XXXX member but is only passed to the Job in the next run. This is causing problems some times when my job gets triggered but do not run immediately. Due to this some jobs try to read the same log file and create the same output dataset and fail.

Are there any Alternatives to INCLUDE=MEMBER statement? How can we pass the same log dataset name to another step as INPUT in the same execution of job without using INCLUDE statement?

Any help is greatly appreciated.
jcllearner5
 
Posts: 3
Joined: Sat Jan 23, 2016 12:21 am
Has thanked: 0 time
Been thanked: 0 time

Re: Alternatives to INCLUDE=MEMBER statement

 

Re: Alternatives to INCLUDE=MEMBER statement

Postby Akatsukami » Sat Jan 23, 2016 4:09 am

Two methods come to mind (I do not say that there are not others):

  1. Place the DSN in a non-JCLLIB data set in step 1; in step 2, read it and dynamically allocate the data set
  2. In step 1, write the JCL with the DSN incorporated in it to the INTRDR as a separate job .
"You have sat too long for any good you have been doing lately ... Depart, I say; and let us have done with you. In the name of God, go!" -- what I say to a junior programmer at least once a day
User avatar
Akatsukami
Global moderator
 
Posts: 1051
Joined: Sat Oct 16, 2010 2:31 am
Location: Bloomington, IL
Has thanked: 6 times
Been thanked: 51 times

Re: Alternatives to INCLUDE=MEMBER statement

Postby NicC » Sat Jan 23, 2016 4:49 am

The reason you get what you get is because the JCL is interpreted in its entirety at submission time so the member is included at that time. You could do either of wht Akatsukami suggests or you could split your job after the first step so that step 2 gets submitted after that first step completes.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2681
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 102 times

Re: Alternatives to INCLUDE=MEMBER statement

Postby jcllearner5 » Sat Jan 23, 2016 8:20 pm

Thanks Akatsukami and Nic for your responses. I would like to go with option 1 suggested by Akatsukami i.e Place the DSN in a non-JCLLIB data set in step 1; in step 2, read it and dynamically allocate the data set.

Any idea how I can do so? I tried to use temp datasets to store the desired dynamic dataset name and allocate it in the following steps but it did not work. I would like to it in the same run of the job.
Any suggestions would be helpful and appreciated.

Thank You.
jcllearner5
 
Posts: 3
Joined: Sat Jan 23, 2016 12:21 am
Has thanked: 0 time
Been thanked: 0 time

Re: Alternatives to INCLUDE=MEMBER statement

Postby Robert Sample » Sun Jan 24, 2016 1:48 am

I tried to use temp datasets to store the desired dynamic dataset name and allocate it in the following steps but it did not work. I would like to it in the same run of the job.
As pointed out earlier, JCL goes through the converter / interpreter process when the job is read into the system. Hence it is not possible for you to modify the JCL of an executing job, under any circumstances, ever. So if you expect to have JCL to allocate a dynamic data set DD statement in the same job, that's not going to happen. You could write a program using the language of your choice to use BPXWDYN to dynamically allocate a data set (which does not require a DD statement in the JCL) and access it that way. However, if you insist on having a DD statement, you have no choice but to submit a job through the internal reader that contains the DD statement.
Robert Sample
Global moderator
 
Posts: 3354
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 219 times

Re: Alternatives to INCLUDE=MEMBER statement

Postby jcllearner5 » Mon Jan 25, 2016 2:37 am

Thanks Robert. Yes, I indeed need a DD statement in the JCL. So, from all of the responses from the experts I understand that I can not even use BPXWDYN for my process. Looks like my only option is to use the internal reader.
jcllearner5
 
Posts: 3
Joined: Sat Jan 23, 2016 12:21 am
Has thanked: 0 time
Been thanked: 0 time

Re: Alternatives to INCLUDE=MEMBER statement

Postby Robert Sample » Mon Jan 25, 2016 5:17 am

BPXWDYN works great. However, it does not use a DD statement in JCL but allocates dynamically. So for your requirement you will have to submit another job to the internal reader.
Robert Sample
Global moderator
 
Posts: 3354
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 219 times


Return to JCL

 


  • Related topics
    Replies
    Views
    Last post