Michael,

Well you got the memory jogged.  I had been going through the HP intrinsics
manual but, well.....got your note and said "Ah!" and turned to the SMUG
book.
Nope not there, at least that I could find readily.  I think it must be in
one of the
two books that Eugene Volokh wrote dealing with all kinds of stuff - got 'em
at
home which is no help here (duh).  One is from umm mid '80's and it was
updated
to include MPE/XL in, errr, 1991?  Anyhow, as long as whoever is looking for
that
Image/3000 handbook from Wordware, you might as well dig up the SMUG book
from Robelle and the HP3000 Handbook(s) from Vesoft if you want to be well
equipped.

I might mention that none of the three manuals is going to tell you how not
to forget.

Anyhow, as a reward for Michael solving my problem and jogging my memory I
have
decided to send Cooter over to his home for a couple of days.  Solves both
my
problems.  Enjoy.

Back to reality.  Thank you Mr. Anderson.  Very much.

Jim Trudeau

> -----Original Message-----
> From: Michael Anderson [SMTP:[log in to unmask]]
> Sent: Monday, February 08, 1999 12:21 PM
> To:   [log in to unmask]
> Subject:      Re: Where's the file?
>
> James,
>
> This is not necessarily a COBOL thing, it's an "MPE NEW FILE" thing. Cobol
> by
> default creates a "NEW" file. No matter what Language, the following is
> always
> true:
>
> When you create a file, you can indicate to the file system that it is a
> new
> file (COBOL DEFAULT); it has not previously existed.  Space for this file
> has
> not yet been allocated.  As a new file, it is known only to the program
> that
> creates it, and exists only while the program is being executed.  When the
> program concludes, the file simply vanishes, unless you take actions to
> retain
> it.
>
> I call this "MPE's third file domain" (NEW), or Scratch file domain.
>
> A file need not always stay in the same domain.  Any disk file can be made
> permanent, or can be deleted when it has served its purpose.  The FILE
> command
> can be used to change the domain of a file.  The DEL, TEMP, and SAVE
> parameters
> determine what happens to the file when it is closed.  FCLOSE may override
> the
> DEL,TEMP,SAVE in the file equation, using the disposition parm.
>
> If you don't want your work files to vanish, you may want to look at
> programmatically checking for a file equation before opening the file, or
> the
> existence of a PERM or TEMP file. Or you could use a file info intrinsic
> to
> verify the files domain before writing to it. Because when the program
> closes a
> file,  if it is a NEW file, that is open for writing, it remains in that
> "NEW"
> domain, you can't save it, it's gone.
>
> Hope this helps, say hello to Cooter for me.
>
> Regards,
> Michael Anderson
> Houston Texas.
>
>
>
>
>
> Trudeau, James L wrote:
>
> > Howdy,
> >
> > I checked the bit bucket but someone already emptied it
> > so I don't know where these fifteen files I worked yesterday
> > to get went.  I'm simple minded enough to keep the story
> > simple - I think.
> >
> > So in the program (COBOL) there is a select PARTS and
> > with it an assign to MFGPARTS.  Vanilla stuff,  no file types
> > sizing or anything, just ASSIGN TO "MFGPARTS".
> >
> > In the stream file we have:
> >
> > !purge MFGPARTS
> > !file MFGPARTS;disc=350000000;rec=-530,15;save
> >
> > So Cooter comes along and changes the file statement to:
> >
> > !FILE VNDPARTS;disc=350000000;rec=-530,15;save
> >
> > Now we run the job.  There are no errors in the sysout save
> > the File "MFGPARTS" not found. No purge done. (CIWARN 383)
> > message which is OK there was no file there.  There also is no
> > file after the job is run :-()  There is a report file of all the
> production
> > data that it deleted but there is no MFGPARTS file.
> >
> > So the screw up is that MPE/iX, bless it's heart, found no VNDPARTS
> > file and created it in the temporary job domain and when the job closed
> out
> > to bit city they went.  Ummmm......seems to me that it used to be that
> when
> > the OS did this the file was created with record lengths and such as
> defined
> > in the program and the file length was 1024 records.  Ladies and gents
> that
> > program wrote to MFGPARTS and then deleted from the Image database
> > over 1,118,000 records.  Yep we got big bit buckets in Texas, but this
> is
> > a bit much.  My guess is I'm wrong about the file length being 1024
> records
> > although I've been burned by this before.  Any guesses while I beat off
> the
> > users and get the production base glued back together?
> >
> > OS is 5.0 express 3 and has not been patched for over a year.
> >
> > Jim Troubled