Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: (ancient history) 668: System command cannot be executed, 255: Not in transaction

202 views
Skip to first unread message

Jonathan Leffler

unread,
Apr 7, 2006, 4:41:34 PM4/7/06
to
In December 2005, "Frank" <fmor...@yahoo.com> asked:
>I'm just trying to update a table and it's giving me the following
>errors:
>668: System command cannot be executed.
>255: Not in transaction.

Back in December, people partially identified the problem - there was a
stored procedure called from a trigger that used the SYSTEM statement
and the SYSTEM statement was failing in some way.

However, I ran across the problem again today, in a marginally
different form, and realized that the problem was in part a misleading
error message (668).

Consider the stored procedure that follows:
CREATE PROCEDURE exitfail(i INTEGER DEFAULT 0)
DEFINE cmd VARCHAR(20);
DEFINE n VARCHAR(12);
LET n = i;
LET cmd = "exit " || TRIM(n);
SYSTEM cmd;
END PROCEDURE;
* If you run it with no argument or with argument 0, you get success.
* If you run it with argument 1, you get SQL -668 "System command
cannot be executed" and ISAM -1 "Not owner".
* If you run it with argument 255, you get SQL -668 and ISAM -255 "Not
in transaction".
* In other words, choose your poison error message!
The problem is not that the system command cannot be executed, but
that the command executed and returned a non-zero exit status.

This is the top part of the PTS Bug number B176705. For the time
being, you should be aware that error 668 could be better phrased as
"System command cannot be executed or exited with non-zero status".

Dirk Moolman

unread,
Apr 10, 2006, 10:20:20 AM4/10/06
to Jonathan Leffler, inform...@iiug.org
I can confirm this. Had a similar issue about 2 months ago, with a
procedure calling a 4gl, which crashed, and gave me the same result ...


We have a couple of processes which I do not like (too long in my
opinion), like a trigger calling a procedure calling a 4gl ..... calling
......

To difficult to troubleshoot. In the ideal world, DBA's should be more
involved in the SDLC.

_______________________________________________
Informix-list mailing list
Inform...@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list

>
The information on this e-mail including any attachments relates to the official business of DigiCare (Pty) Ltd. The information is confidential and legally privileged and is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised and as such any disclosure, copying, distribution or any action taken or omitted in reliance on it is unlawful. Please notify the sender immediately if it has inadvertently reached you and do not read, disclose or use the content in any way.
>
No responsibility whatsoever is accepted by DigiCare (Pty) Ltd if the information is, for whatever reason, corrupted or does not reach its intended destination. The views expressed in this e-mail are the views of the individual sender and should in no way be construed as the views of DigiCare (Pty) Ltd, except where the sender has specifically stated them to be the views of DigiCare (Pty) Ltd.
>

Doug Lawry

unread,
Apr 10, 2006, 10:42:37 AM4/10/06
to
"Jonathan Leffler" <jleffl...@gmail.com> wrote in message
news:1144442494.8...@e56g2000cwe.googlegroups.com...

A work-around based on the above procedure follows below:

CREATE PROCEDURE system_test(result INTEGER DEFAULT 0)

DEFINE sql INTEGER;
DEFINE isam INTEGER;
DEFINE cmd CHAR(20);

ON EXCEPTION IN (-668) SET sql, isam
RAISE EXCEPTION -746, 0,
'System command returned ' || - isam;
END EXCEPTION

LET cmd = "exit " || result;

SYSTEM cmd;

END PROCEDURE;

EXECUTE PROCEDURE system_test(1);

This displays:

SQL Error (-746): System command returned 1

--
Regards,
Doug Lawry
www.douglawry.webhop.org


0 new messages