On Sunday, November 6, 2022 at 7:55:23 AM UTC-6, Scott Dorsey wrote:
> First thing: VMS has heavyweight processes. There's a lot of stuff in the
> process, so spawning off new processes takes a good while, and you don't do
> it very often. Conceptually different than Unix and Unixalikes where the
> processes are lightweight and the overhead of a fork is minimal so you fork
> off a new process for nearly everything.
>
> Whereas the concept of "resources" in Linux is fairly simple, VMS has a lot
> of different resources which are managed statically by the operating system.
> Some of that resource management goes into making the processes more
> heavyweight. This can be a powerful tool to keep multiple users from
> interfering with one another on a system with limited resources. In a
> scientific computing environment it can also be a pain in the neck because
> people will run their job for three days and then hit a working set limit
> and need to figure out what the limit really should be.
>
> But yes, some of the "big computer" batch features that you get with PBS and
> OS/360 are present by default in VMS, and that's a nice thing. Using VMS on
> a machine acting as a front-end to a high-speed computer was great.
>
> Mind you, the best batch management system in the world won't keep researchers
> from paying the second shift operators under the table to move their jobs to
> the front of the queue.
> --scott
>
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

Going a slightly different way, does files versioning help relieve the programmers from some of the work necessary to roll back a corrupted dataset when something goes wrong with their job? In the IBM world, they talk about the production control analysts managing the batch processing. I suppose file version control might be one of the tools that they use, maybe in organizations that have a lot of duty separation.

On 11/6/2022 12:23 AM, Dave Froble wrote:
> On 11/5/2022 8:42 PM, Arne Vajhøj wrote:
>> On 11/5/2022 8:25 PM, Robert Carleton wrote:
>>> I work in an environment where there's lots of scientific computing
>>> on the Linux platform. One of the things about it, is that getting
>>> compute time is very competitive, and our users/coders game the batch
>>> systems to gain an advantage in getting their jobs to run. We can't
>>> use the stock Linux batch systems (at, batch, atd, cron, and friends)
>>> for that work, though the system administrators probably use those
>>> for some of what they do. We have to use add-on batch systems for
>>> controlling those jobs.
>>>
>>> I'm not familiar with the VMS batch facilities yet (I'm a Linux/BSD
>>> jockey), but I've heard that they are pretty advanced. Perhaps that
>>> would provide an advantage, at least when there is a lot of
>>> competition for compute resources.
>>
>> VMS batch queues are pretty good. You setup the queues with
>> priority, task limit, CPU limit, memory limit etc.. Good cluster
>> support. The only thing I don't like is the defaults for
>> the log file - and that is a minor inconvenience.
>
> Not sure what you dislike about batch log files ...
>
> SUBMIT
>
>   /LOG_FILE
>
>         /LOG_FILE[=filespec]
>         /NOLOG_FILE
>
>      Names the log file. The asterisk (*)  and the percent sign (%)
>      wildcard characters are not allowed in the file specification.
>
>      When you use the /LOG_FILE qualifier, the system writes the batch
>      job's output to the file you specify. If you use the /NOLOG_FILE
>      qualifier, no log file is created. By default, a log file is
>      created, is written to the directory defined by the logical name
>      SYS$LOGIN in the UAF, and is given the batch job's name as its
>      file name with a file type of LOG. By default, a log file also is
>      given the batch job's name as its file name with a file type of
>      LOG.
>
> Seems to cover a lot.

I dislike the default location. I would very much prefer
them to go to either dir with com file or current dir when
submitting instead of sys$login.

And I dislike that /PRINT is default.

Arne

On 11/6/2022 1:18 PM, Robert Carleton wrote:
> Going a slightly different way, does files versioning help relieve
> the programmers from some of the work necessary to roll back a
> corrupted dataset when something goes wrong with their job? In the
> IBM world, they talk about the production control analysts managing
> the batch processing. I suppose file version control might be one of
> the tools that they use, maybe in organizations that have a lot of
> duty separation.

I suspect that most VMS users at one point in time has been
very happy about the file versions because it saved them from
loosing something important.

But in more structured environments then the important
files are managed via some sort of repository with version
control.

Arne

On 11/6/2022 8:55 AM, Scott Dorsey wrote:
> First thing: VMS has heavyweight processes. There's a lot of stuff in the
> process, so spawning off new processes takes a good while, and you don't do
> it very often. Conceptually different than Unix and Unixalikes where the
> processes are lightweight and the overhead of a fork is minimal so you fork
> off a new process for nearly everything.

That was the gospel for many years.

But the overhead of creating a process much be a lot less
significant on an Itanium or x86-64 today than it was on
a VAX 35 years ago.

And I believe that for true high performance then even
*nix are switching from traditional forking to threads.

Arne

On 11/6/22 12:50 PM, Arne Vajhøj wrote:
> On 11/6/2022 12:23 AM, Dave Froble wrote:

>> Not sure what you dislike about batch log files ...

> I dislike the default location. I would very much prefer
> them to go to either dir with com file or current dir when
> submitting instead of sys$login.

The user in many common scenarios does not have write access to either
of those locations.

> And I dislike that /PRINT is default.

Amen!

On 11/6/22 12:58 PM, Arne Vajhøj wrote:
> On 11/6/2022 8:55 AM, Scott Dorsey wrote:
>> First thing: VMS has heavyweight processes.  There's a lot of stuff in
>> the
>> process, so spawning off new processes takes a good while, and you
>> don't do
>> it very often.  Conceptually different than Unix and Unixalikes where the
>> processes are lightweight and the overhead of a fork is minimal so you
>> fork
>> off a new process for nearly everything.
>
> That was the gospel for many years.
>
> But the overhead of creating a process much be a lot less
> significant on an Itanium or x86-64 today than it was on
> a VAX 35 years ago.
>
> And I believe that for true high performance then even
> *nix are switching from traditional forking to threads.

And not everyone thinks fork() is such a great idea anymore even aside
from performance considerations, e.g.:

https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

This could be good news for VMS if major applications start using
posix_spawn() instead of fork(); it would map much better to the VMS way
of doing things, and it might even be reasonable to provide a
posix_spawn() API on VMS.

On 11/6/2022 1:18 PM, Robert Carleton wrote:
> On Sunday, November 6, 2022 at 7:55:23 AM UTC-6, Scott Dorsey wrote:
>> First thing: VMS has heavyweight processes. There's a lot of stuff in the
>> process, so spawning off new processes takes a good while, and you don't do
>> it very often. Conceptually different than Unix and Unixalikes where the
>> processes are lightweight and the overhead of a fork is minimal so you fork
>> off a new process for nearly everything.
>>
>> Whereas the concept of "resources" in Linux is fairly simple, VMS has a lot
>> of different resources which are managed statically by the operating system.
>> Some of that resource management goes into making the processes more
>> heavyweight. This can be a powerful tool to keep multiple users from
>> interfering with one another on a system with limited resources. In a
>> scientific computing environment it can also be a pain in the neck because
>> people will run their job for three days and then hit a working set limit
>> and need to figure out what the limit really should be.
>>
>> But yes, some of the "big computer" batch features that you get with PBS and
>> OS/360 are present by default in VMS, and that's a nice thing. Using VMS on
>> a machine acting as a front-end to a high-speed computer was great.
>>
>> Mind you, the best batch management system in the world won't keep researchers
>> from paying the second shift operators under the table to move their jobs to
>> the front of the queue.
>> --scott
>>
>> --
>> "C'est un Nagra. C'est suisse, et tres, tres precis."
>
> Going a slightly different way, does files versioning help relieve the programmers from some of the work necessary to roll back a corrupted dataset when something goes wrong with their job? In the IBM world, they talk about the production control analysts managing the batch processing. I suppose file version control might be one of the tools that they use, maybe in organizations that have a lot of duty separation.
>

Question is way too vague for reasonable answers. However, I personally would
not consider file versions for any data issues. BACKUP, and today's RDBMS
systems with complex transactions, and such, might work for screw-ups, if I had
any idea what screw-ups you might be considering.

My biggest use of multiple file versions was if I made some changes to a program
that I didn't like. Easy to revert to a prior version, or, to extract from a
prior version some code you wish you hadn't deleted.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/6/2022 6:42 PM, Craig A. Berry wrote:
>
> On 11/6/22 12:58 PM, Arne Vajhøj wrote:
>> On 11/6/2022 8:55 AM, Scott Dorsey wrote:
>>> First thing: VMS has heavyweight processes. There's a lot of stuff in the
>>> process, so spawning off new processes takes a good while, and you don't do
>>> it very often. Conceptually different than Unix and Unixalikes where the
>>> processes are lightweight and the overhead of a fork is minimal so you fork
>>> off a new process for nearly everything.
>>
>> That was the gospel for many years.
>>
>> But the overhead of creating a process much be a lot less
>> significant on an Itanium or x86-64 today than it was on
>> a VAX 35 years ago.
>>
>> And I believe that for true high performance then even
>> *nix are switching from traditional forking to threads.
>
> And not everyone thinks fork() is such a great idea anymore even aside
> from performance considerations, e.g.:
>
> https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
>
> This could be good news for VMS if major applications start using
> posix_spawn() instead of fork(); it would map much better to the VMS way
> of doing things, and it might even be reasonable to provide a
> posix_spawn() API on VMS.
>

I could argue that VMS already has several APIs for spawned and detached
processes, but, I'd be the first to agree that the devil is in the details.
I've used subprocesses and detached processes for a long time, and developed my
methods for performing such tasks.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/6/2022 1:50 PM, Arne Vajhøj wrote:
> On 11/6/2022 12:23 AM, Dave Froble wrote:
>> On 11/5/2022 8:42 PM, Arne Vajhøj wrote:
>>> On 11/5/2022 8:25 PM, Robert Carleton wrote:
>>>> I work in an environment where there's lots of scientific computing
>>>> on the Linux platform. One of the things about it, is that getting
>>>> compute time is very competitive, and our users/coders game the batch
>>>> systems to gain an advantage in getting their jobs to run. We can't
>>>> use the stock Linux batch systems (at, batch, atd, cron, and friends)
>>>> for that work, though the system administrators probably use those
>>>> for some of what they do. We have to use add-on batch systems for
>>>> controlling those jobs.
>>>>
>>>> I'm not familiar with the VMS batch facilities yet (I'm a Linux/BSD
>>>> jockey), but I've heard that they are pretty advanced. Perhaps that
>>>> would provide an advantage, at least when there is a lot of
>>>> competition for compute resources.
>>>
>>> VMS batch queues are pretty good. You setup the queues with
>>> priority, task limit, CPU limit, memory limit etc.. Good cluster
>>> support. The only thing I don't like is the defaults for
>>> the log file - and that is a minor inconvenience.
>>
>> Not sure what you dislike about batch log files ...
>>
>> SUBMIT
>>
>> /LOG_FILE
>>
>> /LOG_FILE[=filespec]
>> /NOLOG_FILE
>>
>> Names the log file. The asterisk (*) and the percent sign (%)
>> wildcard characters are not allowed in the file specification.
>>
>> When you use the /LOG_FILE qualifier, the system writes the batch
>> job's output to the file you specify. If you use the /NOLOG_FILE
>> qualifier, no log file is created. By default, a log file is
>> created, is written to the directory defined by the logical name
>> SYS$LOGIN in the UAF, and is given the batch job's name as its
>> file name with a file type of LOG. By default, a log file also is
>> given the batch job's name as its file name with a file type of
>> LOG.
>>
>> Seems to cover a lot.
>
> I dislike the default location. I would very much prefer
> them to go to either dir with com file or current dir when
> submitting instead of sys$login.
>
> And I dislike that /PRINT is default.
>
> Arne

Arne, I've always used the /LOGFILE=<some location>. I like to know where to
look for my logfiles, not have to search for them. It sure makes automated
searches of logfiles much easier. And I never allow a default print of a logfile.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/6/2022 9:00 PM, Dave Froble wrote:
> On 11/6/2022 1:50 PM, Arne Vajhøj wrote:
>> On 11/6/2022 12:23 AM, Dave Froble wrote:
>>> On 11/5/2022 8:42 PM, Arne Vajhøj wrote:
>>>> VMS batch queues are pretty good. You setup the queues with
>>>> priority, task limit, CPU limit, memory limit etc.. Good cluster
>>>> support. The only thing I don't like is the defaults for
>>>> the log file - and that is a minor inconvenience.
>>>
>>> Not sure what you dislike about batch log files ...

>> I dislike the default location. I would very much prefer
>> them to go to either dir with com file or current dir when
>> submitting instead of sys$login.
>>
>> And I dislike that /PRINT is default.
>
> Arne, I've always used the /LOGFILE=<some location>.  I like to know
> where to look for my logfiles, not have to search for them.  It sure
> makes automated searches of logfiles much easier.

I use that as well.

But if the default was current dir when SUBMIT or dir with COM file,
then I could omit that in 95% of cases.

> And I never allow a
> default print of a logfile.

I would assume nobody does that today or for the last few
decades.

I even doubt that most VMS system have a printer at all
today.

So I think /NOPRINT would be a better default.

Arne

PS: I realize that changing default will likely not happen.

PPS: And it is just a tiny problem.

On 11/6/2022 9:06 PM, Arne Vajhøj wrote:
> On 11/6/2022 9:00 PM, Dave Froble wrote:
>> On 11/6/2022 1:50 PM, Arne Vajhøj wrote:
>>> On 11/6/2022 12:23 AM, Dave Froble wrote:
>>>> On 11/5/2022 8:42 PM, Arne Vajhøj wrote:
>>>>> VMS batch queues are pretty good. You setup the queues with
>>>>> priority, task limit, CPU limit, memory limit etc.. Good cluster
>>>>> support. The only thing I don't like is the defaults for
>>>>> the log file - and that is a minor inconvenience.
>>>>
>>>> Not sure what you dislike about batch log files ...
>
>>> I dislike the default location. I would very much prefer
>>> them to go to either dir with com file or current dir when
>>> submitting instead of sys$login.
>>>
>>> And I dislike that /PRINT is default.
>>
>> Arne, I've always used the /LOGFILE=<some location>. I like to know where to
>> look for my logfiles, not have to search for them. It sure makes automated
>> searches of logfiles much easier.
>
> I use that as well.

Not only do I use a special location for batch log files, such as the logical
BATLOG, the file usually includes data such as YYYYMMDDHHMMSS in the filespec.

Having a convention of some string included in error messages, which can easily
be found using a SEARCH command, sure makes finding exceptions easy, and the
lack of any such is a decent indicator of success.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-11-06, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
> On 11/6/22 12:50 PM, Arne Vajhøj wrote:
>> On 11/6/2022 12:23 AM, Dave Froble wrote:
>
>>> Not sure what you dislike about batch log files ...
>
>> I dislike the default location. I would very much prefer
>> them to go to either dir with com file or current dir when
>> submitting instead of sys$login.
>
> The user in many common scenarios does not have write access to either
> of those locations.
>

And in the second example, even when you do have write access, that means
the log files would be created all over the place within the directory tree
instead of in one known location. Yuck!!! :-)

>> And I dislike that /PRINT is default.
>
> Amen!
>

Now that is one thing I _strongly_ agree with. It's about 30 years
later than it should have been for that to be switched to /NOPRINT
by default. Yes, it's an incompatible change. Yes, it's worth it.

VSI: If you want to change that default to /NOPRINT, then you would
strongly have my support. :-)

Here's a related question: Should /NOTIFY be the default on batch jobs
instead of the current /NONOTIFY ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Robert Carleton <rbc@rbcarleton.com> wrote:
>Going a slightly different way, does files versioning help relieve the prog=
>rammers from some of the work necessary to roll back a corrupted dataset wh=
>en something goes wrong with their job? In the IBM world, they talk about t=
>he production control analysts managing the batch processing. I suppose fil=
>e version control might be one of the tools that they use, maybe in organiz=
>ations that have a lot of duty separation.

I found it problematic in a scientific programming environment, but I think
a lot of that was due to users not really taking advantage of it.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 11/6/2022 8:55 AM, Scott Dorsey wrote:
>> First thing: VMS has heavyweight processes. There's a lot of stuff in the
>> process, so spawning off new processes takes a good while, and you don't do
>> it very often. Conceptually different than Unix and Unixalikes where the
>> processes are lightweight and the overhead of a fork is minimal so you fork
>> off a new process for nearly everything.
>
>That was the gospel for many years.
>
>But the overhead of creating a process much be a lot less
>significant on an Itanium or x86-64 today than it was on
>a VAX 35 years ago.

Yes, but fork is faster on Unix than it used to be also.

>And I believe that for true high performance then even
>*nix are switching from traditional forking to threads.

Different tools for different jobs. But threads are another thing that DEC
did so much better than anyone else but then totally lost the lead on.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 11/7/2022 8:16 AM, Simon Clubley wrote:
> On 2022-11-06, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>> On 11/6/22 12:50 PM, Arne Vajhøj wrote:
>>> On 11/6/2022 12:23 AM, Dave Froble wrote:
>>>> Not sure what you dislike about batch log files ...
>>> I dislike the default location. I would very much prefer
>>> them to go to either dir with com file or current dir when
>>> submitting instead of sys$login.
>>
>> The user in many common scenarios does not have write access to either
>> of those locations.
>
> And in the second example, even when you do have write access, that means
> the log files would be created all over the place within the directory tree
> instead of in one known location. Yuck!!! :-)

I guess there are two ways to structure ones files:
- by type, com & exe files one dir (possible with subdirs
per application), data files one dir, log files one dir
- by application, one dir per application with everything
com & exe and data and log files (possible with a subdir
per type)

I prefer the second.

>>> And I dislike that /PRINT is default.
>>
>> Amen!
>
> Now that is one thing I _strongly_ agree with. It's about 30 years
> later than it should have been for that to be switched to /NOPRINT
> by default. Yes, it's an incompatible change. Yes, it's worth it.
>
> VSI: If you want to change that default to /NOPRINT, then you would
> strongly have my support. :-)
>
> Here's a related question: Should /NOTIFY be the default on batch jobs
> instead of the current /NONOTIFY ?

Makes sense to me.

Arne

On 11/7/2022 3:48 PM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 11/6/2022 8:55 AM, Scott Dorsey wrote:
>>> First thing: VMS has heavyweight processes. There's a lot of stuff in the
>>> process, so spawning off new processes takes a good while, and you don't do
>>> it very often. Conceptually different than Unix and Unixalikes where the
>>> processes are lightweight and the overhead of a fork is minimal so you fork
>>> off a new process for nearly everything.
>>
>> That was the gospel for many years.
>>
>> But the overhead of creating a process much be a lot less
>> significant on an Itanium or x86-64 today than it was on
>> a VAX 35 years ago.
>
> Yes, but fork is faster on Unix than it used to be also.

Of course.

The relative difference is probably the same, but the absolute
difference has gotten smaller.

If back then it was VMS process creation 5% CPU Unix fork 0.5% CPU,
then it today would be VMS process creation 0.1% CPU *nix fork 0.01%
CPU.

>> And I believe that for true high performance then even
>> *nix are switching from traditional forking to threads.
>
> Different tools for different jobs. But threads are another thing that DEC
> did so much better than anyone else but then totally lost the lead on.

What are you referring to? The old CMA$ interface?

Arne

> [...] I dislike that /PRINT is default.

> [...] Should /NOTIFY be the default on batch jobs
> instead of the current /NONOTIFY ?

By the principle of minimum annoyance, the defaults should be
/NONOTIFY and /NOPRINTER. I'd prefer an accidental qualifier omission
not to cause gratuitous waste of trees and toner, nor to corrupt all my
interactive terminal session displays.

If I want a batch job to generate output, then I know how to make
that happen.

On 2022-11-06 18:18:29 +0000, Robert Carleton said:

> Going a slightly different way, does files versioning help relieve the
> programmers from some of the work necessary to roll back a corrupted
> dataset when something goes wrong with their job? In the IBM world,
> they talk about the production control analysts managing the batch
> processing. I suppose file version control might be one of the tools
> that they use, maybe in organizations that have a lot of duty
> separation.

For small stuff, sure. XQP file versions can and do work. For more
complex code changes as tend to be typical, file version rollbacks get
gnarly as most change sets lack a consistent number of versions for a
set of related code changes across a selection of files. Rolling back
changes with file versions then means finding the right group of file
versions. Which is usually not ;-1 or ;-2 across all of the various
files involved in the source code change.

XQP file versions also tend to need explicit management, and version
cleanups can be hazardous for the practices used at some sites. And
there's no good means to clean up intermediate file versions between
those that a developer might wish to preserve.

IBM Rational Clearcase VOB is a very nice implementation of file
versioning for app development, though that never really caught on more
generally. The VOB presents a build or version or baselevel or whatever
a developer or development team might call a collection of related
source code changes, as a synthetic file system as a view from within
the DVCS. The usual implementation here is based on a FUSE, which is
fairly commonly feature available. There are undoubtedly some other and
analogous implementations to VOBs, too. Switch the build or version or
whatever, and the (virtual, synthetic) part of the file system you're
looking and working within switches to what that build or baselevel
would look like.

For the development projects I'm typically dealing with, pushing
changes to the local DVCS is the usual approach when building stuff and
is integrated within the IDE, and that makes rollbacks easy. Once ready
to share, the code gets pushed from local into general availability.
Getting better support in LSEDIT might help some, and other folks can
choose to use VSC as that gets better integrated. If you're not using
an IDE, then you're probably going to be getting familiar with git
command line syntax.

As a competitive feature, I suspect there'd be much more interest in
integration with git or hg and with common IDE such as VSC than with
the existing file versioning scheme. But sure, XQP file versioning does
work for smaller efforts and smaller pools, and it does work when the
developer and the local tooling is lacking. (Which it kinda is lacking,
on OpenVMS. VSC and VGIT only gets you so far. The current compiler
overhaul will absolutely help, as that becomes available. And that'll
then help with better VSC integration, too.)

As for rolling back a database, that and usually some form of
integrated backups are part of pretty much any production database.
XQP RMS has some gaps here, as BACKUP is not integrated, as version
rollbacks are not integrated, and RMS journaling is not widely
deployed, and few apps I've worked with are integrated with host-based
RAID-1; with HBVS.

There are also some details around app scaling too, as a number of
OpenVMS production apps around could probably be re-hosted over onto a
big laptop, too. This in terms of storage and memory and processor
performance—less so features, though that can be debatable. In terms of
capacity and performance, any of the Itanium servers aren't all that
big, by 2022 standards. NVMe/NVMe-oF/CXL/TB/USB4/etc I/O is just stupid
fast. And obviously, VSI is and will be working on this support,
virtualized or paravirtualized or otherwise, or eventually native.

XQP file versions have been around for over forty years, so probably
not going to be a big draw for new apps and new developers. Not
compared with git or hg or VSC or recent compilers or other of what are
increasingly considered "table stakes" features.

If file versions are your marketing in an era of near-ubiquitous and
increasingly-integrated DVCS support for developers, and for production
rollbacks, you're going to find yourself in some comparisons and some
discussions.

Full disclosure: I've done exactly these XQP file version rollbacks
several times over the past couple of years. The astute reader might
wonder why those same environments were not under source code revision
control, but that's fodder for other discussions. That written, I've
done more rollbacks via DVCS, for those environments that are under
revision control.

--
Pure Personal Opinion | HoffmanLabs LLC

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 11/7/2022 3:48 PM, Scott Dorsey wrote:
>>
>> Different tools for different jobs. But threads are another thing that DEC
>> did so much better than anyone else but then totally lost the lead on.
>
>What are you referring to? The old CMA$ interface?

Yes. DECthreads was so much better than anything else available at the time
for multithreaded code. It's not anymore though.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

El miércoles, 9 de noviembre de 2022 a las 7:29:57 UTC-5, Scott Dorsey escribió:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
> >On 11/7/2022 3:48 PM, Scott Dorsey wrote:
> >>
> >> Different tools for different jobs. But threads are another thing that DEC
> >> did so much better than anyone else but then totally lost the lead on.
> >
> >What are you referring to? The old CMA$ interface?
> Yes. DECthreads was so much better than anything else available at the time
> for multithreaded code. It's not anymore though.
> --scott
>
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

But in our days, you consider that there will be new jobs will it be just keeping the current one until it is migrated to another operating system? What do you think?

In article <tk8vlb$mj9$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> I dislike the default location. I would very much prefer
> them to go to either dir with com file or current dir when
> submitting instead of sys$login.

Consider the fact that the user submitting the file might not have write
permission to the current directory or to the directory where the
procedure is located, but very probably does to SYS$LOGIN.

I prefer the default. I certainly don't want my procedure directory
cluttered up with log files. Current directory? Then one has to look
for it if one forgets what it was.

Don't like the default? Change it with the qualifier. Use a logical
name like LOG_DIR.

> And I dislike that /PRINT is default.

Again, change it.

$ SUBMIT :== SUBMIT/NOPRINT/LOG=LOG_DIR

Edgar Ulloa <ulloa.edgar@gmail.com> wrote:
>
>But in our days, you consider that there will be new jobs will it be just k=
>eeping the current one until it is migrated to another operating system? Wh=
>at do you think?

When I was in college, every class pretty much used a different computing
environment, so I got basic experience in a whole lot of different operating
systems and programming languages in the process just as a free bonus.

So I don't particularly feel bad about moving to one more operating system
after having spent much of my life moving from one to another.

But, that said, I miss commercial grade operating systems that are
database-centric with the filesystem and database being integrated. I
think that is a good approach for commercial applications, what we once
called "ADP." Perhaps the future isn't VMS but I would like to see some
of the concepts within VMS integrated into future commercial systems.

As software becomes more and more expensive, I think the need to have an
efficient operating system that provides database features in the kernel
becomes more important.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 11/10/2022 12:56 AM, Phillip Helbig (undress to reply) wrote:
> In article <tk8vlb$mj9$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> <arne@vajhoej.dk> writes:
>
>> I dislike the default location. I would very much prefer
>> them to go to either dir with com file or current dir when
>> submitting instead of sys$login.
>
> Consider the fact that the user submitting the file might not have write
> permission to the current directory or to the directory where the
> procedure is located, but very probably does to SYS$LOGIN.

Not having write access to the dir must be a special case.

> I prefer the default. I certainly don't want my procedure directory
> cluttered up with log files.

The alternative is multi-cluttering in sys$login.

And to me it seems logical to have the logs files together
with whatever produces it.

> Current directory? Then one has to look
> for it if one forgets what it was.

Usually it would be the same as where the COM file is, but
location of COM file may indeed be more safe.

> Don't like the default? Change it with the qualifier. Use a logical
> name like LOG_DIR.
>
>> And I dislike that /PRINT is default.
>
> Again, change it.
>
> $ SUBMIT :== SUBMIT/NOPRINT/LOG=LOG_DIR

It is not an unsolvable problem.

There are plenty of solutions:
1) always specify the correct qualifiers
2) create a symbol as above
3) extract CLD and fix DCLTABLES

My preference from most to least preferred is: 1, 3, 2.

But defaults exist to provide most used values.

And I am not happy with these two defaults as they never
seem to match what I want.

Arne

On 11/10/2022 9:51 AM, Scott Dorsey wrote:
> But, that said, I miss commercial grade operating systems that are
> database-centric with the filesystem and database being integrated. I
> think that is a good approach for commercial applications, what we once
> called "ADP." Perhaps the future isn't VMS but I would like to see some
> of the concepts within VMS integrated into future commercial systems.

How would "database-centric with the filesystem and database being
integrated" look in real life?

Like VMS index-sequential files (and its equivalence in the mainframe
world)?

Putting a file system on top of a RDBMS? (like Oracle and MS
experimented with 20 years ago)

Or?

> As software becomes more and more expensive, I think the need to have an
> efficient operating system that provides database features in the kernel
> becomes more important.

Database in the actual OS kernel or just database shipping with the
OS distribution?

It is not uncommon to put application functionality in the
kernel today, but I am not keen on the idea.

Arne

In article <tkk3rr$em$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> > Consider the fact that the user submitting the file might not have write
> > permission to the current directory or to the directory where the
> > procedure is located, but very probably does to SYS$LOGIN.
>
> Not having write access to the dir must be a special case.

I don't know. Certainly there are environments where there is some
official software or whatever where normal users are not allowed to
write. Think SYS$SYSTEM. Should every user have access there? Think
of a company's software package in some directory. Same thing.

> > I prefer the default. I certainly don't want my procedure directory
> > cluttered up with log files.

> And to me it seems logical to have the logs files together
> with whatever produces it.

Consider a multi-user development system where there is some global
software (though users might have local copies, the default path being
defined by a search-list logical or whatever); surely the log files of
the individual users should not go into that global directory.