Edward Jaffe wrote:
גדי בן אבי wrote:
We have an automation rule the deletes old jobs from the spool
according to certain criteria.
The rule issues several commands of form:
$OJOBQ,ALL,CANCEL,A>1,JOBMASK=B280O*
Since we migrated to z/OS 1.7, when the commands are issued we get
these type of messages:
$HASP9203 LONG PCE DISPATCH 814
DURATION-000:00:14.59 PCE-COMM EXIT-NONE JOB ID-JOB38281
COMMAND-$OJOBQ,ALL,CANCEL,A>1,JOBMASK=B185BYZM $HASP9207
JES2 CHECKPOINT LOCK HELD 815
DURATION-000:00:14.71
This causes JES2 to wait and delay many JES2 related functions like
submit and sdsf access.
Has anyone come across this problem? Do you know of a fix?
FWIW, I looked back through our log and discovered that this is
happening to us *every* morning in our z/OS V1R7 JES2 environments!
$COJOBQ,Q=ABCDEHIKMNOSTUWXY0123456789,DAYS>60
$HASP263 WAITING FOR ACCESS TO JES2 CHECKPOINT VOLUME MVSJ21
$HASP263 WAITING FOR ACCESS TO JES2 CHECKPOINT VOLUME MVSJ21
*$HASP9203 LONG PCE DISPATCH 214
DURATION-000:00:13.94 PCE-COMM EXIT-NONE JOB ID-JOB03849
COMMAND-$COJOBQ,Q=ABCDEHIKMNOSTUWXY0123456789,DAYS>60
IEF196I IOS071I 2036,**,*MASTER*, START PENDING
IOS071I 2036,**,*MASTER*, START PENDING
*$HASP9207 JES2 CHECKPOINT LOCK HELD 247
DURATION-000:00:18.03
[it finally breaks free and cancels the intended output]
$HASP9301 JES2 MAIN TASK ALERTS CLEARED
$HASP9302 JES2 CHECKPOINT LOCK RELEASED
No similar issues exist for our JES3 environments.
I went back and checked our history; it could be that you've been having this
happen longer than you realize.
We ran into this after converting from OS/390 2.10 to z/OS 1.4. My answer was
to split our automatic commands similar to your $COJOBQ in fourths and stagger
them by five minutes.
Bob
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
