| View previous topic :: View next topic |
| Author |
Message |
asj
Beginner
Joined: 20 Apr 2007
Posts: 3
Topics: 1
|
 Posted: Thu Apr 02, 2009 2:44 am Post subject: ISF015I SDSF COMMAND ATTEMPTED (spool purge through REXX) |
 |
|
Hello,
We have 2 LPARs, say P and W, both running z/OS 1.9.
From LPAR "P" an operator submits a job which is remotely executed in LPAR "W" (using JES command /*XEQ). This job executes in LPAR "W". It has only one step: executes a REXX script that purges the spool of LPAR "W" based on some input criteria. The goal is to remotely clean up the spool of LPAR "W" from LPAR "P".
The result of the job then goes back to LPAR "P". The trace of the REXX script says that it successfully purged what it was asked to purge, but:
1) Within the joblog I can see several lines similar to this one | Code: | | ISF015I SDSF COMMAND ATTEMPTED '$COJ(6864),OUTGRP=1.1.1' UUUUUUU REXX INTRDR |
where UUUUUUU is the user id under which authority the job was submitted. There are as many lines like the previous one as job logs tried to purge. Those same lines appear in the SYSLOG of LPAR "W".
2) I log on LPAR "W" and I can see all the jobs in the spool that the REXX script said it had successfully purged.
Message ISF015I is:
| Code: | ISF015I SDSF COMMAND ATTEMPTED|EXECUTED command userid logon-proc terminal-name
Explanation:
The message contains the first 42 characters of the command being processed. If the text exceeds 42 characters, the text contains a trailing + sign.
User response:
The operator should respond according to the installation's procedures.
Note:
If the command attempted or executed is the REPLY command, the command field of this message contains "REPLY nn TEXT of REPLY IS SUPPRESSED". The text of the REPLY command is suppressed to prevent confidential data from being logged. |
Could anybody give me a hint what's going on? Am I doing anything wrongly? Or have I missed anything? I'm stucked and baffled, and I can't get anything clear from the message explanation.
Thanks in advance. |
|
| Back to top |
|
 |
semigeezer
Supermod
Joined: 03 Jan 2003
Posts: 1014
Topics: 13
Location: Atlantis
|
| Posted: Thu Apr 02, 2009 1:14 pm Post subject: |
|
|
I ran into this last week doing something similar and just assumed it was an SDSF authority thing where I didn't have the same authority to run SDSF commands from batch as I do from foreground (I was trying to run a command via a web server or batch job to cancel my TSO id). I didn't persue it though because I found I had authority to issue commands using just the plain /* command syntax. You might check with whomever installed SDSF to see if the have set up authorities that might cause this
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html. |
|
| Back to top |
|
|
asj
Beginner
Joined: 20 Apr 2007
Posts: 3
Topics: 1
|
| Posted: Fri Apr 03, 2009 4:36 am Post subject: |
|
|
| Quote: | ... just assumed it was an SDSF authority thing... You might check with whomever installed SDSF to see if the have set up authorities that might cause this
|
It looks like it is SDSF authority related, but I have no idea about SDSF security configuration/customisation. I just wrote a REXX script to do what we needed. It works with my user id, but it doesn't to a workmate. We'll have to look into it.
Thanks anyway. |
|
| Back to top |
|
|
asj
Beginner
Joined: 20 Apr 2007
Posts: 3
Topics: 1
|
| Posted: Tue Apr 28, 2009 3:56 am Post subject: |
|
|
It was SDSF authority-related in the RACF.
SOLUTION: Needed "ALTER" access to ISF*.** (class SDSF)
Regards. |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
