Model 204 A Faster Way to CREATE
By James Damon
To use a dataset as a Model 204 file, you must first format it as a collection of 6184-byte blocks on disk using the CREATE command. Each page of the file, including FREESIZE pages, is formatted as a 6184-byte block.
Creating a file with FORMAT
CREATE command processing writes the following string to the first 50 bytes of each page, followed by hexadecimal zeroes for a total length of 6184 bytes:
INITIAL filename jobname stepname userid date/time
The pages are formatted in the buffer pool and written to the disk dataset, which guarantees that future I/O to the file will always read or write 6184-byte blocks. Any other block size on disk results in I/O errors, request cancellation, and user restarts.
Recreating a file with NOFORMAT
The CREATE command has an often overlooked option, which eliminates the formatting process and significantly reduces the elapsed time required for CREATE command processing. If you previously created a file using the (FORMAT) option and now you need to change parameters, such as FILEORG, ASIZE, CSIZE or BRECPPG, or you need to define additional fields as preallocated, and so on, issue a CREATE command with the NOFORMAT option. This avoids reformatting already formatted pages. CREATE command processing completes nearly instantaneously.
Reviewing the CREATE command statistics
For large files, the elapsed time that is required for the CREATE (FORMAT) process could be quite lengthy. In Figure 1 the T REQUEST command results illustrate the elapsed time required to format an OS dataset consisting of 50040 pages (417 cylinders) on IBM RAMAC disks emulating IBM-3390 DASD.
Figure 1. Statistics from an initial CREATE command
In Figure 1 the CNCT statistic shows that 134 seconds of elapsed time were required to format this file. The DKWR statistic shows that 50,042 disk writes were required. The elapsed time required for CREATE command processing depends on:
Processing statistics can vary substantially from one test to another, even for the same dataset or datasets.
By-passing reformatting
In our example, the NOFORMAT option saved 2.2 minutes of elapsed time and 50,040 disk writes, as Figure 2 illustrates.
Figure 2. Statistics after recreating the file with the NOFORMAT option
NOFORMAT option limitations
You can use the NOFORMAT option only when issuing a CREATE command against a file and associated datasets that were previously formatted using a CREATE (FORMAT) command. If datasets comprising the file have been deleted and reallocated with different space attributes, or if new datasets have been added, some blocks on disk may now be less than or greater than 6184 bytes in length. The NOFORMAT option must not be used. Otherwise, you will get I/O errors and Model 204 error messages.
If you are uncertain whether the file is completely formatted and you now need to make changes, you can always reissue a CREATE (FORMAT) command to avoid problems.
NOFORMAT option recommendations
The NOFORMAT option is most useful in the development cycle of file design. File parameters and field attributes are changing, as more information regarding file requirements becomes known. In these cases, files are often created and re-created numerous times. The development team is usually aware whether the datasets involved were completely formatted by a previous CREATE (FORMAT) command. In the development cycle the NOFORMAT option saves considerable time.
System 1032 Security Aspects of System 1032 Files
By Tym Stegner
There are two maxims about data security:
While the former method is actually used in some government applications–data is removed from the computer nightly–the latter can lead to some ticklish social problems.
This article briefly explores System 1032's inherent and extendable abilities to secure your data, and in a much less drastic manner.
Keeping Outsiders Out
Users of the System 1032 DBMS are truly fortunate, because System 1032 runs on OpenVMS, one of the more secure operating systems available today. By following the instructions in the OpenVMS system security guide and running some additional third-party software, OpenVMS recently withstood an entire hacker's convention. The purpose of the convention was to have teams of hackers break into each other’s on-site systems. At the end of the three-day conference, the organizers declared OpenVMS unhackable.
For more details on the conference look at their Web site:
www.pointsecure.com/defconwhite.pdf
Or, search the comp.os.vms newsgroup for the keyword unhackable.
Keeping Insiders Where They Belong
However, a secure operating system may not protect your system from your own users. Even though you might encapsulate your applications into command files and menu systems, occasionally an error may drop your user to the command prompt. A savvy user might try to exploit this error by wandering about the system while they have the chance.
System-level security
OpenVMS has features that help you isolate and control access to your files. This includes the directory and file-level protection mechanisms, as well as subsystem, file, and resource identifiers.
Also, OpenVMS security auditing server process lets you track which account accessed files and by what means. Use of the SET and SHOW AUDIT commands lets you set alerts and track different sorts of access to any resource on your system, including devices, accounts, directories, and individual files.
System 1032-level security
In addition to all the OpenVMS security, there are the System 1032 security mechanisms. System 1032 security is a layer below OpenVMS resource security. Although OpenVMS might allow access to a file, System 1032 might not. Or, System 1032 might allow different, more limited access.
You can apply System 1032 security at the catalog level–databases, datasets and libraries–as well as at the individual attribute level and down to the record level. Access is denied using the PREVENT command and enabled using the ADMIT command. Both commands are used in combination. Sometimes it is enough to deny access to only System 1032 resources. At other times, selected groups must be granted a higher level access than the default.
In a similar fashion, you can apply security to procedures, RDs, and forms that limits access only to those users authorized to make use of them.
You can enable security on any combination of UIC, Username, password or resource identifier level access. You can apply security to a discrete level of options, including ADD, ALL_ACCESS, CHANGE, DELETE, EXECUTE, MODIFY, OPEN, READ, SHOW, and UPDATE.
Record-level security
For record-level security, the dataset presents to users only those records available to their level of security access. You can set record-level security to automatically update the user's record set after authorized updates, which continues to limit the exposure of the records. It is possible to set record security so that a user can add a record, but not read it.
Security violations at the System 1032-level result in E-level errors. Unauthorized access during any program aborts that program.
Correcting the unintended action
Security is checked before update commands are executed. Unauthorized users cannot trash data from within System 1032. However, this does not prevent authorized, but unintended updates from overwriting valid data, or prevent deleting an entire block of data, when the intent was to delete a single record. System 1032 journaling and good backups can be the solution to the former problem. A PL1032 UNDELETE command can solve the latter.
The Enemy Within: dump
"Wait!" says the evil user. "OpenVMS gives me read-access to the file, although System 1032 does not. I can recover data from System 1032 datasets just by using the OpenVMS dump command to output the file contents. I can read it all from the output listing."
"Foiled!" you reply, "Because, even if you know the exact layout of a dataset, you are likely to recover only obvious text data elements–and we’ve got ways to hide those."
Scrambling data by design
System 1032 does not store data in a record-oriented format. All I/O to datasets is done at the block I/O level. Although records in the dataset appear in sequential order, the data structures within the dataset file are not required to be in such order. Furthermore, the order of data within the System 1032 record structure does not often follow the attribute order; usually data is not in attribute order.
For numeric or date items with ranges, the attribute values are not stored in the record. The same goes for numeric items with PRECISION or SCALE properties. Text varying attributes are stored in completely separate data structures from the records; the correlation between a particular text varying item and its record isn't apparent.
Encrypting text data
By design, the values of text attributes are stored openly and could be recovered from a dump command output. The overhead associated with encrypting and decrypting text data is excessive for the default data entry, storage, and retrieval mechanisms. Sites can make their own decisions about whether to encrypt text data.
Fortunately, it is not difficult for your site to encrypt your text data. Any encryption program available for an OpenVMS system can be used, as long as you can call the interface at the shareable image level. A System 1032 external procedure is defined to interface with the callable interface, and your application must take the necessary steps to encrypt and decrypt data.
In Summary
Thus, the combination of OpenVMS embedded security features and the available security features of System 1032 combine to almost completely hide your valuable data from prying eyes.
Copyright © 2003 Computer Corporation of America. All right reserved. Published in the United States of America.
500 Old Connecticut Path, Framingham, MA 01701 Contact CCA Webmaster Copyright 2005
