Running Stata well on LINCOMM: do-files vs. the interface

Why a do-file run in batch mode is the right way to run real work on LINCOMM, when the interactive interface still helps, and how the log file keeps a record.

There are two ways to run Stata on LINCOMM (Linux Community Servers): working in the interactive interface, or running a do-file. Both have a place, but for the real work you came to LINCOMM to do, a do-file is almost always the better choice. This page explains why, and what the batch log file gives you.

The two ways to work

The interactive interface runs one command at a time and shows the result immediately. It's ideal for exploring: looking at a variable, trying a regression, checking a recode before you commit to it.

A do-file is a plain .do file holding the whole analysis. On LINCOMM you run it in batch mode, which writes the output to a log file instead of to the screen:

stata -b do analysis.do

Why a do-file wins for real jobs

Once you know what you want to compute, a do-file beats interactive work for three reasons:

Reproducibility. A do-file is the exact, complete record of what you did. Run it again and you get the same result. Commands typed one at a time are easy to lose track of and hard to trust.
It runs unattended. LINCOMM is for long jobs. A do-file started inside tmux runs to completion on its own, even if your connection drops — you don't have to sit and enter commands. See Keep work running with tmux and How to run and manage jobs on LINCOMM.
It travels. A do-file with relative paths runs unchanged on your computer and on LINCOMM, and you can share it with a colleague. See How to use relative paths in Stata.

The log file is your record

Batch mode (-b) doesn't print to the screen. Instead it writes everything — commands and their output — to a log file named after your do-file, such as analysis.log, in the same folder. This is a feature, not a limitation: the log is a permanent, timestamped record of the run that you can read afterward to confirm what happened and to check for errors. Always look at the log after a batch job to make sure it finished cleanly.

A good working pattern

The two modes work best together. Explore in the interface until you know what you want. As you go, capture the commands that work into your do-file — Stata's Review window makes this easy. When the do-file is complete, run it in batch under tmux for the full job, then read the log. You get the speed of exploration and the reliability of a do-file.

Limitations and trade-offs

The interface is more convenient for open-ended exploration, where you don't yet know your next command. That's exactly what it's for.
Because batch output goes to the log rather than the screen, you won't see problems as they happen. Reading the log after the run is how you catch them.