Re: DSCJOB gives CPF1389

Not an answer, but if interested in debugging it...

If that message is specific to prior use of STRPCO in the session, then it is possible that the command request is being made without the knowledge of the user\programmer. There is most notably, both the initial and routing programs, which could have requested that command invocation; an attention program is unlikely, but possible. The user should issue DSCJOB upon signon, to see if PCO is active upon the start of the job versus only after some action within the job.

I am not sure what configuration options are in the client [I have never used it; apparently, one way is by a plugin?] that could effect the STRPCO invocation in a session, but perhaps by use of a macro, for example as part of an automated signon used by that user\programmer. A review of the configuration for the session with the issue is probably worthwhile, and maybe even a search of files on the PC for the string 'strpco'.?

If the STRPCO feature is unused nor expected to be used anywhere, then by temporarily moving the STRPCO *CMD out of QSYS or renaming it, would likely cause [surely for explicit] invocations to fail with an error stating /command not found/, which could help identify where the command is unexpectedly being used. Instead of making a failure as cause to investigate, auditing the command object would have less impact. Using auditing requires a review for the usage of the command since auditing was started, until after both the next restart of the client by that user\programmer and when he sees that PCO is again active in their session.

Exception for either of those possibilities to find origin, is if there exists a non-command method that is being used to start PCO. Or of course, if there is some defect for which the job is indicated to have PCO active, when in fact PCO is not active. Pursuit as defect would seem appropriate after verification [best as can be inferred] that the job is not invoking STRPCO.

Regards, Chuck

Steve McKay wrote:

I am trying to configure our PCs to disconnect when the QINACTITV
system value expires. This works beautifully for all but one PC.
This particular PC produces a CPF1389 (Disconnect Job (DSCJOB)
command not allowed for this job at this time. Job
433089/VICKB/VICKBA1 cannot be disconnected because PC organizer or
PC text assist is active.) in the job log. This message used to be
produced when STRPCO was used from the PC (back in the Client Access
days) but I'm certain that is not the case here.

PC is Win XP Pro with iSeries Access V5R4M0 service level SI20465.
iSeries is V5R4M0 with latest PTFs.

I have asked the user (programmer) if he is using RMTCMD or STRPCCMD
commands or iSeries Navigator plug-ins but he says he is not.

Any ideas what may cause CPF1389?