Re: AS/400 job recovery -- MIDRANGE-L

I think you'd have to add object locks and record locks that were in place when 
the job went down to
your list of major problems.  Not an easy thing to restore.

-- 
Larry Bolhuis         |
Arbor Solutions, Inc  | Two rules to success in life:
(616) 451-2500        | 1. Never tell people everything you know.
lbolhui@ibm.net       |

lg - Loyd Goodbar wrote:
> 
> I was wondering... the AS/400 offers so much as far as system security,
> integrity, etc. is concerned. Thinking about that, I was wondering why the 400
> doesn't offer any form of job recovery.
> 
> When a job is running, the 400 has to be able to page the entire job out of
> memory if necessary. This predicates that state information for CPU processing
> as well as IO processing (file RRNs, record of input, output) can be saved and
> restored as necessary.
> 
> However, when a shutdown is performed, all job information is lost. (I'm
> considering user jobs here; system jobs are restarted via the startup
> program.)
> 
> What I was thinking was: when a PWRDWNSYS or ENDSBS was performed, could
> active job information be saved, and optionally restored and resumed when the
> system/subsystem was restarted?
> 
> For instance, if I powered down the system with 5 jobs active in QBATCH, when
> I restarted the system, the system operator (or secofr, whoever) could be
> presented with a screen of previously active jobs: (example)
> 
> These jobs are not currently active, but were active when the subsystem was
> ended. The sysopr could choose 1 to resume the job where it left off; 2 to
> resubmit the job from the beginning; 4 delete the job; 5 display job
> attributes (WRKACTJOB opt 5)
> ---------------
> Resume user jobs
> 
> Options:
> 1=Resume 2=Submit 4=Delete 5=Display
> 
> SUBSYS/JOB Date/Time Started Date/Time Suspended
> MIS
> _ CRTBNDRPG/GOODBAR/300010 11/06/98 17:53:00 11/06/98 17:54:08
> QBATCH
> _ QBATCH/GOODBAR/300001 11/06/98 14:03:34 11/06/98 17:54:03
> _ MONITOR/QSYSOPR/300002 11/04/98 01:00:00 11/06/98 17:54:04
> 
> F3=Exit F11=View 2 F12=Cancel F23=Delete all F24=More keys
> ... other options??
> ---------------
> 
> Obviously, the sysopr must know what the job did; it wouldn't help if s/he
> restarted a job that consumed all system resources or whatever.
> 
> The only major problems with this I could think about would be if access paths
> were rebuilt during an IPL or changed between the time a job was "suspended"
> and when it resumed. Would journaling be required on all files used by a job
> to have it resumable? What other wierd things am I missing that explain why
> this feature couldn't be present in OS/400?
> 
> Just some thoughts,
> Loyd Goodbar
> --
> "You can nail me, but not to a tree."
> lgoodbar@watervalley.net  ICQ#504581  
>http://www.watervalley.net/users/lgoodbar/
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---