AS400 - CLROUTQ really works - anyone ever find a way to get it back ?
Dave White, President
I have a client who has been keeping thousands of reports on line in an
OUTQ. Against all advice.
Yes - you guessed it - Friday the operator issued the dreaded CLROUTQ
command and it did its thing.
I suspect it took quite a bit of time because how quickly can you get
rid of 70,000 reports.
Now the client is calling wanting to know is it possible to get them
back.
You see - they were the reports of a client who uses their machine.
Well, I know they are gone forever, but you have to make an attempt to
help.
Modern medicine has come up with miracle drugs, so why can't IBM one day
invent a command to Unclear.
After you stop laughing, if you know of any way - let me know. My
client will remain anonymous.
Thanks.
Dave White, President voice: (804) 227-3985
VT Associates fax: (804) 227-3054
P.O. Box 280 website: www.vtassociates.net
Doswell, VA 23047-0280 email: vir...@vtassociates.net
Hal Leahy
>help.
>Modern medicine has come up with miracle drugs, so why can't IBM one day
>invent a command to Unclear.
Since the AS/400 scatter loads its disks in small segments, there is
no way to unclear. The space could have been used by the next task
that needed disk space. If the disk is heavily utilized you can almost
guarantee the space is written over.
It looks like you will have to secure the command or the output queue.
Darryl Johns
This is unfortunate but I hope you have backup of these queues ,which
would have had to have been saved as database file(s). If backup is
lacking they are out of luck.
Regards,
Darryl Johns
IBM AS/400 e-business Specialist
(opinions expressed are mine, not necessarily those of IBM)
On Mon, 19 Oct 1998 18:20:25 -0400, "Dave White, President"
<vir...@vtassociates.net> wrote:
>To all who promise not to laugh too hard here is the issue.
>
>I have a client who has been keeping thousands of reports on line in an
>OUTQ. Against all advice.
>Yes - you guessed it - Friday the operator issued the dreaded CLROUTQ
>command and it did its thing.
>I suspect it took quite a bit of time because how quickly can you get
>rid of 70,000 reports.
>Now the client is calling wanting to know is it possible to get them
>back.
>You see - they were the reports of a client who uses their machine.
>
>Well, I know they are gone forever, but you have to make an attempt to
>help.
>Modern medicine has come up with miracle drugs, so why can't IBM one day
>
>invent a command to Unclear.
>
Tim
After 20 years of thousands of people requesting, begging, petitioning, and
threatening, has IBM still refused to provide OS support of spool file save
restore?
How many support calls from desperate users would be saved? How many lives
would be made simpler? How many thousands of lines of homegrown code could
be saved?
It is ridiculous and rather inexcusable, IMHO. For God's sake the API
manuals virtually give step by step instruction on how to write your own
back-up. Can't the OS developers take the logical next step and just do it?
Darryl Johns wrote in message <362ee4db...@ausnews.austin.ibm.com>...
Gary Guthrie
>
> After 20 years of thousands of people requesting, begging, petitioning, and
> threatening, has IBM still refused to provide OS support of spool file save
> restore?
>
> How many support calls from desperate users would be saved? How many lives
> would be made simpler? How many thousands of lines of homegrown code could
> be saved?
>
> It is ridiculous and rather inexcusable, IMHO. For God's sake the API
> manuals virtually give step by step instruction on how to write your own
> back-up. Can't the OS developers take the logical next step and just do it?
Tim, et al,
You can wander over to The RPG Source Web site at http://www.news400.com/theRPGsource and
download a utility for saving/restoring spooled files.
You'll need to download the following utilities from the Download Utilities area.
1) SpcAPI - service program with user space API procedures
2) ObjAPI - service program with object API procedures
3) SplFAPI - service program with spooled file APIs and a command front-end for saving
spooled files and restoring spooled files.
You'll need to create a binding directory to house the service programs. SpcAPI and ObjAPI
must be created and added to the binding directory prior to creating SplFAPI.
I suppose I should put together a LstAPI service program soon for getting a list of
spooled files in an output queue and create a SAVOUTQ front-end. I'll get busy working on
that and put it up on the site in the near future.
Be sure to get this utility while the Download area is still available to the general
public. Of course, once it is for subscribers only, you can simply fork out a handful of
dollars for an annual subscription to the newsletter and download utilities to your
heart's delight.
Hope this helps.
Gary Guthrie
Editor, The RPG Source
Tim
myself.
I am really more interested in an IBMer's opinion of the lack of built in
support.
Gary Guthrie wrote in message <362C1F8E...@airmail.net>...
Rodney Johnson
mouth.
I am one of the developers who works on the Spool code. The number one reason
why a save/restore for spooled files has not been done is due to FUNDING.
Every
business has to prioritize what it is going to produce as a product, which
means
some things just won't get done.
A second reason is from a technical view point. Have you ever really looked at
what
the API QSPCRTSP can and CANNOT do. 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 nolonger
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.
Tim wrote:
> =Thank you for your source code, but I have already developed these tools
> =myself.
>
> =I am really more interested in an IBMer's opinion of the lack of built in
> =support.
>
> =Gary Guthrie wrote in message <362C1F8E...@airmail.net>...
--
\begindata{text,537673800}
\textdsversion{12}
\template{messages}
\bold{Rodney A Johnson, } \italic{(ro...@ibm.us.com)}
Technical Team Lead for AS/400 Spool
Dept GJC
IBM Rochester, Minnesota
t/l 553-7925\
\enddata{text,537673800}
Richard Daniels
simple issue. I guess thorny complications like security and integrity
don't end with file / object access.
Dick Daniels
http://www.wynth.com/
Tim
everything) I had to consider each of the issues you raised. And, yes, these
issues you raise are tricky, but they are by no means insurmountable.
Rodney Johnson wrote in message <362CFFF4...@rchland.ibm.com>...
>You wanted an IBMer's opinion, so here it comes straight from the horse's
>mouth. I am one of the developers who works on the Spool code. The number
one reason
>why a save/restore for spooled files has not been done is due to FUNDING.
>Every business has to prioritize what it is going to produce as a product,
which
>means some things just won't get done.
The crazy thing is your application developers have the funding for RDARS...
a spool archival system
You overestimate the customer's expectation. You also overestimate the
requirement. For example, RSTOBJ doesnt restore a "perfect" match for the
original object. The object's owner can change, private authorities are
lost, indexes sometimes get rebuilt, queues are cleared.
We, as customers don't require *EXACT*, we require a way to recover vital
spool files in a recovery situation. If I have to deal with the minor
annoyances of job id changes, creation date changes, etc.. then so be it. It
is the contents of the spool files that are important.
Besides that it is still better than nothing at all. Is it IBM's design goal
to only provide perfect solutions? If so they have missed the mark many
times.
An example of a missed mark: Save While Active, was in huge demand from
System/38 days up until V2R2. Is Save While Active perfect? Not at all. But
it meets the requirement and those using it accept the limitations. (which
improve each release)
If funding is a problem, what else is the software subscription for other
than to raise the revenue for this type of development.
Arich H.
SOQ and it only cost about $500ish. I am sure that is cheaper than trying to
recreate those reports. 70.000 reports wow... I bet performance improved on
the machine since every SPLF on the system counts as a job on the system!
Hal Leahy wrote:
> >Well, I know they are gone forever, but you have to make an attempt to
> >help.
> They will have to rerun the reports.
>
> >Modern medicine has come up with miracle drugs, so why can't IBM one day
> >invent a command to Unclear.
Richard Knechtel
>
> I have developed my own save/restore spool file. (It uses AFP resources and
> everything) I had to consider each of the issues you raised. And, yes, these
> issues you raise are tricky, but they are by no means insurmountable.
>
I have a GREAT idea about this. Since Time has a save/restore spool file
why not submit it to IBM for inclusion in the next OS relese or PTF CUM
tape? This would 1) get a function people want out. 2) eliminate the
"funding" issue.
Here is an opportunity for US as users/developers etc.. to put give
something back. Heck it's done with Linux. People wrtie fixes to the OS
or write a good program, or better the functionality of an existing OS
program and Submit it for inclusion. If WE submited nice programs that
were develped that IBM could include we would in a sense be helping fix
or improve the AS/400 while IBM wouldn't have to worry about the
"funding" issue for the small stuff like this.
What do you think?
Would IBM go for this sort of thing?
RK.
Rodney Johnson
requests from products such as RDARs and BRMS who use our Spool APIs to
implement a "save/restore". Those requests were to change the API QSPCRTSP to
"honor" the qualified job name, creation date and time, etc. Their customers
were willing to buy the product to back up their spooled files and were not
completely satisfied. You can easily say you would be satisfied with a partial
solution, but I'm the one that has to deal with all of the angry customers who
will be unhappy with a partial solution.
There is also a tool (which is FREE) in QUSRTOOL that implements "save/restore"
of spooled files. Yes it is C source code, and it does have limitations
(cannot save spooled files larger than 16 megabytes), but it provides MOST of
what you are looking for. I'm sure you probably could convince someone at IBM
to compile the objects for you if you don't have the ILE C compiler.
What is the point of writing a save/restore that doesn't work as a true
save/restore should. If we created a save/restore solution as you purpose, it
wouldn't be any different than what you have programmed yourself. The only
difference, is it would be FREE with the operating system, and you wouldn't
have to maintain your tool. Besides, I'm only the developer. I have NO
CONTROL over the funding. All I can do is voice my OPINION. Until a couple of
days ago, I was unaware of this forum/bulletin board. One of the most popular
discussions concerning spooled files is the lack of save/restore. I will pass
that on, but again, all I can do is mention it to our planners. If you want
save/restore of spooled files, you need to keep telling your IBM
representatives so.
Tim wrote:
> See previous posts:
Gary Guthrie
> save/restore should. If we created a save/restore solution as you purpose, it
> wouldn't be any different than what you have programmed yourself.
I guess it would be the same point as writing a convert date (see CL's CVTDAT command)
that only workds for certain years - the point being that for many situations it is
adequate.
I understand your comments about "true S/R", Rodney, but surely you realize that's a silly
reason to not provide any sort of S/R of spooled files, even given the knowledge that for
an overwhelming majority of situations and purposes the re-created spooled file would
suffice just fine for the customer.
I also understand the funding issues, priorities, etc. But, I'll have to add that the
ability to save and restore spooled files have received considerable clamor over the
years.
I have a suggestion that might address the "nervousness" behind the fear of not having a
true save/restore solution - provide a spooled file "archival" solution. There, no need to
be exact, now.
Gary Guthrie