Updates conditions in other jobs that refer to it.
Not allowed while the job is STARTING or RUNNING; needs write permission.
Older versions: export with autorep -q, insert under the new name, update every dependent's condition, then delete the old job.
✦ Definition~90s read
What is Rename an AutoSys Job (rename_job)?
rename_job is a JIL subcommand (AutoSys Workload Automation 12.0 and later) that renames an existing job of any type, including boxes, and updates the conditions of other jobs that refer to it. The job can't be in STARTING or RUNNING, and you need write permission on it.
★
Insert and delete is moving house without forwarding your mail: the new house is fine, but everyone still writes to the old address.
Plain-English First
Insert and delete is moving house without forwarding your mail: the new house is fine, but everyone still writes to the old address. rename_job sets up the forwarding.
Renaming a box the old way (insert a copy, delete the original) leaves every dependent job waiting for a name that's gone. Since version 12.0, rename_job does it properly.
rename_job
Give the current name and new_name.
rename.jilJIL
1
2
rename_job: FIN_DAILY_BOX
new_name: FIN_EOD_BOX
🎯 Key Takeaway
rename_job + new_name.
What It Updates
Conditions in other jobs that refer to the renamed job are updated to the new name.
verify.shBASH
1
autorep -J RPT_DAILY -q | grep condition
🎯 Key Takeaway
Dependents follow the rename.
Restrictions
The job can't be in STARTING or RUNNING. You need write permission on it.
check.shBASH
1
autorep -J FIN_DAILY_BOX # status must not be ST or RU
🎯 Key Takeaway
Not in ST/RU.
Older Versions
Before 12.0 there's no rename. Export, insert under the new name, update every condition that names the old job, then delete it.
old_way.shBASH
1
2
3
4
5
autorep -J FIN_DAILY_BOX -q > old.jil
# edit the name, load the new job
jil < new.jil
# update each dependent's condition, then:
echo 'delete_box: FIN_DAILY_BOX' | jil
⚠ delete_box
delete_box deletes every job inside the box. Move child jobs first.
🎯 Key Takeaway
Fix dependents before deleting.
● Production incidentPOST-MORTEMseverity: high
Six Jobs Waiting for a Deleted Box
Symptom
The new box ran; six downstream jobs never started.
Assumption
Recreating the box under a new name was the same as renaming it.
Root cause
The dependents' conditions still referenced s(FIN_DAILY_BOX), which no longer existed.
Fix
Updated the six conditions, and adopted rename_job for future renames.
Key lesson
Insert + delete doesn't update dependents.
Use rename_job on 12.0+.
Search for references before deleting a job.
Production debug guideBefore and after2 entries
Symptom · 01
Before
→
Fix
Make sure the job isn't ST or RU; check you have write access.
Symptom · 02
After
→
Fix
autorep -J NEW_NAME -q, and check a dependent's condition shows the new name.
⚙ Quick Reference
4 commands from this guide
File
Command / Code
Purpose
rename.jil
rename_job: FIN_DAILY_BOX
rename_job
verify.sh
autorep -J RPT_DAILY -q | grep condition
What It Updates
check.sh
autorep -J FIN_DAILY_BOX # status must not be ST or RU
Restrictions
old_way.sh
autorep -J FIN_DAILY_BOX -q > old.jil
Older Versions
Key takeaways
1
rename_job on 12.0+.
2
Works on boxes.
3
Updates conditions.
4
Not in ST or RU.
5
Old way leaves dependents broken.
Common mistakes to avoid
2 patterns
×
Insert + delete on 12.0+
Symptom
Dependents never start.
Fix
rename_job.
×
Renaming a running job
Symptom
Rename rejected.
Fix
Wait for it to finish or hold it.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
How do you rename an AutoSys job?
Q01 of 01SENIOR
How do you rename an AutoSys job?
ANSWER
On 12.0+, rename_job with new_name; it updates dependent conditions.