1. COMMAND=SBX:<sbxnam> option in printer INI files may now include optional parameters. For example,:
COMMAND=SBX:PFILTR, "A, B, C", 25, "MicroSabio"
would pass 3 additional parameters to the PFILTR.SBX call. These would come after the 6 automatic parameters, i.e.:
XCALL PFILTR, STATUS, FSPEC, PRINTER, SWITCHES, COPIES, FORM, "A,B,C", 25, "MicroSabio"
The routine, PFILTR, can detect whether the parameters were passed by looking at the parameter count (XCBCNT).
2. A sample print filter, PFILTR, which simply displays the received parameters and prompts you for changes to them, is now included among the sample programs in [7,376].
3. (WINDOWS) Another sample print filter, EMAILP, is now included. It takes the passed print file and converts it into an email message, then passes it to the local default email client, where the user can address and edit the message before sending it. To use it, create a printer ini file with the following line:
COMMAND=SBX:EMAILP, <flags>, <subject>, <introtext>
The 3 optional parameters are interpreted as follows:
<flags> may be a combination of;
1 = Receipt requested
2 = Send the file as an attachment (otherwise it is embedded into the message as text)
4 = Use HTML coding to set fixed pitch for the embedded message.
<subject> is an optional subject line. (The user will be able to fill in the subject when the email client is popped up.)
<introtext> is a short message which will be placed at the beginning of the body of the message (e.g. "Here's the report..."). Like the subject, the user will be able to edit it before sending.
Note that there is currently a 136 byte limit on the length of the COMMAND= line in the printer ini file (So the subject and introtext fields, if specified at all, have to be short.)
4. The MEM: device now supports random file access. In other words, you can load a random file into memory, and then open it and access it as a random file from BASIC. To set this up, you must first define the MEM: device as follows:
DEVICE=MEM: MEM:
Technically, you could use any device name for the logical name (the first MEM:) but the physical name (the second MEM:) must be MEM: (in upper case, with the: on the end).
If already have a PPN-specific MEM: or MEM0: device defined, then make sure it is defined first, i.e.:
DEVICE=MEM0:[1,1] /tmp
DEVICE=MEM: MEM:
Second, remove MEM: from the ERSATZ.INI file. (ERSATZ devices are processed first.) (Obviously, if you are using the MEM: ersatz, you will want to make other arrangements. However, it you are too committed to using MEM: as a disk device, then you could use some other logical name to refer to MEM:. For example, DEVICE=RAM: MEM: would define a logical device named "RAM:" which referred to the physical device MEM: (user memory).
Now that you have the MEM: device defined, you can load a random file into it and then open it as follows:
.LOAD MYFILE.DAT ; load MYFILE.DAT into MEM:
.MAP ; (displays MYFILE.DAT in memory)
.RUN TEST
<within TEST.RUN...
OPEN #CH, "MEM:MYFILE.DAT", RANDOM, RSIZE, RFILE >
It doesn't much matter whether you open the file RANDOM or RANDOM'FORCED, since there is no locking of a file in memory.
The question arises: "Why would you want to load a random file into memory?" The answer is found primarily in Windows network environments, where you are unhappy with the performance of a particular report program. In some cases, it might take hundreds of times longer to read a file record by record across the network that it does to copy it from the server to your workstation. Given the huge amount of RAM available on typical workstations, it is often practical to load one or more files entirely into memory, thereby speeding up the report by a significant factor.
As an example, we run a accounting system which uses XCALL SERCH. One particular report, the AR Trial Balance, involves a lot of indexed accesses to the customer file (about 2000 records) and the item file (about 10000 records.) XCALL SERCH is particularly inefficient on networks, since it involves a lot of small accesses. When these files are open by other users, running the report across the network may take up to 3 minutes. However, the total size of the files involved is only about 1 MB (an insignificant amount on a typical PC.) By first loading them into memory, the time to run the report drops to about 10 seconds (about 18 times faster) including the overhead of loading the files initially.
Note that one of the reasons this is possible is that the A-Shell implementation of user memory expands as needed (until all physical memory is exhausted.) So it doesn't make any difference what your MEMORY= setting in the MIAME.INI is.
Further notes, restrictions, and warnings about accessing files in the MEM: device:
•This currently only applies to RANDOM files, and not to ISAM or ISAMPLUS files.
•BASIC READ(L), WRITE(L), OPEN, CLOSE are supported, as well as XCALL SERCH and XCALL BASORT. But other XCALL routines written in C that access files may not recognize the files in memory.
•Obviously, any updates you make to the file will not be written back to disk (unless you manually SAVE the file later.)
•If you don't want to use LOAD.LIT, DEL.LIT, and SAVE.LIT to load, delete, and/or save the files to and from memory, you can also use MIAMEX functions 108, 109, and 110 (described elsewhere in this document.)
5. DEVTBL.LIT 1.2(105) now recognizes the MEM: device and reports it accordingly. It also now recognizes read-only devices (provided they are defined with the ,RO modifier in the MIAME.INI.)
6. SAVE.LIT 1.0(101) fixes a bug in which the /D switch may not have worked.
7. A new MIAME.INI command, OPTIONS=AUTO_MEMOPEN, may be specified to cause every BASIC random file OPEN statement to first check to see if the file being opened is already in memory. If so, it accesses the memory copy as if the filespec had specified MEM: directly.
The idea of this option is that it permits you to experiment with, or take advantage of the MEM: device (described above) without actually modifying your programs to specify MEM: in the file open statements. For example, consider the following open statement:
OPEN #CH, "DSK2:MYFILE.DAT[123,222]", RANDOM, RSIZE, RFILE
If OPTIONS=AUTO_MEMOPEN is set, then the OPEN will first check to see if MYFILE.DAT is in user memory. If not, then it works normally. But if it is, then it uses the memory copy. So to make a particular report program run faster, you could just manually LOAD the file (e.g. .LOG DSK2:MYFILE.DAT[123,222]) before running the program.
Again, it must be noted that this is only practical for files that are not updated by a program. (Any updates would be written to memory, not disk.) Caution should be exercised to make sure you don't inadvertently leave the file in memory and then run a program that performs updates on it (thinking the updates were being written to disk.)
8. Three new ASFLAG.SBR options have been defined, all of which are potentially useful solely for speeding up access to files across a network that are not being updated. They apply to both Windows and UNIX, but probably are most attractive in slow Windows peer to peer network environments.
16 = Memory Map
32 = No IDX Lock
64 = Local Copy
As with other ASFLAG.SBR options, they affect any subsequent random files opened in the current program. (The options are automatically reset at the end of the program.)
Option 16 (Memory Map) causes the subsequently opened random files to be "memory mapped". Memory mapping is a technique used very effectively on UNIX/Linux systems to greatly speed up file access. Essentially it makes the file act like virtual memory, such that you can then access it with memory (rather than disk) operations. This eliminates most of the overhead of disk service calls (which under UNIX require a context switch to supervisor mode, and under Windows networks may require machine-to-machine messaging.) The advantage is most pronounced in files which are accessed very frequently and have small record sizes. (For this reason, we use memory mapping on the qflock.sys file.)
There are, however, two downsides to memory mapping. The biggest one only affects Windows, where the memory "view" of a file is not kept coherent with the disk "view" of the file. Thus it is not a good idea to use this technique in multi user mode, unless you are only planning to read from a file.
The second downside is that it causes a lot of memory to be allocated, which may decrease overall efficiency of the system if it is used too much. (If the total size of memory mapped files exceeds available memory, the system will begin to "thrash", which is not a pretty sight.)
Option 32 (No IDX Lock) was implemented mainly as a test to see if ISAM access in a non-LOKSER environment could be significantly improved by not bothering to place a lock on the IDX "rock" when performing an ISAM operation. In theory, this simulates the way it works under AMOS when LOKSER is not on. In my experience, it does not seem to have that much of an effect.
It was implemented as a file-oriented switch rather than a global option (like OPTIONS=ISAM_IDXLOK) because it is probably only practical, if at all, with files that are only going to be scanned and not updated.
WARNING: using this option with a file that is being updated may lead to IDX corruption, unless you have some other mechanism in place to make sure two users are updating the IDX at once!
Option 64 (Local Copy) only applies to Windows, and provides yet another way of speeding up access to a file that is only going to be read. When turned on, all random OPEN file operations result in a local copy being made of the file in the workstation's "TEMP" directory. (It uses the TEMP environment variable definition to locate this directory.) The local copy is then accessed, rather than the network copy. When the file is closed, the local copy is deleted. (So any updates to the file are lost!) The Local Copy option provides nearly as much performance improvement as memory mapping and even loading files into memory, and has the advantage of not requiring any extra physical memory. So it can work just as well with a 100MB file as with a 500K file (provided you have sufficient disk space.) As with all of the related schemes for getting around the performance penalty of peer-to-peer shared file access, it makes the most sense in situations where you are going to be accessing a large part, or all, of the file. (It wouldn't make much sense to transfer a 100MB file from the server to the workstation and then only access a few records from it.) Unlike memory mapping and the MEM: device, this technique works with ISAM files as well.
10.ASHQFLK.LOG files are no longer created. Any unusual jobtbl.sys or qflock.sys activity will now be written to the main log file, ashell.log.
