[Info-vax] Still no DIR/SORT_BY_TIME

[AEF]

On Wednesday, August 12, 2015 at 6:55:22 PM UTC-4, Stephen Hoffman wrote:
> On 2015-08-12 22:29:26 +0000, xxxxx said:
> 
> > ... I'm just surprised that after ~38 years someone at DEC/... would 
> > have gotten around to it.
> 
> It's certainly reasonable -- maybe as part of that newer file system.

Newer file system?

> 
> Or you can put the timestamp in the filename.

Too much work. 

We are running a file-transfer system with files coming and going on a daily basis. We add our own time stamps. In some cases the customer is nice enough to put in _their own_ time stamps. And we have to add our own anyway!

> 
> But then I'm increasingly working a whole lot less with writing or 
> storing zillions of files -- and trying to create or store even fewer -- 
> and a whole lot more with data stored in databases.

I'm migrating a file-transfer system. And there's a real crap-load of files!

> 
> > We have several Alphas where I work now. My company got bought by 
> > another that has some Alphas and guess what? They want to move the 
> > stuff running on it to Solaris!
> 
> illumos provides a reasonably-compatible alternative there, if there's 
> ever a decision to exit the Oracle orbit.

We're using Sybase and Rapid SQL.

> 
> > And then upgrade that to Linux.
> 
> So... Somebody has a short attention span?

It's the old wait and hurry-up bit. I'm a frequent victim.

> 
> > And then write a nice front end for the database.
> 
> It seems maybe this is more about the Oracle database than the 
> operating system platform?

Most of the work is setting up jobs on the Unix/Sybase side. And most of that is entering data into the database that tells the well-established perl scripts what to do. Each and every file must be carefully processed and tracked, with numerous things happening differently for different jobs. Some are pgp-encrypted. Protocols vary (ftp, sftp, NDM, etc.).

And AutoSys runs the show; there's that too. Once the job is set up on the Unix side, we simply stop the corresponding job on the VMS side. Then something breaks. We go back to the VMS side, fix the Unix side, and then do take 2.

> 
> > This is the third time I'm involved with moving stuff off of VMS.
> 
> That's fairly common -- while the numbers of those have definitely 
> slowed down, the migrations may well start up again, depending on...

Well, with fewer and fewer VMS systems around, I'd expect things to slow down. :-)

> 
> > Should I freely load freeware onto production boxes? (Didn't intend the 
> > pun, but I'm leaving it in!)
> 
> You probably already have freeware on production boxes.  There's some 
> in the base OpenVMS distro.  Some in layered products.

But with those I can blame others.

Regardless, I couldn't stand setting default to non-existent directories anymore (with my co-worker having trouble remembering the exact spellings!) and not having all the other conveniences I have in my TO.COM command procedure. So I "installed" it. Fortunately there are no incompatibility issues.

> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC