QALTER(1P)

qalter(1P) 💅✨

okay so bestie, welcome to the POSIX Programmer's Manual 🎀 — that's the manual this page lives in. Fold that name in your brain and let's go.

---

PROLOG 🫶

Real talk before we start: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so like, consult the corresponding Linux manual page for details of Linux behavior, bestie), or the interface may not be implemented on Linux at all 🙈.

tl;dr — don't @ me if Linux does its own thing. Check the Linux page. Sometimes it's just... not there. 💀

---

NAME 🌸

qalter — alter batch job ✨

---

SYNOPSIS 🦋

qalter [-a date_time] [-A account_string] [-c interval] [-e path_name]
    [-h hold_list] [-j join_list] [-k keep_list] [-l resource_list]
    [-m mail_options] [-M mail_list] [-N name] [-o path_name]
    [-p priority] [-r y|n] [-S path_name_list] [-u user_list]
    job_identifier...

---

DESCRIPTION 👑

So here's the vibe. The attributes of a batch job are altered by a request to the batch server that manages the batch job. The qalter utility is a user-accessible batch client that requests the alteration of the attributes of one or more batch jobs. It's literally the go-between. The messenger. The main character delivering your little requests. 💌

The qalter utility shall alter the attributes of those batch jobs, and only those batch jobs, for which a batch job_identifier is presented to the utility.

The qalter utility shall alter the attributes of batch jobs in the order in which the batch *job_identifier*s are presented to the utility. No skipping the line, no cutting, it's a queue bestie 🎢

If the qalter utility fails to process a batch job_identifier successfully, the utility shall proceed to process the remaining batch *job_identifier*s, if any. (Not me failing on one and still showing up for the rest. Resilient queen behavior.) 💅

For each batch job_identifier for which the qalter utility succeeds, each attribute of the identified batch job shall be altered as indicated by all the options presented to the utility.

For each identified batch job for which the qalter utility fails, the utility shall not alter any attribute of the batch job. Nope. Not a single one. It's all or nothing, periodt.

For each batch job that the qalter utility processes, the utility shall not modify any attribute other than those required by the options and option-arguments presented to the utility. Stay in your lane, utility. Only touch what you were told to touch. 🧚

The qalter utility shall alter batch jobs by sending a Modify Job Request to the batch server that manages each batch job. At the time the qalter utility exits, it shall have modified the batch job corresponding to each successfully processed batch job_identifier.

An attempt to alter the attributes of a batch job in the RUNNING state is implementation-defined. So like... maybe it works, maybe it doesn't, maybe it does something feral. It depends on the implementation. 🙈

---

OPTIONS ✨

The qalter utility shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines. Rules are rules, bestie, and we follow them. 📜

The following options shall be supported by the implementation:

• -a date_time — Redefine the time at which the batch job becomes eligible for execution. 🕰️

The date_time argument shall be in the same form and represent the same time as for the touch utility. The time so represented shall be set into the Execution_Time attribute of the batch job.

If the time specified is earlier than the current time, the -a option shall have no effect. Like, past you already missed it, so there's nothing to schedule. Nothing happens. No cap.

• -A account_string — Redefine the account to which the resource consumption of the batch job should be charged. 💸

The syntax of the account_string option-argument is unspecified. (Yeah, they just didn't define it. It's giving mystery.)

The qalter utility shall set the Account_Name attribute of the batch job to the value of the account_string option-argument.

• -c interval — Redefine whether the batch job should be checkpointed, and if so, how often. 💾

The qalter utility shall accept a value for the interval option-argument that is one of the following:

• n — No checkpointing is to be performed on the batch job (NO_CHECKPOINT).
• s — Checkpointing is to be performed only when the batch server is shut down (CHECKPOINT_AT_SHUTDOWN).
• c — Automatic periodic checkpointing is to be performed at the Minimum_Cpu_Interval attribute of the batch queue, in units of CPU minutes (CHECKPOINT_AT_MIN_CPU_INTERVAL).
• c=minutes — Automatic periodic checkpointing is to be performed every minutes of CPU time, or every Minimum_Cpu_Interval minutes, whichever is greater. The minutes argument shall conform to the syntax for unsigned integers and shall be greater than zero. (so zero is not it, bestie, must be > 0)

An implementation may define other checkpoint intervals. The conformance document for an implementation shall describe any alternative checkpoint intervals, how they are specified, their internal behavior, and how they affect the behavior of the utility.

The qalter utility shall set the Checkpoint attribute of the batch job to the value of the interval option-argument.

• -e path_name — Redefine the path to be used for the standard error stream of the batch job. 😭

The qalter utility shall accept a path_name option-argument that conforms to the syntax of the path_name element defined in the System Interfaces volume of POSIX.1‐2017, which can be preceded by a host name element of the form hostname:.

If the path_name option-argument constitutes an absolute pathname, the qalter utility shall set the Error_Path attribute of the batch job to the value of the path_name option-argument, including the host name element, if present.

If the path_name option-argument constitutes a relative pathname and no host name element is specified, the qalter utility shall set the Error_Path attribute of the batch job to the value of the absolute pathname derived by expanding the path_name option-argument relative to the current directory of the process that executes the qalter utility. (aka it grows up and becomes absolute, relative to wherever you ran it from)

If the path_name option-argument constitutes a relative pathname and a host name element is specified, the qalter utility shall set the Error_Path attribute of the batch job to the value of the option-argument without expansion. No expansion. It stays exactly as you typed it.

If the path_name option-argument does not include a host name element, the qalter utility shall prefix the pathname in the Error_Path attribute with hostname:, where hostname is the name of the host upon which the qalter utility is being executed. 🖥️✨

• -h hold_list — Redefine the types of holds, if any, on the batch job. The qalter -h option shall accept a value for the hold_list option-argument that is a string of alphanumeric characters in the portable character set. 🔒

The qalter utility shall accept a value for the hold_list option-argument that is a string of one or more of the characters 'u', 's', or 'o', or the single character 'n'. For each unique character in the hold_list option-argument, the qalter utility shall add a value to the Hold_Types attribute of the batch job as follows, each representing a different hold type:

• u — USER
• s — SYSTEM
• o — OPERATOR

If any of these characters are duplicated in the hold_list option-argument, the duplicates shall be ignored. (say it with me: duplicates are ignored, they get no extra meaning) An existing Hold_Types attribute can be cleared by the hold type:

• n — NO_HOLD

The qalter utility shall consider it an error if any hold type other than 'n' is combined with hold type 'n'. Do not do that. That's a whole error.

Strictly conforming applications shall not repeat any of the characters 'u', 's', 'o', or 'n' within the hold_list option-argument. The qalter utility shall permit the repetition of characters, but shall not assign additional meaning to the repeated characters. An implementation may define other hold types. The conformance document for an implementation shall describe any additional hold types, how they are specified, their internal behavior, and how they affect the behavior of the utility.

• -j join_list — Redefine which streams of the batch job are to be merged. The qalter -j option shall accept a value for the join_list option-argument that is a string of alphanumeric characters in the portable character set. 🌊

The qalter utility shall accept a join_list option-argument that consists of one or more of the characters 'e' and 'o', or the single character 'n'.

All of the other batch job output streams specified shall be merged into the output stream represented by the character listed first in the join_list option-argument. First one wins, the rest pile in. Main character stream energy.

For each unique character in the join_list option-argument, the qalter utility shall add a value to the Join_Path attribute of the batch job as follows, each representing a different batch job stream to join:

• e — The standard error of the batch job (JOIN_STD_ERROR).
• o — The standard output of the batch job (JOIN_STD_OUTPUT).

An existing Join_Path attribute can be cleared by the join type:

• n — NO_JOIN

If 'n' is specified, then no files are joined. The qalter utility shall consider it an error if any join type other than 'n' is combined with join type 'n'. Same rule as the holds, bestie. 'n' does not share the aux cord. 🎧

Strictly conforming applications shall not repeat any of the characters 'e', 'o', or 'n' within the join_list option-argument. The qalter utility shall permit the repetition of characters, but shall not assign additional meaning to the repeated characters.

An implementation may define other join types. The conformance document for an implementation shall describe any additional batch job streams, how they are specified, their internal behavior, and how they affect the behavior of the utility.

• -k keep_list — Redefine which output of the batch job to retain on the execution host. 🗂️

The qalter -k option shall accept a value for the keep_list option-argument that is a string of alphanumeric characters in the portable character set.

The qalter utility shall accept a keep_list option-argument that consists of one or more of the characters 'e' and 'o', or the single character 'n'.

For each unique character in the keep_list option-argument, the qalter utility shall add a value to the Keep_Files attribute of the batch job as follows, each representing a different batch job stream to keep:

• e — the standard error of the batch job (KEEP_STD_ERROR) 💜
  • o — the standard output of the batch job (KEEP_STD_OUTPUT) 💜

If you say both 'e' and 'o', then bestie, both files are retained. periodt. And if you've got an existing Keep_Files attribute you wanna wipe? Clear it with the keep type:

• n — NO_KEEP 🚫

If 'n' is specified, no files are retained, at all, none, gone. And here's the thing: qalter shall consider it an error if any keep type other than 'n' gets combined with keep type 'n'. Like, don't do that. 🙈

Strictly conforming applications shall not repeat any of the characters 'e', 'o', or 'n' within the keep_list option-argument. The qalter utility shall permit the repetition of characters, but shall not assign additional meaning to the repeated characters — so typing eee is allowed, it just doesn't mean anything extra. iykyk. An implementation may define other keep types. The conformance document for an implementation shall describe any additional keep types, how they are specified, their internal behavior, and how they affect the behavior of the utility. 📜

---

• -l resource_list — redefine the resources that are allowed or required by the batch job. ✨

The qalter utility shall accept a resource_list option-argument that conforms to the following syntax:

resource=value[,,resource=value,,...]

The qalter utility shall set one entry in the value of the Resource_List attribute of the batch job for each resource listed in the resource_list option-argument. 🫶

Because the list of supported resource names might vary by batch server, the qalter utility shall rely on the batch server to validate the resource names and associated values. See Section 3.3.3, Multiple Keyword-Value Pairs for a means of removing keyword=value (and value@keyword) pairs and other general rules for list-oriented batch job attributes. 👑

• -m mail_options — redefine the points in the execution of the batch job at which the batch server is to send mail about a change in the state of the batch job. 📬

The qalter -m option shall accept a value for the mail_options option-argument that is a string of alphanumeric characters in the portable character set.

The qalter utility shall accept a value for the mail_options option-argument that is a string of one or more of the characters 'e', 'b', and 'a', or the single character 'n'. For each unique character in the mail_options option-argument, the qalter utility shall add a value to the Mail_Users attribute of the batch job as follows, each representing a different time during the life of a batch job at which to send mail: 💌

• e — MAIL_AT_EXIT
• b — MAIL_AT_BEGINNING
• a — MAIL_AT_ABORT

If any of these characters are duplicated in the mail_options option-argument, the duplicates shall be ignored. (not me typing eeeee for fun, it does nothing extra bestie 💀)

An existing Mail_Points attribute can be cleared by the mail type:

• n — NO_MAIL

If 'n' is specified, then mail is not sent, full stop. The qalter utility shall consider it an error if any mail type other than 'n' is combined with mail type 'n'. Strictly conforming applications shall not repeat any of the characters 'e', 'b', 'a', or 'n' within the mail_options option-argument. The qalter utility shall permit the repetition of characters but shall not assign additional meaning to the repeated characters. 🙅

An implementation may define other mail types. The conformance document for an implementation shall describe any additional mail types, how they are specified, their internal behavior, and how they affect the behavior of the utility. 📮

• -M mail_list — redefine the list of users to which the batch server that executes the batch job is to send mail, if the batch server sends mail about the batch job. 🧚

The syntax of the mail_list option-argument is unspecified. If the implementation of the qalter utility uses a name service to locate users, the utility shall accept the syntax used by the name service. 🌈

If the implementation of the qalter utility does not use a name service to locate users, the implementation shall accept the following syntax for user names:

mail_address[,,mail_address,,...]

The interpretation of mail_address is implementation-defined.

The qalter utility shall set the Mail_Users attribute of the batch job to the value of the mail_list option-argument. ✉️

• -N name — redefine the name of the batch job. 🏷️

The qalter -N option shall accept a value for the name option-argument that is a string of up to 15 alphanumeric characters in the portable character set where the first character is alphabetic. (so no starting with a digit, bestie, the first one has to be a letter 👑)

The syntax of the name option-argument is unspecified.

The qalter utility shall set the Job_Name attribute of the batch job to the value of the name option-argument.

• -o path_name — redefine the path for the standard output of the batch job. 🌸

The qalter utility shall accept a path_name option-argument that conforms to the syntax of the path_name element defined in the System Interfaces volume of POSIX.1‐2017, which can be preceded by a host name element of the form hostname:.

• If the path_name option-argument constitutes an absolute pathname, the qalter utility shall set the Output_Path attribute of the batch job to the value of the path_name option-argument.
• If the path_name option-argument constitutes a relative pathname and no host name element is specified, the qalter utility shall set the Output_Path attribute of the batch job to the absolute pathname derived by expanding the path_name option-argument relative to the current directory of the process that executes the qalter utility. 📂
• If the path_name option-argument constitutes a relative pathname and a host name element is specified, the qalter utility shall set the Output_Path attribute of the batch job to the value of the path_name option-argument without any expansion of the pathname. (no expansion, ok? it's staying exactly how you wrote it 💅)
• If the path_name option-argument does not include a host name element, the qalter utility shall prefix the pathname in the Output_Path attribute with hostname: , where hostname is the name of the host upon which the qalter utility is being executed. 🖥️

• -p priority — redefine the priority of the batch job. 🔥

The qalter utility shall accept a value for the priority option-argument that conforms to the syntax for signed decimal integers, and which is not less than -1024 and not greater than 1023.

The qalter utility shall set the Priority attribute of the batch job to the value of the priority option-argument.

• -r y|n — redefine whether the batch job is rerunnable. 🔁
  • If the value of the option-argument is 'y', the qalter utility shall set the Rerunable attribute of the batch job to TRUE.
  • If the value of the option-argument is 'n', the qalter utility shall set the Rerunable attribute of the batch job to FALSE.

The qalter utility shall consider it an error if any character other than 'y' or 'n' is specified in the option-argument. Like, literally anything else and it's over. 🚫

• -S path_name_list — redefine the shell that interprets the script at the destination system. 🐚

The qalter utility shall accept a path_name_list option-argument that conforms to the following syntax:

pathname[@host][,pathname[@host],...]

The qalter utility shall accept only one pathname that is missing a corresponding host name. The qalter utility shall allow only one pathname per named host. 🙌

The qalter utility shall add a value to the Shell_Path_List attribute of the batch job for each entry in the path_name_list option-argument. See Section 3.3.3, Multiple Keyword-Value Pairs for a means of removing keyword=value (and value@keyword) pairs and other general rules for list-oriented batch job attributes. ✨

• -u user_list — redefine the user name under which the batch job is to run at the destination system. 🫶

The qalter utility shall accept a user_list option-argument that conforms to the following syntax:

username[@host][,,username[@host],,...]

The qalter utility shall accept only one user name that is missing a corresponding host name. The qalter utility shall accept only one user name per named host. 💜

The qalter utility shall add a value to the User_List attribute of the batch job for each entry in the user_list option-argument. See Section 3.3.3, Multiple Keyword-Value Pairs for a means of removing keyword=value (and value@keyword) pairs and other general rules for list-oriented batch job attributes. 👑

---

🦋 OPERANDS 🦋

The qalter utility shall accept one or more operands that conform to the syntax for a batch job_identifier (see Section 3.3.1, Batch Job Identifier). 🌈

---

✨ STDIN ✨

Not used. (nothing goes in here bestie, it's giving silence 🤐)

---

🎀 INPUT FILES 🎀

None. 💖

🌸 ENVIRONMENT VARIABLES 🌸

ok so these are the env vars that shall affect how qalter runs, bestie. pay attention 💅

• LANG — gives a default value for all the internationalization variables that are unset or null. (peep the Base Definitions volume of POSIX.1‐2017, Section 8.2, Internationalization Variables for the whole tea on the precedence of internationalization variables used to determine the values of locale categories.)
• LC_ALL — if you set this to a non-empty string value, it overrides the values of all the other internationalization variables. she's the main character fr 👑
• LC_CTYPE — determines the locale for how sequences of bytes of text data get interpreted as characters (like, single-byte vs multi-byte characters in arguments, iykyk).
• LC_MESSAGES — determines the locale that should be used to affect the format and contents of diagnostic messages written to standard error. basically it controls the vibe of your error messages 🫶
• LOGNAME — determines the login name of the user.
• TZ — determines the timezone used to interpret the date-time option-argument. if TZ is unset or null, an unspecified default timezone shall be used. no cap, unspecified. 🙈

---

⚡ ASYNCHRONOUS EVENTS ⚡

Default. that's it. that's the whole section. 💀

---

📤 STDOUT 📤

None. nothing. zero. empty. she gives you nothing on stdout ✨

---

📥 STDERR 📥

The standard error shall be used only for diagnostic messages. only for the drama (the diagnostics). periodt.

---

📁 OUTPUT FILES 📁

None. nada. 🎀

---

🌈 EXTENDED DESCRIPTION 🌈

None. truly nothing here bestie, move along 🦋

---

🚪 EXIT STATUS 🚪

ok so these are the exit values that shall be returned:

• 0 — Successful completion. slay 💖
• >0 — An error occurred. it's giving oops 😭

---

💥 CONSEQUENCES OF ERRORS 💥

So on top of the default behavior, qalter shall not be required to write a diagnostic message to standard error when the error reply received from a batch server indicates that the batch job_identifier doesn't exist on the server. And whether or not qalter even tries to locate the batch job on other batch servers? That's implementation-defined. 🤷

The following sections are informative. (translation: this is the bonus content, the commentary track, the director's cut ✨)

---

🧠 APPLICATION USAGE 🧠

None. 💅

---

🎬 EXAMPLES 🎬

None. i know, i know, we love examples, but there are literally none here 😭

---

📚 RATIONALE 📚

ok bestie this is the why section, the lore drop, let's get into it 🌸

The qalter utility lets users change the attributes of a batch job. simple as that.

As a means of altering a queued job, qalter is superior to deleting and requeuing the batch job, insofar as an altered job retains its place in the queue with some traditional selection algorithms. plus, qalter is both shorter and simpler than a whole sequence of qdel and qsub utilities. like, why do two things when one thing does it better? ✨

Now — the result of a user trying to alter a batch job in a RUNNING state is implementation-defined, because a batch job in the RUNNING state will already have opened its output files and otherwise performed any actions indicated by the options in effect at the time the batch job began execution. so yeah, once she's running, she's running 💀

The options processed by qalter are identical to those of the qsub utility, with a few exceptions: -V, -v, and -q. Here's why:

• -V and -v are inappropriate for qalter, since they capture potentially transient environment information from the submitting process.
• -q would specify a new queue, which would largely negate the previously stated advantage of using qalter; plus, the qmove utility provides a superior means of moving jobs. so like, use qmove for that, bestie 🫶

Each of the following paragraphs provides the rationale for a qalter option. additional rationale concerning these options can be found in the rationale for the qsub utility. iykyk 📖

• The -a option allows users to alter the date and time at which a batch job becomes eligible to run.
• The -A option allows users to change the account that will be charged for the resources consumed by the batch job. Support for the -A option is mandatory for conforming implementations of qalter, even though support of accounting is optional for servers. Whether or not to support accounting is left to the implementor of the server, but mandatory support of the -A option assures users of a consistent interface and allows them to control accounting on servers that support accounting.
• The -c option allows users to alter the checkpointing interval of a batch job. A checkpointing system, which is not defined by POSIX.1‐2008, allows recovery of a batch job at the most recent checkpoint in the event of a crash. Checkpointing is typically used for jobs that consume expensive computing time or must meet a critical schedule. Users should be allowed to make the tradeoff between the overhead of checkpointing and the risk to the timely completion of the batch job; therefore, this volume of POSIX.1‐2017 provides the checkpointing interval option. Support for checkpointing is optional for servers.
• The -e option allows users to alter the name and location of the standard error stream written by a batch job. However, the path of the standard error stream is meaningless if the value of the Join_Path attribute of the batch job is TRUE. (so don't come for her if it does nothing, okay? 🙈)
• The -h option allows users to set the hold type in the Hold_Types attribute of a batch job. The qhold and qrls utilities add or remove hold types to the Hold_Types attribute, respectively. The -h option has been modified to allow for implementation-defined hold types.
• The -j option allows users to alter the decision to join (merge) the standard error stream of the batch job with the standard output stream of the batch job.
• The -l option allows users to change the resource limits imposed on a batch job.
• The -m option allows users to modify the list of points in the life of a batch job at which the designated users will receive mail notification.
• The -M option allows users to alter the list of users who will receive notification about events in the life of a batch job.
• The -N option allows users to change the name of a batch job.
• The -o option allows users to alter the name and path to which the standard output stream of the batch job will be written.
• The -P option allows users to modify the priority of a batch job. Support for priority is optional for batch servers.
• The -r option allows users to alter the rerunability status of a batch job.
• The -S option allows users to change the name and location of the shell image that will be invoked to interpret the script of the batch job. This option has been modified to allow a list of shell name and locations associated with different hosts.
• The -u option allows users to change the user identifier under which the batch job will execute.

The job_identifier operand syntax is provided so that the user can differentiate between the originating and destination (or executing) batch server. These may or may not be the same. The .server_name portion identifies the originating batch server, while the @server portion identifies the destination batch server. 🔍

Historically, the qalter utility has been a component of the Network Queuing System (NQS), the existing practice from which this utility has been derived. a little heritage moment for you 🎀

---

🔮 FUTURE DIRECTIONS 🔮

The qalter utility may be removed in a future version. ⚠️ not to be dramatic but like, heads up.

---

👀 SEE ALSO 👀

• Chapter 3, Batch Environment Services, qdel, qhold, qmove, qrls, qsub, touch
• The Base Definitions volume of POSIX.1‐2017, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines

---

⚖️ COPYRIGHT ⚖️

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the whole page bestie!! 💖✨ this was put out by IEEE/The Open Group back in 2017, and the man page is QALTER(1P). go forth and alter those batch jobs, you absolute icon 👑🦋🎀