CTRL/D Versus CTRL/Z

[lawren...@gmail.com]

Even though they started out very different, somehow along the way, *nix systems managed to pick up most of the DEC conventions for control characters (CTRL/C to interrupt a process, CTRL/Q and CTRL/S for flow control, CTRL/U to discard the input line), except one: the end-of-file indicator is CTRL/D, not CTRL/Z as it is on DEC systems.

Instead, CTRL/Z means “suspend the foreground process group”. This is part of the job-control facility for managing multiple concurrent processes. I also see a mention in the bash docs of a “delayed-suspend” character, which defaults to (wait for it) CTRL/Y. However, this might be a Hurd or BSD feature; it doesn’t seem to be available on Linux.

Did VMS ever pick up the idea of foreground/background process groups?

No, there was never an equivalent to CTRL/T. I get around that by running multiple terminal sessions, so I can keep an eye on one process using a separate session.

[Phillip Helbig (undress to reply)]

In article <9c57ed8c-021a-47a5...@googlegroups.com>,
lawren...@gmail.com writes:

> Instead, CTRL/Z means _suspend the foreground process group_. This is

> part of the job-control facility for managing multiple concurrent
> processes.

> Did VMS ever pick up the idea of foreground/background process groups?

As far as I know, no. I think that this unix functionality using CTRL/Z
is one of the few things which unix has, VMS lacks, and I think would be
useful. Some other things can be implemented in a roundabout way but
with essentially the same functionality, e.g.:

$ TOUCH :== APPEND/NEW NL:

[lawren...@gmail.com]

On Thursday, June 30, 2016 at 8:33:15 PM UTC+12, Phillip Helbig (undress to reply) wrote:
> Some other things can be implemented in a roundabout way but
> with essentially the same functionality, e.g.:
>
> $ TOUCH :== APPEND/NEW NL:

Touch has quite a few more capabilities than that: <http://man7.org/linux/man-pages/man1/touch.1.html>.

[hb]

On 06/30/2016 09:38 AM, lawren...@gmail.com wrote:
> No, there was never an equivalent to CTRL/T. I get around that by
> running multiple terminal sessions, so I can keep an eye on one
> process using a separate session.

On some *nix systems (BSD as far as I know and you may need kernel
support for this to work) you have VSTATUS bound to CTRL/T, man 3 termios:
...
VSTATUS
(not in POSIX; not supported under Linux; status request: 024,
DC4, Ctrl-T). Status character (STATUS). Display status
information at terminal, including state of foreground process
and amount of CPU time it has consumed. Also sends a SIGINFO
signal (not supported on Linux) to the foreground process
group.

[John Reagan]

On Thursday, June 30, 2016 at 3:38:17 AM UTC-4, lawren...@gmail.com wrote:
> Even though they started out very different, somehow along the way, *nix systems managed to pick up most of the DEC conventions for control characters (CTRL/C to interrupt a process, CTRL/Q and CTRL/S for flow control, CTRL/U to discard the input line), except one: the end-of-file indicator is CTRL/D, not CTRL/Z as it is on DEC systems.
>
> Instead, CTRL/Z means “suspend the foreground process group”. This is part of the job-control facility for managing multiple concurrent processes. I also see a mention in the bash docs of a “delayed-suspend” character, which defaults to (wait for it) CTRL/Y. However, this might be a Hurd or BSD feature; it doesn’t seem to be available on Linux.
>
> Did VMS ever pick up the idea of foreground/background process groups?
>

There is the ATTACH command that might solve some similar problems but isn't quite the same since it is a DCL command.

[Johnny Billquist]

On 2016-06-30 10:33, Phillip Helbig (undress to reply) wrote:
> In article <9c57ed8c-021a-47a5...@googlegroups.com>,
> lawren...@gmail.com writes:
>
>> Instead, CTRL/Z means _suspend the foreground process group_. This is
>> part of the job-control facility for managing multiple concurrent
>> processes.
>
>> Did VMS ever pick up the idea of foreground/background process groups?
>
> As far as I know, no. I think that this unix functionality using CTRL/Z
> is one of the few things which unix has, VMS lacks, and I think would be
> useful.

This is actually a very funny/interesting topic/question.

RSX is the other way around. By default *everything* is in the
background (using Unix terms). It's like every command you typed were
done with an '&' at the end of the line.

I can understand why VMS would not want this by default, but I would
have thought that it would still be possible if you dug enough into the
internals... But maybe not.

I do agree that being able to run several commands in parallel is a very
useful thing from time to time.

Johnny

[John E. Malmberg]

There are a couple of CRTL routines that claim to support process
groups. The documentation for them is insufficient to ues them.

For a group of programs that you have source for, the feature can be
implemented using the VMS SYS$ENQ() have the foreground process hold the
lock.

A generic solution would potentially need a change to how VMS starts up
processes if that code is not already present.

For those not familiar with process groups, this would be the VMS
equivalent (Going a bit from memory in the early morning, so I probably
have a few things wrong).

1. Foreground process takes out a foreground lock which indicates that
it gets access to data (and signals?) from sys$command:.

2. Foreground process has queued an blocking ast to relinquish the
foreground lock on request.

3. Processes not holding the foreground lock treat reads from
sys$command to be EOF.

4. A process moves from the background to the foreground by requesting
the foreground lock.

And none of this deals with handling changing a child process to be a
parent process or changing which process is the parent for a child,
which would also be needed.

I suspect that a VMS implementation would require that the holder of the
foreground lock to always be the parent process and that as long as the
parent process is alive, any orphaned child processes would be adopted
by it.

Control-D is the ancient modem disconnect character. Sending it used to
cause some modems to hang up according to some documentation I have
read. (DecSystem 10 manuals)

Which would have made it a very questionable control character to use
for communication to a operating system, and probably why Digital
operating systems did not use it.

Even odder is the Unix selection of Control-H (Backspace) character for
delete, since no terminals at that time would send that code when you
pushed the key labeled delete or rubout.

Terminals that could be configured to send a Control-H instead of delete
did not appear until well after Unix was established.
(As well a various broken emulators that only sent Control-H, defaulted
to Control-H, and sent the delete (0x7F) character for the keypad delete
key)

The GNV Coreutils updated package reports the VMS settings for the
control characters by providing a termios emulation layer.

Linux Utilities that assume Control-D is EOF instead of looking it up
have a bug in them, as you can change the EOF character on Linux.

Regards,
-John
wb8...@qsl.net_work

[Johnny Billquist]

On 2016-06-30 15:36, John E. Malmberg wrote:
> On 6/30/2016 7:19 AM, John Reagan wrote:
>> On Thursday, June 30, 2016 at 3:38:17 AM UTC-4, lawren...@gmail.com
>> wrote:
>>> Did VMS ever pick up the idea of foreground/background process
>>> groups?
>>
>> There is the ATTACH command that might solve some similar problems
>> but isn't quite the same since it is a DCL command.

I seem to remember some some select other programs also have an
ATTACH/DETACH command?

> There are a couple of CRTL routines that claim to support process
> groups. The documentation for them is insufficient to ues them.
>
> For a group of programs that you have source for, the feature can be
> implemented using the VMS SYS$ENQ() have the foreground process hold the
> lock.
>
> A generic solution would potentially need a change to how VMS starts up
> processes if that code is not already present.
>
> For those not familiar with process groups, this would be the VMS
> equivalent (Going a bit from memory in the early morning, so I probably
> have a few things wrong).
>
> 1. Foreground process takes out a foreground lock which indicates that
> it gets access to data (and signals?) from sys$command:.
>
> 2. Foreground process has queued an blocking ast to relinquish the
> foreground lock on request.
>
> 3. Processes not holding the foreground lock treat reads from
> sys$command to be EOF.

If this are to model how things are in Unix, a background process trying
to read from stdin is blocked. It does not get EOF.

> 4. A process moves from the background to the foreground by requesting
> the foreground lock.
>
> And none of this deals with handling changing a child process to be a
> parent process or changing which process is the parent for a child,
> which would also be needed.
>
> I suspect that a VMS implementation would require that the holder of the
> foreground lock to always be the parent process and that as long as the
> parent process is alive, any orphaned child processes would be adopted
> by it.
>
> Control-D is the ancient modem disconnect character. Sending it used to
> cause some modems to hang up according to some documentation I have
> read. (DecSystem 10 manuals)

Wow. That is more than I knew. But it sounds pretty plausible.

> Which would have made it a very questionable control character to use
> for communication to a operating system, and probably why Digital
> operating systems did not use it.
>
> Even odder is the Unix selection of Control-H (Backspace) character for
> delete, since no terminals at that time would send that code when you
> pushed the key labeled delete or rubout.

You know that ^H as delete is a very modern thing in Unix, right?
It only came about after the IBM PC became widespread, and Unix was
ported to it.

Before then, DEL was more common, as most terminals had a key that sent
that character, and not BS. (As you note.)

But original Unix used neither. It instead, horribly enough, used # for
delete. (Hard to believe.)

> Terminals that could be configured to send a Control-H instead of delete
> did not appear until well after Unix was established.
> (As well a various broken emulators that only sent Control-H, defaulted
> to Control-H, and sent the delete (0x7F) character for the keypad delete
> key)

Yes. And personally, I still consider using ^H for delete to be a broken
idea.

> The GNV Coreutils updated package reports the VMS settings for the
> control characters by providing a termios emulation layer.
>
> Linux Utilities that assume Control-D is EOF instead of looking it up
> have a bug in them, as you can change the EOF character on Linux.

Correct. And very few (if any) programs I've seen actually explicitly
check for ^D, but instead just expects the terminal driver to give an
EOF error when reading, which the terminal does based on what the
settings are.

Johnny

[John Reagan]

On Thursday, June 30, 2016 at 10:16:42 AM UTC-4, Johnny Billquist wrote:
> On 2016-06-30 15:36, John E. Malmberg wrote:
> > On 6/30/2016 7:19 AM, John Reagan wrote:
> >> On Thursday, June 30, 2016 at 3:38:17 AM UTC-4, lawren...@gmail.com
> >> wrote:
> >>> Did VMS ever pick up the idea of foreground/background process
> >>> groups?
> >>
> >> There is the ATTACH command that might solve some similar problems
> >> but isn't quite the same since it is a DCL command.
>
> I seem to remember some some select other programs also have an
> ATTACH/DETACH command?
>

I found it in the debugger and DTM. For the debugger, that is for debugging multi-process applications. DTM? Not sure why.

The problem that ATTACH seemed to solve was trying to manage multiple processes from a VT100 (without using something like TOPS-10 OPSER or TOPS-20 PTYCON). Now a days, you have a larger screen where you can have multiple terminal emulators so ATTACH has less value (they do share the JOB table so that is a benefit over separate terminal screens).

[One of my former coworkers actually wrote a PTYCON-32 for VAX/VMS. It might be on some older Freeware CDs but I'm not sure.]

[VAXman-]

In article <89c3862b-c250-4b03...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
>On Thursday, June 30, 2016 at 10:16:42 AM UTC-4, Johnny Billquist wrote:
>> On 2016-06-30 15:36, John E. Malmberg wrote:
>> > On 6/30/2016 7:19 AM, John Reagan wrote:
>> >> On Thursday, June 30, 2016 at 3:38:17 AM UTC-4, lawren...@gmail.com
>> >> wrote:
>> >>> Did VMS ever pick up the idea of foreground/background process
>> >>> groups?
>> >>
>> >> There is the ATTACH command that might solve some similar problems
>> >> but isn't quite the same since it is a DCL command.

>>=20
>> I seem to remember some some select other programs also have an=20
>> ATTACH/DETACH command?
>>=20
>
>I found it in the debugger and DTM. For the debugger, that is for debuggin=

>g multi-process applications. DTM? Not sure why.
>

>The problem that ATTACH seemed to solve was trying to manage multiple proce=
>sses from a VT100 (without using something like TOPS-10 OPSER or TOPS-20 PT=
>YCON). Now a days, you have a larger screen where you can have multiple te=
>rminal emulators so ATTACH has less value (they do share the JOB table so t=

>hat is a benefit over separate terminal screens).
>

>[One of my former coworkers actually wrote a PTYCON-32 for VAX/VMS. It mig=

>ht be on some older Freeware CDs but I'm not sure.]

There are/were a number of similar applications employing pseudo-terminals --
Freeware BOSS is one of them. There are/were several third-party commercial
products too.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Johnny Billquist]

Maybe we are talking about different ATTACH? There is definitely ATTACH
in MAIL, for example, to move between processes.

Johnny

[John Reagan]

Forgot to check MAIL.

I personally never used ATTACH in any of the tools.

[VAXman-]

In article <57475af1-8bb9-491e...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
>On Thursday, June 30, 2016 at 3:05:25 PM UTC-4, Johnny Billquist wrote:
>> On 2016-06-30 20:03, John Reagan wrote:

>> > On Thursday, June 30, 2016 at 10:16:42 AM UTC-4, Johnny Billquist wrote=

>:
>> >> On 2016-06-30 15:36, John E. Malmberg wrote:
>> >>> On 6/30/2016 7:19 AM, John Reagan wrote:
>> >>>> On Thursday, June 30, 2016 at 3:38:17 AM UTC-4, lawren...@gmail.com
>> >>>> wrote:
>> >>>>> Did VMS ever pick up the idea of foreground/background process
>> >>>>> groups?
>> >>>>
>> >>>> There is the ATTACH command that might solve some similar problems
>> >>>> but isn't quite the same since it is a DCL command.
>> >>
>> >> I seem to remember some some select other programs also have an
>> >> ATTACH/DETACH command?
>> >>
>> >

>> > I found it in the debugger and DTM. For the debugger, that is for debu=

>gging multi-process applications. DTM? Not sure why.
>> >

>> > The problem that ATTACH seemed to solve was trying to manage multiple p=
>rocesses from a VT100 (without using something like TOPS-10 OPSER or TOPS-2=
>0 PTYCON). Now a days, you have a larger screen where you can have multipl=
>e terminal emulators so ATTACH has less value (they do share the JOB table =

>so that is a benefit over separate terminal screens).
>> >

>> > [One of my former coworkers actually wrote a PTYCON-32 for VAX/VMS. It=

> might be on some older Freeware CDs but I'm not sure.]

>>=20
>> Maybe we are talking about different ATTACH? There is definitely ATTACH=
>=20

>> in MAIL, for example, to move between processes.

>>=20

>> Johnny
>
>Forgot to check MAIL.
>
>I personally never used ATTACH in any of the tools.

What? You don't SPAWN off procedures from within MAIL to delete all the SPAM
and hate mail you get? ;)

[John Reagan]

On Thursday, June 30, 2016 at 4:05:26 PM UTC-4, VAXman- wrote:

Hate mail, moi? I haven't even started to piss people off. :)

I actually don't get email on my VMS box (other than VDE checkin notices and nightly GEM build/test results - some might consider *that* SPAM). I read my work email on my Macbook Pro using Outlook. For comp.os.vms, I used my trusty Windows 7 box with Google Groups (although I have a fresh Win10 box with a nice Skylake processor sitting next to it waiting for me to migrate over).

[lawren...@gmail.com]

On Friday, July 1, 2016 at 1:36:22 AM UTC+12, John E. Malmberg wrote:
> For a group of programs that you have source for, the feature can be
> implemented using the VMS SYS$ENQ() have the foreground process hold the
> lock.

That’s no good, because it has to be completely transparent. The process tries to read from (or, optionally, write to) its controlling terminal, and automatically gets suspended if it’s not in the foreground process group.

[lawren...@gmail.com]

On Friday, July 1, 2016 at 12:00:36 AM UTC+12, hb wrote:

Interesting. But, given the range of regular command-line tools you have to get information about processes, perhaps CTRL/T is no big loss anyway...

[VAXman-]

In article <69c865af-82a7-4b0a...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
>On Thursday, June 30, 2016 at 4:05:26 PM UTC-4, VAXman- wrote:

>> In article <57475af1-8bb9-491e-.com>, John Reagan <xcom> writes:
>> >On Thursday, June 30, 2016 at 3:05:25 PM UTC-4, Johnny Billquist wrote:
>> >> On 2016-06-30 20:03, John Reagan wrote:

>> >> > On Thursday, June 30, 2016 at 10:16:42 AM UTC-4, Johnny Billquist wr=
>ote=3D

>> >:
>> >> >> On 2016-06-30 15:36, John E. Malmberg wrote:
>> >> >>> On 6/30/2016 7:19 AM, John Reagan wrote:

>> >> >>>> On Thursday, June 30, 2016 at 3:38:17 AM UTC-4, lawren...@gmail.c=

>om
>> >> >>>> wrote:
>> >> >>>>> Did VMS ever pick up the idea of foreground/background process
>> >> >>>>> groups?
>> >> >>>>

>> >> >>>> There is the ATTACH command that might solve some similar problem=

>s
>> >> >>>> but isn't quite the same since it is a DCL command.
>> >> >>
>> >> >> I seem to remember some some select other programs also have an
>> >> >> ATTACH/DETACH command?
>> >> >>
>> >> >

>> >> > I found it in the debugger and DTM. For the debugger, that is for d=
>ebu=3D

>> >gging multi-process applications. DTM? Not sure why.
>> >> >

>> >> > The problem that ATTACH seemed to solve was trying to manage multipl=
>e p=3D
>> >rocesses from a VT100 (without using something like TOPS-10 OPSER or TOP=
>S-2=3D
>> >0 PTYCON). Now a days, you have a larger screen where you can have mult=
>ipl=3D
>> >e terminal emulators so ATTACH has less value (they do share the JOB tab=
>le =3D

>> >so that is a benefit over separate terminal screens).
>> >> >

>> >> > [One of my former coworkers actually wrote a PTYCON-32 for VAX/VMS. =
> It=3D

>> > might be on some older Freeware CDs but I'm not sure.]

>> >>=3D20
>> >> Maybe we are talking about different ATTACH? There is definitely ATTAC=
>H=3D
>> >=3D20

>> >> in MAIL, for example, to move between processes.

>> >>=3D20

>> >> Johnny
>> >
>> >Forgot to check MAIL.
>> >
>> >I personally never used ATTACH in any of the tools.

>>=20
>> What? You don't SPAWN off procedures from within MAIL to delete all the =

>SPAM
>> and hate mail you get? ;)

>>=20
>> --=20
>> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)=
>ORG
>>=20

>> I speak to machines with the voice of humanity.
>

>Hate mail, moi? I haven't even started to piss people off. :)
>

>I actually don't get email on my VMS box (other than VDE checkin notices an=
>d nightly GEM build/test results - some might consider *that* SPAM). I rea=
>d my work email on my Macbook Pro using Outlook. For comp.os.vms, I used m=
>y trusty Windows 7 box with Google Groups (although I have a fresh Win10 bo=
>x with a nice Skylake processor sitting next to it waiting for me to migrat=
>e over).

Noooo! Don't do it. It's the spawn of satan.

[IanD]

Spawn of Satan or not, Windows is slowly morphing itself to try and be all things to all people.

The new MS CEO is certainly changing how MS behave, sure, it's the same old MS in some areas but in others they are actually trying to provide some good stuff

They, like everyone else are trying to move to a service pays model instead of a product based model, along the way they will be ahead of the curve and in others behind it.

Gone are the days were you tarnish an entire company based on pure past experiences (although I still have trust issues with oracle personally)

I'm no MS advocate but I do recognise the effort they have placed in trying to change

Had HP or even Digital embraced the same desire to change we would not be nursing a near dead VMS that we have to try and revive today

[lawren...@gmail.com]

On Friday, July 1, 2016 at 12:14:26 PM UTC+12, IanD wrote:
> Spawn of Satan or not, Windows is slowly morphing itself to try
> and be all things to all people.

Trouble is, it’s not flexible enough. Their mobile strategy has been a complete disaster. What happened to Windows HPC Server, their offering for supercomputers? Killed by Linux. Windows Home Server? Killed by cheap NAS boxes running Linux and BSD. Heard about their “Windows 10 IoT Edition” for the Raspberry π 3? A crippled joke of an OS.

The Windows NT underpinnings were supposed to make it a cross-platform OS. But that goal has been a complete failure.

[Phillip Helbig (undress to reply)]

In article <34b89f6e-8fb2-4a22...@googlegroups.com>, John

Reagan <xyzz...@gmail.com> writes:

> There is the ATTACH command that might solve some similar problems but isn't
> quite the same since it is a DCL command.

You can't start something interactively, shove it into the background,
then log out. I use SPAWN and ATTACH and MAIL> ATTACH/PARENT all the
time.

[VAXman-]

In article <e8ed8a80-5783-44e2...@googlegroups.com>, IanD <iloveo...@gmail.com> writes:
>Spawn of Satan or not, Windows is slowly morphing itself to try and be all things to all people.
>

>The new MS CEO is certainly changing how MS behave, sure, it's the same old MS in some areas but in others they are actually trying to provide some good stuff

Unlike "El CRAPitan!" Perhaps, Apple now want to be Micro$oft.

[VAXman-]

There are BATCH and DETACHED processes for that sort of thing. ;)

[John Reagan]

On Thursday, June 30, 2016 at 7:49:06 PM UTC-4, VAXman- wrote:

Absolutely spawn of satan. I have problems with the task bar thingy moving between monitors by "surprise". I can't keep an SSH connection in place without it timing out IN SPITE of me setting what I think are all the right config files. It often confused which monitor when it comes out of sleep mode. It forgets my screen backdrop about 1/2 of the time. I've been told not to update my OS since it will break my VPN connections to VSI. Few of my co-workers like it.... But what can I say, the VSI CEO is a Apple fan. ;)

[John E. Malmberg]

Ok. I did say I was going from memory. I looked this up a few years
back to see how feasible it would be to implement in the GNV Bash update.

But many programs write out in their help prompts to use Control-D to
exist instead of what the current EOF character is.

I have a patch submitted to c Python 3.x that fixes it there, but it
does not seem to be getting much movement.

Regards,
-John

[Johnny Billquist]

That's a good one actually. As almost unanimously, those programs will
not actually check for ^D, but will check for EOF, meaning the printed
out string is actually where the error in the code is.

One could argue that it's just a visual error, but it's still pretty bad.

Johnny

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of John
> Reagan via Info-vax
> Sent: 01-Jul-16 8:46 AM
> To: info...@rbnsn.com
> Cc: John Reagan <xyzz...@gmail.com>
> Subject: Re: [Info-vax] CTRL/D Versus CTRL/Z
>
> On Thursday, June 30, 2016 at 7:49:06 PM UTC-4, VAXman- wrote:
> > In article <69c865af-82a7-4b0a-9252-beoups.com>, John Reagan
> <xyzzcom> writes:
> > >On Thursday, June 30, 2016 at 4:05:26 PM UTC-4, VAXman- wrote:
> > >> In article <57475af1-8bb9-491e-.com>, John Reagan <xcom> writes:
> > >> >On Thursday, June 30, 2016 at 3:05:25 PM UTC-4, Johnny Billquist
> wrote:

[snip...]

>
> Absolutely spawn of satan. I have problems with the task bar thingy
> moving between monitors by "surprise". I can't keep an SSH connection
> in place without it timing out IN SPITE of me setting what I think are
all
> the right config files. It often confused which monitor when it comes
out
> of sleep mode. It forgets my screen backdrop about 1/2 of the time.
I've
> been told not to update my OS since it will break my VPN connections
to
> VSI. Few of my co-workers like it.... But what can I say, the VSI
CEO is a
> Apple fan. ;)
>

Well, I am certainly no fan of MS on the enterprise server side, and
while
I hate the way MS is forcing Win10 upgrades, I must admit that after a
few
rocky issues after the initial release of Win10, Win10 on my HP Envy dv7

laptop has been rock solid for me in the last 4-5 months (touch wood).

The only irritant / bug is that I occasionally lose connection to a few
USB3
RAID drives which, because they are encrypted, means I have to unplug
them, then replug the USB3 cable and then re-enter pwds to get them
back.

A few suggestions:
- I also had SSH timeouts (usually around 15 min timeframe) and this due
To my firewall. There was a keep alive type FW setting that needed to be

increased. Suggest talk to whoever maintains your FW.

- I use a few different VPN's for various environments and have had no
Issues related to Win10.

- With Win 10, one should assume there will be more frequent updates
which you have little control over, but you can control when the node
reboots to implement those fixes.

- highly recommend laptop have SSD drive as the boot/reboot times, &
overall "snap" and recovery times from sleep/hibernation is noticeable.
What I did was add a 500GB SSD drive for my OS disk and now use what
was the old primary disk as my additional storage volume.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[John Reagan]

On Friday, July 1, 2016 at 12:10:05 PM UTC-4, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vcom] On Behalf Of John
> > Reagan via Info-vax
> > Sent: 01-Jul-16 8:46 AM
> > To: info...@rbnsn.com
> > Cc: John Reagan <xyz.com>
> > Subject: Re: [Info-vax] CTRL/D Versus CTRL/Z
> >
> > On Thursday, June 30, 2016 at 7:49:06 PM UTC-4, VAXman- wrote:

> > > In article <69c865af-82a7-4b0a-9m>, John Reagan

For those who can't tell, I was complaining about my Macbook. My W7 machine is solid. My W10 had some issues which were solved by an updated graphics driver. It is solid as well. I can connect (via PuTTY) to VSI and keep connections set for days. Not from my Macbook sitting right next to the Windows machines. Heck, I can't keep them connected when I'm physically sitting in a cubicle at VSI headquarters.

[VAXman-]

In article <cc132014-1dba-4caa...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
>On Friday, July 1, 2016 at 12:10:05 PM UTC-4, Kerry Main wrote:

>> > -----Original Message-----
>> > From: Info-vax [mailto:info-vcom] On Behalf Of John
>> > Reagan via Info-vax
>> > Sent: 01-Jul-16 8:46 AM
>> > To: info...@rbnsn.com
>> > Cc: John Reagan <xyz.com>
>> > Subject: Re: [Info-vax] CTRL/D Versus CTRL/Z
>> >=20
>> > On Thursday, June 30, 2016 at 7:49:06 PM UTC-4, VAXman- wrote:
>> > > In article <69c865af-82a7-4b0a-9m>, John Reagan
>> > <xyzzcom> writes:
>> > > >On Thursday, June 30, 2016 at 4:05:26 PM UTC-4, VAXman- wrote:
>> > > >> In article <57475af1-8bb9-491e-.com>, John Reagan <xcom> writes:
>> > > >> >On Thursday, June 30, 2016 at 3:05:25 PM UTC-4, Johnny Billquist
>> > wrote:

>>=20
>> [snip...]
>>=20
>> >=20

>> > Absolutely spawn of satan. I have problems with the task bar thingy
>> > moving between monitors by "surprise". I can't keep an SSH connection
>> > in place without it timing out IN SPITE of me setting what I think are
>> all
>> > the right config files. It often confused which monitor when it comes
>> out
>> > of sleep mode. It forgets my screen backdrop about 1/2 of the time.
>> I've
>> > been told not to update my OS since it will break my VPN connections
>> to
>> > VSI. Few of my co-workers like it.... But what can I say, the VSI
>> CEO is a
>> > Apple fan. ;)

>> >=20
>>=20

>> Well, I am certainly no fan of MS on the enterprise server side, and
>> while
>> I hate the way MS is forcing Win10 upgrades, I must admit that after a

>> few=20

>> rocky issues after the initial release of Win10, Win10 on my HP Envy dv7

>>=20

>> laptop has been rock solid for me in the last 4-5 months (touch wood).

>>=20
>
>For those who can't tell, I was complaining about my Macbook. My W7 machin=
>e is solid. My W10 had some issues which were solved by an updated graphic=
>s driver. It is solid as well. I can connect (via PuTTY) to VSI and keep =
>connections set for days. Not from my Macbook sitting right next to the Wi=
>ndows machines. Heck, I can't keep them connected when I'm physically sitt=
>ing in a cubicle at VSI headquarters. =20

What's it running? "El CRAPitan?"

I'm fond of my MacBook Pro 17" but it has not been updated to "El CRAPitan."
The iMac, OTOH, had to be updated to "El CRAPitan" to appease TurboTax. It
has been one disappointment after another. The most recent was the supposed
fix for "El CRAPitan" that would make the SD card slot, no longer functional
with the "El CRAPitan" update, functional again. Not only did it NOT correct
the SD card, but it located other drives with older OS X versions and it made
them all useless! That REALLY sucks because there were libraries of Aperture
containing photos and all of the Final Cut video processing stuff... NOW ALL
HISTORY.

The "migration" assistant or whatever it was called is complete crap too. My
wife, primarily, uses the iMac. "El CRAPitan" completely horked all of here
email history. Of course, every new OS X removes some application that was
of use to us too. iDVD, for example, is now just a memory but we used it to
create DVD intros and chapters for video processed with the "now" historical
Final Cut thanks to the "El CRAPitan" updates and fuck-ups.

[John Reagan]

On Friday, July 1, 2016 at 3:52:37 PM UTC-4, VAXman- wrote:

I'm still back on Mavericks (10.9.5). Yosemite totally hoses our VPN solution. El Capitan is somewhat better but takes several workarounds, a pentagram, and some goat entrails to get the VPN working. That is why I still use PuTTY from W7. With several handfuls of port forwardings and a few passwords to set up the initial connections, I can connect to any number of machines back at VSI.

[Craig A. Berry]

On 7/1/16 12:42 PM, John Reagan wrote:

> For those who can't tell, I was complaining about my Macbook. My W7
> machine is solid. My W10 had some issues which were solved by an
> updated graphics driver. It is solid as well. I can connect (via
> PuTTY) to VSI and keep connections set for days. Not from my Macbook
> sitting right next to the Windows machines. Heck, I can't keep them
> connected when I'm physically sitting in a cubicle at VSI
> headquarters.

Well, for me it's the opposite. My Win7 machine hangs or crashes once or
twice a week and sometimes takes an hour to boot while trying to apply
policies that can't be applied for one reason or another. My MacBook Pro
running El Capitan has never crashed nor hung and does ssh connections
that stay up for days or weeks. I've used the built-in VPN client
without any issues and also have GlobalProtect from Palo Alto for the
company network; it's had some issues from time to time but they always
get fixed by the next update.

[Phillip Helbig (undress to reply)]

In article <00B0B6F2...@SendSpamHere.ORG>, VAXman-

@SendSpamHere.ORG writes:

> In article <nl59nn$1v8c$1...@news.kjsl.com>, hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
> >In article <34b89f6e-8fb2-4a22...@googlegroups.com>, John
> >Reagan <xyzz...@gmail.com> writes:
> >
> >> There is the ATTACH command that might solve some similar problems but isn't
> >> quite the same since it is a DCL command.
> >
> >You can't start something interactively, shove it into the background,
> >then log out. I use SPAWN and ATTACH and MAIL> ATTACH/PARENT all the
> >time.
>
> There are BATCH and DETACHED processes for that sort of thing. ;)

Yes, but in unix you can start a program, perhaps enter some input
interactively, make sure it is running OK, then shove it into the
background and LOG OUT.

[David Froble]

RSTS/E has this capability.

[Simon Clubley]

Yes, the word "detach" actually meant something on RSTS/E.

When porting some code from RSTS/E to VMS, what I ended up doing was
starting the to-be-detached-job on a batch queue instead.

Under RSTS/E, you could also use "attach <job_number>" to re-attach
to the detached job IIRC.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Paul Sture]

On 2016-07-02, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2016-07-02, David Froble <da...@tsoft-inc.com> wrote:
>> Phillip Helbig (undress to reply) wrote:
>>>
>>> Yes, but in unix you can start a program, perhaps enter some input
>>> interactively, make sure it is running OK, then shove it into the
>>> background and LOG OUT.
>>>
>>
>> RSTS/E has this capability.
>
> Yes, the word "detach" actually meant something on RSTS/E.
>
> When porting some code from RSTS/E to VMS, what I ended up doing was
> starting the to-be-detached-job on a batch queue instead.
>
> Under RSTS/E, you could also use "attach <job_number>" to re-attach
> to the detached job IIRC.

This functionality existed with Time Shared Dibol (TSD) on RT-11, and it
was very useful. You would typically put a "detach" statement in any
long running program after user input of parameters (e.g. start/end keys
or dates), and it would free up the terminal for other work.

A detached job would pause if it issued terminal I/O but otherwise run
to completion without needing an attach. You only needed to attach a
job if it had either displayed an error or filled up a spool file and
wanted you to give it another.

I missed this functionality on moving to VMS. In particular, you needed
2 programs for the cases where you wanted to start with user input, the
first to accept the input and submit a batch job and the second the
batch job itself. Needless to say I saw this duplication of effort as
a backwards step :-(

--
A sure cure for sea-sickness is to sit under a tree.
-- Spike Milligan

[Simon Clubley]

On 2016-07-02, Paul Sture <nos...@sture.ch> wrote:
> On 2016-07-02, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>> Yes, the word "detach" actually meant something on RSTS/E.
>>
>> When porting some code from RSTS/E to VMS, what I ended up doing was
>> starting the to-be-detached-job on a batch queue instead.
>>
>> Under RSTS/E, you could also use "attach <job_number>" to re-attach
>> to the detached job IIRC.
>
> This functionality existed with Time Shared Dibol (TSD) on RT-11, and it
> was very useful. You would typically put a "detach" statement in any
> long running program after user input of parameters (e.g. start/end keys
> or dates), and it would free up the terminal for other work.
>
> A detached job would pause if it issued terminal I/O but otherwise run
> to completion without needing an attach. You only needed to attach a
> job if it had either displayed an error or filled up a spool file and
> wanted you to give it another.
>

You are bringing back some memories now Paul. :-)

The same was true with RSTS/E Dibol as well.

SYSTAT showed a detached idle job in SL state normally but it only
changed to HB when there was terminal I/O to be done. If that was
a detached job, then it was rather bad news...

(All IIRC BTW; it's been over a couple of decades since I last had to
worry about this.)

[Phillip Helbig (undress to reply)]

In article <6g9l4d-...@news.chingola.ch>, Paul Sture

<nos...@sture.ch> writes:

> I missed this functionality on moving to VMS. In particular, you needed
> 2 programs for the cases where you wanted to start with user input, the
> first to accept the input and submit a batch job and the second the
> batch job itself. Needless to say I saw this duplication of effort as
> a backwards step :-(

One can do something like

$ IF F$MODE() .EQS. "INTERACTIVE"
$ THEN
<read input interactively>
$ SUBMIT 'F$ENVIRONMENT("PROCEDURE")'/PARAM=<derived from input>
$ ELSE
$ <do "batch" processing>
$ ENDIF
$ EXIT

But one can get it back into the foreground.

It would be nice to do

$ SEARCH [*...]* <string>
put it to the background
pull it to the foreground to see if it has found something

and so on.

[Jan-Erik Soderholm]

I think we have to put things into perspective. I can search all
our Cobol source files for a <string> in approx 7.5 sec. This is on
an old DS20e 666 MHz box. I do not have the time to put things into
the background and then pull it back to see if it has found anything.

There is a lot of things one could do in the systems 20-30 years
ago that isn't rellevant in todays much faster environments.

$ sea/stat disk1:<*...>*.cob,*.sco <a 6-char string>/out=nl:

Files searched: 2633 Buffered I/O count: 13484
Records searched: 1659156 Direct I/O count: 8682
Characters searched: 41980282 Page faults: 24
Records matched: 272 Elapsed CPU time: 0 00:00:06.80
Lines printed: 328 Elapsed time: 0 00:00:07.51
$

I guess one could save a few seconds by using some more modern box.

[VAXman-]

Different strokes for different folks. If people here want VMS to be unix,
why the fuck don't they just use unix?

[Phillip Helbig (undress to reply)]

In article <nl92s8$ffk$1...@news.albasani.net>, Jan-Erik Soderholm

<jan-erik....@telia.com> writes:

> > It would be nice to do
> >
> > $ SEARCH [*...]* <string>
> > put it to the background
> > pull it to the foreground to see if it has found something
> >
> > and so on.
> >
>

> I think we have to put things into perspective. I can search all
> our Cobol source files for a <string> in approx 7.5 sec. This is on
> an old DS20e 666 MHz box. I do not have the time to put things into

> the background and then pull it back to see if it has found anything.

Depends on the number of lines you are searching, of course. This was
just an example. It could also be a particularly nasty SQL query.

Sure, things that I know will run for weeks I write as a batch job from
the start. But sometimes something takes longer than expected; it would
be nice to do something else without having to kill it first.

Sure, these days we have many terminals at home, DECwindows with many
DECterms and so on. The days of one user per (real) terminal are long
gone. However, these days I use a VT220 emulator to log in to my
cluster at home from an iPad. This is one reason I am now looking at
BOSS (particularly its feature to log in AS A DIFFERENT USER then switch
between the various sessions.

Right now, I am typing this on a VT320 since I am doing a hardware
inventory and am now testing the state of my various terminals. This
particular one is a console. The size of the characters has become
noticeably smaller but is still useful. This is a common symptom of an
aging terminal. (There is even an iPad appp which simulates terminal
aging and so on!)

[lawren...@gmail.com]

On Saturday, July 2, 2016 at 10:39:03 PM UTC+12, Phillip Helbig (undress to reply) wrote:

> ... in unix you can start a program, perhaps enter some input

> interactively, make sure it is running OK, then shove it into the
> background and LOG OUT.

Make sure you use setsid(1) <http://man7.org/linux/man-pages/man1/setsid.1.html> for that. Otherwise it is liable to be killed when you log out.

[lawren...@gmail.com]

On Sunday, July 3, 2016 at 2:18:52 AM UTC+12, David Froble wrote:
> Phillip Helbig (undress to reply) wrote:

>> ... start a program, perhaps enter some input

>> interactively, make sure it is running OK, then shove it into the
>> background and LOG OUT.
>>
>
> RSTS/E has this capability.

I thought that was only available to privileged users.

[David Froble]

Simon Clubley wrote:
> On 2016-07-02, David Froble <da...@tsoft-inc.com> wrote:
>> Phillip Helbig (undress to reply) wrote:
>>> Yes, but in unix you can start a program, perhaps enter some input
>>> interactively, make sure it is running OK, then shove it into the
>>> background and LOG OUT.
>>>
>> RSTS/E has this capability.
>
> Yes, the word "detach" actually meant something on RSTS/E.
>
> When porting some code from RSTS/E to VMS, what I ended up doing was
> starting the to-be-detached-job on a batch queue instead.
>
> Under RSTS/E, you could also use "attach <job_number>" to re-attach
> to the detached job IIRC.
>
> Simon.
>

Yeah, a nice capability. But on RSTS with it's minute resources, it was a handy
thing. On VAX I wrote a utility to start up detached processes. Never really
thought batch was the right place for such jobs. I know others who did use batch.

[lawren...@gmail.com]

On Sunday, July 3, 2016 at 6:36:02 AM UTC+12, Phillip Helbig (undress to reply) wrote:
> It would be nice to do
>
> $ SEARCH [*...]* <string>
> put it to the background
> pull it to the foreground to see if it has found something
>
> and so on.

These days we just open multiple terminal windows/tabs.

Unless you are accessing a remote machine, when that becomes inconvenient. Then we use screen(1) <http://man7.org/linux/man-pages/man1/screen.1.html>.

[lawren...@gmail.com]

On Sunday, July 3, 2016 at 8:09:52 AM UTC+12, VAXman- wrote:
> If people here want VMS to be unix, why the fuck don't they just use unix?

Perhaps because “wanting VMS to be Unix” is an unfair and misleading characterization of what people want?

[Hans Vlems]

I agree Brian. And they might want to stop whining about why VMS lacks unix/posix capabilities.

I realize VMS is not a clean design let alone a clean implementation. No wonder after 40 years. But I refuse to be convinced that Windows Server et al are better off.
Hans

[Jan-Erik Soderholm]

One cannot of course say that one or the other is "better" without
specifying what params one is looking at.

Windows Server is "better" in running Windows Server applications.
VMS is "better" at running old "legacy" VMS applications.

Which is more important for you, I can't possible tell...

The single most important reason to run VMS today, is that
you already have it.

Jan-Erik.

[Simon Clubley]

That's exactly right at least in my case.

I don't want VMS to become Unix; I want it to get the kind of
functionality that Unix has in certain areas.

This includes simple stuff such as being able to edit long command
lines, save and recall command history (with multiple sessions being
merged correctly) and a way of searching for previous commands that
doesn't involve as much effort as just retyping the command for short
commands.

It also includes more complicated stuff such as reloadable device
drivers and plug in filesystem modules with full usage documentation.

It also includes being able to more easily pull over the large
ecosystem of Unix style application code over to VMS and run it on VMS.

There are other areas; these are just some simple examples off the
top of my head.

Simon.

PS: Oh and before someone dismisses the whole Unix application on VMS
thing, just remember that compilers on VMS x86-64 will be LLVM based.

PPS: As an aside, I wonder how VSI are building LLVM on VMS ? I wonder
if they are using the configure scripts (which are now obsolete in
current LLVM versions) or if instead they have CMake running on VMS ?

[Simon Clubley]

On 2016-07-03, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>
> The single most important reason to run VMS today, is that
> you already have it.
>

I agree with that. However, once VSI have got VMS as it currently is
up and running for the current user base, they then need to start
thinking about how they are going to attract new users to VMS.

Simon.

[VAXman-]

In article <nlar2s$ho$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2016-07-03, lawren...@gmail.com <lawren...@gmail.com> wrote:

>That's exactly right at least in my case.
>
>I don't want VMS to become Unix; I want it to get the kind of
>functionality that Unix has in certain areas.
>
>This includes simple stuff such as being able to edit long command
>lines, save and recall command history (with multiple sessions being
>merged correctly) and a way of searching for previous commands that
>doesn't involve as much effort as just retyping the command for short
>commands.

That's all a piece of cake; I've said it before. However, that discussion
always veers off the road, down the ravine and into a quagmire of terminal
driver limitiations. It doesn't have to be handled by the terminal driver.
In fact, all DCL command I/O is handled by a single RMS $READ. Think that
can't be easily replaced or something wedged in to give you what you want?

>It also includes more complicated stuff such as reloadable device
>drivers and plug in filesystem modules with full usage documentation.

Reloadable device drivers would be nice. We had them before.

>It also includes being able to more easily pull over the large
>ecosystem of Unix style application code over to VMS and run it on VMS.

Unix, again! The problem there was the myth of portable "C" obscuring the
sky.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> lawrencedo99--- via Info-vax
> Sent: 02-Jul-16 8:47 PM
> To: info...@rbnsn.com
> Cc: lawren...@gmail.com
> Subject: Re: [Info-vax] CTRL/D Versus CTRL/Z
>

> On Sunday, July 3, 2016 at 6:36:02 AM UTC+12, Phillip Helbig (undress
to
> reply) wrote:
> > It would be nice to do
> >
> > $ SEARCH [*...]* <string>
> > put it to the background
> > pull it to the foreground to see if it has found something
> >
> > and so on.
>
> These days we just open multiple terminal windows/tabs.
>

Agree - I use Putty Connection Manager which allows multiple tabbed
Window sessions running SSH or telnet to multiple systems.

I may have 2 or 3 session tabs open to the same system at the same
time for doing different tasks on the same system.

Each tab can be re-named for easy reference.

> Unless you are accessing a remote machine, when that becomes
> inconvenient. Then we use screen(1) <http://man7.org/linux/man-
> pages/man1/screen.1.html>.
>

I use putty connection manager for remote sessions as well.

Once connected, each local/remote tab appears local to me and I can
pop back and forth.

[John Reagan]

On Sunday, July 3, 2016 at 6:57:33 AM UTC-4, Simon Clubley wrote:

>
> PPS: As an aside, I wonder how VSI are building LLVM on VMS ? I wonder
> if they are using the configure scripts (which are now obsolete in
> current LLVM versions) or if instead they have CMake running on VMS ?
>

We're using an older LLVM for the cross-compilers (3.4.2) which still builds with configure/make. With minimal DECC$ logicals I must say. :)

$ set process /parse=extended
$ define/nolog DECC$ARGV_PARSE_STYLE ENABLE
$ define/nolog DECC$EFS_CASE_PRESERVE ENABLE
$ define/nolog DECC$EFS_CHARSET ENABLE


We'll bootstrap to a newer version LLVM for the native compilers. I'm very much aware of the CMake requirement (no, it isn't running on OpenVMS yet).

[David Froble]

Simon Clubley wrote:
> On 2016-07-03, lawren...@gmail.com <lawren...@gmail.com> wrote:
>> On Sunday, July 3, 2016 at 8:09:52 AM UTC+12, VAXman- wrote:
>>> If people here want VMS to be unix, why the fuck don't they just use unix?
>> Perhaps because “wanting VMS to be Unix” is an unfair and misleading
>> characterization of what people want?
>
> That's exactly right at least in my case.
>
> I don't want VMS to become Unix; I want it to get the kind of
> functionality that Unix has in certain areas.

If *+ix functionality is required, then just run *ix ...

> This includes simple stuff such as being able to edit long command
> lines, save and recall command history (with multiple sessions being
> merged correctly) and a way of searching for previous commands that
> doesn't involve as much effort as just retyping the command for short
> commands.

We've been over this many times. The reality still is that what people are
running their applications for, their main purpose, has no need for the command
line editing. Got to retain some perspective.

> It also includes more complicated stuff such as reloadable device
> drivers and plug in filesystem modules with full usage documentation.

Reloadable drivers, and unloadable drivers, would be nice for device driver
developers. Tell me what it does for the customers running applications.

> It also includes being able to more easily pull over the large
> ecosystem of Unix style application code over to VMS and run it on VMS.

My customers run VMS applications. That's why they run VMS.

[David Froble]

Jan-Erik Soderholm wrote:
> Den 2016-07-03 kl. 10:24, skrev Hans Vlems:
>> I agree Brian. And they might want to stop whining about why VMS lacks
>> unix/posix capabilities.
>>
>> I realize VMS is not a clean design let alone a clean implementation. No
>> wonder after 40 years. But I refuse to be convinced that Windows Server
>> et al are better off. Hans
>>
>
> One cannot of course say that one or the other is "better" without
> specifying what params one is looking at.
>
> Windows Server is "better" in running Windows Server applications.
> VMS is "better" at running old "legacy" VMS applications.

How about my "new" non-legacy applications?

[David Froble]

Simon Clubley wrote:
> On 2016-07-03, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>> The single most important reason to run VMS today, is that
>> you already have it.
>>
>
> I agree with that. However, once VSI have got VMS as it currently is
> up and running for the current user base, they then need to start
> thinking about how they are going to attract new users to VMS.
>
> Simon.
>

Well, it sure isn't going to be by imitating *ix. It's going to be by providing
capabilities not available, or not well implemented, elsewhere.

[Jan-Erik Soderholm]

Den 2016-07-03 kl. 15:24, skrev David Froble:
> Jan-Erik Soderholm wrote:
>> Den 2016-07-03 kl. 10:24, skrev Hans Vlems:
>>> I agree Brian. And they might want to stop whining about why VMS lacks
>>> unix/posix capabilities.
>>>
>>> I realize VMS is not a clean design let alone a clean implementation. No
>>> wonder after 40 years. But I refuse to be convinced that Windows Server
>>> et al are better off. Hans
>>>
>>
>> One cannot of course say that one or the other is "better" without
>> specifying what params one is looking at.
>>
>> Windows Server is "better" in running Windows Server applications.
>> VMS is "better" at running old "legacy" VMS applications.
>
> How about my "new" non-legacy applications?
>

Then comes what I wrote below. You already have VMS, don't you?

If you had nothing (and in particular if you didn't know
about VMS), I'd guess that you'd be running something else.

[Simon Clubley]

On 2016-07-03, John Reagan <xyzz...@gmail.com> wrote:
>
> We'll bootstrap to a newer version LLVM for the native compilers.
> I'm very much aware of the CMake requirement (no, it isn't running on
> OpenVMS yet).

Thanks for the feedback; I was beginning to wonder if you had an
internal port of CMake up and running. I've started looking at LLVM
in detail recently as part of a project and I noticed the configure
scripts are now obsolete.

Simon.

[Simon Clubley]

On 2016-07-03, David Froble <da...@tsoft-inc.com> wrote:

> Simon Clubley wrote:
>>
>> I don't want VMS to become Unix; I want it to get the kind of
>> functionality that Unix has in certain areas.
>
> If *+ix functionality is required, then just run *ix ...
>

Seeing specific functionality in other operating systems and wanting
it in your own operating system is nothing new.

>
>> It also includes being able to more easily pull over the large
>> ecosystem of Unix style application code over to VMS and run it on VMS.
>
> My customers run VMS applications. That's why they run VMS.

What about other customers who might want to run some Unix applications
or utilities alongside their VMS applications ?

Simon.

[lawren...@gmail.com]

On Monday, July 4, 2016 at 12:35:04 AM UTC+12, Kerry Main wrote:
>
> Lawrence D’Oliveiro wrote:
>
>> Then we use screen(1) <http://man7.org/linux/man-pages/man1/screen.1.html>.

>
> I use putty connection manager for remote sessions as well.
>
> Once connected, each local/remote tab appears local to me and I can
> pop back and forth.

Note I just open a single SSH connection to the remote host, then run screen(1) there to manage multiple terminal sessions.

The nice thing, I can disconnect and leave those terminal sessions running, then log in later and reattach to them.

[David Froble]

Simon Clubley wrote:
> On 2016-07-03, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> I don't want VMS to become Unix; I want it to get the kind of
>>> functionality that Unix has in certain areas.
>> If *+ix functionality is required, then just run *ix ...
>>
>
> Seeing specific functionality in other operating systems and wanting
> it in your own operating system is nothing new.
>
>>> It also includes being able to more easily pull over the large
>>> ecosystem of Unix style application code over to VMS and run it on VMS.
>> My customers run VMS applications. That's why they run VMS.
>
> What about other customers who might want to run some Unix applications
> or utilities alongside their VMS applications ?

1) they should not ...

2) run a Unix system alongside their VMS system ...

Everyone is entitled to their opinion. I just cannot get excited with Unix
stuff. If I need it, I'll implement it on VMS.

(Steve, no comments about SSL are required here ...)

[Craig A. Berry]

On 7/3/16 9:18 PM, David Froble wrote:

> Simon Clubley wrote:

>> What about other customers who might want to run some Unix applications
>> or utilities alongside their VMS applications ?
>
> 1) they should not ...
>
> 2) run a Unix system alongside their VMS system ...
>
> Everyone is entitled to their opinion. I just cannot get excited with
> Unix stuff. If I need it, I'll implement it on VMS.
>
> (Steve, no comments about SSL are required here ...)

What about SSH? ;-)

[David Froble]

Multinet SSH fixed that, for now ....

[Stephen Hoffman]

On 2016-07-03 00:47:06 +0000, lawren...@gmail.com said:

> On Sunday, July 3, 2016 at 6:36:02 AM UTC+12, Phillip Helbig (undress
> to reply) wrote:
>> It would be nice to do
>>
>> $ SEARCH [*...]* <string>
>> put it to the background
>> pull it to the foreground to see if it has found something
>>
>> and so on.
>
> These days we just open multiple terminal windows/tabs.

That, or we use systems with cached (fast) search tools. In addition
to the limitations of its query syntax, the design of SEARCH makes it
positively glacial.




--
Pure Personal Opinion | HoffmanLabs LLC

[Stephen Hoffman]

On 2016-07-03 10:57:32 +0000, Simon Clubley said:

> I don't want VMS to become Unix; I want it to get the kind of
> functionality that Unix has in certain areas.

OpenVMS is behind Unix in many areas. For too many folks, in too many
areas, too.

> This includes simple stuff such as being able to edit long command
> lines, save and recall command history (with multiple sessions being
> merged correctly) and a way of searching for previous commands that
> doesn't involve as much effort as just retyping the command for short
> commands.
>
> It also includes more complicated stuff such as reloadable device
> drivers and plug in filesystem modules with full usage documentation.
>
> It also includes being able to more easily pull over the large
> ecosystem of Unix style application code over to VMS and run it on VMS.
>
> There are other areas; these are just some simple examples off the top
> of my head.

Yes, there are valuable parts of OpenVMS. Parts well worth keeping.
But there are problem areas. Development tools and IDEs. Compiler
support. Patch support. Integrated, modern security. Remote
management and automated and automate-able user and app and server
management. zip and unzip. Caching search tools. Simplicity.
More than a few bits are either missing, mis-implemented, or
mis-integrated.

OpenVMS has become comparatively much harder to configure and to use,
much harder to program, harder to troubleshoot, harder to keep patched,
and that's for an experienced user.

For the VSI folks, OpenVMS is an exceedingly difficult sale outside of
the installed base. The port to x86-64 will help (somewhat) with
that, but that general difficulty will be an issue for the foreseeable
future and with the knock-off effects that has on the development and
marketing budgets.