Skip to main content

File-Related Issues

Name Mangling

Different operating and applications systems permit different characters to be used in file names. While they all agree on uppercase alphabetic characters and digits, they differ on the rest. The following are the rules Caché MultiValue uses for converting file names containing “special” characters into forms that are accepted across all the platforms it runs on.

Alphanumeric Characters

These become part of the name without conversion.

The Empty String

The resulting filename is “%”.

ANSI Punctuation Characters

Each character listed is converted to the sequence shown (chosen to be easily remembered). Punctuation characters not in the table become part of the name without conversion.

Character Replacement Mnemonic
% %%  
* %A Asterisk
\ %B Backslash
: %C Colon
" %D Double quote
> %G Greater than
< %L Less than
. %P Period (only used for the leading or trailing character of a file name)
? %Q Question mark
/ %S Slash
| %V Vertical bar
(del) %Z  
ANSI Control Characters

Each of the control characters is converted to its own sequence as shown here:

Character Replacement
(nul) %^0
Chars 1 to 26 %^A to %^Z, respectively
Chars 27 to 31 %^1 to %^5, respectively
Latin-1 Characters

The Latin-1 characters shown in the table are converted to their respective sequences. Characters above 159 are printable characters and are left unchanged.

Character Replacement
128 %_0
Chars 129 to 154 %_A to %_Z, respectively
Chars 155 to 159 %_1 to %_5, respectively
Prohibited Names

Files whose names begin with any of the following sequences followed by a period will be prefixed with %M (Microsoft):

  • COM1 through COM9

  • LPT1 through LPT9

  • CON

  • PRN

  • AUX

  • CLOCK$

  • NUL

ANODE Files and INODE Files

By default, the CREATE.FILE command creates INODE files, in which each global node represents one item. An INODE file stores each record in a global node. Therefore, in an INODE file each record cannot exceed 3.5 million characters in length. INODE files generally provide superior query and read/write performance.

The CREATE.FILE command can also create ANODE files. In an ANODE file, each field of each record is stored as a global node. Therefore, in an ANODE file the limit for each field in each record can be 3.5 million characters. ANODE files can be extremely large. ANODE files are especially useful when writing directly to the global. However, maximum string length restrictions may limit the usage of extremely large ANODE files. For example, the MVBasic READ command may encounter a maximum string size when reading an extremely large ANODE file.

  • CREATE.FILE and CREATE.BFILE can create an ANODE file by specifying the ANODE option. By default, these commands creates both DICT and DATA files as INODE files. If you specify the ANODE option, the DATA file is created as an ANODE file, but the DICT file is still created as an INODE file. You must explicitly specify DICT ANODE to create both DICT and DATA as ANODE files.

  • Select lists are stored as ANODE files.

  • &SAVELISTS& and &PH& files are created as ANODE files by default. The &HOLD& file can be created as an ANODE file.

  • When CMQL is used on an ANODE file, only the first 100 attributes are available. This permits the listing of the files and a sample of the data but prevents CMQL from trying to read in very large items.

  • An index cannot be an ANODE file.

  • You cannot create a class on an ANODE file.

Example Showing the Difference Between INODE and ANODE Files

Create an INODE file with:

MV:CREATE.FILE CARI 

Create an ANODE file with:

MV:CREATE.FILE CARA ANODE  

Use ED to enter the same two records in each file, displayed below:

MV:CT CARI 1 2 
1 
0001 1965 
0002 Ford 
0003 Mustang 
0004 Red        

2 
0001 2008 
0002 Austin 
0003 Mini Cooper 
0004 RedýBlack 
MV:CT CARA 1 2 
1 
0001 1965 
0002 Ford 
0003 Mustang 
0004 Red       

 2 
0001 2008 
0002 Austin 
0003 Mini Cooper 
0004 RedýBlack 

If you examine the data on disk, you can see the difference.

For the INODE file, each record is stored in a global node, with fields delimited by field (attribute) marks.

MV:[zw ^CARI 
^CARI=$lb(0) 
^CARI(1)="1965þFordþMustangþRed" 
^CARI(2)="2008þAustinþMini CooperþRedýBlack" 

For the ANODE file, each field of each record is stored in a global node, where the second subscript is the field number.

MV:[zw ^CARA 
^CARA=$lb(1) 
^CARA(1,1)=1965 
^CARA(1,2)="Ford" 
^CARA(1,3)="Mustang" 
^CARA(1,4)="Red" 
^CARA(2,1)=2008 
^CARA(2,2)="Austin" 
^CARA(2,3)="Mini Cooper" 
^CARA(2,4)="RedýBlack" 

In the INODE file, MultiValue field values are delimited by fiedd marks. In the ANODE file, field four with Red and Black shows a value mark (see the section “Dynamic Arrays” in the Caché Multivalue Basic Reference for a table of dynamic array delimiter characters.

Locking Behavior

Caché associates locks with the file variable. This differs from most MultiValue implementations (except UniData) which associate the lock with the file. Locking is affected by the transaction state; see also the section “Transaction Lock Handling” in this book.

For example, consider the following sequence of events:

  1. A main program opens a file and locks a record in it.

  2. The main program calls a subroutine, passing the file name but not the file variable.

  3. The subroutine uses the name to open the file using a local file variable, locks the same record in the file, performs some calculation, releases the lock, and returns to its caller.

When the subroutine returns control to the main program, the lock set by the main program is still in force. It is associated with the file variable in the main program.

In this sequence, however:

  1. A main program opens a file.

  2. The main program calls a subroutine, passing the file variable as an argument.

  3. The subroutine uses the file variable argument to lock a record in the file, performs some calculation, and returns to its caller.

When control returns to the main program, the lock set by the subroutine is still in effect because it is associated with the file variable passed as the argument.

Note:

The same principle applies to a single program which opens the same file multiple times using different file variables. Lock operations using one file variable do not affect locks taken using a different file variable. Thus, when a program locks the same item through two different file pointers, the second lock isn't blocked, because it is taken by the same process. (Some MultiValue implementations DO block such a lock.) However, each lock must be separately released.

FeedbackOpens in a new tab