View previous topic :: View next topic
|
Author |
Message |
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Hi All,
I am using SDSF REXX to retrieve the return code of the job submitted through REXX. But when giving display for the ISFROWS it returns 0 value due to which the loop is not processed. i got the sample code from websites and wrote as using SDSF with REXX is new to me. some please help me why is that ISFROWS is returning 0 when there are jobs in the spool.
please see the code which i have used:
Code: |
"SUBMIT '"DSN"' " /* DSN holds the JCL that is submitted */
RC=ISFCALLS("ON")
ISFOWNER = 'JOB*'
ISFPREFIX = 'JOBID*'
ADDRESS SDSF "ISFEXEC ST"
IF RC <> 0 THEN
EXIT RC
FIXEDFIELD = WORD(ISFCOLS,1)
SAY "NUMBER OF ROWS RETURNED:" ISFROWS
DO IX =1 TO ISFROWS
SAY "NOW PROCESSING JOB:" VALUE(FIXEDFIELD"."IX)
DO JX = 1 TO WORDS(ISFCOLS)
COL = WORD(ISFCOLS,JX)
SAY "COLUMN" COL"."IX "HAS THE VALUE:" VALUE(COL"."IX)
END
END
RC=ISFCALLS('OFF')
|
Kindly help me in solving this problem....
Thanks in advance |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
From your code, you seem to be looking for a job with name "JOBID*' submitted by owner "JOB*" . Are these the names of the job(s) and the job owner(s) you want to process? These look very like the names of the SDSF fields you are expected to populate with values rather than the values you should be supplying.
Garry. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
From your code, you seem to be looking for a job with name "JOBID*' submitted by owner "JOB*" . Are these the names of the job(s) and the job owner(s) you want to process? These look very like the names of the SDSF fields you are expected to populate with values rather than the values you should be supplying.
Garry. |
Hi,
I am not aware of the use of PREFIX and OWNER in this code....I thought that its just way of defining that it has prefix and owner....now the use of that...But as per my need OWNER can be any one whoever runs the rexx program and prefix also the same case. So i tried giving ISFPREFIX = ' ' and ISFOWNER = ' ' but i get error like "REXX SERVICE IRXEXCOM FAILED, Return code FFFFFFFE, reason 00000000. "
Can you tell how to solve this issue what value should I define for PREFIX and OWNER....? |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
If you supply ISFPREFIX = '*' and ISFOWNER = userid(), you would get returned every job submitted by the current REXX user. If the jobname is the userid followed by some character, you set ISFPREFIX = userid() ¦¦ '*'.
You are getting the error because SDSF expects some value in the fields, not nulls.
Garry. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
If you supply ISFPREFIX = '*' and ISFOWNER = userid(), you would get returned every job submitted by the current REXX user. If the jobname is the userid followed by some character, you set ISFPREFIX = userid() ¦¦ '*'.
You are getting the error because SDSF expects some value in the fields, not nulls.
Garry. |
Thanks a lot...code is working fine now....and one more thing, like now all the jobs that are submitted in my userid is retrieved. Is there a way to get the job which is submitted latest. can we obtain that through JOB ID that is created when submitting the job.....? Also I just cannot take the last row because some user might have sorted the spool based on Return code and other might be based on JOBID ....so suggest me any other way please.... |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
You can set ISFFILTER to the JobID value obtained when submitting the job e.g. ISFFILTER = submitted_jobid_returned.
Have you googled/read the IBM Redbook "Implementing REXX Support in SDSF" ?
Garry. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
You can set ISFFILTER to the JobID value obtained when submitting the job e.g. ISFFILTER = submitted_jobid_returned.
Have you googled/read the IBM Redbook "Implementing REXX Support in SDSF" ?
Garry. |
Hi Garry,
I tried with ISFFILTER Like below and I am getting command failed messages without displaying anything.
Code: |
CALL OUTTRAP(P.)
"SUBMIT '"DSN"' "
CALL OUTTRAP(OFF)
FRSTPOS = POS('(',P.2)
JOBNUM = SUBSTR(P.2,(FRSTPOS+1),8)
RC=ISFCALLS("ON")
ISFOWNER = USERID()
ISFPREFIX = USERID()||'*'
ISFFILTER = JOBNUM
ADDRESS SDSF "ISFEXEC ST"
IF RC <> 0 THEN
EXIT RC
SAY "NUMBER OF ROWS RETURNED:" ISFROWS
DO IX =1 TO ISFROWS
SAY WORDS(ISFCOLS)
DO JX = 1 TO WORDS(ISFCOLS)
JBN = WORD(ISFCOLS,3)
RTC = WORD(ISFCOLS,20)
SAY "JOB NUMBER:" JOBNUM
SAY "VALUE OF JOB:" VALUE(JBN"."IX)
IF JOBNUM = VALUE(JBN"."IX) THEN
DO
SAY "MATCHED WITH" VALUE(JBN"."IX)
IF VALUE(RTC"."IX) == 0 THEN
DO
SAY "RETURN CODE PASSED"
CALL ANALYSERPT
END
ELSE DO
SAY "JOB SUBMITTED HAS RETURN CODE" VALUE(RTC"."IX)
EXIT
END
END
END
END
RC=ISFCALLS('OFF')
RETURN
|
Should it be JOB NUM or JOBID for ISFFILER.... I tried giving both but the message COMMAND FAILED is returned with displaying anything execution is stopped. Can ou let me know why is it occuring. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
I did a cut&paste of your code and ran in debug (trace = ?r). I added in some say statements - say p.0; say p.1; say p.2 and found the jobname/jobid is returned in p.1, not p.2 . When I changed to
Code: |
JOBNUM = SUBSTR(P.1,(FRSTPOS+1),8) |
I got the correct JobID.
You should set
Code: |
ISFFILTER = 'JobID EQ '¦¦JOBNUM |
The command takes the same format as if you were entering "FILTER JobID EQ JOBnnnnn" in SDSF panels.
Garry. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
I did a cut&paste of your code and ran in debug (trace = ?r). I added in some say statements - say p.0; say p.1; say p.2 and found the jobname/jobid is returned in p.1, not p.2 . When I changed to
Code: |
JOBNUM = SUBSTR(P.1,(FRSTPOS+1),8) |
I got the correct JobID.
You should set
Code: |
ISFFILTER = 'JobID EQ '¦¦JOBNUM |
The command takes the same format as if you were entering "FILTER JobID EQ JOBnnnnn" in SDSF panels.
Garry. |
I tried my code with the ISFFILTER as you mentioned and now it returns the job which is submitted and the ISFROWS value is now 0... That should be 1 right why is that it is displaying the 0 value and ISFROWS display the rows starting from the jobs submitted and now since we have filtered with jobid that is submitted it show 1 right....?
Code: |
RC=ISFCALLS("ON")
ISFOWNER = USERID()
ISFPREFIX = USERID()||'*'
ISFFILTER = 'JOBID EQ'||JOBNUM
ADDRESS SDSF "ISFEXEC ST"
IF RC <> 0 THEN
EXIT RC
COLS = WORDS(ISFCOLS)
JBN = WORD(ISFCOLS,3)
RTC = WORD(ISFCOLS,20)
SAY "JOBNUMBER & RETURN CODE" JBN RTC
IF VALUE(JBN"."1) = JOBNUM THEN
DO
IF VALUE(RTC"."1) = 0 THEN
DO
SAY "RETURN CODE PASSED"
CALL ANALYSERPT
END
ELSE DO
SAY "JOB SUBMITTED HAS RETURN CODE" VALUE(RTC"."IX)
EXIT
END
END
RC=ISFCALLS('OFF')
|
I think the ISFROWS is not taking the job that is submitted that is why is it is showing 0...But why is that happening....even before using the filter all the jobs are taken in the ISFROWS but the job that is currently submitted was not taken.... |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1742 Location: Tirupur, India
|
|
|
|
Hello,
Could you try including
ISFSYSNAME = '*'
So that all the systems with shared JES are included. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
vasanthz wrote: |
Hello,
Could you try including
ISFSYSNAME = '*'
So that all the systems with shared JES are included. |
Even then the above mentioned scenario exists. ISFROWS remains 0. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
I seem to find isfrows = 0 where ISFFILTER is used, but don't see that documented (yet). Without the ISFFILTER, I get isfrows set > 0.
I've put in
Code: |
ISFCOLS = "JNAME JobID DDNAME TOKEN" |
before the
Code: |
ADDRESS SDSF "ISFEXEC ST " |
and can check:
Code: |
if jname.0 ¬= 0
then do i = 1 to jname.0
say 'isfrows = ' isfrows
say jobid.i
end |
I can then compare jobid.i with the value saved from job submission. Once you have that, to get into the JESMSGLG dataset, you will need to use ISFACT e.g.
Code: |
Address SDSF ,
"ISFACT DA TOKEN('"token.i"') PARM(NP ?) " ,
" (ALTERNATE DELAYED PREFIX J_)" |
This returns isfrows2 which you can control a loop to find JESMSGLG (or whatever sdsf ddname available). Then you can read in the file and look for the values (cond codes). - see pages 91/92 of the Redbook.
Hope this helps.
Garry. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
I seem to find isfrows = 0 where ISFFILTER is used, but don't see that documented (yet). Without the ISFFILTER, I get isfrows set > 0.
I've put in
Code: |
ISFCOLS = "JNAME JobID DDNAME TOKEN" |
before the
Code: |
ADDRESS SDSF "ISFEXEC ST " |
and can check:
Code: |
if jname.0 ¬= 0
then do i = 1 to jname.0
say 'isfrows = ' isfrows
say jobid.i
end |
I can then compare jobid.i with the value saved from job submission. Once you have that, to get into the JESMSGLG dataset, you will need to use ISFACT e.g.
Code: |
Address SDSF ,
"ISFACT DA TOKEN('"token.i"') PARM(NP ?) " ,
" (ALTERNATE DELAYED PREFIX J_)" |
This returns isfrows2 which you can control a loop to find JESMSGLG (or whatever sdsf ddname available). Then you can read in the file and look for the values (cond codes). - see pages 91/92 of the Redbook.
Hope this helps.
Garry. |
Hi,
While comparing the jobid.i with the jobid number obtained from submission it doesnt match with any of the jobid.i as the last submitted job in the spool is not taken by isfrows. I changed my code in many and displayed it but no use the latest submitted job row was not taken by isfrows.... |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
search the forum for may SDSF REXX snippets. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
On reflection , while this exercise in accessing SDSF from REXX may have some merit, a routine such as this should NEVER be released for use. If the routine submits a job and then keeps executing until the job has ended so it can check return codes &c, it would be extremely wasteful of resources.
If run from a TSO session, it will not only consume CPU wastefully - it will also lock the TSO session, preventing the user from doing productive work.
Garry |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1742 Location: Tirupur, India
|
|
|
|
Quote: |
On reflection , while this exercise in accessing SDSF from REXX may have some merit, a routine such as this should NEVER be released for use. |
I completely agree with Garry, I have been looking at the little technicalities of things and missed the whole picture of waiting for a batch job to complete while the session is locked up on a REXX.
I believe this is one of things that could be done, but should not be done. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
If run from a TSO session, it will not only consume CPU wastefully - it will also lock the TSO session, preventing the user from doing productive work.
Garry |
I dint find any other option other than this as the job should be executed at the background. I have used ISFACT to get the return code and now it is working fine. Also I have used rexx sleep manually for 5 like
Code: |
ADDRESS SYSCALL
"SLEEP" 5
|
but sometimes the job might take long time to execute. As i dint find anyother option i used this. Do you have any idea about this....? |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
vasanthz wrote: |
Quote: |
On reflection , while this exercise in accessing SDSF from REXX may have some merit, a routine such as this should NEVER be released for use. |
I completely agree with Garry, I have been looking at the little technicalities of things and missed the whole picture of waiting for a batch job to complete while the session is locked up on a REXX.
I believe this is one of things that could be done, but should not be done. |
Do you mean that two person cannot execute the Rexx code that is using the job at the same time.....?? |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
No, that is not what is meant. What I'm getting at is the effects of running this REXX:
1. while your TSO session is executing the REXX code, you are unable to do anything else in that TSO session
2. while the submitted job is running, it is using one processor while the 'locked' TSO session is using another in an indefinite loop - there is no facility to suspend execution of the REXX on z/OS until the submitted job completes, or for the submitted job to 'wake' your REXX on completion
In both cases, the TSO session is wasting CPU resources. You may be able to use your time doing other non-TSO work, but then you might miss when the job completes. The waste of resources increases with every user who uses this functionality - which will affect all users, batch jobs and online systems across any PLEX which shares the processors - including, probably the production system.
Garry |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
No, that is not what is meant. What I'm getting at is the effects of running this REXX:
1. while your TSO session is executing the REXX code, you are unable to do anything else in that TSO session
2. while the submitted job is running, it is using one processor while the 'locked' TSO session is using another in an indefinite loop - there is no facility to suspend execution of the REXX on z/OS until the submitted job completes, or for the submitted job to 'wake' your REXX on completion
In both cases, the TSO session is wasting CPU resources. You may be able to use your time doing other non-TSO work, but then you might miss when the job completes. The waste of resources increases with every user who uses this functionality - which will affect all users, batch jobs and online systems across any PLEX which shares the processors - including, probably the production system.
Garry |
But there is no other option right...? This happens commonly when ever we run the rexx code ...The other thing here is the Job execution is also increasing cpu time as it has to complete its execution. But when the job has to be submitted internally I thought this would be the easy way [i.e execute the job through REXX ] |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
I can't agree that there is no other option. There are job schedulers which provide this sort of functionality. Also, why can't the user who's submitting the job (using the REXX) use SDSF to see the job complete and examine the cond codes? Properly implemented security around SDSF can be used to limit a user's SDSF access.
The submitted job will use the same amount of resources (CPU &c.) whether or not you use this option.
Using this option could result in huge increases in resource usage which, in turn, could lead to disciplinary action - possible even job loss. Even if you intend only one or two users to have access to this, these things have a tendency to creep into general usage.
Garry. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
Garry Carroll wrote: |
I can't agree that there is no other option. There are job schedulers which provide this sort of functionality. Also, why can't the user who's submitting the job (using the REXX) use SDSF to see the job complete and examine the cond codes? Properly implemented security around SDSF can be used to limit a user's SDSF access.
The submitted job will use the same amount of resources (CPU &c.) whether or not you use this option.
Using this option could result in huge increases in resource usage which, in turn, could lead to disciplinary action - possible even job loss. Even if you intend only one or two users to have access to this, these things have a tendency to creep into general usage.
Garry. |
Now I feel like you are right. What I thought was automating everything with just user entering only 3 fields. From which the job is submitted and a report is created. So that if the RC is zero using that report's data new file is created in comma separated format by finding whether the job name is present in that report and details of those jobname from that report is taken moved to the new file and is sent mail. Its basically like creating the control m doc.
But I dint think of the cpu resources usage that happens to be high when automating the the job run through rexx. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
While I'm not fully aware of what you're trying to achieve, perhaps what you want to do is modify the submitted job to add a sort (DFSORT or SYNCSORT) step to produce the .csv file from the report created if the cond code from the report step is zero. Also add another step, again based on cond code zero, to send the e-mail using the z/OS SMTP server?
Is that an option?
Garry. |
|
Back to top |
|
|
sakrat
Active User
Joined: 05 Feb 2014 Posts: 164 Location: India
|
|
|
|
No actually my idea for creating the rexx tool is to automate the process of creating the control m document which will be used as part of release documentation.
So what I thought was create a panel where user will input the change man package name where the jcls reside, scheduler names that which will be used for creating the report.
Once the user inputs the detail, next ispf table will be opened in the panel containing the jcl names that is taken from package. Now the user will select the jobs that is needed in document and press enter.
Next in the the background the job will be submitted where a readable format of the control m table specified by the user will be created from the job.
It checks for RC of the job submitted to make sure report is created.
Now the jcl names which the user selected from the ispf table will be founf one by one in the report and the details corresponding to the jcl will be moved to sstem variable and written into new file with comma separated.
Once all the jcls are found and written into the new file, it will be sent to the specific mail with csv format excel sheet. So that now the control m doc is created. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
Assuming that you can get everything done up to the point of produucing the report, continue from....
Quote: |
It checks for RC of the job submitted to make sure report is created.
Now the jcl names which the user selected from the ispf table will be founf one by one in the report and the details corresponding to the jcl will be moved to sstem variable and written into new file with comma separated.
Once all the jcls are found and written into the new file, it will be sent to the specific mail with csv format excel sheet. So that now the control m doc is created. |
If your REXX builds the necessary DFSORT/SYNCSORT control cards to identify the 'jcl names' (jobnames?) that the user entered, the necessary control cards can be built by the REXX to be used in a sort step to extract the details from the report into a comma separated file. This comma separated file can be attached in MIME format to an email to be sent by z/OS SMTP server to whatever email address you (or the users) specify. This can all be achieved within the submitted job.
Garry. |
|
Back to top |
|
|
|