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?
midrange.com
