Or they could simply provide some more user data fields so the this
information could be captured, making it still available when the spool
files are restored!!

                -----Original Message-----
                From:   Graap, Ken [mailto:keg@exchange.gasco.com]
                Sent:   Thursday, March 18, 1999 3:40 PM
                To:     'Shannon O'Donnell'
                Cc:     MIDRANGE-L@midrange.com
                Subject:        RE: Saving spool files!

                Shannon wrote ...

                >mmm....I don't think so.   I'm capturing everything and
restoring it, as
                is.
                >That is, if it's created as job TB01 by user MEUSER
with job #, 456778,
                then when
                >I restore it, it will be placed back out there the same
way.

                I've tried... You may want to try again. When you
restore the spool file it
                retains all the attributes that are needed for printing,
it retains the
                userid, it retains the file name, it retains page width
and length etc...
                but the "original creation date" is the current time and
the "job name"
                associated with the restored file is the name of the job
which was run to
                restore it....

                So if a user wants to find a restore spool file by date,
they are out of
                luck... 

                If they want to find all the restored spool files
associated with a
                particular job, they are out of luck...

                The reason why this happens is that when you save a
"copy" of spool file via
                the API's and then it gets deleted from the output queue
the information for
                the original job is removed from the Work Control Table.
The job no longer
                exists on the system when all the spool files are
deleted, therefore the
                restore of the spool file "copy" can't be associated
with the original job
                anymore. It has to be associated with something so it
becomes a output file
                for the restore job and is given a creation date that
equals the current
                date and time. 

                This is all due to the fact that spool files are
associated with jobs that
                create them and are not objects themselves. All the
API's do is save
                "copies" of spool files, they don't save the original
spool file.

                What I wish IBM would do is to change how spool files
defined to the system
                and how they are saved. Instead of saving copies via
API's define spool
                files as objects (*SPLF for example). These objects
could then be saved via
                SAVOBJ, SAVLIB commands like any other object on the
system. Object
                information like the original job name and the original
creation time could
                be retained as *SPLF object attributes. API's could be
created that would
                access this information allowing a user to find restored
spool files for
                jobs that no longer exist 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: Shannon O'Donnell [mailto:ORION@auburnctnet.com]
                Sent: Wednesday, March 17, 1999 3:27 PM
                To: MIDRANGE-L@midrange.com
                Subject: Re: Saving spool files!

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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].