Some notes on debugging pshare source code

by Rob Andre

This is done the same way as in your own distribution using dbxadd,uplink ... debug, etc while logged in as pshare.

I usually reset the debug directory $DBGDIR to ${DBGDIR}/../randre/debug when I am pshare so I do not interfere with other pshare debugging. Having the debug directory path end in a directory called "debug" is necessary for some of the scripts.
Adding or removing a file from a library or executable requires a rebuild of the makefiles using "cmsmms" or "makelink". A change which extends over several libraries or requires one of the global code generators (do_build, trdatgen, plotgen) to run is probably better left for a full pshare update from cvs.
With the change in runtrx, if you modify a library file you will need to also uplink trdat and pretr if they depend on it. It would also be wise to uplink transp to verify it can link properly. The actual transp executable used by a production system job is built by runtrx when the job is submitted. So to restart a production system run containing a modified file used by transp execute,

  tr_restart <runid> link    # to relink transp and restart from last restart time
or
  tr_restart <runid> delete   # to relink and start from scratch

If you modify a source file defining a module it would be wise to run linkcheck when done. It may be necessary to run linkcheck twice to satisfy all the make dependencies. This should be safe since linkcheck has a locking mechanism to prevent it from being called simultaneously.
A good method for debugging pshare is to experiment with modified source files in $DBGDIR then move these to the $CODESYS/source source tree when done and run uplib,uplink,...
If the production system breaks or the full rebuilding of a library or executable may take some time (nubeam), you can turn off the production system queue with
  pshare_deactivate "my message"
and turn it back on with 
  pshare_activate "some other message"

A nightly cron job will execute "code_daemon" to check that the production system code is built correctly.


runtrx

The operation of runtrx and runtr is changing with respect to how it handles out of date source code files. Previously, if an out of date source code file in one of the executables or libraries used by pretr,trdat or transp exists when runtrx (or runtr) is called, then it would be compiled and the executables relinked before running pretr,trdat or transp. This is causing problems with the production system when user jobs try to simultaneously recompile an out of date file. So this feature is being removed from runtrx.


TRANSP Production System
Last modified: Wed Oct 22 11:59:51 EDT 2003