Yes, I have spent way too much time looking at dumps that were 
caused by this (enough so that I persuaded Peter Relson to 
make a change in z/OS 2.2 so that a DELAY(1) is done if a delay 
value larger than 1 was not specified).  That has helped a lot. 
But you could easily have a fetching operation that takes
longer than 1 second (or any arbitrary number of seconds) 
due to things like a reserve on the device, or the job getting 
logically swapped due to workload considerations. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> 
> More important, has anyone actually experienced a problem with JOB(*)? 
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> [email protected]
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]
> ] On Behalf Of Mark Zelden
> Sent: Wednesday, May 17, 2017 10:49 AM
> To: [email protected]
> Subject: (External):Re: setrog lnklst question
> 
> On Tue, 16 May 2017 23:10:10 +0000, Gibney, Dave <[email protected]> wrote:
> 
> >And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. 
> >
> >On the other hand, so far, I haven't have need to modify my linklst and 

> >effect all running address spaces. It's usually limited to  a smaller 
subset.
> 
> Yet I continue to see people using it as a matter of habit instead 
> of an "emergency"
> basis.  The only place I have used it regularly is in a sysprog 
> sandbox LPAR and since "delay" was added as an option, I use that 
> along with it.
> 
> LNKLST UPDATE JOB(*) DELAY(5)
> 
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL
> v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: 
> http://www.mzelden.com/mvsutil.html
> Systems Programming expert at 
http://search390.techtarget.com/ateExperts/
> 
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to