I've never used it for this particular purpose, but a secondary JES2 might fill the bill. For one thing, whatever pondering you do under the secondary would not affect the primary. And once the secondary is running, you can use SDSF to look at spool content. It's a bit tricky to set up but perfectly doable with no impact on the primary system.
. . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: "Joel C. Ewing" <jcew...@acm.org> To: IBM-MAIN@LISTSERV.UA.EDU Date: 10/01/2012 03:42 PM Subject: Re: Restore JES2 spool/chkpt to new volumes? Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On 10/01/2012 04:32 PM, David Andrews wrote: > On Mon, 2012-10-01 at 16:48 -0400, Chambers, David W. wrote: >> Since you're IPLing the Test LPAR you could temporarily relabel the >> BEBS... volumes to the original BEBC... volume serials and respond >> with the appropriate reply to the DUPLICATE VOLUME message at IPL >> time. And the production volumes would also be offline to your Test >> LPAR. Just make sure you've got the right (test) volumes online on the >> Test LPAR. > I thought of that, but wasn't altogether clear on what x-system magic > JES2 was doing. Two LPARs on a GRS ring, with their primary JES talking > to the same volsers, but different unit addresses. Wonder if that would > make a mess? > If I were trying this, I would for sure use a stand-alone test LPAR system that was completely independent from production with production DASD offline to the test LPAR, test LPAR DASD off-line to prod LPAR, and no shared GRS ring, coupling facility, or other unneeded communication with the production environment. When you are deliberately creating multiple drives with same volser and making a test JES2 that may essentially "think" it is a production JES2, you want to be double-double sure that test system cannot touch prod drives or other prod resources by accident and there are no cross system enqueues or other unintended cross-system communication to confuse things. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
