1. modify qprep's output file extensions. currently they make no sense. the output file get's named .pst, but the preamble is translated, so the output file should really be called .pbs or .nqe or .... 2. change qprep man page to include total_cpus as an option. 3. clarify documentation so implementer understands what qprep does when both key and value of an option in the translation table are set to []. this is done in localQprep.pm::qprepInitCallback() and in qprep.pm::qprepTranslationTableInitialize() (for ALL). 4. for completeness, export qprepPostTranslationCallback() in localQprep.pm 5. get rid of duplicate specification in qprep output: if qprep translates a directive for the user, it should make sure that directive does not appear twice. if it looks like by entering the desired directive qprep will produce duplicate entries, then qprep should replace the existing one with the new one, i think. this goes for the first line that specifies the shell as well. the subject here has to do with the preamble AFTER translation. the user might have hard-coded preamble entries. when qprep is envoked and new values are specified, you could end up with the same info twice. i propose that once qprep understands the target_directive_prefix, it should then read the existing preamble and store it. if it them attempts to write output that duplicates some existing preamble, it should then either substitute its directive (if the value occured as a PST directive) or disregard its value (if it attempted to specify the default because it did not detect the directive). now the issue is when to make the comparison. there are two ways to do this. METHOD 1: the first way is to attempt a reverse translation of the existing preamble, mapping the existing preamble onto the appropriate qprep syntax. METHOD 2: the second way is to translate qprep's directives to the local syntax first, then compare the result with that for the existing preamble. problems arise when there are multiple ways to specify the same result. for example, when METHOD 1 is attempted, there may be specifications encountered that do not (reverse) translate to anything in qprep's list of directives because chose to translate the result in a different manner. these existing directives will then translate to qprep's catch-all directive. the duplicate information may be specified with different directives of the local queuing system. behavior may not be as predicted, unfortunately. the only way to avoid this is to not allow an existing preamble with directives specific to the local queuing system, but this would be unfortunate, i think. the problem with attempting method 1 is it requires a reverse translator. this may not be too big a deal, but i don't want to think too hard about it just now. so i think we should start by attempting METHOD 2. recognize though that when a reverse translator exists, the problems encountered in either method are presumably delt with, i.e., decisions are made w.r.t. handling potential redundancy, so a reverse translator would make METHOD 1 fairly trivial, i think. the problem with METHOD 2 has to do again with the potential for the local queuing system to permit multiple ways to achieve the same queue behavior. hence, qprep may choose one implementation that it does not recognize as conflicting with a way that is specified in the existing preamble. what's a guy to do? for now we go with METHOD 2. 6. mike set up qprep to spit out an output stream for the preamble. this causes a problem. if qprep is not specifying the first line (shell specification), and a first line already exists, then the first line can get pushed down. ... 7. incorporate erdc batch script generator in the pstoolkit.nwra.com website. 8. add mail=n option 9. permit multiple instances of target_script_directive & target_cmd_line_arg. what if you want to submit multiple commands that are not included. i think, at least with nqs, that you must include each item on its own line. currently qprep catches multiple entries and only includes the first. this may be fine for other directives, but not this one, i think. 10. qprep on jim thought stderr-file and stdout-file were same when they weren't. the offending file is below. obviously qprep on jim is wrong. #!/bin/csh -x # specify jobname for batch job #PSTQ job_name = batch-job-name # specify filename for standard output #PSTQ stdout = stdout-name # specify filename for standard error #PSTQ stderr = stderr-name # have mail sent at job end #PSTQ mail = e # have email sent to the given address #PSTQ mail_to = werne@co-ra.com # name of queue to use #PSTQ queue = challenge # walltime requested for job #PSTQ wall_time = 02:00 # specify number of processors #PSTQ total_cpus = 10 # PSTQ submit=y #PSTQ END_OF_PREAMBLE # Warning: Batch specific command # directory where script was executed becomes current directory cd ${QSUB_WORKDIR} # Command used to run the job mpprun -n 10 executable-name 11. -eo option should be default if stderr and stdout are same. when running qprep on jim, i set stderr and stdout at the same file. this shoud automatically result in the -eo option being set, but it is not on jim. fix this! 12. make sure target_script_directive does not specify the target directive prefix. he target directive prefix should get added by default by localQprep.pm you are in the process of editing: /u/werne/PST/TUSC/other_sites/localQprep-NQS-ERDC.pm get rid of double output for time info. before including a #!/bin/csh (or equivalent line), strip off the existing line (or comment it out). read comments in qprep.pm. study qprep.pm. make sure mail works (it doesn't seem to now). 13. write an on-line installation tutorial for qprep 14. rerun=y|n -- we intended to do this, but we didn't. 15. strip leading and trailing blank space from user-passed qprep arguments. see email from dan duffy (pst-dev email) on 7-12-2002 16. add "host" as a new qprep directive so that #PST host=silicon will get translated into the LSF #BSUB -m silicon see jeff hensley email dated 6-26-2003 at 10:09am