Re: Final thread: Gold nugget

Justin,

I personally was NOT "criticizing management of our 400s" so don't take offense.
Just trying to recount "been there done that (learned that the hard way)"
experiences buddy !

That is AMAZING that you crank through stuff like that !!

Please tell us more about these spool files though - ARE they job logs because 
as
was pointed out, changing logging levels can make them go away !!

Chuck

"Haase, Justin C." wrote:

> Folks, before you continue criticizing management of our 400s, let me tell
> you about our situation.
>
> 740 12-way.  1Tb DASD, 16Gb RAM.  We run trading operations.  We are an
> application service provider.  We generate 140,000 spools in ONE DAY.  It's
> not an archive thing here.  You're all aware of job numbers, I'm sure.  This
> machine resets to 000001 every week and a half.  That's 1 million (or 999999
> for those who are so adept at calling people on technicalities) So - not an
> inexperienced 400 shop here.  Just one with a LOT of transactions.
>
> 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
>
> -----Original Message-----
> From: Chuck Lewis [mailto:clewis@iquest.net]
> Sent: Thursday, July 20, 2000 9:01 AM
> To: MIDRANGE-L@midrange.com
> Subject: Re: Final thread: Gold nugget
>
> 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
> +---
> +---
> | 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
+---