Re: Saving spool files!

I hope IBM doesn't do this, Have you think the cost on the system if every
spool file is transformed in an object?, Addresses, Ownership,
Authorizations, Description, Etc...

On my thinking, spool files are something temporary, and is not suppose to
be leave on the system.  I know, there is always some kind of reports that
you will need as reference and us it, once in a while.  This ones can be
save on an electronic media, as optical disk.

By policy, we don't keep any spool file on the system for more than a week,
and everything that is important we save it on optical disk.

Emilio Padilla

-----Original Message-----
From: Graap, Ken <keg@exchange.gasco.com>
To: 'MIDRANGE-L@midrange.com' <MIDRANGE-L@midrange.com>
Cc: 'blackandblue' <blackandblue@tianet.com>
Date: Thursday, March 18, 1999 11:13 AM
Subject: RE: Saving spool files!


>Brendan wrote:
>
>>The APIs do track the original user id - either as the job user of the new
>>spooled file  (QPRTJOB/olduser/newnumber) or as the 'User who created
file'
>>attribute.
>>
>>To track the spooled file with all it's job attributes you'll need to keep
>>them within a separate cross-reference file - which allows searching via
>the
>>old job name, and finds the new spooled file.
>
>This is all well and good, but then you need to create an application to
>handle the saving and restoring of spool files. Several people have pointed
>me to several such applications during this discussion. In fact... I'm
>currently using one, BRMS and it will archive copies of spool files and I
>can search the archive and find files by original jobname and original
>create time.
>
>But when I restore the spool file it is "different" than the original,
>because I haven't saved a spool file, I've saved a copy of a spool file.
>This is the point I've been trying to make and I guess I haven't been very
>articulate in my attempt...
>
>I'm frustrated because I have to do all this work to save and restore a
>spool file. Why can't IBM allow me to save a spool file, restore a spool
>file and retain the original creation date and original job name of the
>file. For example, when you restore a DB file it still has information
about
>when it was created....
>
> Creation information:
>   Creation date/time . . . . . . . . : 08/30/91  10:08:10
>
>   Created by user  . . . . . . . . . : QSECOFR
>
>   System created on  . . . . . . . . : DPSNET
>   Object domain  . . . . . . . . . . : *SYSTEM
>
>I would just like to see spool files defined like other objects on the
>system.
>
>Kenneth
>
>--
>********************************
>       Kenneth  E.  Graap
>    IBM Certified Specialist
>          AS/400   Professional
>          System  Administrator
> NW Natural - Information Services
>           System Services
>        503 226 4211 X5537
>          FAX  503 721 2521
>      keg@nwnatural.com
>********************************
>
>
>-----Original Message-----
>From: blackandblue [mailto:blackandblue@tianet.com]
>Sent: Thursday, March 18, 1999 2:11 AM
>To: MIDRANGE-L@midrange.com
>Subject: RE: Saving spool files!
>
>
>>The spool API's do not retain the original job name and original create
>time
>>attributes. They create copies of the spool data, not a direct save of a
>>spool files like you can save an object. When you use the API's to restore
>a
>>copied spool file the job name becomes the restore job's name and the
>create
>>time becomes the current time.
>
>
>Ken,
>
>The APIs do track the original user id - either as the job user of the new
>spooled file  (QPRTJOB/olduser/newnumber) or as the 'User who created file'
>attribute.
>
>To track the spooled file with all it's job attributes you'll need to keep
>them within a separate cross-reference file - which allows searching via
the
>old job name, and finds the new spooled file.
>
>Our company does have something which does this, Easy Spool Archiver. It is
>more expensive than other options mentioned previously, but if you use it
>for a CISC-RISC migration (or in your case a system upgrade), the
WRKOUTQESA
>& 'Restore' facility can be used indefinitely.
>
>You can download it at http://www.black-and-blue.com
>
>An alternative might be to change the OUTQ/USRDTA/FORMTYPE fields to keep
>the information you use for searching (e.g. keep the jobname in USRDTA, the
>create date in USRDTA and separate the spooled files in outqs named after
>the USER).
>
>As to your original point, why OS/400 has never had a SAVOUTQ or at least a
>backup of QSPL is amazing. I can only surmise that it is because the
spooled
>file is regarded as belonging to a job, which like job locks, overrides
etc.
>cannot actually be saved. The information needed to make sense of the QSPL
>members is perhaps contained in the job, and this dies with the job (i.e.
>when the file is deleted)?
>
>IBM probably had the choice of introducing a SAVJOB/RSTJOB command, or
>writing APIs to separate the spooled file from the job and allowing that to
>be SAV/RST'd.
>
>
>Brendan Bispham
>Black and Blue Software Engineering
>
>
>
>+---
>| 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
>+---
>+---
>| 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
>+---
>

+---
| 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
+---