Re: Protection for spool files?

//--- forwarded letter -------------------------------------------------------
> X-Mailer: Mozilla 3.01Gold (Win95; I)
> Date: Fri, 30 Jan 98 10:42:53 -0600
> From: "Jeff Carey" <jeffreycarey@usa.net>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Re: Protection for spool files?

> 
> I would have to agree the implementation is lacking - if spool files are
> records in tables now, why can't each file be its own object (or at
> least member in an object - maybe the outq is a file, and the spool
> files ae it's members?).  I'm sure this implementation was probably
> ported over from an earlier system (S/36? S/38?).  Perhaps reworking
> spool file handling should be a future requirement?  Although tht would
> put those savsplf vendors out of business...
> 

**** Stuff deleted *******************

Hello Jeff,

I meant to clarify this a while ago but the message got lost in my in-basket 
and I haven't 
seen a later response.

The AS/400 is an object based machine.  Most entities are objects in their own 
right, not just 
a special case of a file.  So you cannot READ and WRITE to a *PGM object 
because those methods 
are not valid for a *PGM.  In the same way you cannot run a *FILE because that 
method is only 
valid for *PGM objects.  This is not the case for most other machines where the 
name of the 
object determines what you can do with it; DOS, Win, OS/2 use the file 
extension to determine 
if a file is executable -- rename a text file to have an .EXE extension and the 
OS will try to 
run the file.  Unix uses permission bits; give a text file execute permission 
and the OS will 
try to run the file.  The AS/400 is cleverer than that.  However not everything 
in the AS/400 
is implemented as an object.  The system directory is one example, TCP/IP 
configuration is 
another.  Spooled files are also another -- they are implemented as members of 
files in QSPL.

The *OUTQ is simply a queue object.  It is not a file.  It contains entries 
indicating the 
position in the queue of a spooled file, status information (hld, rdy, etc) and 
information 
about where that spooled file can be found in QSPL.  Queue entries are not 
saved when the 
queue object is saved.  This is true for all queues on the AS/400 (job queues, 
data queues, 
user queues, output queues).

The job control structures for each job in the system contain a spool control 
block which 
contains pointers to the *OUTQ and also the member in QSPL in which the spooled 
data resides.

Spooled files themselves (that is the printed data) are held in members of 
files in the QSPL 
library.  Members are added to files (usually only ever two, but occasionally 
more -- it seems 
to depend on the record length of the spooled file) as required.  Members are 
reused if the 
spooled file has been printed and not saved, and another spooled file of the 
same name is 
generated.  Members are removed when spooled file cleanup is performed; 
RCLSPLSTG command is 
run or when a member has not been used for more than the number of days 
specified in the 
QRCLSPLSTG system value.  The system used to remove members that had not been 
used for more 
than 7 IPLs.  I am not sure if this still happens, I think it has been replaced 
by the 
QRCLSPLSTG function.

This structure is essentially the same as that used on the System/38 with the 
addition of more 
user control of the clean-up functions.

Each member is an object of type *MEM located from an object of type *FILE 
located from and 
object of type *LIB called QSPL.

Spooled files by their nature are transient so it makes little sense to expose 
them as objects 
and set authorities on the objects because they and their authorities will be 
removed when the 
system prints the spooled file (unless the file is saved).  The output queues 
are permanent 
which is why authorisation to spooled files is performed via the *OUTQ objects. 
 Yes, it is 
messy and I suppose a similar technique to *AUTHLR objects could be developed 
to hold the 
authorities for spooled files.  You'd probably have to raise this as a COMMON 
Resolution (is 
that the right term?) to get IBM to listen to this and enough of you would have 
to want the 
new function.  After all, we've been working quite happily for nearly 20 years 
with the 
existing structure.

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 3 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.
 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@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
+---