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.

My system came with Python3 installed. Debian 12.

Looks like a line by line translation from the python. Will you use it to backup your home directory?

@droolio@feddit.uk I see what you’re asking. You’re wondering if, instead of storing a duplicate file when another backup set already contains it, I could use a hardlink to point to the file already stored in that other set?

I have a system where I create a backup set for each day of the week. When I do a backup for that day, I update the set, or if it’s out of date, I replace it entirely with a fresh backup image (After 7 backups to that set). But if the backup sets became inter-dependent, removing or updating one set could lead to problems with others that rely on files in the first set.

Does that make sense? I am asking because I am not familiar with the utilities you mentioned and may be taking your post wrong.

Especially one that lets you know how long it’s been since you took time to run a backup, keeps track of which set of backups could be updated, and which should be refreshed, and keeps a log file up to date and in .csv format so you can mess with it in a spreadsheet?

That’s ok Like any landing you can walk away from. Any code that runs to spec is good, much could be better.

Yeah, no problem… I started out with just bare rsync - but I did the backup infrequently and needed my notes to know the command. Then I wrote a simple shell script to run the rsync for me. Then I decided I needed more than one backup, redundancy is good. Then I wanted to keep track of the backups so I had it write to .backuplog then that file started getting dated (every time I run a “sun” backup the record of the previous one is useless) so Finally TaDa! loci is born.

It’s also to help me learn python. And it works for me. : ^ )