Even more on 'a safer method': possibly the safest method of all

One comment to these blogs basically said that the PAR parameter in the initial INPUT step doesn't have to be the same as the implicit PAR parameter in HTMLCURSOR. Bearing this in mind, I wrote a new procedure that has the following intermediate step between the INPUT and HTMLCURSOR steps.

SELECT :$.PAR INTO :OLDPAR FROM DUMMY;
LINK CUSTOMERS OLD TO :OLDPAR;
SELECT SQL.TMPFILE INTO :$.PAR FROM DUMMY;
LINK CUSTOMERS TO :$.PAR;
DECLARE CUR CURSOR FOR
SELECT CUST, CUSTNAME
FROM CUSTOMERS OLD
WHERE CUST > 0;
OPEN CUR;
GOTO 300 WHERE :RETVAL <= 0;
LABEL 100;
FETCH CUR INTO :CST, :CNAME;
GOTO 200 WHERE :RETVAL <= 0;
LOOP 100 WHERE RSTRIND (:CNAME, 1, 1) <> '0';
INSERT INTO CUSTOMERS (CUST, CUSTNAME)
VALUES (:CST, :CNAME);
LOOP 100;
LABEL 200;
CLOSE CUR;
LABEL 300;
UNLINK CUSTOMERS OLD;
UNLINK CUSTOMERS ;

This actually works! Obviously I'm taking an arbitrary range of customers but one that meets the criterion of having a number that ends in 0 does have orders and the procedure does create a report of orders for this specific customer. In the real program, a series of tests are run, and only customers that pass these tests are inserted into the linked table.

This method is the safest and easiest - no deletions, no external tables and one person can run the report more than once concurrently with different parameters.

One reason why my previous tests using STACK as an intermediate table failed is that the new record has to be inserted with both the A and U keys (cust and custname respectively). STACK only has one field into which I was inserting the A key; looking at this now in retrospect, it's clear that this wasn't sufficiently as every tuple has to have a value for the U key.