Re: Final thread: Gold nugget -- MIDRANGE-L

Well said and I couldn't agree more Richard !

Case in point. At my last job we were a company with worldwide operations. We
were running S2K's (now Infinium) Financials and the GL folks would run trials
for all of these companies that generated THOUSANDS of spool files that were
THOUSANDS of pages long. While this didn't necessarily rack up the job # count
(since one job run could do this and even though they were doing this over AND
over again each month) I investigated several spool file save utilities and the
one I picked paid for itself in less than 2 months. What had been happening was
that the Financial folks insisted that they needed all of this stuff saved in
case they were audited but they didn't want to print it out. I could see that
because it took PHYSICAL room, but at the same time it was taking up DISK room.
At the time we had well over a years worth of this stuff, one Year/Month outq 
for
each month. I started offloading this stuff to tape and knocked over 25% off of
our storage and this was on a fairly large system  for then (5 or 6 years ago).
It kept us from having to add disk !

ANYONE who is getting pressured to let spool files "hang around" on the system
should save them off. In 2 1/2 years there was only ONE time that I had to
restore anything... And spool files can take up a TON of space !!

JMHO !

Chuck

Richard Jackson wrote:

> Justin:
>
> You have a point but answer me this, Mr. Wizard <bg>  Why would anyone have
> 140,000 jobs on a 400?
>
> I can think of only two reasons.  (1) They create job logs and don't delete
> them or (2) they create spool files and leave them on the system.
>
> So who reads these job logs?  Nobody can read that many job logs.  The other
> half of the problem is that they don't delete the logs.  Well, that can't go
> on forever.  You already told us that.  There are two reasonable answers for
> this.  Either set logging to (4 0 *nolist) or delete all the jobs logs more
> than 2 days old.  Neither is a challenge.  In my opinion, all other choices
> rely on something being true that is, in my experience, either never true or
> almost never true.  I suggest that the design follow the most like path, not
> the impossible or almost impossible path.
>
> Using WRKSPLF to review reports is fine but not when you have 140,000 of
> them.  There are much better ways to archive spool data than leaving them as
> unprinted reports in dead jobs.  There are archive programs that roll spool
> files off to disk, there are PC programs that do the same thing, there
> microfiche programs, services - a million choices all better than leaving
> them in jobs on the 400.
>
> Do you think that it is okay for people to create more than 100,000 job
> logs?  Is it okay to have all those dead jobs hanging around just for the
> spool files?
>
> Now, here's my point.  You say below, "Rather than bickering back and forth
> about how many jobs actually can exist, why not be thankful that he saved
> himself one heck of a hard crash?"  Why not try to figure out a way to stop
> paying the huge price for all of those jobs in the first place?
>
> Richard Jackson
> mailto:richardjackson@richardjackson.net
> www.richardjacksonltd.com
> Voice: 1 (303) 808-8058
> Fax:   1 (303) 663-4325
>
> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of Haase, Justin C.
> Sent: Thursday, July 20, 2000 10:52 AM
> To: MIDRANGE-L@midrange.com
> Subject: Final thread: Gold nugget
>
> Folks,
>
> Rather than bickering back and forth about how many jobs actually can exist,
> why not be thankful that he saved himself one heck of a hard crash?  Sure,
> you can get 160,xxx jobs in the system, but if you've been around to see
> yours hit 140k, you know what trouble it is to even get to a command line or
> see your outqueues.  So, rather than cluttering up the list anymore, just
> leave it at the fact that yes, you can have more than 140k but if you get
> much higher you risk going casters-up.  Thanks.
>
> Justin C. Haase
> AS/400 Systems Administrator
> Kingland Systems Corporation
> phone - 641.494.1535
> fax - 641.424.1669
> cellular - 641.430.6381
> pager - 641.422.3023
> e-mail - justin.haase@kingland.com
> alpha page - 5550923.beeper@pager.beeperpeople.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
> +---

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