I'm having problem to form the field section's structure into xfd files after analyse by issuing commnad "vutil32.exe -i -kx pogl.dad". I hope somebody could help me out how to form out field structure as highlighted in below. I've uploaded sample of my file known as "pglc.dad" i hope soneone could guide me how to form .xfd file from his expert skills and guide me.Thanks
Result from vutil32.exe
file size: 250880
record size (min/max): 121/1024 compressed(80%)
# of keys: 4
key size: 16:02 31:03 56:03 15
key offset: 0 0 0 1
duplicates okay: N N N N
block size: 512
blocks per granule: 1
tree height: 4/2/2.7
# of nodes: 200
# of deleted nodes: 1
total node space: 101800
node space used: 67463 (66%)
user count: 0
Key Dups Seg-1 Seg-2 Seg-3 Seg-4 Seg-5 Seg-6
(sz/of) (sz/of) (sz/of) (sz/of) (sz/of) (sz/of)
0 N 1/0 15/1
1 N 1/0 15/66 15/1
2 N 1/0 40/81 15/1
3 N 15/1
Here is my further construction of .xfd file.
XFD,02,PGLC,PGLC
00300,00041,004
1,0,013,00000
01
PGSTAT
3,0,004,00004,020,00021,004,00000
3
PGSTAT
PGDESC
PGLINE
3,0,004,00004,008,00013,004,00000
03
PGSTAT
PGDESC
PGLINE
1,0,012,00021
01
PGSTAT
000
0150,00150,00003 =================>> How can i form this field section.
00000,00013,16,00016,+00,000,000,PGSTAT
00000,00001,16,00001,+00,000,000,PGDESC
00001,00015,16,00015,+00,000,000,PGLINE
here is the link for my pglc.dad : http://files.engineering.com/getfile.aspx?folder=080fdad6-b1d5-4a37-8dd0-b89f9a985c69&file=PGLC.DAD
Thanks appopriate to someone could helps.
I know the XFD format intimately as I have written a couple of parsers of this file format in both Perl and Cobol.
Having said that, I would strongly recommend that you do not try to hand craft an XFD file from scratch.
If you have an AcuCobol (MicroFocus) compiler, and the source of the file's SELECT and FD definitions, then you can create a very small Cobol program that has just the SELECT and FD definitions and then compile the program using:
ccbl32.exe -Fx <program>
That will create an XFD file for the indexed file definition. Note, you can specify a directory for the created XFD file using the -Fo <directory> option.
If you don't have the source of the file definitions, then you are just going to be guessing what and where the fields are. The indexed file by itself will not tell you that information. I can see from extracting the data in your file (using the vutil -e option) that the file contains binary data as well as text, so without knowing exactly what PICture those fields are (COMP-?) you will be struggling to figure out the structure of those fields.
I'll try to redefine the XFD file structure based on below file settings option
Anaylsis Result:
Max Record length 300
Min record length 61
No of records 466
Blocking factor 1
Preallocation amount 0
Extension amount 1
Compression factor 80
Encrypted ? No
Number of keys 4
Primary key has 1 segments
key size 13 offset 0
key 02 has 3 segments
Duplicates Are allowed
Key size 4 offset 4
Key size 40 offset 21
Key size 4 offset 0
Key 03 has 3 segments
Duplicates Are allowed
Key size 4 offset 4
Key size 8 offset 13
Key size 4 offset 0
Key04 has 1 segment
Duplicates Are allowed
Key size 10 offset 21
Another given XFD file structure which is already failed to obtained data from AcuODBC:
I 'm linking against from pote.XFD to pote Acu database file through ACUODBC.
XFD,02,POTE,POTE
00026,00018,002
1,0,008,00000
02
INTIND-UNIQ
INTIND-OCC
1,1,010,00008
01
IND16
000
0004,00004
00000,00004,12,00009,+00,000,000,INTIND-UNIQ
00004,00004,12,00009,+00,000,000,INTIND-OCC
00008,00010,16,00010,+00,000,000,IND16
00018,00008,16,00008,+00,000,000,TERM20
I'm linking against from pote.XFD to pote Acu database file through ACUODBC.
My Question is here how could I change my pote.XFD structure based on give analysis as given on top to form a correct XFD structure.
I know there are four keys in this cobol table, but I still don't know how to manually configure this data structure based on given analysis information.
Below is another reference guide on how to form XFD correct structure in manual where I've already obtained, hope someone expert can help to explained the way on how to form on correct XFD structure.
# This xfd layout is a generic one suitable for accessing any
# .DAD file. However, it needs to be copied and amended for each
# DAD file that you wish to get access to.
# The simplest scenario is that you copy dad.xfd to a new file
# with the same name as the database you wish to access and extension .XFD
# Then edit this new file and replace the two instances of 'FILE' with the
# filename that you want to access. e.g. if you want to have ODBC access to
# icvc.dad then copy dad.xfd to new file icvc.xfd and change line
# XFD,02,FILE,FILE to be
# XFD,02,ICVC,ICVC
#
# If this doesn't work then the database file you are trying to access has
# probably set different values for search index sizes. The easiest way to
# check this is to run $list for the database that you want to access and
# note down all the key information that it gives. If that is different
# to the key info in this file then you need to modify the xfd file to match
# In the current xfd there are four indexes defined. In all cases the first
# index will be correct and so should the third index. However, the other
# two may need to be modified or removed if not present.
# Index 4 is optional and is not present if the database is rebuilt without
# the fast list option.
# explaining the details of 2nd index. 1 st line consists of 8 values separated
# by commas. The first value of 3 is how many segments the index consists of.
# second value 1 means duplicates allowed (0 means NO DUPS).
# The remaining six fields are three pairs of key size and byte offset, e.g.
# first index segment is 4 bytes long and starts from byte 4, second index
# segment is 20 bytes long and starts from byte 21 etc.
# The second line specifies how many field names there are to follow and lines 3
# to 5 are the three field names as defined lower in this xfd. For instance
# if you look at field D1UNIQ you will see it is defined as starting from byte 0
# and is 4 bytes long. This corresponds to the values entered in the key definition.
#
XFD,02,ICVC,ICVC
00300,00041,004
# [Key Section]
# [1st index]
01,0,013,00000
04
D1UNIQ
D1NAME
D1NAMX
D1OCCU
# [2nd index]
3,1,004,00004,020,00021,004,00000
03
D1NAME
D1TUPP
D1UNIQ
# [3rd index]
3,1,004,00004,008,00013,004,00000
03
D1NAME
D1NUMB
D1UNIQ
# [4th index]
1,1,020,00021
01
D1TUPP
# [Condition Section]
000
# [Field Section]
0015,00015,00016
00000,00013,16,00013,+00,000,999,D1KEY
00000,00004,12,00009,+00,000,000,D1UNIQ
00004,00004,16,00004,+00,000,000,D1NAME
00008,00001,16,00001,+00,000,000,D1NAMX
00009,00004,12,00009,+00,000,000,D1OCCU
00013,00008,11,00018,-06,000,000,D1NUMB
00021,00040,16,00040,+00,000,000,D1TUPP
00061,00001,01,00001,+00,000,000,D1GRAD
00062,00004,12,00008,+00,000,000,D1DLUP
00066,00004,12,00008,+00,000,000,D1TLUP
00070,00004,16,00004,+00,000,000,D1OLUP
00074,00001,16,00001,+00,000,000,D1TYPE
00075,00002,16,00002,+00,000,000,D1FORM
00077,00160,16,00160,+00,000,000,D1TEXT
00237,00001,16,00001,+00,000,000,D1PRIN
00238,00062,16,00062,+00,000,000,D1FILL
First do this:
'# This xfd layout is a generic one suitable for accessing any
'# .DAD file. However, it needs to be copied and amended for each
'# DAD file that you wish to get access to.
'# The simplest scenario is that you copy dad.xfd to a new file
'# with the same name as the database you wish to access and extension .XFD
'# Then edit this new file and replace the two instances of 'FILE' with the
'# filename that you want to access. e.g. if you want to have ODBC access to
'# icvc.dad then copy dad.xfd to new file icvc.xfd and change line
'# XFD,02,FILE,FILE to be
'# XFD,02,ICVC,ICVC
If that does not work, follow the instructions for finding out how many keys ther are and the values for the second key. If you discover there are only three keys, remove the fourth key from the template. If the values for the second key are different, change them in the [FieldSection].
Get it working before changing anything else.
ISQL-SE 4.10.DD6 (DOS 6.22):
BCHECK C-ISAM B-tree Checker version 4.10.DD6
C-ISAM File: c:\dbfiles.dbs\*.*
ERROR: cannot open C-ISAM file
In SE2.10 it worked with wilcards * .* for all files, but in SE4.10 it doesn’t. I have an SQL script which my users periodically run to reorg customer and transactions tables. Then I have a FIX.BAT DOS script [bcheck –y * .*] as a utility option for my users in case any tables get screwed up. Since users running the reorg will now increment the table version number, example: CUSTO102, 110, … now I’m going to have to devise a way to strip the .DAT extensions from the .DBS dir and feed it to BCHECK. Before, my reorg would always re-create a static CUSTOMER.DAT with CREATE TABLE customer IN “C:\DBFILES.DBS\CUSTOMER”; but that created the write permission problem and had to revert back to SE’s default datafile journaling…
Before running BCHECK on CUSTO102, its .IDX file size was 22,089 bytes and its .DAT size is 882,832 bytes.
After running BCHECK on CUSTO102, its .IDX size increased to 122,561 bytes, however a new .IDY file was created with 88,430 bytes..
What's a .IDY file ???
C:\DBFILES.DBS> bcheck –y CUSTO102
BCHECK C-ISAM B-tree Checker version 4.10.DD6
C-ISAM File: c:\dbfiles.dbs\CUSTO102
Checking dictionary and file sizes.
Index file node size = 512
Current C-ISAM index file node size = 512
Checking data file records.
Checking indexes and key descriptions.
Index 1 = unique key
0 index node(s) used -- 1 index b-tree level(s) used
Index 2 = duplicates (2,30,0)
42 index node(s) used -- 3 index b-tree level(s) used
Index 3 = unique key (32,5,0)
29 index node(s) used -- 2 index b-tree level(s) used
Index 4 = duplicates (242,4,2)
37 index node(s) used -- 2 index b-tree level(s) used
Index 5 = duplicates (241,1,0)
36 index node(s) used -- 2 index b-tree level(s) used
Index 6 = duplicates (46,4,2)
38 index node(s) used -- 2 index b-tree level(s) used
Checking data record and index node free lists.
ERROR: 177 missing index node pointer(s)
Fix index node free list ? yes
Recreating index node free list.
Recreating index 6.
Recreating index 5.
Recreating index 4.
Recreating index 3.
Recreating index 2.
Recreating index 1.
184 index node(s) used, 177 free -- 1083 data record(s) used, 0 free
The problem with the wild cards is more likely an issue with the command interpreter that was used to run bcheck than with bcheck itself. If you give bcheck a list of file names (such as 'abc def.dat def.idx', then it will process the C-ISAM file pairs (abc.dat, abc.idx), (def.dat, def.idx) and (def.dat, def.idx - again). Since it complained about being unable to open 'c:\dbfiles.dbs\*.*', it means that the command interpreter did not expand the '*.*' bit, or there was nothing for it to expand into.
I expect that the '.IDY' file is an intermediate used while rebuilding the indexes for the table. I do not know why it was not cleaned up - maybe the process did not complete.
About sizes, I think your table has about 55,000 rows of size 368 bytes each (SE might say 367; the difference is the record status byte at the end, which is either '\0' for deleted or '\n' for current). The unique index on the CHAR(5) column (index 3) requires 9 bytes per entry, or about 56 keys per index node, for about 1000 index nodes. The duplicate indexes are harder to size; you need space for the key value plus a list of 4-byte numbers for the duplicates, all packed into 512-byte pages. The 22 KB index file was missing a lot of information. The revised index file is about the right size. Note that index 1 is the 'ROWID' index; it does not occupy any space. (Index 1 is also why although every table created by SE is stored in a C-ISAM file, not all C-ISAM files are necessarily compatible with SE.)
Segments of memory - BSS, Stack, Heap, Data, Code/Text (Are there any more?).
Say I have a 128MB RAM, Can someone tell me:
How much memory is allocated for each of these memory segments?
Where do they start? Please specify the address range or something like that for better clarity.
What factors influence which should start where?
That question depends on the number of variables used. Since you did not specify what compiler or language or even operating system, that is a difficult one to pin down on! It all rests with the operating system who is responsible for the memory management of the applications. In short, there is no definite answer to this question, think about this, the compiler/linker at runtime, requests the operating system to allocate a block of memory, that allocation is dependent on how many variables there are, how big are they, the scope and usage of the variables. For instance, this simple C program, in a file called simpletest.c:
#include <stdio.h>
int main(int argc, char **argv){
int num = 42;
printf("The number is %d!\n", num);
return 0;
}
Supposing the environment was Unix/Linux based and was compiled like this:
gcc -o simpletest simpletest.c
If you were to issue a objdump or nm on the binary image simpletest, you will see the sections of the executable, in this instance, 'bss', 'text'. Make note of the sizes of these sections, now add a int var[100]; to the above code, recompile and reissue the objdump or nm, you will find that the data section has appeared - why? because we added a variable of an array type of int, with 100 elements.
This simple exercise will prove that the sections grows, and hence the binary gets bigger, and it will also prove that you cannot pre-determine how much memory will be allocated as the runtime implementation varies from compiler to compiler and from operating system to operating system.
In short, the OS calls the shot on the memory management!
you can get all this information compiling your program
# gcc -o hello hello.c // you might compile with -static for simplicity
and then readelf:
# readelf -l hello
Elf file type is EXEC (Executable file)
Entry point 0x80480e0
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x08048000 0x08048000 0x55dac 0x55dac R E 0x1000
LOAD 0x055dc0 0x0809edc0 0x0809edc0 0x01df4 0x03240 RW 0x1000
NOTE 0x000094 0x08048094 0x08048094 0x00020 0x00020 R 0x4
Section to Segment mapping:
Segment Sections...
00 .init .text .fini .rodata __libc_atexit __libc_subfreeres .note.ABI-tag
01 .data .eh_frame .got .bss
02 .note.ABI-tag
The output shows the overall structure of hello. The first program header corresponds to the process' code segment, which will be loaded from file at offset 0x000000 into a memory region that will be mapped into the process' address space at address 0x08048000. The code segment will be 0x55dac bytes large and must be page-aligned (0x1000). This segment will comprise the .text and .rodata ELF segments discussed earlier, plus additional segments generated during the linking procedure. As expected, it's flagged read-only (R) and executable (X), but not writable (W).
The second program header corresponds to the process' data segment. Loading this segment follows the same steps mentioned above. However, note that the segment size is 0x01df4 on file and 0x03240 in memory. This is due to the .bss section, which is to be zeroed and therefore doesn't need to be present in the file. The data segment will also be page-aligned (0x1000) and will contain the .data and .bss ELF segments. It will be flagged readable and writable (RW). The third program header results from the linking procedure and is irrelevant for this discussion.
If you have a proc file system, you can check this, as long as you get "Hello World" to run long enough (hint: gdb), with the following command:
# cat /proc/`ps -C hello -o pid=`/maps
08048000-0809e000 r-xp 00000000 03:06 479202 .../hello
0809e000-080a1000 rw-p 00055000 03:06 479202 .../hello
080a1000-080a3000 rwxp 00000000 00:00 0
bffff000-c0000000 rwxp 00000000 00:00 0
The first mapped region is the process' code segment, the second and third build up the data segment (data + bss + heap), and the fourth, which has no correspondence in the ELF file, is the stack. Additional information about the running hello process can be obtained with GNU time, ps, and /proc/pid/stat.
example taken from:
http://www.lisha.ufsc.br/teaching/os/exercise/hello.html
memory depend on the global variable and local variable