RE: Final thread: Gold nugget

You're right, I did criticize without knowing the facts.  Sorry about that.
I should have asked first or phrased my comments with the questions in them.

Thanks for the explanation.  That helps to justify the numbers and it makes
sense in detail but overall I still don't get it.  Are you creating a new
job structure for every spool file?  Why not use server jobs and communicate
via data queue or similar?  It will be substantially faster and greatly
reduces the CPU overhead you pay when creating a new job structure.  In my
opinion, that makes system performance management a lot easier.

A few months ago, I worked on a nice little 12-way with 24 GB of main
storage and 800 GB of disk (at that time) and it will take them a year to
turn over the job number counter.  They use several technical means,
including the one described above, to avoid submitting jobs.

I have some idea of and experience with ASP operations.  I suspect that this
is central to the issue but, for what it's worth, I think that the print
server idea would be worth looking at.  The big question is: is the capacity
and work management gain worth the coding cost and the potential security
risk.

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 2:39 PM
To: 'MIDRANGE-L@midrange.com'
Cc: Mart, Nick
Subject: RE: Final thread: Gold nugget


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