[Info-vax] wrong file format

[1tim....@gmail.com]

well written code includes maintainability. if you don't ever have to revisit clever code, then great. If you have to go in years later to a bunch of non-typical code that is undocumented and spend quite a while untangling what the intent was, then you cost your company money unnecessarily. (I've written clever code, it has bit me and others - now I stress correct code, and if you have to do something weird, document it. explain why and what.)

we had a routine, for example, that allocated memory to use as caches for the application. it had some interesting things, and worked really well, until it was ported to the Alpha. I ended up completely-re-writing it.The original author made a lot of assumptions on everything from pointer sizes to what would be continuous and what would not. After it was re-written, it was faster and a number of mysterious application issues vanished. I didn't do anything particularly clever in the code, but I did document how it works.

Good algorithms and clean code usually trumps clever code. The exceptions are few. When they are necessary, then they're good. But document them!
By the same token, sometimes non-optimized code is appropriate too.  I've written code that appeared to be redundant, but I documented the why and the what.

</soapbox off>
On Thursday, January 7, 2021 at 6:16:55 PM UTC-7, Dave Froble wrote:
> On 1/7/2021 3:35 PM, 1tim.... at gmail.com wrote:
> > On Thursday, January 7, 2021 at 11:24:06 AM UTC-7, Stephen Hoffman wrote: 
> >> On 2021-01-07 17:44:40 +0000, 1tim.... at gmail.com said: 
> >> 
> >>> So do I, a product with a data dictionary and routines that use it to 
> >>> get at data. 
> >>> Short of making a relational or object oriented Database part of the 
> >>> OS, some extensions to RMS would go a long ways to being useful and 
> >>> shouldn't be that hard to implement. Once you start wandering into 
> >>> relational operators and joins, stuff get more complex and at that 
> >>> point you really should have a database... 
> >> Given there's a widely-used, portable, and robust SQL database already 
> >> ported to OpenVMS, and the port was integrated with the lock manager, 
> >> and it's free... 
> >> ...Tweaks around the edges of RMS which would require app code changes, 
> >> and replacing or acquiring CDD/Repository—for a fraction of what SQL 
> >> provides—don't seem optimal. 
> >> -- 
> >> Pure Personal Opinion | HoffmanLabs LLC 
> > 
> > Don't disagree with what you are saying, but going to a database is a "rip and replace" option, vs incorporating some convenient features into legacy code. 
> > If I'm supporting a large application with a large codebase, I'm not interested in ripping out the guts and making it use a relational database. I am, however, interested in making incremental improvements and simplifying code where possible. 
> > 
> > The ROI isn't there for most companies to replace the existing file system. The ROI is there to fold in incremental improvements in the course of doing enhancements and new development. The ability to do sets of data easily makes importing and exporting data to outside systems easier, or exposing data via web services easier. It's a lot easier to create a service that grabs a bunch of records in a single call than to have to loop and accumulate the data for the call. I suspect many of us have had to implement something like this. (Yes, solutions like Connex exist)
> I had this exact situation. I determined several things. 
> 
> 1) The application just didn't have use, in current form, for such 
> enhancements. 
> 
> 2) Any such project would extend itself to eternity, regardless of 
> original intentions. 
> 
> 3) What use might a relational database be? If for data mining and 
> such, the solution is simple. Set up a RDBMS and the means to populate 
> and update it from live data files. Which is what we did. This also 
> keeps people out of the live data.
> > It's funny how years later, clever code usually turns out to not be. 
> >
> I would not agree with that. Perhaps resources today allow better 
> solutions, but, the old solutions still do what they always have done.
> -- 
> David Froble Tel: 724-529-0450 
> Dave Froble Enterprises, Inc. E-Mail: da... at tsoft-inc.com 
> DFE Ultralights, Inc. 
> 170 Grimplin Road 
> Vanderbilt, PA 15486