You're both missing the point of Glenn's question. The "DISK" driver, as opposed to the "<" driver, normally doesn't complain or present an error if the input file doesn't exist. It just presents EOF. It appears, however, that it indeed ends with an error (119) if a specific filemode is named and there's nothing accessed at that filemode. I've not run into it before, but would consider it unexpected behavior. And Glenn, it does look like state or equivalent test is needed for your situation. Note that state even returns a different return code (36) for an empty filemode as opposed to the 28 for file not found, and maybe that's why DISK's behavior differs. -- Mike Harding z/VM System Support
[email protected] [email protected] [email protected] (925) 926-3179 (w) (925) 457-9183 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) CMSTSO Pipelines Discussion List <[email protected]> wrote on 11/11/2009 12:57:34 PM: > From: Paul Gilmartin <[email protected]> > To: [email protected] > Date: 11/11/2009 12:59 PM > Subject: Re: DISK minus filemode validation > Sent by: CMSTSO Pipelines Discussion List <[email protected]> > > On 11/11/09 13:46, Frank M. Ramaekers wrote: > > I get: > > > > pipe < dummy dummy * | hole > > PIPDSR146E File "DUMMY DUMMY *" does not exist. > > PIPSCA003I ... Issued from stage 1 of pipeline 1. > > PIPSCA001I ... Running "< dummy dummy *". > > Ready(00146); T=0.01/0.01 14:45:58 > > pipe < profile exec * | hole > > Ready; T=0.01/0.01 14:46:06 > > > > What do you want to do if the file doesn't exist? > > > There's a more general underlying question: Is there any way > to trap such errors, diagnose, and recover? > > I don't know the OP's need, but a plausible recovery action > might be to create the file and initialize it with a header > record containing a timestamp. > > -- gil
