FILE1.

How can I undelete a file?

OpenVMS doesn't have an undelete function. However, if you are quick to write-protect the disk (or if you can guarantee that no new files get created or existing files extended), your data is still on the disk and it may be possible to retrieve it. The FLORIAN tool available from the WKU Fileserver claims to be able to do this (see question SOFT1.)
Other alternatives here include the DFU tool, available on the OpenVMS Freeware CD-ROM distribution.

If you are setting up a user environment for yourself or for others, it is quite easy to use DCL to intercept the DELETE command, using a symbol: 

  $ DEL*ETE :== @SYS$LOGIN:MYDELETE.COM
The DELETE symbol will cause the procedure to be invoked whenever the user enters the DELETE command, and it can copy the file(s) to a trashcan subdirectory before issuing a real DELETE on the files. Other procedures can retrieve the file(s) from the trashcan subdirectory, and can (and should) clean out the trashcan as appropriate.
(Realize that this DELETE symbol can interfere with DELETE/GLOBAL and other similar DCL commands.) 
					[Steve Hoffman]


FILE2.

Why does SHOW QUOTA give a different answer than DIR/SIZE?

DIR/SIZE doesn't take into account the size of file headers which are charged to your quota. Also, unless you use DIR/SIZE:ALL, you'll see only the "used" size of the file, not the allocated size which is what gets charged against your quota. Also, you may have files in other directories. 
					[Steve Lionel]

$ DIR/SIZ=ALL/GRAND [username...]

Grand total of D1 directories, F1 files, B1/B2 blocks.

$ DIR/SIZ=ALL/GRAND [-]username.DIR

Grand total of 1 directory, 1 file, B3/B4 blocks.

$ SHOW QUOTA
  User [username] has B5 blocks used, B6 available,
  of B7 authorized and permitted overdraft of B8 blocks on disk
If the user has no files in other directories and all file-headers are only 1 block, then the following should apply: 
  B5=B2+B4+F1+1
If the diskquota is out of synch, then the system-manager can do a rebuild.

Also be aware that the DIRECTORY/SIZE command can report larger values than might otherwise be expected when used to evaluate files and/or directories that are alias links - such as the system roots on OpenVMS system disks - as the command reports a total that is cumulative over all of the files and directories examined, without regard for which ones might be alias entries and which are not. (In other words, a DIRECTORY/SIZE of an entire OpenVMS system disk will report a disk useage value larger than the (usually more accurate) value reported by the SHOW DEVICE command. This as a result of the alias entries linking each SYS$SYSDEVICE:[SYSCOMMON]SYS*.DIR directory file and the SYS$SYSDEVICE:[000000]VMS$COMMON.DIR file together.) 


					[Arne Vajhøj]


FILE3.

How do I make sure that my data is safely written to disk?

If your application must absolutely guarantee that data is available, no matter what, there's really no substitute for RMS Journalling. However, you can achieve a good degree of data integrity by issuing a SYS$FLUSH RMS call at appropriate times (if you're using RMS, that is.) If you're using a high-level language's I/O system, check that language's documentation to see if you can access the RMS control blocks for the open file. In C you can use fflush followed by fsync. Note that fsync, which was undocumented for VAX C but is documented for DEC C, takes a file descriptor as an argument, not a *FILE.


FILE4.

What are the limits on file specifications and directories?

A file specification has an aggregate maximum size of 255 characters at present. The node and device specification may be up to 255 characters each - file name and file types may be up to 39 characters each. File versions are from 1 through 32767, though 0 (latest version), -0 (oldest version) and , -n (n'th previous version) can be used in most contexts. A file specification may not have more than 8 directories and subdirectories - while it is possible to create subdirectories of greater depth, accessing them is problematic in most cases and this should be avoided.

Application developers should use OpenVMS-supplied routines for parsing file specifications - this ensures that changes in what is allowable will not tend to break your application. Consider that various parts of the file specification may contain quoted strings with embedded spaces and other punctuation!
Some routines of interest are SYS$FILESCAN, SYS$PARSE and LIB$TRIM_FILESPEC.
For further information, see the OpenVMS Guide to File Applications.


FILE5.

What is the largest disk volume size OpenVMS can access?

   One Terabyte (231 blocks of 29 bytes)

Prior to the release of V6.0, the OpenVMS file system was limited to disk volumes of 8.38 GB (224 blocks) or less.

On some systems, there are restrictions in the console program that limit the size of the OpenVMS system disk. Note that data disks are not affected by console program limits. For example, all members of the VAXstation 3100 series are limited to a system disk to 1.073 GB or less due to the console, though larger data disks are possible.

Some SCSI disks with capacities larger than 8.6 gigabytes (GB) will require the use of an OpenVMS ECO kit (eg: ALPSCSI04_062 or later) for new SCSI device drivers. Failure to use this ECO can cause "rounding errors" on the SCSI disk device capacity - OpenVMS will not use nor display the full capacity of the drive - and give
"%SYSINIT-E-ERROR, Mounting system device status equals 000008C4"
(8C4 -> "%SYSTEM-?-FILESTRUCT, unsupported file structure level")
errors during bootstrap. (One workaround for the bootstrap when the bitmap is located far into the disk is the use of INIT/INDEX=BEGIN.) The problem here involves the particular extensions and fields used for larger capacity disks within the SCSI specifications and within the various intepretations of same. 

					[Steve Hoffman]
For IDE disk drives:
See ALPHA23 for additional IDE DQDRIVER information.
Be aware that a known restriction in certain older versions of the Alpha SRM Console prevents booting most IDE drives larger than 8.455 GB, depending on exactly where the various files are located on the volume. Updated SRM consoles for systems with SRM and IDE drive support are (will be) available. (OpenVMS Engineering has successfully bootstrapped 20GB IDE disks using the appropriate SRM console version.)

NOTE: All IDE-related disk sizes listed in this section are stated in units of "disk (base 10) gigabytes" (1GB = 109 bytes) and not in units of "software (base 2) gigabytes" (1GB = 230 (1073741824.) bytes. 

                                                  [Atlant Schmidt]
Be aware that larger disks that are using an extension of SCSI-2 -- disks that are using a mode page field that the SCSI specifications normally reserved for tape devices - to permit a larger disk volume size will require a SCSI driver update for OpenVMS, and this change is part of V7.1-2 and later, and also part of ALPSCSI07_062 and later.
(These larger disks disks will typically report a DRVERR, or will see the volume size "rounded down".) SCSI disks larger than 16777216 blocks circa 8.455 GB (base ten); 8GB (base two) require this ECO, or require the use of OpenVMS Alpha V7.1-2 or later.
Also see VAX5. 
                                        [Atlant Schmidt]


FILE6.

What is the maximum file size, and the RMS record size limit?

RMS can store individual files of a size up to the maximum supported volume size. Under OpenVMS V6.0 and later, the volume size and the RMS maximum file size limit is

   231 * 512 bytes = one terabyte (1 TB.)

The RMS formats - sequential, relative, and indexed - are limited by the one terabyte maximum volume size. RMS relative files are further limited to a number of records that will fit in 32 bits - 4 billion records. Sequential and indexed formats do not have a record limit.

Also see PROG14. 

					[Steve Hoffman]


FILE7.

How do I write recordable CD media (CD-R) on OpenVMS?

Creation of CD-ROMs using recordable CD media (CD-R) under OpenVMS typically involves one of two approaches: the use of the optional CD-R (Scribe) capabilities available for the InfoServer or other "offline" hardware packages, or the use of a host-based package such as the CDWRITE13_VMS utility, an OpenVMS port of a Linux tool.

OpenVMS has no integrated support for recording CD-R media.

OpenVMS can read both ODS2 and ISO9960 format CD-ROMs.

InfoServer hardware configurations are no longer availble from Compaq, but may potentially be acquired through other means.

The CDWRITE13_VMS package is one example of a host-based package that can be used to create CD-R media. The contact for CDWRITE13_VMS is Dr. Eberhard Heuser-Hofmann. One website that discusses this package is located at: 

   http://www.geocities.com/SiliconValley/Lakes/9999/vmscdwri.html
Also see the newest linux-cdwrite package, XCDROAST.

Additional information is available via David J. Dachtera at: 

  http://www.djesys.com/vms/cdrom.html

Also see: 

  http://www.cd-info.com/CDIC/Technology/CD-R/vms.html

  http://www.faqs.org/faqs/cdrom/cd-recordable/part1/preamble.html

  http://www.tmesis.com/CDrom/

  http://www.tditx.com/~odsiso/


                                          [Steve Hoffman]
U.S. Design offers a package that includes the tools necessary to create a CD with either 9660 or ODS-2 format, for standalone CD-R drives, for OpenVMS Alpha V7.1 and later. Details are available at: 
  http://www.usdesign.com/

                                           [Harry Garonzik]


FILE8.

What I/O transfer size limits exist in OpenVMS?

The maximum transfer size is an attribute of the particular I/O device, controller and driver combination; there is no inherent limit imposed by OpenVMS (other than the fact that, today, byte counts and LBNs are generally limited to 32 bits).

The maximum size of a device I/O request is limited by the value in UCB$L_MAXBCNT, which is set by the device driver based on various factors. (Also check the setting of the MAXBUF system parameter for buffered I/O transfers, and check the process quotas.)

Currently, SCSI drivers limit I/O transfers to FE00(16) bytes, 65024 bytes (decimal). The reasons for this transfer size limitation are largely historical. Similarly, DSSI devices are limited to the same value, this for hardware-specific reasons. Transfers to HSC and HSJ device controllers via the CI are limited to 1,048,576 bytes. Client MSCP-served devices are limited to 65535 bytes - to help ensure that the I/O fragmentation processing happens on the client and not on the server system.

Parts of the OpenVMS I/O subsystem are optimized for data transfers less than 64KB, because (obviously) most I/O operations are (substantially) less than that. OpenVMS can handle larger transfers, if the driver and the device can handle it.
Also see FILE4, FILE5 

                                        [John Croll]


FILE9.

Can I use ODBC to connect to OpenVMS database files?

Yes, you can use various available third-party packages that permit remote ODBC clients to access RMS files and various commercial databases via the network.

For RMS, consider acquiring packages from ISG (Navigator), EasySoft, Synergex, or Oracle (DB Integrator).

For specific commercial databases (other than RMS), contact the database vendor directly for assistance.


Next Back