× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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)


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.