On 1/10/22 4:18 PM, Bob Eager wrote:
> On Mon, 10 Jan 2022 12:41:32 -0500, Bill Gunshannon wrote:
>
>> On 1/10/22 8:34 AM, Arne Vajhøj wrote:
>>> On 1/10/2022 4:31 AM, Bob Eager wrote:
>>>> On Sun, 09 Jan 2022 19:58:48 -0500, Arne Vajhøj wrote:
>>>>> And I get a REXX.EXE.
>>>>>
>>>>> Unfortunately I cannot test it because I don't know REXX.
>>>>
>>>> Easy test. Feed it:
>>>>
>>>>    say 'Hello, world'
>>>
>>> That works.
>>>
>>> $ type bob.rexx say 'Hello, world'
>>> $ mcr []rexx bob.rexx Hello, world
>>>
>>> The little test program that it comes with also works:
>>>
>>> $ typ [.demo]testvms.rexx /*
>>>  * Test program for Regina 3.3 *
>>>  * This program tests the OpenVMS specific BIFs.
>>>  *
>>>  */
>>> Trace o Say Say 'Name of the my current disk:' f$getdvi("sys$disk:",
>>> 'volnam')
>>> Say 'My own pid:' f$getjpi("0","pid")
>>> Say Begin of external command dir '*.cxx'
>>> Say end of external command Return 0 $ mcr []rexx [.demo]testvms.rexx
>>>
>>> Name of the my current disk: DISK2 My own pid: 0000043E BEGIN OF
>>> EXTERNAL COMMAND %DIRECT-W-NOFILES, no files found END OF EXTERNAL
>>> COMMAND
>>>
>>>
>> If you want a more detailed test, Rosetta Code has a bunch of REXX
>> examples.
>
> I don't *think* I did anything on there, althiugh I know you did, Bill.
>
> But I did most of the pages on ML/I !

I've done a number. Some in obscure languages like RATFOR and Basic09.
I even did some DIBOL-11 and MACRO-11. It's actually a lot of fun.
Been working mostly on COBOL lately and plan to submit more in the near
future. Keeps my skills well honed. Never know when someone will need
a job done in one of the languages I can still do. :-)

bill

On 1/10/2022 6:37 PM, Dave Froble wrote:
> Sometimes I think over half of my code is condition handling ...
>
> :-)

Nothing unusual in that.

The "demo level" code just doing the happy scenario is typical
short and simple. And then adding handling of all the not so happy
scenarios, adding some logging to help troubleshooting, adding
various sanity checks etc. make the code grow dramatically.

Condition handling will impact the code a bit less
if the language supports exceptions and try resource
constructs, bit in the end the developer still needs to
consider things.

Arne

On 1/8/2022 2:58 PM, Arne Vajhøj wrote:
> On 1/8/2022 1:40 PM, Scott Dorsey wrote:
>> plugh  <jchimene@gmail.com> wrote:
>>> I think one of the aspects of MUmPhs that buggers newbs is that it's
>>> one of=
>>> the few languages implementing content addressable memory, even to
>>> seconda=
>>> ry storage. I've professionally written REXX, which is the only other
>>> such =
>>> language. I'm sure there are others.
>>
>> It's actually become a popular thing recently, with hashes being
>> implemented
>> in perl and python as standard data structures.  Not as extensive or
>> transparent as in Mumps, mind you.
>
> In memory hashtables/hashmaps/dictionaries/associative arrays are a
> standard feature in most newer languages.
>
> Index-sequential files/NoSQL Key Value Stores are also common across
> technologies.
>
> The combination is not common. Even though I guess that languages
> that allow overloading of indexing operator could do something
> similar under the hood.

Just for fun here is an example with Kotlin and MapDB.

Plain in memory:

package simple

fun main() {
val m = HashMap<String,Int>()
//
m["A"] = 111
m["B"] = 222
m["C"] = 333
println(m["A"])
println(m["B"])
println(m["C"])
var x = m.getOrDefault("X", 0)
x = x + 1
m["X"] = x
println(m["X"])
//
}

On disk:

package mapdb

import org.mapdb.DBMaker

fun main() {
val db = DBMaker.fileDB("/work/fun.db").make()
@Suppress("UNCHECKED_CAST")
val m = db.hashMap("demo").createOrOpen() as MutableMap<String,Int>
//
m["A"] = 111
m["B"] = 222
m["C"] = 333
println(m["A"])
println(m["B"])
println(m["C"])
var x = m.getOrDefault("X", 0)
x = x + 1
m["X"] = x
println(m["X"])
//
db.close()
}

Arne

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

> After a 5-minute read of the Mumps language syntax, I have come to
> the conclusion that it makes TECO look user-friendly. :-)
>
> The total of my Mumps knowledge has been acquired over the last few
> minutes and is based on the following:
>
> https://en.wikipedia.org/wiki/MUMPS#Summary_of_key_language_features
>
> I really don't like the dynamic nature of variables and the dynamic
> way they are created when first referenced. It makes Mumps look more
> like a scripting language than an application programming language.

It is a long-standing tradition that Mumps has no declarations.

Except maybe for the verb NEW as in NEW x,y,z - although you can
think of it as saving any preexisting values (or lack thereof)
on a stack for recovery upon exit from the current context.

I would consider Mumps to be something of a scripting language. It
is precompiled in most implementations into something like p-code.
I also consider it a language for maintaining and navigating trees,
with tree nodes labelled by alphanumeric keys a.k.a. subscripts. The
rest looks like a language designed to be quite spare, written as
verb arg[,...] with a _single_ space as a separator when continuing
on a line with additional commands, and with all the important
verbs (SET, IF, ELSE, DO...) capable of being abbreviated with a
single letter.

With regard to tightly written code with few comments, I once heard
one of our vendors quoted as stating "if it was hard to write, it
_should_ be hard to read!"

We tried to adopt a standard. So something like

S X=12,A("Jones","Sam")=12 P U+3 D sub1 P "Done"

could be written (using the newer . indentation marker and the
so-called "naked DO"):

SET X=12,A("Jones","Sam")=12
PRINT U+3
DO
. <line 1 of subroutine>
. <line 2 of subroutine>
PRINT "Done"

where the initial spaces would actually be tabs that marked the
end of the label field and the beginning of the commands.

Oh, and Mumps stores its data on disk with the same tree structure
as in memory, again with names as subscripts. Data in external
storage is prefixed with an up-caret, say ^A instead of A.

Its facility with keyed data arranged in trees, and its facility
with delimited data items, made it a rapid prototyping language.

And it had some interesting indirection capabilities. You had
an XECUTE verb to execute command lines, say, generated on the fly,
but you also had @-sign indirection, which could refer to parts
of commands: arguments and subscript expressions. So you might
have tables defining, say, laboratory tests, which included bits
of the code needed to do some of the calculations associated
with a given test. Indirection is heavily used in VA Fileman,
as I recall.

And DSM (Digital Standard Mumps) had some nice features for
interfacing with VMS - think Mumps syntax implementation of
most of the DCL lexicals, for example.

George

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

Arne Vajh?j <arne@vajhoej.dk> wrote:

[...]

> Hewlett Packard said in a letter published by Kyoto University on
> December 29, 2021 that it took "100% responsibility" for the issue
> ...
> HPE said: "The backup script includes a find command to delete log files
> older than 10 days. In addition to functional improvement of the script,
> the variable name passed to the find command for deletion was changed to
> improve visibility and readability."
> ...
> The company added: "However, there was a lack of consideration in the
> release procedure of this modified script. We were not aware of the side
> effects of this behavior and released the [updated] script, overwriting
> [a bash script] while it was still running," HPE admitted. "This
> resulted in the reloading of the modified shell script in the middle of
> the execution, resulting in undefined variables. As a result, the
> original log files in /LARGE0 [backup disc storage] were deleted instead
> of the original process of deleting files saved in the log directory."
> </quote>

Say what you will, 100% online backup storage does not replace
magnetic tapes that are removed from tape drives and moved to a
tape rack or an external vault when the backup is complete.

Backups should be physically secured, or at least something close to
that: an interlock associated with each backup such that it takes
more than mere programmatic action by root to overwrite it. Now that
ransomware takes steps to erase your backups, an interlock that
requires human intervention, perhaps at the storage array console
itself, in order to be overridden, should be the norm, not the
exception.

Wasn't there a time when tape management systems were considered to
have become so reliable you no longer needed to remove the "write rings"
from your nine-track tapes to avoid overwriting crucial data? The
beginning, of course, of a rather long and slippery slope down.

George

> Arne

On Wed, 12 Jan 2022 22:23:30 +0000, George Cornelius wrote:

> Wasn't there a time when tape management systems were considered to have
> become so reliable you no longer needed to remove the "write rings" from
> your nine-track tapes to avoid overwriting crucial data? The beginning,
> of course, of a rather long and slippery slope down.

I worked on a system where the software only allowed backup tapes to be
mounted with a write ring when a backup was being taken. At all other
times (e.g. for a restore) the system would refuse to touch them unless
the ring was removed or an operator specifically intervened on the
operator console.

--
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 1/12/2022 5:23 PM, George Cornelius wrote:
> Arne Vajh?j <arne@vajhoej.dk> wrote:
> [...]
>> Hewlett Packard said in a letter published by Kyoto University on
>> December 29, 2021 that it took "100% responsibility" for the issue
>> ...
>> HPE said: "The backup script includes a find command to delete log files
>> older than 10 days. In addition to functional improvement of the script,
>> the variable name passed to the find command for deletion was changed to
>> improve visibility and readability."
>> ...
>> The company added: "However, there was a lack of consideration in the
>> release procedure of this modified script. We were not aware of the side
>> effects of this behavior and released the [updated] script, overwriting
>> [a bash script] while it was still running," HPE admitted. "This
>> resulted in the reloading of the modified shell script in the middle of
>> the execution, resulting in undefined variables. As a result, the
>> original log files in /LARGE0 [backup disc storage] were deleted instead
>> of the original process of deleting files saved in the log directory."
>> </quote>
>
> Say what you will, 100% online backup storage does not replace
> magnetic tapes that are removed from tape drives and moved to a
> tape rack or an external vault when the backup is complete.
>
> Backups should be physically secured, or at least something close to
> that: an interlock associated with each backup such that it takes
> more than mere programmatic action by root to overwrite it. Now that
> ransomware takes steps to erase your backups, an interlock that
> requires human intervention, perhaps at the storage array console
> itself, in order to be overridden, should be the norm, not the
> exception.

There is certainly advantages of having backups on tape.

But with hundreds of TB then the effort to do proper tape backup
is significant.

Arne

On 1/12/2022 6:44 PM, Arne Vajhøj wrote:
> On 1/12/2022 5:23 PM, George Cornelius wrote:
>> Arne Vajh?j <arne@vajhoej.dk> wrote:
>> [...]
>>> Hewlett Packard said in a letter published by Kyoto University on
>>> December 29, 2021 that it took "100% responsibility" for the issue
>>> ...
>>> HPE said: "The backup script includes a find command to delete log files
>>> older than 10 days. In addition to functional improvement of the script,
>>> the variable name passed to the find command for deletion was changed to
>>> improve visibility and readability."
>>> ...
>>> The company added: "However, there was a lack of consideration in the
>>> release procedure of this modified script. We were not aware of the side
>>> effects of this behavior and released the [updated] script, overwriting
>>> [a bash script] while it was still running," HPE admitted. "This
>>> resulted in the reloading of the modified shell script in the middle of
>>> the execution, resulting in undefined variables. As a result, the
>>> original log files in /LARGE0 [backup disc storage] were deleted instead
>>> of the original process of deleting files saved in the log directory."
>>> </quote>
>>
>> Say what you will, 100% online backup storage does not replace
>> magnetic tapes that are removed from tape drives and moved to a
>> tape rack or an external vault when the backup is complete.
>>
>> Backups should be physically secured, or at least something close to
>> that: an interlock associated with each backup such that it takes
>> more than mere programmatic action by root to overwrite it. Now that
>> ransomware takes steps to erase your backups, an interlock that
>> requires human intervention, perhaps at the storage array console
>> itself, in order to be overridden, should be the norm, not the
>> exception.
>
> There is certainly advantages of having backups on tape.
>
> But with hundreds of TB then the effort to do proper tape backup
> is significant.

The issue is not whether or not tapes are used. The issue is whether the
backups can be accessed for other than actual backups. Removable disk drives
would do the same as removable tapes. Backup to a node that cannot be normally
accessed, and in a different location would work. The key is, you can lose
everything, but still recover from last backup.

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

On Wednesday, January 12, 2022 at 1:27:36 PM UTC-7, George Cornelius wrote:
>
>
>
> Oh, and Mumps stores its data on disk with the same tree structure
> as in memory, again with names as subscripts. Data in external
> storage is prefixed with an up-caret, say ^A instead of A.
>
> Its facility with keyed data arranged in trees, and its facility
> with delimited data items, made it a rapid prototyping language.

Yes, forgetting that caret... Thanks for the memories.

Regarding the transparency of file I/O in Mumps and her spawn:
https://hardware.slashdot.org/story/22/01/12/222254/ultraram-breakthrough-could-combine-memory-and-storage-into-one

>-----Original Message-----
>From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
>Info-vax
>Sent: January-12-22 7:44 PM
>To: info-vax@rbnsn.com
>Cc: Arne Vajhøj <arne@vajhoej.dk>
>Subject: Re: [Info-vax] Meditech in the news
>
>On 1/12/2022 5:23 PM, George Cornelius wrote:
>> Arne Vajh?j <arne@vajhoej.dk> wrote:
>> [...]
>>> Hewlett Packard said in a letter published by Kyoto University on
>>> December 29, 2021 that it took "100% responsibility" for the issue
>>> ...
>>> HPE said: "The backup script includes a find command to delete log
>>> files older than 10 days. In addition to functional improvement of
>>> the script, the variable name passed to the find command for deletion
>>> was changed to improve visibility and readability."
>>> ...
>>> The company added: "However, there was a lack of consideration in the
>>> release procedure of this modified script. We were not aware of the
>>> side effects of this behavior and released the [updated] script,
>>> overwriting [a bash script] while it was still running," HPE
>>> admitted. "This resulted in the reloading of the modified shell
>>> script in the middle of the execution, resulting in undefined
>>> variables. As a result, the original log files in /LARGE0 [backup
>>> disc storage] were deleted instead of the original process of deleting
files
>saved in the log directory."
>>> </quote>
>>
>> Say what you will, 100% online backup storage does not replace
>> magnetic tapes that are removed from tape drives and moved to a tape
>> rack or an external vault when the backup is complete.
>>
>> Backups should be physically secured, or at least something close to
>> that: an interlock associated with each backup such that it takes more
>> than mere programmatic action by root to overwrite it. Now that
>> ransomware takes steps to erase your backups, an interlock that
>> requires human intervention, perhaps at the storage array console
>> itself, in order to be overridden, should be the norm, not the
>> exception.
>
>There is certainly advantages of having backups on tape.
>
>But with hundreds of TB then the effort to do proper tape backup is
>significant.
>
>Arne
>

The traditional best practice backup strategy is often referred to 3-2-1.
This translates to 3 copies of data = 2 local (live + disk backup) + 1
offline with an air gap.

By air gap, this usually refers to an offline copy in a separate facility,
so you have a copy that is not destroyed by a significant facility ending
event.

While storage increases have certainly put a strain on traditional tape
sub-systems and associated backup strategies, it should be noted that tape
technologies like LTO have also been seeing very large increases in speed
and capacity.

Reference:
<https://www.lto.org/>
<https://www.lto.org/lto-9/>
- 18TB per single cartridge, 45TB compressed.

<https://www.quantum.com/en/products/tape-storage/>
Large tape library can support up to 540PB (yes, PB) tape storage

One biggie for tape is that current LTO tape solutions will do a write, then
read-back for every write. Disks just do a write, unless you do a
backup/verify type operation.

In todays "Cloud" (aka outsourcing) world, here is what can happen using the
traditional cloud backup if there is no air gap between your data and your
backups:
<https://www.networkcomputing.com/cloud-infrastructure/code-spaces-lesson-cl
oud-backup>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

Reposting full link without the wrap.

https://www.networkcomputing.com/cloud-infrastructure/code-spaces-lesson-cloud-backup

This link should work.

On 2022-01-13, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>
> One biggie for tape is that current LTO tape solutions will do a write, then
> read-back for every write. Disks just do a write, unless you do a
> backup/verify type operation.
>

That only guarantees that the data, as presented to the tape drive, is
what was actually written to the tape.

It does nothing for a failing controller delivering the wrong data to
the tape drive or for a faulty backup program delivering the wrong data
to the controller.

IMHO, you still need a full verify pass by the backup program.

Simon.

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

On 1/14/22 8:51 AM, Simon Clubley wrote:
> On 2022-01-13, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>>
>> One biggie for tape is that current LTO tape solutions will do a write, then
>> read-back for every write. Disks just do a write, unless you do a
>> backup/verify type operation.
>>
>
> That only guarantees that the data, as presented to the tape drive, is
> what was actually written to the tape.
>
> It does nothing for a failing controller delivering the wrong data to
> the tape drive or for a faulty backup program delivering the wrong data
> to the controller.
>
> IMHO, you still need a full verify pass by the backup program.
>

COOP!!

40 years ago before any of this OOP or Agile crap took over
the IT world I worked doing COBOL in a Univac 1100 environment,
Once a month we used to pack up a backup set and travel to Rome
AFB which was our designated COOP site. We would take over one
of their 1100's for the morning and do a complete restoration
of the OS and all our data from the backup tape. Does anyone
still do this? Does anyone here even know what COOP means
(without Googling it!!)

bill

On 1/14/2022 12:18 PM, Bill Gunshannon wrote:
> On 1/14/22 8:51 AM, Simon Clubley wrote:
>> On 2022-01-13, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>>> One biggie for tape is that current LTO tape solutions will do a
>>> write, then
>>> read-back for every write. Disks just do a write, unless you do a
>>> backup/verify type operation.
>>
>> That only guarantees that the data, as presented to the tape drive, is
>> what was actually written to the tape.
>>
>> It does nothing for a failing controller delivering the wrong data to
>> the tape drive or for a faulty backup program delivering the wrong data
>> to the controller.
>>
>> IMHO, you still need a full verify pass by the backup program.
>
> COOP!!
>
> 40 years ago before any of this OOP or Agile crap took over
> the IT world I worked doing COBOL in a Univac 1100 environment,
> Once a month we used to pack up a backup set and travel to Rome
> AFB which was our designated COOP site.  We would take over one
> of their 1100's for the morning and do a complete restoration
> of the OS and all our data from the backup tape. Does anyone
> still do this?  Does anyone here even know what COOP means
> (without Googling it!!)

Restore test is still considered necessary and full
recovery test based on tapes and iron is still considered
desirable.

But a full recovery test is often difficult
today.

The Kyoto super computer that triggered this thread
is in an environment with 3 HPC clusters with
1800, 850 and 16 nodes respectively and a storage
system with 24 PB.

In a worst case where data does not compress well
then that is like 1000 LTO-9 tapes and 10000
tape station hours to restore.

I am pretty sure that they never did it.

Arne

PS: And no - I do not know that FLA.

On 1/6/2022 3:01 PM, Arne Vajhøj wrote:
> On 1/6/2022 10:46 AM, Arne Vajhøj wrote:
>> One may not like MUMPS and its variants.
>
> For those with an strong desire to try MUMPS aka M on VMS, then:
>
> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>
> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
> 6.3 or 7.0).
>
> I have not tried it myself.

Now I have. Hello world works.

$ type test.m
hello()
write "Hello world from Mumps!",!
quit
$ mumps test
$ link test
$ r test
Hello world from Mumps!

Arne

Arne Vajh?j <arne@vajhoej.dk> wrote:
> On 1/6/2022 3:01 PM, Arne Vajh?j wrote:
>> On 1/6/2022 10:46 AM, Arne Vajh?j wrote:
>>> One may not like MUMPS and its variants.
>>
>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>
>> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>
>> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
>> 6.3 or 7.0).
>>
>> I have not tried it myself.
>
> Now I have. Hello world works.
>
> $ type test.m
> hello()
> write "Hello world from Mumps!",!
> quit
> $ mumps test
> $ link test
> $ r test
> Hello world from Mumps!

Congratulations!

Though Greystone ran here for a number of years on AIX, I never
bothered to ask for access to it, nor did I try to install it
under VMS.

Would be curious as to what the compiled code looks like, though.

Greystone was unusual in that it generated object code. I suspect
it was a lot of calls to subroutines. Or a bit of setup code followed
by invoking an interpreter for, say, stack-machine code.

If the latter, not sure why it would be necessary to have separate
compilation - other environments just perform a hidden precompile -
except that, if the language had the capability to call external
routines, you could link those routines directly in with the compiled
Mumps code and not have to have a special shared library of
globally defined external routines [*],[**].

George

[*] DSM, and predecessor DSM-11, had external calls that looked
like:

SET RESULT=$ZCALL(function,arg[,...])

although DSM eventually changed the name to ECALL, along with
a slight syntax modification.

[**] Got into writing ZCALL routines early in my DSM-11 programming
days with the help of Mark Berryman - thanks, Mark! - who provided
some links to what was published about it by Digital, along with
various missing details such as register conventions. To create
binary code to be placed in a patch area at startup time, worked
on our VAX 11/780's RT11 console system to assemble (and maybe link?)
my Macro-11 code - which I suspect had to be carefully written to
be position independent - then transfer it to the '11 to be placed
in the ^PATCH global from which the autoload would occur. DSM,
running on top of VMS, was more advanced, and you could compile
and link your code, along with a special ECALL table, into a VMS
shared image.

On 1/17/2022 7:55 AM, George Cornelius wrote:
> Arne Vajh?j <arne@vajhoej.dk> wrote:
>> On 1/6/2022 3:01 PM, Arne Vajh?j wrote:
>>> On 1/6/2022 10:46 AM, Arne Vajh?j wrote:
>>>> One may not like MUMPS and its variants.
>>>
>>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>>
>>> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>>
>>> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
>>> 6.3 or 7.0).
>>>
>>> I have not tried it myself.
>>
>> Now I have. Hello world works.
>>
>> $ type test.m
>> hello()
>> write "Hello world from Mumps!",!
>> quit
>> $ mumps test
>> $ link test
>> $ r test
>> Hello world from Mumps!
>
> Congratulations!
>
> Though Greystone ran here for a number of years on AIX, I never
> bothered to ask for access to it, nor did I try to install it
> under VMS.
>
> Would be curious as to what the compiled code looks like, though.
>
> Greystone was unusual in that it generated object code. I suspect
> it was a lot of calls to subroutines. Or a bit of setup code followed
> by invoking an interpreter for, say, stack-machine code.
>
> If the latter, not sure why it would be necessary to have separate
> compilation - other environments just perform a hidden precompile -
> except that, if the language had the capability to call external
> routines, you could link those routines directly in with the compiled
> Mumps code and not have to have a special shared library of
> globally defined external routines [*],[**].

Separate compile and link is the VMS way ...

I don't know how the compiled code looks like.

It supports /LIST but not /LIST/MACH (well it accept the
/MACH but does not produce anything).

Do we have a disassembler for VMS Alpha?

(never used one since DISM32 that was VMS VAX)

Arne

On 2022-01-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> COOP!!
>
> 40 years ago before any of this OOP or Agile crap took over
> the IT world I worked doing COBOL in a Univac 1100 environment,
> Once a month we used to pack up a backup set and travel to Rome
> AFB which was our designated COOP site. We would take over one
> of their 1100's for the morning and do a complete restoration
> of the OS and all our data from the backup tape. Does anyone
> still do this? Does anyone here even know what COOP means
> (without Googling it!!)
>

I (correctly) guessed the first two letters were "Continuity of"
(the US Government likes that phrase) but was not familiar with the
last two letters.

Looked up the definition and it's just another USG specific name
for what is known by multiple names elsewhere. :-)

For example, I refer to what you call COOP as a Business Continuity Plan.

Simon.

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

On 2022-01-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Separate compile and link is the VMS way ...
>
> I don't know how the compiled code looks like.
>
> It supports /LIST but not /LIST/MACH (well it accept the
> /MACH but does not produce anything).
>
> Do we have a disassembler for VMS Alpha?
>

There's the srm_check utility Stephen likes to post about.

If someone has built binutils for Alpha, try the objdump utility.
(I don't know if objdump works for an Alpha target however. When I was
playing with binutils for an Alpha VMS target, there were limitations
in the Alpha VMS support in binutils).

You can also use SDA or the debugger to disassemble an instruction sequence.

Simon.

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

In article <61e59077$0$699$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/17/2022 7:55 AM, George Cornelius wrote:
>> Arne Vajh?j <arne@vajhoej.dk> wrote:
>>> On 1/6/2022 3:01 PM, Arne Vajh?j wrote:
>>>> On 1/6/2022 10:46 AM, Arne Vajh?j wrote:
>>>>> One may not like MUMPS and its variants.
>>>>
>>>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>>>
>>>> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>>>
>>>> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
>>>> 6.3 or 7.0).
>>>>
>>>> I have not tried it myself.
>>>
>>> Now I have. Hello world works.
>>>
>>> $ type test.m
>>> hello()
>>> write "Hello world from Mumps!",!
>>> quit
>>> $ mumps test
>>> $ link test
>>> $ r test
>>> Hello world from Mumps!
>>
>> Congratulations!
>>
>> Though Greystone ran here for a number of years on AIX, I never
>> bothered to ask for access to it, nor did I try to install it
>> under VMS.
>>
>> Would be curious as to what the compiled code looks like, though.
>>
>> Greystone was unusual in that it generated object code. I suspect
>> it was a lot of calls to subroutines. Or a bit of setup code followed
>> by invoking an interpreter for, say, stack-machine code.
>>
>> If the latter, not sure why it would be necessary to have separate
>> compilation - other environments just perform a hidden precompile -
>> except that, if the language had the capability to call external
>> routines, you could link those routines directly in with the compiled
>> Mumps code and not have to have a special shared library of
>> globally defined external routines [*],[**].
>
>Separate compile and link is the VMS way ...
>
>I don't know how the compiled code looks like.
>
>It supports /LIST but not /LIST/MACH (well it accept the
>/MACH but does not produce anything).

[smw] The machine list feature requires a debug build.

[smw] The object code is largely, though not completely, calls into the
runtime C code.

[smw] You don't need to precompile the source to the M routines and
"MUMPS /DIRECT" will get a prompt at which you can type M commands.
"DO ^routine" will compile routine.m if needed and execute it.

[smw] The Programmer's Guide which should be on sf.net is pretty good.

Sam

>Do we have a disassembler for VMS Alpha?
>
>(never used one since DISM32 that was VMS VAX)
>
>Arne

On 1/17/22 1:42 PM, Simon Clubley wrote:
> On 2022-01-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>
>> COOP!!
>>
>> 40 years ago before any of this OOP or Agile crap took over
>> the IT world I worked doing COBOL in a Univac 1100 environment,
>> Once a month we used to pack up a backup set and travel to Rome
>> AFB which was our designated COOP site. We would take over one
>> of their 1100's for the morning and do a complete restoration
>> of the OS and all our data from the backup tape. Does anyone
>> still do this? Does anyone here even know what COOP means
>> (without Googling it!!)
>>
>
> I (correctly) guessed the first two letters were "Continuity of"
> (the US Government likes that phrase) but was not familiar with the
> last two letters.
>
> Looked up the definition and it's just another USG specific name
> for what is known by multiple names elsewhere. :-)
>
> For example, I refer to what you call COOP as a Business Continuity Plan.
>

Exactly. Continuity Of OPerations. Does anyone actually do this
anymore?

bill

On 1/17/2022 3:18 PM, Bill Gunshannon wrote:
> On 1/17/22 1:42 PM, Simon Clubley wrote:
>> On 2022-01-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> COOP!!
>>>
>>> 40 years ago before any of this OOP or Agile crap took over
>>> the IT world I worked doing COBOL in a Univac 1100 environment,
>>> Once a month we used to pack up a backup set and travel to Rome
>>> AFB which was our designated COOP site.  We would take over one
>>> of their 1100's for the morning and do a complete restoration
>>> of the OS and all our data from the backup tape. Does anyone
>>> still do this?  Does anyone here even know what COOP means
>>> (without Googling it!!)
>>
>> I (correctly) guessed the first two letters were "Continuity of"
>> (the US Government likes that phrase) but was not familiar with the
>> last two letters.
>>
>> Looked up the definition and it's just another USG specific name
>> for what is known by multiple names elsewhere. :-)
>>
>> For example, I refer to what you call COOP as a Business Continuity Plan.
>
> Exactly.  Continuity Of OPerations.  Does anyone actually do this
> anymore?

Absolutely.

I believe it is usually called Business Continuity Planning today.

But common practice.

Arne

On 1/17/2022 1:53 PM, Simon Clubley wrote:
> On 2022-01-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Do we have a disassembler for VMS Alpha?
>
> There's the srm_check utility Stephen likes to post about.

Its output is not as readable as /LIST/MACH output.

> If someone has built binutils for Alpha, try the objdump utility.
> (I don't know if objdump works for an Alpha target however. When I was
> playing with binutils for an Alpha VMS target, there were limitations
> in the Alpha VMS support in binutils).

The GCC 2.8.0 objdump does not recognize the input.

Arne

On 1/17/2022 2:52 PM, Sam Weiner wrote:
> In article <61e59077$0$699$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/17/2022 7:55 AM, George Cornelius wrote:
>>> Arne Vajh?j <arne@vajhoej.dk> wrote:
>>>> On 1/6/2022 3:01 PM, Arne Vajh?j wrote:
>>>>> On 1/6/2022 10:46 AM, Arne Vajh?j wrote:
>>>>>> One may not like MUMPS and its variants.
>>>>>
>>>>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>>>>
>>>>> https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>>>>
>>>>> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
>>>>> 6.3 or 7.0).
>>>>>
>>>>> I have not tried it myself.
>>>>
>>>> Now I have. Hello world works.
>>>>
>>>> $ type test.m
>>>> hello()
>>>> write "Hello world from Mumps!",!
>>>> quit
>>>> $ mumps test
>>>> $ link test
>>>> $ r test
>>>> Hello world from Mumps!
>>>
>>> Congratulations!
>>>
>>> Though Greystone ran here for a number of years on AIX, I never
>>> bothered to ask for access to it, nor did I try to install it
>>> under VMS.
>>>
>>> Would be curious as to what the compiled code looks like, though.
>>>
>>> Greystone was unusual in that it generated object code. I suspect
>>> it was a lot of calls to subroutines. Or a bit of setup code followed
>>> by invoking an interpreter for, say, stack-machine code.
>>>
>>> If the latter, not sure why it would be necessary to have separate
>>> compilation - other environments just perform a hidden precompile -
>>> except that, if the language had the capability to call external
>>> routines, you could link those routines directly in with the compiled
>>> Mumps code and not have to have a special shared library of
>>> globally defined external routines [*],[**].
>>
>> Separate compile and link is the VMS way ...
>>
>> I don't know how the compiled code looks like.
>>
>> It supports /LIST but not /LIST/MACH (well it accept the
>> /MACH but does not produce anything).
>
> [smw] The machine list feature requires a debug build.
>
> [smw] The object code is largely, though not completely, calls into the
> runtime C code.
>
> [smw] You don't need to precompile the source to the M routines and
> "MUMPS /DIRECT" will get a prompt at which you can type M commands.
> "DO ^routine" will compile routine.m if needed and execute it.
>
> [smw] The Programmer's Guide which should be on sf.net is pretty good.

I get the feeling that someone knows this product well.

:-)

Arne

In article <61e60705$0$701$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/17/2022 2:52 PM, Sam Weiner wrote:
>> In article <61e59077$0$699$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/17/2022 7:55 AM, George Cornelius wrote:
>>>> Arne Vajh?j <arne@vajhoej.dk> wrote:
>>>>> On 1/6/2022 3:01 PM, Arne Vajh?j wrote:
>>>>>> On 1/6/2022 10:46 AM, Arne Vajh?j wrote:
>>>>>>> One may not like MUMPS and its variants.
>>>>>>
>>>>>> For those with an strong desire to try MUMPS aka M on VMS, then:
>>>>>>
>>>>>>
>https://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/V6.2-001/
>>>>>>
>>>>>> should be a VMS Alpha build of GT.M version 6.2 (no VMS version of
>>>>>> 6.3 or 7.0).
>>>>>>
>>>>>> I have not tried it myself.
>>>>>
>>>>> Now I have. Hello world works.
>>>>>
>>>>> $ type test.m
>>>>> hello()
>>>>> write "Hello world from Mumps!",!
>>>>> quit
>>>>> $ mumps test
>>>>> $ link test
>>>>> $ r test
>>>>> Hello world from Mumps!
>>>>
>>>> Congratulations!
>>>>
>>>> Though Greystone ran here for a number of years on AIX, I never
>>>> bothered to ask for access to it, nor did I try to install it
>>>> under VMS.
>>>>
>>>> Would be curious as to what the compiled code looks like, though.
>>>>
>>>> Greystone was unusual in that it generated object code. I suspect
>>>> it was a lot of calls to subroutines. Or a bit of setup code followed
>>>> by invoking an interpreter for, say, stack-machine code.
>>>>
>>>> If the latter, not sure why it would be necessary to have separate
>>>> compilation - other environments just perform a hidden precompile -
>>>> except that, if the language had the capability to call external
>>>> routines, you could link those routines directly in with the compiled
>>>> Mumps code and not have to have a special shared library of
>>>> globally defined external routines [*],[**].
>>>
>>> Separate compile and link is the VMS way ...
>>>
>>> I don't know how the compiled code looks like.
>>>
>>> It supports /LIST but not /LIST/MACH (well it accept the
>>> /MACH but does not produce anything).
>>
>> [smw] The machine list feature requires a debug build.
>>
>> [smw] The object code is largely, though not completely, calls into the
>> runtime C code.
>>
>> [smw] You don't need to precompile the source to the M routines and
>> "MUMPS /DIRECT" will get a prompt at which you can type M commands.
>> "DO ^routine" will compile routine.m if needed and execute it.
>>
>> [smw] The Programmer's Guide which should be on sf.net is pretty good.
>
>I get the feeling that someone knows this product well.
>
>:-)

[smw2] You could say that.

[smw2] BTW, I was wrong about sf.net having the manuals. The wikipedia
entry for "GT.M" does have a reference to where they are however. Enjoy.

Sam