|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.