On 2022-04-09, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 4/9/22 00:31, Dave Froble wrote:
>>
>>
>> I doubt that many, if any, choose assembler because they like it.  At
>> times it is the best choice.  That appears to have decreased.
>>

Sometimes it is the only choice, but those cases are limited these days.

>
> I always like assembler. Have done some recently and expect to more
> in the near future. I know the assembler for at least 10 processors.
> But then, I am a dinosaur.
>

Assembly languages I've used in recent years: ARM, x86, MIPS, Macro-32,
and Alpha native assembly language.

Older assembly languages I knew at one time: Macro-11, Z80.

The above is not an exclusive list, but the point is that I am experienced
when it comes to assembly language.

And with that experience, I believe the time for assembly language is
well and truly past, unless it's needed for something specific such
as some inline assembly fragment to access a CPU-specific register
(for example), or really low-level stuff such as the initial interrupt
handling and dispatch the interrupt to a device driver stuff or other
such low-level work where not even C would be suitable.

Simon.

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

On 04/09/22 19:51, Simon Clubley wrote:
> On 2022-04-09, Bill Gunshannon<bill.gunshannon@gmail.com> wrote:
>> On 4/9/22 00:31, Dave Froble wrote:
>>>
>>>
>>> I doubt that many, if any, choose assembler because they like it. At
>>> times it is the best choice. That appears to have decreased.
>>>
>
> Sometimes it is the only choice, but those cases are limited these days.
>
>>
>> I always like assembler. Have done some recently and expect to more
>> in the near future. I know the assembler for at least 10 processors.
>> But then, I am a dinosaur.
>>
>
> Assembly languages I've used in recent years: ARM, x86, MIPS, Macro-32,
> and Alpha native assembly language.
>
> Older assembly languages I knew at one time: Macro-11, Z80.
>
> The above is not an exclusive list, but the point is that I am experienced
> when it comes to assembly language.
>
> And with that experience, I believe the time for assembly language is
> well and truly past, unless it's needed for something specific such
> as some inline assembly fragment to access a CPU-specific register
> (for example), or really low-level stuff such as the initial interrupt
> handling and dispatch the interrupt to a device driver stuff or other
> such low-level work where not even C would be suitable.
>
> Simon.
>

Not fluent with any now, but quite a few in the past. Here, it's
typically used to clear memory, perhaps setup cpu clock and
other registers if required, set stack pointer and then call main().
Just about everything else, peripheral control registers, interrupt
handlers etc are all in C for years now, though interrupt handlers
may have a bit of inline assember to save context, depending on the
cpu and toolchain. In general, try to minimise assembler usage for
clarity and maintenance reasons...

Chris

On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> > On 4/9/22 00:31, Dave Froble wrote:
> >>
> >>
> >> I doubt that many, if any, choose assembler because they like it. At
> >> times it is the best choice. That appears to have decreased.
> >>
>
> Sometimes it is the only choice, but those cases are limited these days.
>
> >
> > I always like assembler. Have done some recently and expect to more
> > in the near future. I know the assembler for at least 10 processors.
> > But then, I am a dinosaur.
> >
>
> Assembly languages I've used in recent years: ARM, x86, MIPS, Macro-32,
> and Alpha native assembly language.
>
> Older assembly languages I knew at one time: Macro-11, Z80.
>
> The above is not an exclusive list, but the point is that I am experienced Simon,
> when it comes to assembly language.
>
> And with that experience, I believe the time for assembly language is
> well and truly past, unless it's needed for something specific such
> as some inline assembly fragment to access a CPU-specific register
> (for example), or really low-level stuff such as the initial interrupt
> handling and dispatch the interrupt to a device driver stuff or other
> such low-level work where not even C would be ble.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
Simon,

In my career, I have probably written well over 100K lines of various assembler code (not counting my work writing a code generator back end). Assembler has its place, but today's resources and tools make it a small niche in the overall firmware/software world.

For certain tasks, assembly language is the cleanest choice. Accomplishing the same task in a higher-level language requires all manner of tricks, including embedding assembler code inline. If those special-case features are needed, I am better off writing that module as straight assembler.

- Bob Gezelter, http://www.rlgsc.com

On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
: >
> And with that experience, I believe the time for assembly language is
> well and truly past, unless it's needed for something specific such
> as some inline assembly fragment to access a CPU-specific register
> (for example), or really low-level stuff such as the initial interrupt

I agree for production use, but disagree as a general rule notably for OpenVMS.
It's the only 'language' every single OpenVMS system has available.
I have a dozen or so small tools I needed over the years.
Silly things like a 'strings' program, a patch tool for RMS indexed files, and more.
Using Macro I can provide them as text to customers who would not readily accept binaries.

Hein.

On 10/04/2022 10:44 pm, Hein RMS van den Heuvel wrote:
> On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
>> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> :
>>
>> And with that experience, I believe the time for assembly language
>> is well and truly past, unless it's needed for something specific
>> such as some inline assembly fragment to access a CPU-specific
>> register (for example), or really low-level stuff such as the
>> initial interrupt
>
> I agree for production use, but disagree as a general rule notably
> for OpenVMS. It's the only 'language' every single OpenVMS system has
> available. I have a dozen or so small tools I needed over the years.
> Silly things like a 'strings' program, a patch tool for RMS indexed
> files, and more. Using Macro I can provide them as text to customers
> who would not readily accept binaries.
>
> Hein.

Remember when inner-mode code and protected sub-systems were essential.

Happy days.

In article <82ee4212-d4a9-4178-b86d-ab233d49fc9cn@googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
>> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>:
>>
>> And with that experience, I believe the time for assembly language is
>> well and truly past, unless it's needed for something specific such
>> as some inline assembly fragment to access a CPU-specific register
>> (for example), or really low-level stuff such as the initial interrupt
>
>I agree for production use, but disagree as a general rule notably for OpenVMS.

RMS CDC? ;)

>It's the only 'language' every single OpenVMS system has available.
>I have a dozen or so small tools I needed over the years.
>Silly things like a 'strings' program, a patch tool for RMS indexed files, and more.
>Using Macro I can provide them as text to customers who would not readily accept binaries.

Careful, there are those here that believe all files should be flat streams
of bytes.

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

I speak to machines with the voice of humanity.

On 4/11/22 05:32, VAXman-@SendSpamHere.ORG wrote:
> In article <82ee4212-d4a9-4178-b86d-ab233d49fc9cn@googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>> On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
>>> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> :
>>>
>>> And with that experience, I believe the time for assembly language is
>>> well and truly past, unless it's needed for something specific such
>>> as some inline assembly fragment to access a CPU-specific register
>>> (for example), or really low-level stuff such as the initial interrupt
>>
>> I agree for production use, but disagree as a general rule notably for OpenVMS.
>
> RMS CDC? ;)
>
>
>> It's the only 'language' every single OpenVMS system has available.
>> I have a dozen or so small tools I needed over the years.
>> Silly things like a 'strings' program, a patch tool for RMS indexed files, and more.
>> Using Macro I can provide them as text to customers who would not readily accept binaries.
>
> Careful, there are those here that believe all files should be flat streams
> of bytes.
>

Actually, every file on every computer is just a string of bytes.
(or you could even say bits) Any additional formatting is just
overlayed on top.

bill

On 2022-04-11 13:05, Bill Gunshannon wrote:
> On 4/11/22 05:32, VAXman-@SendSpamHere.ORG wrote:
>> In article <82ee4212-d4a9-4178-b86d-ab233d49fc9cn@googlegroups.com>,
>> Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>>> On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
>>>> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>> :
>>>>
>>>> And with that experience, I believe the time for assembly language is
>>>> well and truly past, unless it's needed for something specific such
>>>> as some inline assembly fragment to access a CPU-specific register
>>>> (for example), or really low-level stuff such as the initial interrupt
>>>
>>> I agree for production use, but disagree as a general rule notably
>>> for OpenVMS.
>>
>> RMS CDC? ;)
>>
>>
>>> It's the only 'language' every single OpenVMS system has available.
>>> I have a dozen or so small tools I needed over the years.
>>> Silly things like a 'strings' program, a patch tool for RMS indexed
>>> files, and more.
>>> Using Macro I can provide them as text to customers who would not
>>> readily accept binaries.
>>
>> Careful, there are those here that believe all files should be flat
>> streams
>> of bytes.
>>
>
> Actually, every file on every computer is just a string of bytes.
> (or you could even say bits) Any additional formatting is just
> overlayed on top.

That is obviously incorrect. Every disk used today is divided into
blocks. So that is what a file on a disk is, in the end. And that is not
the same as a string of bytes. The string of bytes abstraction is
implemented on top of this.
I'm surprised you don't know this.

Johnny

On 2022-04-10, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
> On 10/04/2022 10:44 pm, Hein RMS van den Heuvel wrote:
>> On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
>>>
>>> And with that experience, I believe the time for assembly language
>>> is well and truly past, unless it's needed for something specific
>>> such as some inline assembly fragment to access a CPU-specific
>>> register (for example), or really low-level stuff such as the
>>> initial interrupt
>>
>> I agree for production use, but disagree as a general rule notably
>> for OpenVMS. It's the only 'language' every single OpenVMS system has
>> available. I have a dozen or so small tools I needed over the years.
>> Silly things like a 'strings' program, a patch tool for RMS indexed
>> files, and more. Using Macro I can provide them as text to customers
>> who would not readily accept binaries.
>>
>> Hein.
>
> Remember when inner-mode code and protected sub-systems were essential.
>
> Happy days.

From a _security_ point of view, VMS has only ever had one inner mode,
just like other operating systems.

Once you are in one of the hardware inner modes, you can get to the
others without any additional privileges required on the part of the
account doing it.

As for protected sub-systems, Linux has mandatory access controls in which
you can even control which TCP/IP ports a process is allowed to use.

Other MAC options are also available.

Simon.

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

On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>
> Careful, there are those here that believe all files should be flat streams
> of bytes.
>

There is a strong argument for saying that the RMS record orientated
model has not stood the test of time.

In this case, I will say that it _was_ the right model for the 1970s/1980s,
but it's not the right model for 2022. In today's world, it just gets
in the way.

Also, RMS indexed files were a neat solution for the 1970s/1980s, but
in todays's world they also have not stood the test of time.

For example, you work on a punched card model as there's no field level
data structures in the RMS indexed file metadata, and unlike SQL databases,
you can't extend an RMS indexed file to add a new field, or change the
size of an existing field, while the applications are running.

Simon.

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

In article <t318l3$92b$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-04-10, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
>> On 10/04/2022 10:44 pm, Hein RMS van den Heuvel wrote:
>>> On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
>>>>
>>>> And with that experience, I believe the time for assembly language
>>>> is well and truly past, unless it's needed for something specific
>>>> such as some inline assembly fragment to access a CPU-specific
>>>> register (for example), or really low-level stuff such as the
>>>> initial interrupt
>>>
>>> I agree for production use, but disagree as a general rule notably
>>> for OpenVMS. It's the only 'language' every single OpenVMS system has
>>> available. I have a dozen or so small tools I needed over the years.
>>> Silly things like a 'strings' program, a patch tool for RMS indexed
>>> files, and more. Using Macro I can provide them as text to customers
>>> who would not readily accept binaries.
>>>
>>> Hein.
>>
>> Remember when inner-mode code and protected sub-systems were essential.
>>
>> Happy days.
>
>From a _security_ point of view, VMS has only ever had one inner mode,
>just like other operating systems.
>
>Once you are in one of the hardware inner modes, you can get to the
>others without any additional privileges required on the part of the
>account doing it.

If that were true, then Joe Noprivuser could go from user mode to kernel mode
through a series of steps -- user->supervisor then supervisor->executive then
executive->kernel.

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

I speak to machines with the voice of humanity.

On 4/11/2022 9:06 AM, Simon Clubley wrote:
> On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>
>> Careful, there are those here that believe all files should be flat streams
>> of bytes.
>>
>
> There is a strong argument for saying that the RMS record orientated
> model has not stood the test of time.
>
> In this case, I will say that it _was_ the right model for the 1970s/1980s,
> but it's not the right model for 2022. In today's world, it just gets
> in the way.
>
> Also, RMS indexed files were a neat solution for the 1970s/1980s, but
> in todays's world they also have not stood the test of time.
>
> For example, you work on a punched card model as there's no field level
> data structures in the RMS indexed file metadata, and unlike SQL databases,
> you can't extend an RMS indexed file to add a new field, or change the
> size of an existing field, while the applications are running.
>
> Simon.
>

Ahh yes, back to disagreeing with Simon ...

:-)

Your statement is just wrong.

Anything that can be done in any database product can be done, and as RMS is a
database product, such things could be implemented in RMS. The fact that they
are not at this time does not indicate that they could not be done.

I will comment that the RMS developers did far less than they could have done
back in the day. Before RMS existed the company I worked for at the time had a
database product that while file oriented, had the data field metadata and
utilities that used it. It was doable back then, the RMS developers just failed
to do it.

Not a fan of RMS ...

--
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

> That is obviously incorrect. Every disk used today is divided into
> blocks. So that is what a file on a disk is, in the end. And that is not
> the same as a string of bytes. The string of bytes abstraction is
> implemented on top of this.

Er, not a very convincing argument. In that vein, every magnetic media
disk used today is a string of flux transitions. The bytes and blocks
abstraction are implemented on top of this.

De

Den 2022-04-11 kl. 16:13, skrev Dave Froble:
> On 4/11/2022 9:06 AM, Simon Clubley wrote:
>> On 2022-04-11, VAXman-  @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>>
>>> Careful, there are those here that believe all files should be flat streams
>>> of bytes.
>>>
>>
>> There is a strong argument for saying that the RMS record orientated
>> model has not stood the test of time.
>>
>> In this case, I will say that it _was_ the right model for the 1970s/1980s,
>> but it's not the right model for 2022. In today's world, it just gets
>> in the way.
>>
>> Also, RMS indexed files were a neat solution for the 1970s/1980s, but
>> in todays's world they also have not stood the test of time.
>>
>> For example, you work on a punched card model as there's no field level
>> data structures in the RMS indexed file metadata, and unlike SQL databases,
>> you can't extend an RMS indexed file to add a new field, or change the
>> size of an existing field, while the applications are running.
>>
>> Simon.
>>
>
> Ahh yes, back to disagreeing with Simon ...
>
> :-)
>
> Your statement is just wrong.

What part of it? I find it mostly correct. A standard database product
(we can pick Rdb since this is VMS) is just so much easier to deal with
then a bunch of RMS files. And that is straight out-of-the-box, with no
home-made tools to completment with.

>
> Anything that can be done in any database product can be done, and as RMS
> is a database product, such things could be implemented in RMS.  The fact
> that they are not at this time does not indicate that they could not be done.
>
> I will comment that the RMS developers did far less than they could have
> done back in the day.  Before RMS existed the company I worked for at the
> time had a database product that while file oriented, had the data field
> metadata and utilities that used it.  It was doable back then, the RMS
> developers just failed to do it.
>
> Not a fan of RMS ...
>

As Simon indicated, RMS (indexed) files has passed their best-before date.
I do not see anyone writing a new application based on RMS indexed files.

Jan-Erik.

Op 11.apr..2022 om 13:05 schreef Bill Gunshannon:
> On 4/11/22 05:32, VAXman-@SendSpamHere.ORG wrote:
>> In article <82ee4212-d4a9-4178-b86d-ab233d49fc9cn@googlegroups.com>,
>> Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>>> On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
>>>> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>> :
>>>>
>>>> And with that experience, I believe the time for assembly language is
>>>> well and truly past, unless it's needed for something specific such
>>>> as some inline assembly fragment to access a CPU-specific register
>>>> (for example), or really low-level stuff such as the initial interrupt
>>>
>>> I agree for production use, but disagree as a general rule notably
>>> for OpenVMS.
>>
>> RMS CDC? ;)
>>
>>
>>> It's the only 'language' every single OpenVMS system has available.
>>> I have a dozen or so small tools I needed over the years.
>>> Silly things like a 'strings' program, a patch tool for RMS indexed
>>> files, and more.
>>> Using Macro I can provide them as text to customers who would not
>>> readily accept binaries.
>>
>> Careful, there are those here that believe all files should be flat
>> streams
>> of bytes.
>>
>
> Actually, every file on every computer is just a string of bytes.
> (or you could even say bits) Any additional formatting is just
> overlayed on top.
>
> bill

It depends on the level from which a file is seen. At the lowest level,
even this may be to strong. A 'string' assumes an order. Maybe a
'collection' of bits is a better term. Even the order of bits within a
byte is just a matter of formatting. Similarly the order of bytes within
a block is a matter of formatting. On disk, the physical order of blocks
may be different from the logical order of blocks, which is also a
matter of formatting.
At the highest level, there may be much more structure in a file that
just a sequence of bytes.

On Monday, April 11, 2022 at 5:51:25 AM UTC-7, Johnny Billquist wrote:
> On 2022-04-11 13:05, Bill Gunshannon wrote:

(snip)

> > Actually, every file on every computer is just a string of bytes.
> > (or you could even say bits) Any additional formatting is just
> > overlayed on top.

> That is obviously incorrect. Every disk used today is divided into
> blocks. So that is what a file on a disk is, in the end. And that is not
> the same as a string of bytes. The string of bytes abstraction is
> implemented on top of this.
> I'm surprised you don't know this.

Disk files on Unix-like systems and DOS/Windows are just a string of bytes.
Any block structure is hidden by the OS disk cache.

On the other hand, tapes on Unix, and I believe DOS/Windows do have a block
structure. In some cases, it is necessary to preserve that in order to
properly read them. There are virtual tape formats that convert a tape of
blocks into a stream with block marks included, and others to reverse it.

Note also in IP networking, UDP has a packet (datagram) structure, but
TCP does not. Usual UDP based protocols depend on that, and when
converted to TCP (as seems to happen often enough) have record
marks added to the stream. There is even an RFC on that.

I don't know the VMS forms quite as well as I used to, but I remember
some that are record oriented, not (necessarily) block oriented.

The IBM OS/360 hardware writes blocks to disk similar to
the way it writes them to tape. Users can choose the actual block
size that the hardware writes onto the disk, when creating a disk
file. As well as I know, VMS keeps a 512 byte block, or some multiple
of that hidden by the system, when it writes to disk.

Newer IBM hardware virtualizes the blocks, but they are still
visible to users and the OS. Note, for example, that direct access
data sets in OS/360 are written unblocked, one physical disk block
for every user record, from one byte to the track size. Users select
the size when first opening the file, and the system formats the whole
file with block of that size. There are inter-block gaps, which make
small sizes inefficient. I am pretty sure that VMS doesn't do that.

On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <t318l3$92b$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2022-04-10, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
>>>
>>> Remember when inner-mode code and protected sub-systems were essential.
>>>
>>> Happy days.
>>
>>From a _security_ point of view, VMS has only ever had one inner mode,
>>just like other operating systems.
>>
>>Once you are in one of the hardware inner modes, you can get to the
>>others without any additional privileges required on the part of the
>>account doing it.
>
> If that were true, then Joe Noprivuser could go from user mode to kernel mode
> through a series of steps -- user->supervisor then supervisor->executive then
> executive->kernel.
>

Ok, Brian, you win. I'll be pedantic if you wish. :-)

Once you have code you control running in one of the hardware inner modes,
you can get to the others without any additional privileges required on
the part of the account doing it.

Happy now ? :-)

Simon.

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

On Mon, 11 Apr 2022 12:56:15 +0000, VAXman- wrote:

>>Once you are in one of the hardware inner modes, you can get to the
>>others without any additional privileges required on the part of the
>>account doing it.
>
> If that were true, then Joe Noprivuser could go from user mode to kernel
> mode through a series of steps -- user->supervisor then
> supervisor->executive then executive->kernel.

"Hardware *inner* modes" - i.e. not user.

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On Mon, 11 Apr 2022 10:33:55 -0700, gah4 wrote:

> On Monday, April 11, 2022 at 5:51:25 AM UTC-7, Johnny Billquist wrote:
>> On 2022-04-11 13:05, Bill Gunshannon wrote:
>
> (snip)
>
>> > Actually, every file on every computer is just a string of bytes.
>> > (or you could even say bits) Any additional formatting is just
>> > overlayed on top.
>
>> That is obviously incorrect. Every disk used today is divided into
>> blocks. So that is what a file on a disk is, in the end. And that is
>> not the same as a string of bytes. The string of bytes abstraction is
>> implemented on top of this.
>> I'm surprised you don't know this.
>
> Disk files on Unix-like systems and DOS/Windows are just a string of
> bytes.

And on a very few systems (mainly in the past) a file is always an array
of bytes in virtual memory!

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On Monday, April 11, 2022 at 11:27:19 AM UTC-4, F.Zwarts wrote:
> Op 11.apr..2022 om 13:05 schreef Bill Gunshannon:
> > On 4/11/22 05:32, VAX...@SendSpamHere.ORG wrote:
> >> In article <82ee4212-d4a9-4178...@googlegroups.com>,
> >> Hein RMS van den Heuvel <heinvand...@gmail.com> writes:
> >>> On Saturday, April 9, 2022 at 2:51:56 PM UTC-4, Simon Clubley wrote:
> >>>> On 2022-04-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> >>> :
> >>>>
> >>>> And with that experience, I believe the time for assembly language is
> >>>> well and truly past, unless it's needed for something specific such
> >>>> as some inline assembly fragment to access a CPU-specific register
> >>>> (for example), or really low-level stuff such as the initial interrupt
> >>>
> >>> I agree for production use, but disagree as a general rule notably
> >>> for OpenVMS.
> >>
> >> RMS CDC? ;)
> >>
> >>
> >>> It's the only 'language' every single OpenVMS system has available.
> >>> I have a dozen or so small tools I needed over the years.
> >>> Silly things like a 'strings' program, a patch tool for RMS indexed
> >>> files, and more.
> >>> Using Macro I can provide them as text to customers who would not
> >>> readily accept binaries.
> >>
> >> Careful, there are those here that believe all files should be flat
> >> streams
> >> of bytes.
> >>
> >
> > Actually, every file on every computer is just a string of bytes.
> > (or you could even say bits) Any additional formatting is just
> > overlayed on top.
> >
> > bill
> It depends on the level from which a file is seen. At the lowest level,
> even this may be to strong. A 'string' assumes an order. Maybe a
> 'collection' of bits is a better term. Even the order of bits within a
> byte is just a matter of formatting. Similarly the order of bytes within
> a block is a matter of formatting. On disk, the physical order of blocks
> may be different from the logical order of blocks, which is also a
> matter of formatting.
> At the highest level, there may be much more structure in a file that
> just a sequence of bytes.
Fred,

I do not have my copy of the FILES-11 Level 1 specification (authored by Andy) was cited in my Ph.D. dissertation (at Chapter 13; pp 130):

“... A volume (also often referred to as a unit) is defined as an ordered set of logical blocks. A logical block is an array of 512 8-bit bytes. The logical blocks in a volume are consecutively
numbered from 0 to n − 1, where the volume contains n logical blocks. The number assigned to a logical block is called its logical block number, or LBN. ...” [Goldstein, 1975], Section 2.1

unix and its clade use essentially the same definition. There is a related reference in the original Bell Systems Technical Journal paper.

- Bob Gezelter, http://www.rlgsc.com

On 4/11/2022 9:06 AM, Simon Clubley wrote:
> On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> Careful, there are those here that believe all files should be flat streams
>> of bytes.
>
> There is a strong argument for saying that the RMS record orientated
> model has not stood the test of time.

Difficult to say for sure.

The most common OS (Linux/Unix and Windows) expose files as
streams of bytes.

Other OS with different approach are not nearly as widely used.

But it is not obvious from analytical point of view that
the file system approach has been an important factor in
OS success.

And statistically 2 is not significant.

> In this case, I will say that it _was_ the right model for the 1970s/1980s,
> but it's not the right model for 2022. In today's world, it just gets
> in the way.
>
> Also, RMS indexed files were a neat solution for the 1970s/1980s, but
> in todays's world they also have not stood the test of time.

That is definitely not true.

Indexed files are really a NoSQL databases of the key value store type
and new of such is still being created.

> For example, you work on a punched card model as there's no field level
> data structures in the RMS indexed file metadata, and unlike SQL databases,
> you can't extend an RMS indexed file to add a new field, or change the
> size of an existing field, while the applications are running.

That does not mean that indexed files are obsolete.

It does mean that they should not be default choice.

Arne

On 4/11/2022 11:01 AM, Jan-Erik Söderholm wrote:
> Den 2022-04-11 kl. 16:13, skrev Dave Froble:
>> On 4/11/2022 9:06 AM, Simon Clubley wrote:
>>> Also, RMS indexed files were a neat solution for the 1970s/1980s, but
>>> in todays's world they also have not stood the test of time.
>>>
>>> For example, you work on a punched card model as there's no field level
>>> data structures in the RMS indexed file metadata, and unlike SQL
>>> databases,
>>> you can't extend an RMS indexed file to add a new field, or change the
>>> size of an existing field, while the applications are running.

>> Your statement is just wrong.
>
> What part of it? I find it mostly correct. A standard database product
> (we can pick Rdb since this is VMS) is just so much easier to deal with
> then a bunch of RMS files. And that is straight out-of-the-box, with no
> home-made tools to completment with.

NoSQL databases of key value store type (which is what RMS indexed files
are in modern terminology) are still used for specialized purposes.

The standard/default approach is and should be a relational database,
but sometimes requirements are not to the standard solution.

Rdb is a pretty big database to replace RMS indexed files, but it
will work. I would consider SQLite to be a more obvious replacement.
But options are always good. And in the middle there is MySQL/MariaDB.

>> Anything that can be done in any database product can be done, and as
>> RMS is a database product, such things could be implemented in RMS.
>> The fact that they are not at this time does not indicate that they
>> could not be done.
>>
>> I will comment that the RMS developers did far less than they could
>> have done back in the day.  Before RMS existed the company I worked
>> for at the time had a database product that while file oriented, had
>> the data field metadata and utilities that used it.  It was doable
>> back then, the RMS developers just failed to do it.
>>
>> Not a fan of RMS ...
>
> As Simon indicated, RMS (indexed) files has passed their best-before date.
> I do not see anyone writing a new application based on RMS indexed files.

The concept still exist and are used in the industry.

The biggest problem with RMS indexed files is probably the RMS part
not the indexed part. Max 32K records, VMS IO etc..

I don't see any good reasons for having a new VMS application
use RMS indexed files. The mentioned specialized purposes are
not something that will use VMS.

But I am also sure that some new VMS application will use
RMS indexed files, simply because of tradition and skills.

Arne

In article <t31ose$pr0$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-04-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <t318l3$92b$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>On 2022-04-10, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
>>>>
>>>> Remember when inner-mode code and protected sub-systems were essential.
>>>>
>>>> Happy days.
>>>
>>>From a _security_ point of view, VMS has only ever had one inner mode,
>>>just like other operating systems.
>>>
>>>Once you are in one of the hardware inner modes, you can get to the
>>>others without any additional privileges required on the part of the
>>>account doing it.
>>
>> If that were true, then Joe Noprivuser could go from user mode to kernel mode
>> through a series of steps -- user->supervisor then supervisor->executive then
>> executive->kernel.
>>
>
>Ok, Brian, you win. I'll be pedantic if you wish. :-)
>
>Once you have code you control running in one of the hardware inner modes,
>you can get to the others without any additional privileges required on
>the part of the account doing it.

NOT TRUE. Stop confusing $CMKRNL from EXEC mode with all others. You can
NOT get to EXEC from SUPERVISOR mode. Granted, you found an exploit with an
installed image but that was corrected. There's no $CMEXEC jump from SUPER-
VISOR mode without privileges vis-a-vis $CMKRNL from EXEC mode.

>Happy now ? :-)

No, publish such code here to PROVE me wrong. Otherwise, stop your bullshit.

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

I speak to machines with the voice of humanity.

On 2022-04-11 17:00, Dennis Boone wrote:
> > That is obviously incorrect. Every disk used today is divided into
> > blocks. So that is what a file on a disk is, in the end. And that is not
> > the same as a string of bytes. The string of bytes abstraction is
> > implemented on top of this.
>
> Er, not a very convincing argument. In that vein, every magnetic media
> disk used today is a string of flux transitions. The bytes and blocks
> abstraction are implemented on top of this.

That is true. However, the interface that you have access to, in the
software, is the blocks abstraction, and not the lower level thing,
which is kept internal to the drive.

And either way, it's not a string of bytes.

Johnny

On 2022-04-11 19:33, gah4 wrote:
> On Monday, April 11, 2022 at 5:51:25 AM UTC-7, Johnny Billquist wrote:
>> On 2022-04-11 13:05, Bill Gunshannon wrote:
>
> (snip)
>
>>> Actually, every file on every computer is just a string of bytes.
>>> (or you could even say bits) Any additional formatting is just
>>> overlayed on top.
>
>> That is obviously incorrect. Every disk used today is divided into
>> blocks. So that is what a file on a disk is, in the end. And that is not
>> the same as a string of bytes. The string of bytes abstraction is
>> implemented on top of this.
>> I'm surprised you don't know this.
>
> Disk files on Unix-like systems and DOS/Windows are just a string of bytes.
> Any block structure is hidden by the OS disk cache.

Well, it's not hidden by the OS disk cache in Unix. It's hidden by the
device driver framework. That's where the block and character devices is
about.

> On the other hand, tapes on Unix, and I believe DOS/Windows do have a block
> structure. In some cases, it is necessary to preserve that in order to
> properly read them. There are virtual tape formats that convert a tape of
> blocks into a stream with block marks included, and others to reverse it.

Actually, in Unix, tapes are the same story as disks. However, no sane
person ever cared to use the character device for tapes, since (as you
observe), with tapes there are additional reasons why you want to know,
and preserve block information. The character device hides this from you.

For networking, it's all carried by IP datagrams in the end, which are
blocks. TCP then implements a stream of bytes abstraction on top of that.

Johnny