V5R4 enhancements

[Rodney A. Johnson]

Not sure how many have seen the press releases, so here are some
enhancements in V5R4 that should help you manage your system better
especially with regard to spooling :-).

1. Native save/restore support for spooled files
- new SPLFDTA keyword on SAV/RST CL commands
- APIs QSRSAVO and new API QSRRSTO provide ability to select
spooled files individual or by various attributes
- Library list, spooled file identity, and creation date/time
are preserved. External resources are not saved with the
spooled file, but if resources are save/restore from/into
the same libraries spooled files will print correctly
(i.e. no longer need to make sure resources are in a
common library)

2. New Expiration Date attribute on printer file
- Spooled files can be set to expire on a specific date or
number of days from creation or when last changed (CHGSPLFA)
- New CL command DLTEXPSPLF allows administrator to decide
when expired spooled files are purged from the system.
Help text includes example for a scheduled job entry
for deletion of expired spooled files daily at 1:00am
system local time.
- One annoyance is that you must reset the system printer
files every time you reinstall...default for new attribute
had to be *NONE for upward compatibility.

This only works well if you want to manage your spooled files
life span based on printer file. Not so well if sharing a
printer file (such as QSYSPRT) and have differing life span
requirements.

3. New job attribute LOGOUTPUT (enhanced job log pending support)
- Ability to have job logs not be spooled even if job ends
abnormally
- Have job logs created by a job log server job instead of
during job termination
- Operational Assist cleanup will automatically remove jobs
after the job has been in job log pending for the number
of days specified on system output attribute

Recommend using value *PND as much as possible unless
job logs must be spooled for some automated processes

4. New WRKJOBLOG CL command
- Ability to find your job logs whether spooled or in the
new job log pending status. Spooled ones found regardless
of what output queue the job log resides on
- The new support does NOT hinder spooling operations
(i.e. does not create or add to spool lock contention)
- Can filter by date/time of creation and by job name

Recommend using this for finding/viewing job logs.

5. Enhancements to WRKSPLF CL command filtering capability
- Ability to filter by date/time, file name, and job name
- New filtering CAN result in contention, as
most of the new support results in having to process
all spooled files. See the Spool Performance Experience
Report in the V5R4 infocenter for details.

Recommend using the date/time filter. Do not recommend
using new generic support, file name, or job name filters
during heavy spooling periods to avoid serious lock
contention.
--
Rodney A Johnson
Technical Team Lead for i5/OS (AS/400) Spool
Dept GJC
IBM Rochester, Minnesota

The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, IBM. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.

[s***@cox.net]

Post by Rodney A. Johnson
Not sure how many have seen the press releases, so here are some
enhancements in V5R4 that should help you manage your system better
especially with regard to spooling :-).
1. Native save/restore support for spooled files
- new SPLFDTA keyword on SAV/RST CL commands
- APIs QSRSAVO and new API QSRRSTO provide ability to select
spooled files individual or by various attributes
- Library list, spooled file identity, and creation date/time
are preserved. External resources are not saved with the
spooled file, but if resources are save/restore from/into
the same libraries spooled files will print correctly
(i.e. no longer need to make sure resources are in a
common library)

Do you remember this exchange we had 8 years ago?

http://groups.google.com/group/comp.sys.ibm.as400.misc/browse_frm/thread/4a8dc63b48c32d2/b2786c1938d41fd9?lnk=st&q=backup&rnum=44#b2786c1938d41fd9

You were detailing the difficulties of implementing save/restore spool
file function. You basically said 8 years ago these were the roadblocks
(also funding).


<QUOTE>
The spooled file created using the API is a NEW spooled file. The
qualifed job name of the spooled file ends up being the same as the job
that issued the call to the API, unless a user other than the caller
was specified in the SPLA0200 format. Because the spooled file is a
new one, it also does not have the same spooled file number. The
creation date and time is the date and time the API was called, NOT
when the spooled file "supposedly being restored" was originally
created. Did you know that each spooled file has it's own library
list. This library list is a copy of the job's (job that created the
spooled file) library
list at the time the spooled file was generated. This is used at
printing time. If you are one
of those user's who deal with *AFPDS spooled files and external
resources, you know what
a pain it can be to get your spooled file to print correctly when one
of those
resources was not library qualified in the data stream. When you
create a spooled file
using the API QSPCRTSP, you inherit the library list of the job that
the API is
invoked under, NOT the library list stored in the SPLA0200 structure.

If I was a customer, I would expect the save/restore of spooled files
to work
such that there was NO difference between the original spooled file,
and the one
restored. That, after all, is the intent behind save/restore.

Let's take this a step further. Have you considered the problems with
trying
to preserve the original qualified job name? A job doesn't go away on
the system until all
of it's spooled files have been deleted. How do you restore a spooled
file to a job
that nol onger exists? How do you know if the job is really the job
that created the spooled
file? Believe it or not, we have customers who end up with duplicate
qualified job names.
When that happens, and the sequence of spooled files is identical, you
end up loosing one
jobs worth of spooled files (once you get someone to go into DST and
twiddle some memory).

How do you handle restoring a spooled file to a system it NEVER existed
on.
The original job never existed. These are just SOME of the pitfalls to
consider
when designing a save/restore for spooled files. Believe me, I would
like to implement
save/restore as much as anyone.
</QUOTE>

Did this new support address these concerns?

[Rodney A. Johnson]

Yes I remember that conversation well. Yes those concerns were all
addressed in multiple stages...

Stage 1 was getting the attributes stored "together" with the data.
That is, the attributes couldn't stay stored in a structure hung off of
the job. That was accomplished in V5R1. This also allowed for the
number of spooled files allowed for a single job to be increased
(QMAXSPLF system value).

Stage 2 was making it so a spooled file could survive without a job.
This was accomplished by adding the additional identity attributes
JOBSYSNAME and CRTDATE to all interfaces identifying a spooled file.
This was introduced into V5R2 and allows spooled files to be decoupled
from the job via the job attribute SPLFACN *DETACH (system value QSPLFACN).

Stage 3 was the actual implementation of the save/restore and came in V5R4.

I was able to use the iASP support "bandwagon" to get the changes
"funded". It was helpful that iASP support had the exact same needs and
requirements of save/restore with regard to the spooled file identity
and library list for external resource look up.

I've been wanting to provide a save/restore support for spooled files
since I joined the Spool component back in end of 1993. Only took about
12 years to deliver it :-).

Post by s***@cox.net

Post by Rodney A. Johnson
Not sure how many have seen the press releases, so here are some
enhancements in V5R4 that should help you manage your system better
especially with regard to spooling :-).
1. Native save/restore support for spooled files
- new SPLFDTA keyword on SAV/RST CL commands
- APIs QSRSAVO and new API QSRRSTO provide ability to select
spooled files individual or by various attributes
- Library list, spooled file identity, and creation date/time
are preserved. External resources are not saved with the
spooled file, but if resources are save/restore from/into
the same libraries spooled files will print correctly
(i.e. no longer need to make sure resources are in a
common library)

Do you remember this exchange we had 8 years ago?
http://groups.google.com/group/comp.sys.ibm.as400.misc/browse_frm/thread/4a8dc63b48c32d2/b2786c1938d41fd9?lnk=st&q=backup&rnum=44#b2786c1938d41fd9
You were detailing the difficulties of implementing save/restore spool
file function. You basically said 8 years ago these were the roadblocks
(also funding).
<QUOTE>
The spooled file created using the API is a NEW spooled file. The
qualifed job name of the spooled file ends up being the same as the job
that issued the call to the API, unless a user other than the caller
was specified in the SPLA0200 format. Because the spooled file is a
new one, it also does not have the same spooled file number. The
creation date and time is the date and time the API was called, NOT
when the spooled file "supposedly being restored" was originally
created. Did you know that each spooled file has it's own library
list. This library list is a copy of the job's (job that created the
spooled file) library
list at the time the spooled file was generated. This is used at
printing time. If you are one
of those user's who deal with *AFPDS spooled files and external
resources, you know what
a pain it can be to get your spooled file to print correctly when one
of those
resources was not library qualified in the data stream. When you
create a spooled file
using the API QSPCRTSP, you inherit the library list of the job that
the API is
invoked under, NOT the library list stored in the SPLA0200 structure.
If I was a customer, I would expect the save/restore of spooled files
to work
such that there was NO difference between the original spooled file,
and the one
restored. That, after all, is the intent behind save/restore.
Let's take this a step further. Have you considered the problems with
trying
to preserve the original qualified job name? A job doesn't go away on
the system until all
of it's spooled files have been deleted. How do you restore a spooled
file to a job
that nol onger exists? How do you know if the job is really the job
that created the spooled
file? Believe it or not, we have customers who end up with duplicate
qualified job names.
When that happens, and the sequence of spooled files is identical, you
end up loosing one
jobs worth of spooled files (once you get someone to go into DST and
twiddle some memory).
How do you handle restoring a spooled file to a system it NEVER existed
on.
The original job never existed. These are just SOME of the pitfalls to
consider
when designing a save/restore for spooled files. Believe me, I would
like to implement
save/restore as much as anyone.
</QUOTE>
Did this new support address these concerns?

--
Rodney A Johnson
Technical Team Lead for i5/OS (AS/400) Spool
Dept GJC
IBM Rochester, Minnesota

The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, IBM. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.

[Steve Richter]

Post by Rodney A. Johnson
Yes I remember that conversation well. Yes those concerns were all
addressed in multiple stages...
Stage 1 was getting the attributes stored "together" with the data.
That is, the attributes couldn't stay stored in a structure hung off of
the job. That was accomplished in V5R1. This also allowed for the
number of spooled files allowed for a single job to be increased
(QMAXSPLF system value).
Stage 2 was making it so a spooled file could survive without a job.
This was accomplished by adding the additional identity attributes
JOBSYSNAME and CRTDATE to all interfaces identifying a spooled file.
This was introduced into V5R2 and allows spooled files to be decoupled
from the job via the job attribute SPLFACN *DETACH (system value QSPLFACN).

what about a GUID that uniquely identifies each spooled file, each job,
each object for that matter < warning: pun > in the universe?

When a spooled file is restored on another system it retains its splf
guid and job guid. If the job guid is not found on the system you know
it is from another system. You might even be able to query the network,
just like a mail server finds a recipient, and find out the job that
the job guid identifies.

Post by Rodney A. Johnson
Stage 3 was the actual implementation of the save/restore and came in V5R4.
I was able to use the iASP support "bandwagon" to get the changes
"funded". It was helpful that iASP support had the exact same needs and
requirements of save/restore with regard to the spooled file identity
and library list for external resource look up.
I've been wanting to provide a save/restore support for spooled files
since I joined the Spool component back in end of 1993. Only took about
12 years to deliver it :-).

way to go Rodney! your my kind of people. I hope there are enough
people like you to get this system of ours back on track.

-Steve

p5 + i5/OS = a better p5