1. Welcome to the “Creation And Maintenance Of Files In jBASE 4” learning unit.

This
learning unit will help you to work with J4 files

JBS3.Creation And Maintenance Of Files In jBASE 4- 1

R10.01
 After completing this learning course, you will be able to:

•Differentiate an RDBMS table from a jBASE

•Identify the file types in jBASE
•Create UD and J4 files in jBASE
•Analyze how records are read and written onto j4 files
•Analyse how space is allocated for huge records
•Explain jstat command and its options
•Explain file maintenance in jBASE
•Analyse EB.BAD.SIZE.FILES output
•Explain how file is analysed and resized using the tools available in T24
•Analyse EB.FILE.STATS contents
•Explain CREATE.FILE related environment variables in jBASE

JBS3.Creation And Maintenance Of Files In jBASE 4- 2

R10.01
 In any Relational Database Management System data is stored in tables. A table is a
combination of rows and columns.

What you see here is a sample Employee table with five rows. The table holds information of
an employee like the employee id, name, address, phone, data of birth etc.

JBS3.Creation And Maintenance Of Files In jBASE 4- 3

R10.01
 If you wish to create a similar Employee table in jBASE, two files should be created. Among
the two files, one will be the data file. The data file contains only data records. The second
file will be the dict file. This file will contain the filed names and their attributes. The dict file
name is same as the data file, the only difference is that it is suffixed with ]D

It is not mandatory that the data and the dict file should exist in the same location, it may
reside under different directories. VOC will link the data and dict together.

JBS3.Creation And Maintenance Of Files In jBASE 4- 4

R10.01
 You can classify files in jBASE into two major categories. The first type of files are the
hashed files and the second type of files are the non-hashed files. There are many file
types available in jBASE like UD, j3, j4, JR etc. In this learning unit, you will learn about
J4 files.

1. Non Hashed files are sequential files. They are operating system level directories.
They are basically used to store programs and messages that are posted by
interfaces. To create a Non Hashed file from jBASE you will specify Type=UD
2. Hashed files are random files. As they can be randomly accessed, it improves the
performance of the file. These files have to be regularly resized when it overflows. To
create a J4 file in jBASE you will specify Type=J4

JBS3.Creation And Maintenance Of Files In jBASE 4- 5

R10.01
 Login to the jBASE prompt

1. Use the CREATE.FILE command to create a non hashed file. Consider that you wish to
create a file called TEMENOS.NON.HASHED, use the command CREATE.FILE
TEMENOS.NON.HASHED TYPE=UD. On executing the command a data file
TEMENOS.NON.HASHED and a dict file TEMENOS.NON.HASHED]D will be created.

2. The data as well as the dict files are created as operating system level directories. If you
notice the file description has a value “d” that specifies that is it a directory

3. It is equivalent to creating operating system level directories. If you see this example, it
shows that mkdir command can also be used for creating these files.

JBS3.Creation And Maintenance Of Files In jBASE 4- 6

R10.01
 Read and write into these files are sequential. They can be created under any directory (Use
the ‘cd’ command and change to any directory and issue the CREATE.FILE command, the
data and the dict files will get created under that directory)

1. The data and the dict files can be created separately using the DATA or the DICT
keyword following the CREATE.FILE command

JBS3.Creation And Maintenance Of Files In jBASE 4- 7

R10.01
 1. Use the CREATE.FILE command to create a hashed file. Consider that you wish to
create a file called TEMENOS. HASHED, use the command CREATE.FILE TEMENOS.
HASHED TYPE=J4. On executing the command a data file TEMENOS.HASHED and a
dict file TEMENOS.HASHED]D will be created.

2. The data as well as the dict files are created as operating system files.

Let us now understand the parameters used in the CREATE.FILE command

TYPE=J4 Signifies that the file is a hashed file

3,2,2 are the set of parameters for the dict file where
3 – specifies the number of modulo of the dict file
2 – specifies the separation of the dict file
2 – specifies the secondary buffer size of the dict file

4,2,2 are the set of parameters for the data file where
4 – specifies number of modulo of the data file
2 – specifies separation of the data file
2 – specifies secondary buffer size of the data file

JBS3.Creation And Maintenance Of Files In jBASE 4- 8

R10.01
 While creating the hashed file, you specified 3,2,2 for the dict portion and 4,2,2 for the data
portion. The number of modulo for the dict portion is three and the number of modulo for the
data portion is 4. Modulo is otherwise called a frame or a bucket. The size of each modulo
depends on the paging size of the operating system. It means that for the dict file three
modulo will be created and for the data file four modulo will be created. The separation
specified for the dict and data files is two appropriately. Separation is otherwise called the
multiplying factor for modulo. Separation enables us to increase the size of a frame. Default
value of separation is 1, of not specified in the CREATE.FILE command.

If for example (Lets assume the size of one modulo is 4096) the number of modulo specified
is three and the separation specified is two, it means that three frames (bucket) of size 4096
* 2 will be created, where 4096 K is assumed to be the default size of a frame is assumed
and 2 is the separation. The default size of the modulo can change depending on the
underlying operating system.

JBS3.Creation And Maintenance Of Files In jBASE 4- 9

R10.01
 You will now try to understand how data is written on to a hashed file. Consider a data file
with four modulo.

1. A User writes a record with ID 1

2. Hashing algorithm is used to calculate the frame in which the record needs to be stored
based on the ID and the total number of frames in the file
3. Consider that the result of the hashing algorithm is Frame 1
4. The record is written to Frame 1
5. A User writes a record with ID 2
6. Hashing algorithm is used to calculate the frame in which the record needs to be stored
based on the ID and the total number of frames in the file
7. Consider that the result of the hashing algorithm is Frame 0
8. The record is written to Frame 0

J4 always stores data evenly across frames

JBS3.Creation And Maintenance Of Files In jBASE 4- 10

R10.01
 Now you will see how data is read from hashed files.

1. User opens an existing record with ID 1

2. Hashing algorithm calculates the frame based on the ID and the total number of frames
in the file
3. Consider that the result of the hashing algorithm is Frame 1
4. J4 reads through the Group1 (Frame 1) sequentially until it finds record with ID 1 and
then returns the record to the user

JBS3.Creation And Maintenance Of Files In jBASE 4- 11

R10.01
 What happens when all frames are full?

Consider the following scenario

1. A user writes a record with ID 15

2. Hashing algorithm calculates the Frame in which the record needs to be stored based
on the ID and the total number of Frames in the file
3. Consider that the result of the hashing algorithm is Frame 0
4. The frame is full
5. When a frame is full and j4 is unable to store data in that frame, a new frame gets
created and added to the end of the existing frames. The record gets stored in the new
frame and the main frame holds a pointer to the new frame created.

Whenever j4 calculates the frame number in which the record needs to be stored, it will only
take into account the primary frames (0 – 3 in this case)
When record 15 needs to be fetched, the hashing algorithm will return a value saying that
the record is in frame 0. j4 will then search for the record sequentially in frame 0, if not
found, will use the pointer, get to Frame 4 and search sequentially in Frame 4 until it
finds the record.

JBS3.Creation And Maintenance Of Files In jBASE 4- 12

R10.01
 What is considered a huge record?
A record is considered huge when the size of the record exceeds the size of the ‘Secondary
Buffer Size’ .

1. If you remember, a value two was specified as the secondary buffer size for the file
TEMENOS.HASHED
2. Secondary buffer size will be calculated as size of one frame multiplied by the
secondary buffer size.
2.1 4,2,2 means that size of one frame (assume 4096 ) is multiplied by 2 that is
equal to 8192 bytes. The secondary buffer size will be 8192 multiplied by 2, that
is 16384. So when a record is greater that 16384 bytes, it is considered to be a
huge record. Only when the size of a record is greater than 16384 bytes, will a
secondary buffer space be created to store the new data

If no value is specified for the secondary buffer size, it will default to 2. Meaning, the
secondary buffer size by default will be twice the size of a modulo.

JBS3.Creation And Maintenance Of Files In jBASE 4-

R10.01
 What happens when a huge record is to be written to the file?

Consider the following scenario

1. A user writes a record with ID 16

2. Hashing algorithm calculates the frame in which the record needs to be stored based on
the ID and the total number of frames in the file
3. Consider that the result of the hashing algorithm is Frame 0
4. Size of the record is 17000 Bytes.
5. When the size of a record to be stored is large, then a secondary buffer space is
created. Size of the secondary buffer is equal to the size of the frame multiplied by 2
6. The new record is stored in the secondary buffer space and the original frame holds a
pointer to the secondary buffer space

The secondary buffer area can be created anywhere in the disk. Not necessary adjacent to
the primary frames

JBS3.Creation And Maintenance Of Files In jBASE 4- 14

R10.01
 Points to remember:

1. Keep separation to the minimum, higher the separation, higher will be search time within
a frame as the read within a frame is sequential
2. How do we decide the best separation? Follow the thumb rule – Don’t store more than
10 to 20 records in a frame. More the records in a frame, higher will be the search time
3. When ever data gets stored in the secondary buffer space (When the record is huge) or
when data gets split over to other frames other than the primary, file access will become
slow
4. J4 always spreads and stores records evenly across all frames

JBS3.Creation And Maintenance Of Files In jBASE 4- 15

R10.01
 List contents of hashed as well as non hashed files, using the LIST command

JBS3.Creation And Maintenance Of Files In jBASE 4- 16

R10.01
 1. CLEAR.FILE command can be used to clear contents of hashed as well as non hashed
files
2. To delete a hashed or a non hashed file, use the command DELETE.FILE

JBS3.Creation And Maintenance Of Files In jBASE 4- 17

R10.01
 To clear or delete only the data portion or the dict portion of a file separately, use the
keyword DATA or DICT with the CLEAR.FILE or DELETE.FILE command

JBS3.Creation And Maintenance Of Files In jBASE 4- 18

R10.01
 1. Create a non hashed file XXX.TRG.NON.HASHED where XXX is your name
2. Create a hashed file XXX.TRG.HASHED where XXX is your name
3. List the contents of the hashed and the non hashed files that you just created
4. Clear the contents of the hashed and the non hashed files that you just created
5. Delete the hashed and the non hashed files that you just created

JBS3.Creation And Maintenance Of Files In jBASE 4- 19

R10.01
 File access becomes slow when data spills over to frames that are not primary frames and
when data spills over to the secondary buffer space. How do you prevent performance
degradation which arise due to improper file size? The solution would be to analyze and
resize files periodically. Based on the frequency of file updates, files need to be analyzed
and resized.

jstat command allows you to analyse files in jBASE. The syntax for jstat command is jstat {-
DChar} {-fmrsvw} Filename

1. The –s option is used to display a short summary on the file statistics

2. The –f option will display the free space information for a file

JBS3.Creation And Maintenance Of Files In jBASE 4- 20

R10.01
 1. The –m option will display the file statistics as a machine mode output
2. The –D option with the –m is used to specify the delimiter character to change the
delimiter for machine mode output. By default the delimiter for machine mode output is
tab space
3. When jstat command is used on a file on which records have been locked, the statistical
output is slow. In this case –w option can be used. It will not wait on locked objects.

JBS3.Creation And Maintenance Of Files In jBASE 4- 21

R10.01
 jstat followed by the file name will give the status of the file. The jstat command options are
not mandatory. Consider that you wish to analyse a file called FBNK.ACCOUNT, then you
will use a command jstat FBNK.ACCOUNT. Try to understand the output of the command

Line 1 : Displays the relative path of the file with the actual name of the file. Files could have
truncated
names because of file name length restriction imposed by Unix.
Line 2 : Displays the type of the file(J4). The default hash method for all jBASE-hashed files
is 4 that is what is specified in ‘Hash Method’.
Line 3 :
Groups : Specifies the number of primary frames
Frame Size : Represents the size of 1 frame. Here the size of 1 frame is 4096 bytes.
Therefore the separation would have been 1 when the file was created .
Secondary Buffer Size : Represents the size of the secondary buffer size. The value is
8192 Bytes which is twice the size of 1 frame. Therefore when the file was created the

JBS3.Creation And Maintenance Of Files In jBASE 4- 22

R10.01
 secondary buffer size specified would have been 2.

When the file was created or last resized, the valued would have been Type=J4, Frame = 9,
Separation = 1 and Secondary buffer size = 2.

JBS3.Creation And Maintenance Of Files In jBASE 4- 22

R10.01
 Line 4 :
Record Count : Specifies the total number of records in the file at present
Record Bytes : Specifies the total number of bytes occupied by the file at
present
Line 5 :
Bytes/Record : Specifies the average size of 1 record
Bytes/Group : Specifies the average size of 1 frame at present

Primary File Space : Total number of frames (Actual frames specified when the file was
created or last resized + frames that got created due to lack of space in the existing frames)

Secondary File Space : Total number frames that were allocated to store records that are
bigger than the secondary record size

JBS3.Creation And Maintenance Of Files In jBASE 4- 23

R10.01
 jstat –r command will display statistical information about the file modulo wise

1. Additional modulo is allocated for Frame 0 as this modulo did not have space to hold
records

2. Notice that no data has gone into secondary buffer space

JBS3.Creation And Maintenance Of Files In jBASE 4- 24

R10.01
 Size of 1 frame is 4096 Bytes. Hence 86016-4096 = 81920 is the extra space allocated.
81920/4096 = 20 frames have been allocated since primary Frame 0 did not have adequate
space

JBS3.Creation And Maintenance Of Files In jBASE 4- 25

R10.01
 1. Let us now resize the file FBNK.ACCOUNT. The optimum number of records in one
frame is 10 to 20. Number of records per frame can be calculated as Size of a frame
divided by average size of a record.

2. The number of records per frame is equal to the size per frame, 4096 divided by the
average size of a record is 387. 4096/387 = 11 (Approx) – We are well within the
optimum.

If 1 frame can store11 records, how many frames do we need to store 2001
records? The answer is 2001/11 = 200 (Approx). Now that you have the
required statistical data about the file, you will resize the file with this
information.

3. jrf command is available for file re-sizing. jrf command followed by –S option is used to
specify the size parameter which is then followed by the number of modulo. jrf –S201
.. ../mbdemo.data/ac/FBNK.ACCOUNT will resize the FBNK.ACCOUNT file to 201
frames. You must specify the physical path of the file.

Always keep into account the frequency in which you will be resizing the file and hence
allocate some extra space when resizing. Always specify an odd number or a prime
number for the frame. Else j4 will automatically convert the frame number to the nearest
possible prime or odd number

JBS3.Creation And Maintenance Of Files In jBASE 4- 26

R10.01
 You can also downsize a file using jrf.

1. If you look at the statistics of TRG.TEST file, there are 25 primary frames available.

2. Use the jrf command with –DS option to reduce the number of frames allocated to a file.
You have tried to downsize 25 frames to 3 frames.

JBS3.Creation And Maintenance Of Files In jBASE 4- 27

R10.01
 Assume that the file TEMENOS.HAHSED has just been created and contains no data.

JBS3.Creation And Maintenance Of Files In jBASE 4- 28

R10.01
 Now, insert a record that is lesser than the size of one frame (Size should be lesser than
4096 bytes) and view the statistics of the file.

1. Note that the secondary file space parameters are empty

JBS3.Creation And Maintenance Of Files In jBASE 4- 29

R10.01
 Now, insert a record whose size is greater than the size of one frame but lesser than the
size of secondary file space and view the statistics of the file
Note that an additional frame has been created for Frame 2 and the data has been split and
stored

JBS3.Creation And Maintenance Of Files In jBASE 4- 30

R10.01
 Now, insert a record whose size is greater than the size of size of secondary file space and
view the statistics of the file

Note that secondary buffer space has been allocated and the record which should have
been in frame 3 is stored in the secondary buffer space (Note the + symbol. It denotes that
there is a secondary buffer space allocated for the frame). 3 frames have been allocated in
the secondary buffer space area and they split and store the record. Frame 3 will have the
pointer to the first frame in the secondary file space, the first frame in the secondary file
space will have a pointer to the second frame and so on (Like a link list)

JBS3.Creation And Maintenance Of Files In jBASE 4- 31

R10.01
 Obtain the statistics and resize the following files
FBNK.STMT.ENTRY
FBNK.CATEG.ENTRY
F.DE.O.HEADER
F.DE.ADDRESS
FBNK.RE.CONSOL.SPEC.ENTRY
FBNK.ACCOUNT

JBS3.Creation And Maintenance Of Files In jBASE 4- 32

R10.01
 1. T24 has a built in tool (Enquiry) named EB.BAD.SIZE.FILES which enables us to
1.1 Analyze files
1.2 Resize badly sized files automatically

2. Execute this enquiry at periodic intervals in time to avoid performance issues which
arise due to badly sized files

JBS3.Creation And Maintenance Of Files In jBASE 4- 33

R10.01
 1. This enquiry on execution
1.1 Populates a file named EB.FILE.STATS with the list of files that have been
analyzed. This file also contains the details of the analysis such as the current
frame, suggested frame etc
1.2 Creates a VOC entry named RESIZE.GLOBUS which contains the ‘jrf’
command to resize the files. On execution of this VOC entry, the files will get
resized.

JBS3.Creation And Maintenance Of Files In jBASE 4- 34

R10.01
 This enquiry should be run from the classic interface of T24

JBS3.Creation And Maintenance Of Files In jBASE 4- 35

R10.01
 1. Questions prompted by EB.BAD.SIZE.FILES enquiry

1.1 Gather new file size information?

1. Possible values that can be specified for this question are
1. FULL – Analyze files that have type as ‘F’ in the VOC entry
and prepare a report. Report is stored in a file named
EB.FILE.STATS.
2. NO – Displays the current contents of the file
EB.FILE.STATS. This means that the enquiry will not analyze
the system, but will display previously generated reports
3. FAST – Similar to FULL except that in the report, the total
number of records in each file are not updated

1.2 Please enter label for rebuild

1. A text that appears as part of the report. Useful when this enquiry is
run multiple number of times

1.3 The enquiry can take while to execute based on the number and the size of the
files

JBS3.Creation And Maintenance Of Files In jBASE 4- 36

R10.01
 ID : Name of the file that is analysed. It is the same as that of the Voc ID. For example, the
VOC ID for COMPANY application is F.COMPANY, so a record by ID F.COMPANY will be
created in EB.FILE.STATS
PathName : Path of the file as in the second line of the VOC entry
Min Modulo : The suggested modulo of the file based on the current data. When the file
gets resized, this is the new modulo that will be assigned
Date : Holds the data when the file was analyzed and updated in EB.FILE.STATS file
Size : Unix file size
Modulo : jBASE modulo
Separation : jBASE separation
OverFlow :Overflow per group - indicates if the file is badly sized
Records : Number of records in the file (Not populated when FAST option is chosen at the
time when the enquiry is executed. * will be displayed in this field when the option FAST is
chosen)
Comment : Text that we enter for the question “Please enter label for rebuild”. Useful when
EB.BAD.SIZE.FILES is executed multiple number of times
Important : Whether the file is considered important. List of important files are hard coded.
Has no significance in resizing the files

The latest run details will be updated in the first multi value set. Only the last 10 run details
are held .This is to perform a self clean up of the file.

JBS3.Creation And Maintenance Of Files In jBASE 4- 37

R10.01
 If you compare the output in the EB.FILE.STATS application and the jstat, ls –l outputs the
data will be similar.

JBS3.Creation And Maintenance Of Files In jBASE 4- 38

R10.01
 Overflow calculation can be done in three steps.
1.OVERFLOW = FILESIZE - (FILEMODULO*FILESEP*BLOCK.SIZE)
The product of file modulo separation and size per frame is subtracted from the total
file size
OVERFLOW = 28672 – (3 * 1 * 4096) => 16384

2.OVERFLOW = OVERFLOW / (BLOCK.SIZE*FILESEP)

The resultant overflow is divided with the product of size per frame and file
separation
OVERFLOW = 16384/(4096*1) => 4

3.OVERFLOW = INT(OVERFLOW/FILEMODULO)
Finally, the resultant is divided with the modulo and converted into an integer value

OVERFLOW = INT(4/3) => 1

The data file has over flown to one frame

JBS3.Creation And Maintenance Of Files In jBASE 4- 39

R10.01
 1. The EB.BAD.SIZE.FILES, on execution, also creates a VOC entry named
RESIZE.GLOBUS. This VOC entry contains the command to resize all badly sized files
provided their overflow is greater than 5.

2. Execute this VOC entry from the jsh prompt in order to resize the files. Once the VOC
entry is executed, the names of files get displayed one after the other as they are
resized.

JBS3.Creation And Maintenance Of Files In jBASE 4- 40

R10.01
 Before empty files get resized, user will be prompted whether he wishes to resize empty files
or not.

The content of the VOC entry is not cleared after resize. It is overwritten when
EB.BAD.SIZE.FILES is executed next

JBS3.Creation And Maintenance Of Files In jBASE 4- 41

R10.01
 Now you will learn about two CREATE.FILE related environment variables.

1. If you set some value to the environment variable JEDI_PREFILEOP, it gets defaulted
while using the CREATE.FILE command. Let us understand this with an example.
1.1 Set a value “TYPE=JR LOG=NO” to this variable, you can use the command
export JEDI_PREFILEOP = “TYPE=JR LOG=NO” if you are working on UNIX.
2. Now create a file just by giving a command CREATE.FILE followed by a file name. Let
us consider for example CREATE.FILE TRAINING.TEST
2.1 Now check if you have got the values set in the environment variable. Use the
jstat to do this. Can you see the Type set to JR and Log set to NO.

Remember that value specified in this variable takes more precedence over the value
supplied in command line for the CREATE.FILE command.

JBS3.Creation And Maintenance Of Files In jBASE 4- 42

R10.01
 Let us now look into the next environment that CREATE.FILE uses.

1. This variable is the same like JEDI_PREFILEOP, If you set some value to the
environment variable JEDI_POSTFILEOP, it gets defaulted while using the
CREATE.FILE command. But you should remember that value specified in this variable
can be overridden using the CREATE.FILE command.
2. Let us understand this with an example.
1.1 Set a value “TYPE=JR LOG=NO” to this variable, you can use the command
export JEDI_POSTFILEOP = “TYPE=JR LOG=NO” if you are working on
UNIX.
3. Now create a file using the CREATE.FILE command followed by a file name, also
specify the file type as J4. Let us consider for example CREATE.FILE TRAINING.TEST
TYPE=J4 1 1
2.1 Now check if you have got the values set in the environment variable. Use the
jstat to do this. If you notice, though you have set JEDI_POSTFILEOP to
TYPE=JR, the file type of the file you created just now is J4, this is because
you have given TYPE=J4 in the CREATE.FILE command. As already said, the
value specified in the CREATE.FILE command takes more precedence when
compared to the variable JEDI_POSTFILEOP

JBS3.Creation And Maintenance Of Files In jBASE 4- 43

R10.01
 Let us look into some additional characteristics of a j4 file

Backup: When set to YES, file will be backed up when the jbackup command is executed,
the default value is YES. You can change this value by issuing the command jchmod +B
<File Name> to grant and jchmod –B <File Name> to revoke backup feature.

Log: When set to YES, any DML (Data Manipulation Language) on the file will be recorded
by jBASE Transaction Journaling, provided jBASE Transaction Journaling is started. Its
default value is YES. You can change this value by issuing jchmod +L <File Name> to
grant and jchmod –L <File Name> to revoke log feature.

Rollback: The Rollback flag indicates if a file is subject to transaction boundaries. Its default
value is YES. If unset, it will have an impact on the way jBASE Transaction Journaling
journals data. To grant Rollback use the command jchmod +T <File Name> and to revoke
use the command jchmod –T <File Name>

Network: It is set for files that are NFS mounted so that jBASE can place byte locks on
them. Its default value is NO. It is not used by JR files as JR files use jDLS for locking.
Applicable only for J4 files. The command to grant this feature is jchmod +N <File Name>
and to revoke the command is jchmod –N <File Name>.

Secure: The file is flushed at critical junctures such that any file update will rely only on a
single disk write. This maintains the file structure in the event of system failure. Set so that
file structure never gets corrupt. Its default value is NO. It is applicable only to JR files. It can
affect performance if set. The command to grant this feature is jchmod +S <File Name>
and to revoke it is jchmod –S <File Name>

JBS3.Creation And Maintenance Of Files In jBASE 4- 44

R10.01
 1. TRUE
2. FALSE
3. FALSE
4. TRUE
5. FALSE

JBS3.Creation And Maintenance Of Files In jBASE 4- 45

R10.01
 6. FALSE
7. TRUE
8. TRUE

JBS3.Creation And Maintenance Of Files In jBASE 4- 46

R10.01
 In this learning course, you learnt about J4 file creation and maintenance

You will now be able to

•Differentiate an RDBMS table from a jBASE

•Identify the file types in jBASE
•Create UD and J4 files in jBASE
•Analyze how records are read and written onto j4 files
•Analyse how space is allocated for huge records
•Explain jstat command and its options
•Explain file maintenance in jBASE
•Analyse EB.BAD.SIZE.FILES output
•Explain how file is analysed and resized using the tools available in T24
•Analyse EB.FILE.STATS contents
•Explain CREATE.FILE related environment variables in jBASE

JBS3.Creation And Maintenance Of Files In jBASE 4- 47

R10.01
JBS3.Creation And Maintenance Of Files In jBASE 4- 48
R10.01