Denys wrote:

> This is a good solution, but the only thing I see a problem with is the
> capacity settings.

after I wrote:

> You can replace the root file if you are careful. If you have a schema
that
> matches the data sets exactly then do the following:

Please do not deride my answers, I did specify an exactly matching schema
(because
they had the schema for the database). But thank you for the instructions to
attempt to
adjust an old schema to match the actual capacities.

IMHO, every Image utility should at least ask if you want an updated schema
created
when dynamic changes are made. I attempt to keep them as <dnname>+S0 to SZ.
This also helps to document what changes were made and when.

Mike



----- Original Message -----
From: Denys Beauchemin <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, September 17, 1999 10:47 AM
Subject: Re: Missing IMAGE Root file


> X-no-Archive:yes
> This is a good solution, but the only thing I see a problem with is the
> capacity settings.  These settings are in the root file and since the
capacity
> is used in calculating the record address of master dataset records, if
the
> capacity is wrong, you will not be able to read the master dataset in
anything
> other than serial mode.
>
> The capacity setting is less important for the detail as IMAGE should read
up
> to the capacity setting.
>
> You should be able to get an exact setting for the capacity of the detail
by
> looking at the MPE record size (which contains an IMAGE block, thus the
> blocking factor) and multiplying this blocking factor by the EOF.  Detail
> datasets use whole blocks so the last one will be used completely.
>
> This is not so master datasets.  You can determine the capacity to within
a
> blocking factor variance, but since IMAGE uses the exact capacity of the
master
> to calculate the address of the record, you must be exact.  The last block
will
> probably have less than the blocking factor number of records used.
>
> What you could do is read the bitmap of the last record and see which
records
> are marked busy but yet have no entries.  This will indicate to you what
the
> exact capacity setting should be, (eof-1 * BF + number of free or valid
records
> in the last block.)
>
> Of course, if you already know the capacities, then you are in great
shape.
>
> Do not despair, this should be recoverable.
>
>
> Kind regards,
>
> Denys. . .
>
> Denys Beauchemin
> HICOMP
> (800) 323-8863  (281) 288-7438         Fax: (281) 355-6879
> denys at hicomp.com                             www.hicomp.com
>
>
> -----Original Message-----
> From:   Mike Hornsby [SMTP:[log in to unmask]]
> Sent:   Friday, 17 September, 1999 8:42 AM
> To:     [log in to unmask]
> Subject:        Re: Missing IMAGE Root file
>
> John,
>
> You can replace the root file if you are careful. If you have a schema
that
> matches the data sets exactly then do the following:
>
> 1. create a separate group called dbtemp, and home yourself to that group
> then,
>     file dbstext=dbschema
>     run  dbschema.pub.sys;parm=1
>     run dbutil.pub.sys
>     create dbname
>
> now you should have an empty data base with a good root file, but in the
> wrong group.
>
> 2. store the root file to tape
> 3. restore the root file using the group= option
>
> At this point you should have a good root file in the correct group.
>
> As a final point: Like running buldacct to get an alternative directory
> source in the full backup, it is also a good idea to run Adager or some
> other utility to create a know good schema on a periodic basis.
>
> TGIF!
>
> Mike Hornsby
> Beechglen Development Inc. (www.beechglen.com)
> Co-founder/Chief Technical Officer
> 513-922-0509
> [log in to unmask]
>
>
> ----- Original Message -----
> From: John Korb <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Friday, September 17, 1999 9:13 AM
> Subject: Missing IMAGE Root file
>
>
> > I was just notified that a Navy site tried to run a "once a month"
> > application this morning and it wouldn't work.
> >
> > In checking it out, I found that the IMAGE root file for the database
does
> > not exist.
> >
> > And it gets worse.
> >    1) Their backup tapes are "recycled" every two weeks, and apparently
> >       the root file is NOT on ANY of the existing backup tapes.
> >    2) They had been doing DBSTOREs of the database once a month, but
> >       due to a DDS1 drive problem, there was no DBSTOREs after last
> >       month's run.
> >    3) The input data used to perform last month's updates is also long
> >       gone.  Thus, the only copy of the data is what is on disc in the
> >       datasets.
> >    4) They don't have ANY database utilities other than:
> >       a) those that are a part of FOS
> >       b) the Dictionary/3000 utilities DICTDBU and DICTDBL.
> >
> > So, if the datasets cannot be recovered from disc, the database is lost.
> >
> > They have the schema for the database, so it can be rebuilt, but with no
> > DBSTORE and no backup, there is no data to populate the database.
> >
> > To me it looks like they are SOL.  I don't have an IMAGE HANDBOOK here,
or
> > I might be tempted to do a little bit twiddling and see if I could fool
> > IMAGE into thinking that the date/time stamp on the root file matched
the
> > datasets, etc. and see if I could do a serial read of the datasets.  I
> > guess another option would be to write a PM program to open each dataset
> > and try to copy the data to flat files.
> >
> > Does anyone have any suggestions?
> >
> > Thanks,
> >
> > John
> > --------------------------------------------------------------
> > John Korb                            email: [log in to unmask]
> > Innovative Software Solutions, Inc.
> >
> > The thoughts, comments, and opinions expressed herein are mine
> > and do not reflect those of my employer(s), or anyone else.