-N [ ] and -O[ ] the same
-
The first and most serious pitfall in USP is to direct stdin and stdout to the same file simultaneously, i.e:
prgm -N datain -O datain
or even worse :
prgm < datain > datain
as either of these examples will result in the USP total and immediate erasure of all data present in the file datain. Every USP user does this at least once. Perhaps if you see this here you will save yourself before it is too late. There are a few routines in USP that allow read / write access to datafiles but these are definitely the exception rather than the rule.
This happens as the input dataset is opened read only while the output dataset is opened for writing. The first thing most USP routines do is read the line header, adjust for any command line changes and write the line headers. Of course the act of writing the line header puts the EOF pointer at the start of the file and presto mondo your data is gone.
blanks after line continuation in scripts
-
Another often experienced pitfall is to leave a trailing blank in a shell script after a line continuation. The result is that the job hangs up for no apparent reason. Here is an example of the infraction:
#! /bin/csh -f
editt -Ndatain -rs 100 -re 200 |\ blank characters here
davc -Ojunk
crashing out of sr3d2 -stop while running
when running:
sr3d2 -stop
NEVER crash the job with a control C. The sr3d1 table is being appended to at this point. That file has been opened for writing. If you crash the job, the file will not be closed properly and you will corrupt your sr3d1 table. The consequences of running sr3d1 over again are quite painful if you have not made a backup table prior to running sr3d2 -stop in the first place. The obvious safeguard here is to always back up your sr3d1 table immediately after running sr3d1 and prior to running sr3d2 -stop. Also back up the sr3d1 table again after running sr3d2 -stop for at that point it has been upgraded for everything actually put into the volume. This backup will be good for the rest of the project.
Be advised that sr3d2 starts by determining the amount of disk space required to build the sr3d2 volume. It goes out there and acquires the disk then begins loading the input data and updating the table. It is not unusual for sr3d2 to run for many hours. For instance an sr3d2 -stop run on 128 Gbytes might take 5 to 8 hours.
