Chuck,
In fact, I found out that the error is issued after an ALTER TABLE:
ALTER TABLE TABLE1 DROP COLUMN COL1
On most of our systems this command works fine, but on some systems, is
has an auto reply and sometimes we can handle it in STRSQL and some
other times we can't, it answers itself.
We are implementing objects security, could that be related?
Thanks very much for your help guys
Pascal Bellerose
pascal_bellerose@xxxxxxxxxxxx
Analyst-Programmer-Helpdesk
Telephone: 819-363-6114 (2114)
Fax: 819-363-6155 (6155)
Do you really need to print this e-mail? Change your environmentality!
Le 19 Septembre, 2007 à 16:19, CRPence <crp@xxxxxxxxxxxxxxxxxxxx>
a écrit :
Both *INQUIRY and *NOTIFY messages can receive a response [a reply].
The inquiry message is for program to user communication, and the
notify message is for program to program communication. The CPF5104 is
likely a result of program to program communication, a notify message,
to which added reply list entries do not apply [entries displayed in
WRKRPYLE & added by ADDRPYLE are not used to reply to notify messages].
Overriding the behavior of the program to program messaging could
result in unexpected output.
If for example the CPF5104 was in response to a 'C' = Cancel to a
CPF5034 [duplicate key condition], and if the result could instead be
manipulated to 'I' = Ignore, then the CPYF accounting for its duplicate
key processing would have been overridden. Without that utility
knowing, understanding, and accounting for the ignored condition, its
reporting on the results of the copy request may be inaccurate. The
utility knows of the condition because it was canceled.
If there is a CPF5104 during CPYF, there is probably a Diagnostic
and
a Notify message that precedes it. Investigate the origin for the
conditions preceding the CPF5104, to resolve an error condition that
the
"Cancel reply received" message might effect.
Regards, Chuck
midrange.com
