Some companies may have the $$$$$ for unlimited system resources.
My employer is not one of them ... everything is a trade-off.
Job-Logs are great when trouble-shooting a problem, but thankfully, problems
are few & far between, when you consider 50+ users each with 4+ sessions,
busy busy busy for 12+ hours a day.
Perhaps you are in a different work reality than me.
We are a PRODUCTION SYSTEM with tens of thousands of programs that most
people are reasonably happy with.
Occasionally someone wants a new report, an enhancement to an existing
report, something else on some interactive screen, some 400 data into Excel,
so we add to the collection of programs, as needed, and as my time permits.
We don't need job logs on software that has been running fine for years.
The act of capturing a job-log means disk i/o, which means performance hit
big time. So, our default is NOT to job-log, but establish criteria for
starting one on the fly ... interactive job take an option to change job-log
to maximimum, without bothering the end users what is "behind" that menu
option ... then to get SIGNOFF *LIST, they have a different sign-off menu
option, which I can't get them to use, unless I am standing at their work
station.
GO CLEANUP kills our job-logs (disk space clutter) a few DAYS after they are
created, enough time for someone to squeak about a problem, so we move THEIR
job-log to a spool file OUTQ other than the one getting purged daily.
Without a JOBLOG, all we get from the system, is start and end times in
DSPLOG, but for SOME jobs that are under development, because of many
gripes, I have a separate MSGQ that the job sends "here I am" progress
reports to ... the job may have a string of programs ... I want to know how
long various steps take, so in the software there is
IF such & such a MESSAGE QUEUE exists, then send "progress report there"
When new software working perfectly, I kill that message queue.
Later, if more gripes, I reinstate that message queue, and analysis resumes.
My job function is almost EVERYTHING IT on the 400:
Software Development;
Operations Performance;
Computer Security (mainly adjusting who can get into what, but also trying
to decipher the security audit trail);
Computer Janitor (clean up messes, so end users don't have to know
internals);
Data Mining;
Batch Jobs which must be scheduled when no one else updating stuff, in a
corporate culture where anyone can sign on at any time (I am getting a lot
done in the wee hours);
routine tasks management won't do, like getting reports off printer,
delivered to them;
this is far from an exhaustive list.
I do have a co-worker change backup tape at site where I am not, and after a
recent power outage, when PC network would not come back up, I told someone
how to reboot the 400 (GO POWER needed a 1/2 hour window), while PC guru
told me how to reboot ma bell network.
Right now 75% of my day is filling in for a co-worker on medical leave.
Shannon ODonnell wrote
My question to your programmers would be: "You need this much information
every single time?"
That seems excessive to me unless you're having problems constantly,
in which case you might have more serious issues to address than the
number of job logs on your system.
-----Original Message-----
From: Paul E. Fenstermacher
Sent: Tuesday, May 13, 2008 5:56 PM
To: Midrange Systems Technical Discussion
Subject: Job logs
We're having a discussion about the feasibility of using a messaging
level of 4
0 *SECLVL on all of our job descriptions. This generates an enormous
amount of
spooled files that our TAA tool process has to handle. When asked why
this is
necessary the developers replied "We need the joblogs to do analysis
and
research program invocation, run times, internal command execution
review, all
internal to the logs." How do others handle gathering this type of
information
without capturing a joblog?
Paul Fenstermacher
Certified Specialist - i5 System Administration
Bass Pro Shops
417-873-5424 d
417-429-7694 c
paulf@xxxxxxxxxxx
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options, visit:
http://lists.midrange.com/mailman/listinfo/midrange-l or email:
MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment
to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options, visit:
http://lists.midrange.com/mailman/listinfo/midrange-l or email:
MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment
to review the archives at http://archive.midrange.com/midrange-l.
--
WOW! Homepage (
http://www.wowway.com)
midrange.com
