Re: Programmer sees QTMHHTTP spool file entries when signed

On 08-Sep-2016 12:11 -0600, Tom L. Deskevich wrote:

On 08-Sep-2016 11:07 -0600, Tom L. Deskevich wrote:

I have a programmer here that runs some imaging functions (5250,
not web).

When he finishes and goes back to a command line and does a
WRKSPLF, he sees QTMHHTTP entries.

I checked his job and he is signed in as himself.

I looked through the programs he is calling and do not see anything
that could cause this.

We are on 7.2.

Any Ideas?

It is possible a web service may be doing this. Not sure all that is
happening in the imaging software.
But it is something that everyone uses, and it is only happening to
him.
We are using RVI. We are using 5250 program to feed to an RVI PC
client.
[…]

Work with All Spooled Files

Device or Total
Opt File User Queue User Data Sts Pages
IQS125V1 QTMHHTTP R151PE HLD 46
QPDZDTALOG QTMHHTTP INFPGMR HLD 1
IQS125V1 QTMHHTTP R151PE HLD 46
IQS125V1 QTMHHTTP R151PE HLD 46
IQS125V1 QTMHHTTP R151PE HLD 46
QSYSPRT QTMHHTTP R110P1 IQS650V1 HLD 1
IQS125V1 QTMHHTTP R151PE HLD 46
QPPGMDMP QTMHHTTP QEZDEBUG HLD 37
QPPGMDMP QTMHHTTP QEZDEBUG HLD 37

Bottom
Parameters for options 1, 2, 3 or command
===>

Also, did check the parameters on the WRKSPLF, nothing unusual.

Of possible value to clarify: With the Option-8=Attributes [the "Work With Spooled File Attributes" panel] issued against one of those spooled files, what user profile is named on "User Who Created File" attribute, and what are the Job, User, Number and Job System Name?

Given the default for Work With Spooled Files (WRKSPLF) default to select (SELECT) for the *CURRENT user, I infer that most likely the interactive job had been /switched/ to the current user of QTMHHTTP, but has failed to switch back by the time that WRKSPLF result was requested+presented. Perhaps\¿likely?. rather than a web service producing the spools, the user is likely producing those spools per normal activity, but some prior request made in the job [probably a command request to start the "imaging software"] had obtained a profile handle to QTMHHTTP for some reason, but failed to reset the job back to the original user profile; NB that for a user being able to continue to run with the switched-to\current user as QTMHHTTP, could imply a possible concern for too much authority for that user on the system.

The results from a WRKJOB JOB(*) OUTPUT(*PRINT) followed by DSPSPLF QPDSPJOB SPLNBR(*LAST), as requested\taken from that command-line [from a re-create of the scenario] should reveal the "Current User Profile" active for that job whilst that WRKSPLF is active; that should reveal if the condition arose from what was alluded above as the "most likely" origin.