At our site, we allow the application developers to use all tools that they
want, including LOAD, on the development system or development enviroment.
We allow them nothing in the production environment, even no INSERTs or
UPDATEs. It is very easy to corrupt the production data using a batch job
with DSNTEP2, for example, and SQL UPDATE. This is IMHO not a matter
of LOAD or no LOAD.
If in rare cases that there are some corrections to be made in production by
SQL, this has to be a DSNTEP2 job (or better: home grown tool with more
protocol capabilities) which has to pass the same quality controls as any other
The home grown tool, by the way, is able to trigger INSERT and UPDATE SQLs
from records in flat files, so it is a perfect substitute for LOAD, DSNTEP2, DSNTIAUL
etc.; the difference to LOAD is that it does not support LOG NO etc, and it goes
thru normal SQL processing, so it is slower. Input and output data may be different
formats, for example fixed columns, CSV, XML. And: you can specify that COMMITs
be made every n records.
Am 22.11.2013 22:49, schrieb T.W.:
> We allow the application area to run load jobs to insert into tables
> all though we have been asking for them to convert to a batch job
> to insert data. These are LOG YES loads with DISCARD 1. If they
> abend the data is fixed and resubmitted or DISCARD is changed to 0 and
> resubmitted. DB2 will start from the last check point and continue
> Because we use RI heavily for this application doing a load can fail
> (parent key is missing). I posted this as one pitfall of using RI in
> another thread. Also if there is a duplicate key on the input data
> they will fail.
> Another application we also allow loading but for that they use a
> vendor product we have and not an IBM utility load. Originally this
> application was vendor boughten and because the batch programs
> used for updating or inserting, deleteing, was too slow they now
> unload the data, make changes and load it back. This application has
> no RI.
> -----End Original Message-----