What version of Vision do you use, Version 3, 4, 5? Have you tried using vutil --slow  ? Are your files using compression and if so, what % of compression and for how long? vutil can remove compression. If you've been compressing files at a high percentage for long time, the may be data in the file that aren't actually records.

Thank you for your reply.

Sorry if I am asking some basic questions, as I am new to this environment.

1. How can I check the version of Vision?

2. Here is the info of the file I am trying to rebuild

# of records: 148967
# of deleted records: 0 (0 0)
file size: 33329664 (/home/kumar/test/restored/osfile)
file size: 12193792 (/home/kumar/test/restored/osfile.vix)
total file size: 45523456
segment size: 1073740288
record size: 380 compressed
# of keys: 4
user count: 6

I just tried with vuit - rebuild filename and vuitl - rebuil -k 0, vuitil -rebuild --slow filename. All these returned records lost.

I am not sure how to use this ifno -  what % of compression and for how long? vutil can remove compression

Appreciate any help please.

vutil -info   will provide the Vision version, since you have both data and key files - your data is at least Version 4

The output shows user count of 6 which means that the files was not closed correctly - people doing cntl-alt-del of kill signal on Unix / Linux

vutil -zero will reset your user count

vutil -rebuild -c will remove compression

finally, do have the Select and FD for this file. If so you can use the Acu compiler to make an XFD. Then you can use a utility program we provide called alfred. Using alfred and an xfd allows you to see each record. And edit the record if you choose to.

Please see below info of teh file.

1. Version of vision is 5

2. I reset the user count to 0 vutil -zero and tried vutil -rebuild. It still shows data loss

3. Also I tried vutil -rebuild -c filename. Shows data loss.

Really appreciate if you can help me understand the Select and FD for this file. How can I can use the Acu compiler to make an XFD and proceed further o recovery, please. 

A select statement defines the file and it's keys.

SELECT FD1
ASSIGN TO DISK "osfile"
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
FILE STATUS IS my-stat
RECORD KEY IS FD1-name.

Now the FD defines the data layout of the items in the file

FD FD1.
01 FD1-rec.
   05 FD1-name PIC x(20).
   05 date-test.
          10 FD1-day PIC 9(2).
          10 FD1-mnth PIC 9(2).
          10 FD1-year PIC 9(2).

Many COBOL shops have these as copybooks, it's possible you may have osfile.sl and osfile.fd but your file extensions may differ. If you have the files or the program that contains the Select and FD for osfile, then compile that program using -Fx

ccbl -fx myprog.cbl   or ccbl32 -fx  myprogcbl  - the output of that compile would make osfile.xfd.   You can use alfred without an xfd but it much more intuitive when you have an xfd.

Thank you for the response.

I will look to see if we have the Cobol program with select and fd.

Once we have the xfs, how can I get alfred utility to use the file, please. Thank you once again

Not sure if you're on Unix/Linux or Windows. On Unix/Linux, wherever the Acu is installed, there should be a tools directory, same level as the bin directory. If there is alfred.acu is in there You use the runtime runcbl alfred  - alfred presents 2 entry-fields, the first for the location and name of the file, the 2nd for the location and name of the xfd - from that point alfred has menus to do starts based on keys and their values.  See Unix security, as alfred has the ability to edit files

https://supportline.microfocus.com/000/alfred_users_guide_tcm21-18377.pdf

On Windows, you'll find it as a sample program.

Unfortunately there's no single or guaranteed way to recover records from a broken file.  For example, if half the data segment has been overwritten with zeros, those records obviously aren't being recovered.  You may or may not have luck using our standard tools to access the file, depending on how it is corrupted.

They said that you tried vutil rebuild -k0, -k1, -k2, but they didn't say -k3 (info says 4 keys), or with no -k option to read the records directly from the file.  Make sure they try those two options.

Another thing you can try is vutil -unload with -k on each of the keys, and with -r to read the records directly from the data segment.  Then, take each of the unloaded record files and try to vutil -load them into a new file using the -s option to ignore duplicates.  This may give you an idea of how many records have not been recovered from the file.

OK. I am able to locate an existing osfle.xfs. Can you suggest where I can download alfred tool for Windows, please. Thank you.

what version of the runtime due you have for Windows?

Sorry, Realized that there is no AcuCobol run time environment on Windows. I tried onLinux.

It shows error Can't find entry for 'xterm' in '/etc/a_termcap'...

Thank you.

I don't know your environment, lets say you have the runtime runcbl in

/opt/bin

do an ls in opt .. see if there is an etc directory. If so

export A_TERMCAP=/opt/etc/a_termcap

export A_TERM=vt100

Running this command

/usr/local/bin/acu8.1/runcbl alfred /test02/df/0938/osfile /test01/new/xfd/osfile.xfd

Getting error as 

 *===========================================
                                                             |                                           |
                                                             |  alfred: Program missing or inaccessible  |
                                                             |                                           |
                                                             |                   <Ok>                    |
                                                             |                                           |
                                                             -------------------------------------------

do a search for alfred

cd /usr/local

find ./ -print | grep alfred.acu

lets say you find it in /usr/local/bin/acu8.1/tools

/usr/local/bin/acu8.1/runcbl     /usr/local/bin/acu8.1/tools/alfred.acu

Executed command

/usr/local/bin/acu8.1/runcbl /tstsql/new/pro/alfred/alfred.acu /test02/df/0938/osfile /test01/new/xfd/osfile.xfd

 *==============================================================
                                                   |                                                              |
                                                   |  Memory access violation                                     |
                                                   |  COBOL error at 000029 in /tstsql/new/pro/alfred/alfred.acu  |
                                                   |                                                              |
                                                   |                             <Ok>                             |
                                                   |                                                              |
                                                   --------------------------------------------------------------

wow, not sure why you're getting a mav.

Does running this also mav

/usr/local/bin/acu8.1/runcbl /tstsql/new/pro/alfred/alfred.acu

Did you see this post I made .. 

Unfortunately there's no single or guaranteed way to recover records from a broken file.  For example, if half the data segment has been overwritten with zeros, those records obviously aren't being recovered.  You may or may not have luck using our standard tools to access the file, depending on how it is corrupted.

They said that you tried vutil rebuild -k0, -k1, -k2, but they didn't say -k3 (info says 4 keys), or with no -k option to read the records directly from the file.  Make sure they try those two options.

Another thing you can try is vutil -unload with -k on each of the keys, and with -r to read the records directly from the data segment.  Then, take each of the unloaded record files and try to vutil -load them into a new file using the -s option to ignore duplicates.  This may give you an idea of how many records have not been recovered from the file.

yes