|
 CRTDBGSCP
Parameters
- SCRIPT - Something unique, whatever you want. If you've created the script with this name, it will be overwritten. If someone
else did, the command stops.
- LIB - the library that has the files you want the script based on.
- SCRIPTTYPE - You've two choices here. Use *CPYF for a simple list of CPYF requests to pull full copies of the data across. Use
*LINK to access subsets of data - you must specify at least one file to be used as a reference for subsequent extracts.
- PRIMARY1 - The first reference file for *LINK scripts. This can already contain data, or you can get the script to do it for you
(with suitable editing).
- PRIMARY2 & 3 - more of the above, but optional.
EXCDBGSCP
Parameters
- SCRIPT - The script you want to run.
- LIB - The library with the files you want filling.
- MODE - Two options. *CHK to just verify that any links and sub-scripts in your script exist. *RUN to do the check, and if
everything's okay, run the script.
Notes: The script verification option only checks link and script lines in your script. *CMD, *CALL, *CPYRCDS and any of the
*SQL directives are not checked. Those lines will just fail (gracefully) and the script carries on. Ditto if the directive is
valid, but doesn't do the expected job. Script directives are covered in more detail further on in this documentation. On the
general programming side, I'm not up on using recursive procedural calls yet. If the routine hits a script within a script, it
duplicates itself (with an incremented suffix) into QTEMP. It would probably be (slightly) more efficient to create permanent
objects of these into the DBG400 library if you find you do this frequently - DBG102R401, 02, 03, etc.
|