Added/fixed support for DM daemons (GUNNER, ZONE, BATCHN).

[eswenson1]

Also added ECOMP MDL compiler, which appears necessary to compile some of this code.

[eswenson1]

@larsbrinkhoff This is done with one commit. I didn't really want to break this up because not much can be integrated separately. You need the DEMON==1 in config in order to actually run the DEMSTR daemon code. And that code attempts to launch GUNNER, ZONE, and BATHCH. I could have made the addition of ECOMP a separate commit, but I didn't (shoot me). It was required in order to build the MDL daemons, so I included it. In addition, it would have made testing a lot more difficult if I had to test each commit separately. Let me know if you really object to this.

I've seen some weirdness that I can't exactly explain. So it will be interesting to see if this works right out-of-the-box.

First of all, I occasionally saw GUNNER die on startup, span a GUNNED, which also died. Both died on a DEMSIG or perhaps a DEMSTR (I forget which). However, without changing anything, it started working in a subsequent boot. Not sure why.

COMBAT ZONE is an odd beast. It only runs on holidays or between 8pm and 8am (i.e. at night). You can force it to run outside these hours by putting a file called HLIDAY YYMMDD in the COMBAT directory. Everything was working fine for me on ES, and when I installed into DB, ZONE wasn't compiling anything -- I didn't realize the time range when I tried to submit a job was different.

BATCHN seems to just work. It starts automatically (by DEMSTR) after a few minutes after a boot and is kept running by GUNNER and BATCH.

GUNNER appears to restart daemons that fail. I've seen it work. It also emits a log in the hudini directory. Oops. I may not have remembered to create that.....

[eswenson1]

I'll update this PR with a commit that adds a -read- -me- file to the hudini directory in order to get the directory created and prevented from deletion. That may have been why GUNNER failed the first time.

[eswenson1]

Ok, I amended my commit by adding doc/hudini/-read-.-me. This will ensure that directory is created.

[larsbrinkhoff]

Build Muddle ECOMP compiler (PCOMP isn't good enough)

What is the difference between ECOMP and PCOMP?

[larsbrinkhoff]

I could have made the addition of ECOMP a separate commit, but I didn't (shoot me).

It's never too late to rewrite history!

[larsbrinkhoff]

A nice rule of thumb is "if this commit needs to be reverted later, will we lose more than one feature"?

[larsbrinkhoff]

Let me know if you really object to this.

I won't object, if you don't object to me doing the occasional touch-up. Deal?

[eswenson1]

Well, generally ECOMP was a newer, “experimental” compiler. But in this case, the reason why ECOMP is needed rather than PCOMP has to do with the MDL in which the compiler was loaded and dumped. ECOMP includes a working package and library system whereas that PCOMP doesn’t. So when you compile a file that does a USE of a library package without first loading it, it actually located and loads the package (ECOMP), whereas it fails in PCOMP.

[eswenson1]

Ok, I’ll do that.

[eswenson1]

A nice rule of thumb is "if this commit needs to be reverted later, will we lose more than one feature"?

Yes, but in this case, if we reverted the ECOMP addition, we couldn’t run the rest of the build script (it would bomb out and abort).

[eswenson1]

Let me know if you really object to this.

I won't object, if you don't object to me doing the occasional touch-up. Deal?

Deal. I didn’t realize you were going to fix these things. Thanks. Saves me reading about how to do them again!

[eswenson1]

@larsbrinkhoff is there anything left for me to do? Or is this ready to merge from your perspective? Did it pass any CI build?

[eswenson1]

I see that some builds have succeeded. I’m so used to seeing builds fail when they work fine for me, that I almost ignore the failures from CI!

[eswenson1]

Also, should we have bumped up the version of config? Or does it not matter with the pending changes to consolidate / patch config?

[larsbrinkhoff]

Looks like pdp10-kl/config.202 already had MSPP (message slurped) enabled.

Fixing.

[larsbrinkhoff]

Right, let's leave the config versions as is. Hopefully we'll have just a single version soon.

[eswenson1]

Just did a build and confirmed that ZONE, GUNNER, and BATCHN came up fine and that COMBAT and BATCH both work (as commands to run jobs).

[larsbrinkhoff]

CI usually builds fine now. And no, should be nothing more to do now.

[eswenson1]

Ok, ready to rebase and merge?