In general, how difficult is it to get something which works on linux
and is built via a make file to work on VMS via MMS? The code itself
should run OK on VMS, it's just the build procedure I'm concerned with.

Up until now, I've dealt with my own code, code for others written with
VMS in mind, or simple codes (compile, link, run) written for other
operating systems (but intended to be portable, so just the build is
VMS-specific). I now want to use a rather large code not written by me
and probably never run on VMS.

On Thursday, October 6, 2022 at 5:20:41 AM UTC-4, Phillip Helbig (undress to reply) wrote:
> In general, how difficult is it to get something which works on linux
> and is built via a make file to work on VMS via MMS? The code itself
> should run OK on VMS, it's just the build procedure I'm concerned with.
>
> Up until now, I've dealt with my own code, code for others written with
> VMS in mind, or simple codes (compile, link, run) written for other
> operating systems (but intended to be portable, so just the build is
> VMS-specific). I now want to use a rather large code not written by me
> and probably never run on VMS.

The first big hurdle is that the actions will be unix commands and not VMS
command lines. It's not trivial to refactor a series of conditionally added
-Dmacro command line options into a single /define=(...) for the VMS C
compiler.

In article <8a84da92-46b7-43f8-b507-0a12184e3d3dn@googlegroups.com>,
David Jones <osuvman50@gmail.com> writes:

> On Thursday, October 6, 2022 at 5:20:41 AM UTC-4, Phillip Helbig (undress to reply) wrote:
> > In general, how difficult is it to get something which works on linux
> > and is built via a make file to work on VMS via MMS? The code itself
> > should run OK on VMS, it's just the build procedure I'm concerned with.
> >
> > Up until now, I've dealt with my own code, code for others written with
> > VMS in mind, or simple codes (compile, link, run) written for other
> > operating systems (but intended to be portable, so just the build is
> > VMS-specific). I now want to use a rather large code not written by me
> > and probably never run on VMS.
>
> The first big hurdle is that the actions will be unix commands and not VMS
> command lines. It's not trivial to refactor a series of conditionally added
> -Dmacro command line options into a single /define=(...) for the VMS C
> compiler.

It's Fortran90, amazingly enough. However, that might still apply.

On 2022-10-06, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>
> It's Fortran90, amazingly enough. However, that might still apply.
>

How big is the makefile ? Is it easier to simply write your own build
command procedure as was done in the old days ?

I would have suggested GNV, but I'm not sure how well setup it is to
handle Fortran and to translate Unix Fortran commands to VMS Fortran
commands.

Simon.

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

In article <thmjfo$3c8u4$2@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> > It's Fortran90, amazingly enough. However, that might still apply.
>
> How big is the makefile ?

15 blocks.

> Is it easier to simply write your own build
> command procedure as was done in the old days ?

Grand total of 116 directories, 1015 files, 31604 blocks. :-(

> I would have suggested GNV, but I'm not sure how well setup it is to
> handle Fortran and to translate Unix Fortran commands to VMS Fortran
> commands.

VMS is language-agnostic, which is good; much unix stuff favours C.
Translating the commands is another issue.

Probably not worth the trouble.

I'm also puzzled by the fact that a (compressed) ZIP arXiv has size
193312 blocks, UNZIP/LIST reports 110745595 bytes and 1018 files, which
seems to correspond to what I see on linux, but unpacked I get only the
31604 mentioned above.

Allocation issue? Nope:

Grand total of 116 directories, 1015 files, 31604/42096 blocks.

On linux, du reports 110396 1-k blocks, which jibes with everything
else. du | wc gives 120 so hard to tell at a glance if anything is
really missing on VMS. :-(

OK, there are two files with names which are too long which didn't
survive the UNZIP. They are also big files (*git/objects/pack/pack-/*),
so that explains the difference between the total sizes. Will have to
look closer to see what explains the different number of directories (du
does include ".", but that's only one).

So, probably not worth it. :-(

If I actually modify the code, as opposed to just using it, I might see
if I can work on individual files on VMS, simply because it's more
comfortable. The code's output consists of Fortran files, so I'll
probably make plots and so on on VMS (with some Fortran code which makes
nice PostScript files). But it's probably not worth the trouble to
understand the differences mentioned above, much less try to get the
code to work on VMS. (My guess is that I don't need the long-name
files, but I don't know enough about git (which is how I downloaded the
code) to know for sure.)

On Thu, 2022-10-06 at 14:14 +0000, Phillip Helbig (undress to reply)
wrote:
>
> OK, there are two files with names which are too long which didn't
> survive the UNZIP.  They are also big file *git/objects/pack/pack-
> /*), so that explains the difference between the total sizes.  Will
> have to look closer to see what explains the different number of
> directories (du does include ".", but that's only one).

Git files you can safely ignore. They are not essential for building
the project. In fact, all .dot files you find you probably can get rid
of.
--
Tactical Nuclear Kittens

> In general, [...]

I doubt that there is an "in general" answer. Without seeing the
original "make" file(s), I wouldn't try to guess.

Converting a "make" file to MMS is often relatively easy, but if the
project uses a script-generated "config.h" file, then that's typically a
bigger problem in an environment where you can't run the script. And
much GNU stuff seems to drag in vast quantities of other GNU stuff.

When dealing with a script-generated "config.h", my usual procedure
has been to (try to) build the kit on Tru64, and then manually edit the
result. It's far from automatic.

Various examples are available at antinode,info.

> [...] there are two files with names which are too long which didn't
> survive the UNZIP. [...]

How long is "too long"? "unzip -v"? Any useful info at all might be
helpful.

In article <ca82ecb0-4cee-4788-98d2-912451002d09n@googlegroups.com>,
Steven Schweda <sms.antinode@gmail.com> writes:

> > [...] there are two files with names which are too long which didn't
> > survive the UNZIP. [...]

More than 39 characters (ODS-2).

On 2022-10-06, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> In article <thmjfo$3c8u4$2@dont-email.me>, Simon Clubley
><clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> I would have suggested GNV, but I'm not sure how well setup it is to
>> handle Fortran and to translate Unix Fortran commands to VMS Fortran
>> commands.
>
> VMS is language-agnostic, which is good; much unix stuff favours C.
> Translating the commands is another issue.
>

Yes, but GNV comes with a compiler driver that converts gcc syntax into
VMS compiler syntax at least for C code. I don't know if it works with
the VMS Fortran compiler.

> Probably not worth the trouble.
>
> I'm also puzzled by the fact that a (compressed) ZIP arXiv has size
> 193312 blocks, UNZIP/LIST reports 110745595 bytes and 1018 files, which
> seems to correspond to what I see on linux, but unpacked I get only the
> 31604 mentioned above.
>

$ set response/mode=good_natured

I think the surprising thing here is that you have just confessed to
having a Linux box. :-)

Just use it on your Linux box and call it a day...

> Allocation issue? Nope:
>
> Grand total of 116 directories, 1015 files, 31604/42096 blocks.
>
> On linux, du reports 110396 1-k blocks, which jibes with everything
> else. du | wc gives 120 so hard to tell at a glance if anything is
> really missing on VMS. :-(
>

You have also just confessed to knowing how to use Unix shells. :-)

Are you really Phillip ? :-)

If you install GNV on VMS, you should be able to use the same commands
there and see what it gives you. If you do a recursive single column
directory listing of just the filenames (ie: without any attribute
information) on both boxes, you should be able to use GNU diff to compare
the different listings.

I prefer unified diffs BTW, ie: "diff -u" as I find them much more readable.

Simon.

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

On 2022-10-06, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> In article <ca82ecb0-4cee-4788-98d2-912451002d09n@googlegroups.com>,
> Steven Schweda <sms.antinode@gmail.com> writes:
>
>> > [...] there are two files with names which are too long which didn't
>> > survive the UNZIP. [...]
>
> More than 39 characters (ODS-2).
>

Is there any reason why you can't use ODS-5 ?

Simon.

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

In article <thn4e7$3e49o$2@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> I think the surprising thing here is that you have just confessed to
> having a Linux box. :-)

It's not mine. :-)

> Just use it on your Linux box and call it a day...

That's what I'll do for now; life is short. :-|

> You have also just confessed to knowing how to use Unix shells. :-)

I have some basic knowledge.

In article <thn4h7$3e49o$3@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> Is there any reason why you can't use ODS-5 ?

"The key is not to prioritize what's on your schedule, but to schedule
your priorities." ---Steven R. Covey

:-|

Every decision to do something, i.e. set up an ODS-5 disk, requires an
assessment of whether it is worth the trouble.

By the same token, moving off of VMS is not worth the trouble at the
moment (even if I am stuck with old hardware, software, and licenses).
Unless the license problem is cleared up, even moving to VSI VMS is not
worth the trouble, to me at the moment. (And if that's the case, it's
certainly not worth it for many commercial users.)

> More than 39 characters (ODS-2).

It's your life, but perhaps you should consider climbing out of the
stone age.

> Every decision to do something, i.e. set up an ODS-5 disk, requires an
> assessment of whether it is worth the trouble.

That assessment should include the trouble involved in _not_ doing
it.

Around here, except for those on the VAXes, all the VMS disks (Alpha,
IA64, (virtual) X86_64) are ODS5, and I can't imagine wasting a whole
real disk on ODS2. Been that way for years and years.

I keep a 10MB (LD) virtual disk on my main (IA64) system for
experiments and testing. I can't remember the last time I used it, but
evidence suggests that there was (late 2020) a bug in VMSTAR which
caused it to mishandle I/O errors. The bad behavior was easier to
reproduce on ODS2, because more file names caused I/O errors there.

On 6/10/22 20:20, Phillip Helbig (undress to reply) wrote:
> In general, how difficult is it to get something which works on linux
> and is built via a make file to work on VMS via MMS? The code itself
> should run OK on VMS, it's just the build procedure I'm concerned with.
>
> Up until now, I've dealt with my own code, code for others written with
> VMS in mind, or simple codes (compile, link, run) written for other
> operating systems (but intended to be portable, so just the build is
> VMS-specific). I now want to use a rather large code not written by me
> and probably never run on VMS.
>

In general, the answer is "somewhere between easy and impossible" :)

As you are talking about FORTRAN and you want to use MMS, ignore the
un*x build and generate description files with MMS/GENERATE, then tweak
if needed.

I've used this (with a custom written parser to detect and cope with
some unconventional include files) to automatically generate MMS for a
code base approximately 10 times the size you mention further
down-thread, written in ANSI COBOL. Of the 100K or so source modules,
only about ten or twenty of the generated MMS description files needed
to be tweaked to get it to work.

On 10/6/2022 1:34 PM, Phillip Helbig (undress to reply) wrote:
> In article <ca82ecb0-4cee-4788-98d2-912451002d09n@googlegroups.com>,
> Steven Schweda <sms.antinode@gmail.com> writes:
>
>>> [...] there are two files with names which are too long which didn't
>>> survive the UNZIP. [...]
>
> More than 39 characters (ODS-2).
>

Even Dave has some ODS-5 disks ...

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

Steven Schweda <sms.antinode@gmail.com> wrote:
> Converting a "make" file to MMS is often relatively easy, but if the
>project uses a script-generated "config.h" file, then that's typically a
>bigger problem in an environment where you can't run the script. And
>much GNU stuff seems to drag in vast quantities of other GNU stuff.
>
> When dealing with a script-generated "config.h", my usual procedure
>has been to (try to) build the kit on Tru64, and then manually edit the
>result. It's far from automatic.

Translation: If the makefile is competently-written by a human being, it
will translate to MMS easily.

If the makefile is a horrific mess generated by Configure or some other
automated process, it will be difficult to translate to anything and
difficult to debug when it fails and it should be rewritten.

If the makefile is a horrific mess generated by cmake then just shoot
yourself now and avoid the pain. If you absolutely have to deal with that,
get the original cmakefile and work from that to translate it, avoiding all
the horrific trash that cmake generates from it.
--scott

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