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.

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.

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....?

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.

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....

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....?

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....

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.

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....

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.

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....?

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.

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 ]