🚀 go-pugleaf

In article <mcdonald.624@aries.scs.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
> In article <1992Dec19.012355.26665@ll.mit.edu> ejon@ll.mit.edu (Eric Jones) writes:
> 
> 
>>But isn't that exactly his point?  Sure you can write an ISAM file 
>>structure using fseek (and if you're REALLY smart, you might even
>>write an efficient one), but then how's anyone else going to use
>>your files?
> 
> By RTFM of course!!
 
This post brings up an old problem, namely that of file formats. 
Remember, while it is easy to implement a record management system, it is also 
easy to create a record management system with bugs. Whether or 
not you want to consider it, the RMS file formats and 
implementations represent a choice in favor of STANDARDS, which 
while they are specific to a particular vendor, are standard for 
all conforming programs on the platform, something which is 
certainly not true on platforms where everybody writes their own 
ISAM implementation.
> 
> Consider the converse: 
> 
> You write a file using the oddball formats of VMS.
> 
> You send it to someone else.
> 
> He can't read it because it's oddball.
> 
> How does he read it??
Multipart answer. First, there has always been a standard way of 
sending files between systems, namely SEQUENTIAL, FLAT format. 
Sending an ISAM type file to another site running a different 
type of hardware/operating system is rather chauvanistic, and not 
a good example.
 
> The only way is to RTFM and here the FM refers to the 1600 pounds
> of VMS stuff or Disk 47 of the 677 volume CD manuals.
> 
Last time I checked, the CD DOC set was less than 10 disks (If I 
remember correctly, less than 5). In any event, you can find the 
information required to unload an indexed to a sequential file in 
the online help text.
 
> The Unix way has proven to be the best way; its one of the biggest
> reasons VMS is a current sales disaster.
> 
> The doc for your own ISAM is maybe 2 pages long.
> 
And the doc for each of the other ISAMs written because "mine is 
better" is also two pages long, leading to thousands of pages of 
documentation covering equivalent facilities with small 
differences.

> Also consider this: if you write that file on VMS using the VMS
> proprietary method, you can't read it on any other machine using
> the same code. If you did it the C/Unix way, you code will run as-is
> on any machine using standard C. Even VMS. 
> 
Incorrect. The reason that you cannot read it with C is that C 
has consistently ignored the standardization of IO interfaces. If 
you used a language which included a standard for keyed record 
access (e.g. COBOL((shudder..shudder)), you would be able to use 
the same code on both machines/operatinig systems)

> Doug McDonald
-- 
 
- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+