Re: unrecognized thread in interactive session job log

On 18-Feb-2016 12:31 -0600, Jim Franz wrote:

On 18-Feb-2016 12:09 -0600, Buck Calabro wrote:

On 2/18/2016 12:30 PM, Jim Franz wrote:

On 18-Feb-2016 10:18 -0600, Jim Franz wrote:

This pc was compromised by malware - we are looking at all the
logs during the infection.
Not all interactive logs have this thread text.
A quick view of other logs don't show anything like it.
Every log entry for several hours has that "Thread 000000CD"
text


MSGID TYPE SEV DATE TIME
FROM PGM LIBRARY INST TO PGM
CPF1124 Information 00 02/16/16 13:09:21.461278
QWTPIIPP QSYS 04C0 *EXT
Thread . . . . : 000000CD
Message . . . . : Job 789461/DAVEX/CL7328AC started on 02/16/16
at 13:09:21 in subsystem QINTER in QSYS. Job entered system on
02/16/16 at 13:09:21.
CPF2451 Information 40 02/16/16 13:09:21.942945
QMHCHMSQ QSYS 092E *EXT
Thread . . . . : 000000CD
Message . . . . : Message queue DAVEX is allocated to another
job.
[...]

a clarification - of 6 different interactive job logs during the
infection, this is the only one with the thread text. also the
log is 40+ pages and every single entry has the Thread . . . . :
000000CD

Is this thread text common or unique and should we worry about
it.

Was Dave [user DAVEX] using QShell or PASE?
I see messages about threads in my PASE job logs.
I would think that anyone who uses multiple threads would have
something like this.

Definitely not qshell or Pase - old green screen RPGLE/DSPF/CLLE
app. We have hundreds who use this application and I don't see the
thread stuff in any others. This is Win 7 pc with IBM iAccess for
Windows v6.0 (system at 7.1)
There is a IBM Content Manager client on same pc for viewing and
interacting with images stored on Power i image catalogs. I have
viewed other logs and Intrusion Detection logs in Navigator and
cannot see anything other than this.

Thought this worthwhile to share in the original thread of the OP [at least for the NNTP interface; thus the necro-posting, for the original topic thread: [http://archive.midrange.com/midrange-l/201602/threads.html#00518]

Almost surely, nothing to be concerned about with that thread identifier being shown in the job log of the interactive job.

IIRC, whenever a job has more than one thread active, whilst the Display Joblog (DSPJOBLOG) [i.e. pgm QMHJLOG] starts processing against that job, then as part of /consistent/ formatting of the joblog, *all* logged message entries spooled, will have included the Thread Identifier associated with that message. Presumably a Work With Job (WRKJOB) [for the Job Run Attributes (*RUNA) details], viewed\spooled at the time as that DSPJOBLOG, would have shown a "Threads" value of greater than one.

Normally 5250 jobs will not have multiple threads; IIRC, because reading from and writing to Display Files is not thread-safe. But some functions like Query activity will perform threaded work, despite the query being run in an interactive job. As I recall, an interactive job can only be started with the Allow Multiple Threads (ALWMLTTHD) setting of *NO, however, the operating system can initiate multiple system-threads irrespective that allow-attribute setting for the job.

If the application [or separately the user] had performed some query activity that ran with multiple system-threads, and there was [either an active query or] a SQL pseudo-closed cursor [an Open Data Path (ODP) that remained opened] for which that multi-threaded query ran, then [I seem to recall that] the query feature leaves [at least one of] the threads active, pending a full-close of that ODP. There also may be other system functions that might have the job start additional system-threads, but most are unlikely to keep threads active whilst the user\application continues processing throughout the day; meaning, the joblog would have to have been spooled in a more specific window of time while those threads remained active, than for a job that anytime previously ran some queries for which the threads were kept active for the potential reuse of that query.