× 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.



LOL Joe! Yes I did throw in a lot of things in this sink! And I just found the answer. I have to modify my combination of the data.

What happens is, the job that CAUSES a job to end from a job queue is the one that gets the CPF1164. The job in question was ended from the job queue, and it never received any ending message in the history log, but the ending job did. Hmmm!

I see my problem now - I was linking the row#1 records for CPF1124 and CPF1164 based on job information, hence getting 2 records from there for the job. Then linking to the data in row#3 - I have to change these around!! I use the join ID - the first 8 bytes that is the TOD for the message - from the CPF1124 message to get the start time - it goes to microseconds, where the time in the message is only down to seconds.

Thanks for the push to look further - love having a blank wall - and calling you that IS a compliment!!!

Regards
Vern

At 03:27 PM 3/9/2008, you wrote:

Vernon Hamberg wrote:
> I'm analyzing elapsed times for jobs, using the data in the several
> QHST* files on a system. I copy the first record for the CPF1124 &
> CPF1164 messages into one file, and the third record for the CPF1164
> message into another file. I take the first 8 bytes and convert to a
> timestamp - that value is the join ID for the rows for a given
> message, but it is the MI TOD for the time the message was sent, so
> it seems it is usable for start and end time for the job.
>
> What I see is that some jobs, mostly server jobs, have multiple end
> times for the same start time, same job. Here is an example of counts
> for grouping by job name, job number, and start time.
>
> PCDMAA 863696 2008-03-03-11.58.24.361112 7
> QTCPIP 743863 2008-03-02-10.23.47.283288 17
> QSQSRVR 458037 2008-02-28-18.38.12.996880 2
>
> The first job is an interactive job - the others are server things.
>
> So what's up? Fortunately, this behavior does not affect the stuff
> I'm analyzing, just curious.
>
Well, you've thrown a half dozen variables into the mix, including how
you copy records out of the history file and how you do your
conversions. But assuming everything is copacetic, then what you're
describing is having multiple CPF1164s for one CPF1124. That's highly
unlikely so what I suggest you do is dump the the timestamps of the
multiples, then use that to go back against the QHST file to find the
matching messages. Print the actual messages from the log which have
produced the single CPF1124 and the multiple CPF1164s.

One of two things: you have multiple CPF1164s, or your program is
incorrectly identifying some records. I'll be interested to know the
answer.

Joe
--
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.


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.