DBG/400 logo

Home   Back   Next
bullet point

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.

screenshot

bullet point

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.

screenshot

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.
Home   Back   Next