purging JES2 output whilst retaining required jobs

[alanplayford]

In common with many sites, I have automatic JES2 commands to keep the spool utilisation down and workable.
These include 2 specific commands for this:
$po jobq,/held,days>5
$po jobq,all,protected,days>14

However, I have a job which is required to be kept on spool for longer, due to some specific testing against its output.
It's characteristics are:
$HASP686 OUTPUT(jobname) OUTGRP=1.1.1,BURST=NO,FCB=****,
$HASP686 FLASH=****,FORMS=STD,HOLD=(NONE),
$HASP686 OUTDISP=WRITE,PRIORITY=96,
$HASP686 PRMODE=LINE,QUEUE=A,
$HASP686 RECORDS=(15182 OF 15182),
$HASP686 ROUTECDE=LOCAL,SECLABEL=,TPJOBID=,
$HASP686 TPJOBN=,TSOAVAIL=NO,UCS=****,
$HASP686 USERID=usern,WRITER=

Any suggestions as to:
1. Change the automatic commands to exclude certain jobs, along with SDSF line command to stop it from being deleted2.
Any other method you may use

I've tried the H commnad in SDSF which changes its status to HOLD on the ST panel, and removes it from the O and/or H panel displays already.

Many thanks in advance.

[steve-myers]

This "requirement" is why output managers exist. I can think of at least 3 that CA Technologies (or whatever they call themselves this week) markets (though I think they have more or less forgotten the simplest (and cheapest)) and I know there are more from other vendors that will extract the job from JES2, hold the output in its data area and allow JES2 to purge the output in a more timely manner. JES2 was never intended to hold output for an extended period.

[alanplayford]

Thanks Steve. Understood that spool output managers can do this, but we don't have one for our small shop. So, just wondered if anybody has found a timely way to achieve this?

[NicC]

Not my area of expertise but...can you not print to dataset? I forget the SDSF command that does it in one but simple to allocate a dataset of the right characteristics and then copy.

[alanplayford]

Nic, Yes, we do that regularly, but this particular application requires it to be on spool still?
I have considered using OFFLOAD processing to save it, then recall it into the system.
Not ideal, but it might keep buying us time?!

[NicC]

Supply the people concerned with a job to offload which would run after their testing is done and a job to reload when their testing begins.

[willy jensen]

One solution is to route that job and other like it to a seperate destination. Remember that in JES2 a destination is just a name, you do not need a RMT or NJE node associated with it. Then change your PURGE commands to only hit dest LOCAL.
And you can route those jobs by an automatic command too.
Of course you still ned some housekeeping to handle those nonLOCAL destinations.

[alanplayford]

Willy, excellent idea. I'd already thought of it, but am currently unsure how to change my two purging commands to only purge LOCAL dest jobs?
Remember my 2 purge commands right now are:
$po jobq,/held,days>5
$po jobq,all,protected,days>14

[alanplayford]

Supply the people concerned with a job to offload which would run after their testing is done and a job to reload when their testing begins.

Nic,
I have already manually done this via the OFFLOAD commands.
But if there's a way to submit a batch job to do this, I'd love to hear how?

[willy jensen]

Small test, command '$POJ(*),JOBMASK=WJGENER,DEST=LOCAL' deletes the named job in LOCAL while leaving a job of the same name in dest T1. So the DEST=LOCAL should do the trick. Better test it though...