I guess if you write a set of declarations for NixOS you can copy that same file to the new machine. Thanks for the pointers. What about the “install facts” being just a byproduct of the first install? You don’t even have to write a script… anyway. It seems there are ways to do this already, Thanks!

I have changed the syntax a little: //jo jobname owner(username) log(mailto=user@location) class(a) //** Note that the next step copies /etc/passwd to /tmp/jobname/passwd and then later deletes it when the job is done //dd passwd disp(scratch) source(file=/etc/passwd)
//ex cat passed //!! End of Job

What if one could use this to submit jobs to run on a local server (or a far away one) via email - mail lcl@remoteserver.org Then either paste in the lcl file or attach it to the email. If your owner clause is an email address, the job will be returned via email. The username on the owner clause has to be also a user on the remoteserver. If your username on the two machines differ, you may have to use a //ex to send the log back to you.

It is not mandatory that you install it - Yes, there are other choices already. But in the beginning, Unix only had C and Assembly why didn’t we just stick with those?

More Detail::: What SUBMIT Does with Each LJL Statement:

For every statement, SUBMIT generates corresponding commands in the .deck file. Below is a step-by-step breakdown:

One //jo line, as many /dd lines as are required, and as many //ex as are required

//jo sumjob owner=me@mail.com log=print class=a

• Generates a deck command to invoke ifclass a, which checks if the job’s class allows execution at run time.

• Generates a deck command to Log “sumjob is starting” to /var/log/JCL/ with a timestamp.

• Generates a deck command to create /tmp/sumjob

• Generates a deck command to initializes /tmp/sumjob/jobname.log with a formatted header (e.g., via figlet sumjob).

Job Classes: A = Runs as soon as submitted B = Runs only if load is low enough C = Runs in Off-Hours

//dd alias source(here|file=pathandfilename|new) disp(keep|scratch)

• Note the disp (disposition) if keep the put the file in /home/user/.lcl/jobname as whatever the alias is if the disp(scratch) then the file will go into the /tmp/jobname directory as named by the alias.

• Generate deck commands to

– if source is here: copy lines from lcl up to ‘/*’ to the deck file as a here document if source is a file: add commands to copy the file into a working directory either in user’s home or in the tmp directory under the alias. //dd users source(file=/etc/passwd) disp(keep) ==> copy /etc/passwd to /home/user/.ljl/users

//ex somecommand --options < alias

-Generate doc commands to execute the program as specified and save the output to the logfile In this case echo (somecommand --options < aliasproperlyexpanded ) > logfile

The deck file now forms a fully functional batch file to do the specified computation.

I manually created a .deck file to compile and run a Fortran program with specific data and to create a .log file of all the output, the Fortran program, and the data. I found it to be picky and somewhat hard. So I thought to myself: With something like JCL, one could take simple JCL-like statements, here documents for the source and data files, and programmatically combine them to make a script like the one I created manually.

Debian/KDE because I like the way I can customize (1 panel on the left with everything) No features removed just as one gets used to them. (looking at you gnome) No breaking changes to the desktop gadget api every update (you gnome again) Nice big repo.

I don’t bend my values for entertainment. I pick my OS for privacy and freedom first. If a game won’t run on it, that game doesn’t run in my life.