The >> stages were all added in an attempt to determine the location of the problem. They did not exist in the pipe that had the RC=70. Nor do they exist in the pipe having the single "copy". In it, the only output driver follows the "not lookup".
There may be something to the SFS conflict idea. One of the two files read by the second stream is in SFS. However, the directory was accessed R/O and the only things that update files in it run during the off hours. Still, it is difficult to believe that a single copy in the first stream would clear a lock conflict in the second. This will remain a mystery. The copy stage is not needed today. I removed it and the EXEC runs to completion. Logging off seems to have been the cure. Maybe the PC Help Desk folks are onto something. Regards, Richard Schuh > -----Original Message----- > From: CMSTSO Pipelines Discussion List > [mailto:[email protected]] On Behalf Of Glenn Knickerbocker > Sent: Monday, April 06, 2009 3:46 PM > To: [email protected] > Subject: Re: Schroedinger's Cat > > "Schuh, Richard" wrote: > > This Pipe was failing with an immediate RC=70. > > That's got to be from one of your CMS commands, not > Pipelines. RC 70 from Pipelines (PIPE AHELP 70) is: > > 70E Incorrect OS record descriptor word X'<hex>' > > Not something you're likely to be running into in the output > of CMS commands. RC 70 from many CMS commands (HELP CMS RETCODES) is: > > 70 File sharing conflict. This includes locking conflicts and > failures caused by uncommitted changes. > > Maybe writing the intermediate output or delaying the record > is breaking up some conflict of timing in your other output > from the pipeline. Any chance you have two >> stages trying > to write to the same SFS file at the same time? > > ¬R >
