Senior 4 min · March 19, 2026

AutoSys run_calendar — Jobs Go Silent When Calendars Expire

Q: How do I create an AutoSys calendar?

Use the autocal_asc command to create, update, and manage calendar definitions. You can run it interactively or redirect a calendar definition file to it. The WCC web interface also has a calendar management section.

Q: What is exclude_calendar in AutoSys?

exclude_calendar specifies dates on which the job should NOT run, even if those dates are in the run_calendar or match days_of_week. It's commonly used to exclude public holidays from a business day schedule.

Q: What happens when both days_of_week and run_calendar are set?

When both are set, the job runs on days that satisfy BOTH conditions — the day must be in the run_calendar AND must be one of the specified days_of_week. This is typically not intended; usually you set one or the other.

Q: Do AutoSys calendars need to be updated each year?

Yes, if you're using standard calendars with explicit date lists, they must be updated to include the new year's dates. Many organisations automate this as an annual administrative task at year-end. Extended calendars (logical rules) never need date updates.

Q: What's the difference between standard and extended calendars?

Standard calendars are explicit date lists (e.g., dates: 20260101, 20260102). Extended calendars are logical rules (e.g., last_weekday_of_month: jan,feb,mar). Extended calendars are more maintainable because they don't require annual updates. Use extended for recurring patterns (month-end, quarter-end), standard for one-off or static date lists.

Static calendars like business_days_2025 have no dates after Dec 31st.

Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Notes here come from systems that actually shipped.

✓ Production

production tested

May 23, 2026

last updated

1,554

articles · all by Naren

● Production Incident 🔎 Debug Guide ⚙ Triage Commands

⚡Quick Answer

AutoSys calendar = named date list for scheduling jobs on business days, holidays, or custom patterns — standard (explicit dates) or extended (logical rules)
Key components: run_calendar (run on these dates), exclude_calendar (skip these dates), autocal_asc (calendar management command)
Performance: Calendar lookup is O(1) hash check per job evaluation; 10,000 jobs with calendars = minimal overhead
Production trap: Calendar with explicit dates not updated at year-end — jobs scheduled on expired calendar never run again
Biggest mistake: Setting both days_of_week AND run_calendar — runs only on intersection (days that satisfy both), often unintended, causes jobs to never run

✦ Definition~90s read

What is AutoSys Calendars and run_calendar?

AutoSys run_calendar is a job attribute that ties a job's execution schedule to a named calendar object, which is essentially a list of specific dates (e.g., business days, holidays, or custom date sets). When you set run_calendar: CALENDAR_NAME on a job, AutoSys only runs that job on dates present in that calendar, regardless of any other scheduling conditions like start_times or days_of_week.

★

AutoSys calendars are custom day lists — like a company holiday calendar for your batch jobs.

The critical trap: if the calendar's date list is empty or has expired — meaning the last date in the list has passed — the job goes completely silent. No alerts, no failures, just zero runs. This is not a cron-like recurrence; it's a date whitelist that can silently go stale.

In the AutoSys ecosystem, run_calendar is often paired with exclude_calendar to subtract dates (e.g., run on business days but exclude holidays). However, priority rules matter: run_calendar takes precedence over exclude_calendar when both are set — meaning if a date is in both calendars, the job runs.

This counterintuitive behavior frequently causes missed exclusions. Standard calendars (defined via autocal_asc or jil) are simple date lists, not dynamic rules like "every third Tuesday" — you must manually update them or use extended calendars for complex logic.

Tools like autocal_show and autocal_edit let you inspect and modify calendars, but many teams forget to audit them, leading to the expiry trap.

Real-world impact: A job with run_calendar: LAST_DAY_OF_QUARTER that was last updated in 2022 will never run again after that date passes. Unlike cron, which fails loudly on invalid syntax, AutoSys silently skips the job. This is why run_calendar is best for finite, date-specific schedules (e.g., "run on 2024-12-25") rather than recurring patterns — use days_of_week or start_mins for that.

When you need a calendar that expires, pair it with a monitoring job that checks autocal_show output and alerts if the calendar is empty or past its last date.

Plain-English First

AutoSys calendars are custom day lists — like a company holiday calendar for your batch jobs. Instead of just 'run on weekdays', you can say 'run on every business day that isn't a public holiday or month-end close' — and AutoSys handles the date logic for you.

Time-based scheduling with days_of_week covers most simple cases, but enterprise batch processing often needs more nuanced scheduling. Month-end jobs that only run on the last business day. Jobs that must skip public holidays. Quarter-end runs. AutoSys calendars solve exactly this.

There are two calendar types: standard calendars (a list of dates) and extended calendars (built from logical rules). Both are defined using the autocal_asc command or through the WCC UI.

But calendars are dangerous. A calendar with explicit dates for 2025 will stop working on January 1, 2026. Jobs that depend on it will never run again. The intersection between days_of_week and run_calendar is another trap — if you set both, the job runs only on days that satisfy BOTH conditions, which is rarely what you intend.

By the end you'll know exactly how to create and manage calendars, use run_calendar and exclude_calendar correctly, avoid the year-end trap, and debug why a job isn't running on days you expect it to.

How run_calendar Silences Jobs When It Expires

run_calendar is a named calendar object in AutoSys that defines a set of dates on which a job is allowed to run. When attached to a job definition via the run_calendar attribute, the job will only execute if the current date is included in that calendar. The core mechanic: calendars are evaluated at job start time, and if the date is not in the calendar, the job is skipped — it does not fail, it simply does not start. This is a binary gate: present in calendar → runs; absent → silent skip.

Calendars are typically defined as a list of specific dates (e.g., '2025-01-01', '2025-01-15') or as a repeating pattern (e.g., 'every Monday'). The critical property: calendars have an end date. Once the last defined date passes, the calendar is effectively expired. Any job referencing an expired calendar will never run again, because no future date will ever match. AutoSys does not warn or alert on this condition — the job simply stops starting. The job status remains INACTIVE or SUCCESS, with no error code.

Use run_calendar when you need to restrict job execution to specific business days, holidays, or maintenance windows. It is essential for batch processing that must only run on certain days (e.g., month-end reports, quarterly payroll). The danger: teams often set calendars with a fixed end date and forget to extend them. When the calendar expires, the job goes silent — no alerts, no failures, just a gap in processing that may go unnoticed until a downstream system breaks.

Expired Calendar = Silent Job Death

An expired run_calendar does not produce any alert or job failure. The job simply stops starting — and no one gets notified.

Production Insight

A financial firm's month-end reconciliation job stopped running for three months because the run_calendar had an end date of 2024-12-31 and was never updated for 2025.

Symptom: The job status showed 'SUCCESS' (last run in December), no new runs appeared, and downstream reports were missing data — but no alarms fired.

Rule of thumb: Always set calendar end dates at least one year in the future, and add a monitoring job that checks if any calendar's end date is within the next 90 days.

Key Takeaway

run_calendar is a date gate — if the date isn't in the calendar, the job doesn't run, no error.

An expired calendar is invisible: the job stays in its last state, no alert, no failure.

Always monitor calendar expiration dates separately — do not rely on job failure alerts to catch this.

thecodeforge.io

Calendar-Based Scheduling

Autosys Calendars Run Calendar

Standard calendars — a list of dates

A standard calendar is simply a named list of dates. Jobs with run_calendar: your_calendar_name will run on those dates and only those dates.

io/thecodeforge/autosys/create_calendar.shBASH

# Create a standard calendar using autocal_asc (interactive or file mode)
autocal_asc << 'EOF'
insert_calendar: business_days_2026
calendar_type: standard
dates: 20260102, 20260105, 20260106, 20260107, 20260108, 20260109
/* ... continuing for all business days in 2026 ... */
EOF

# Create a holiday exclusion calendar
autocal_asc << 'EOF'
insert_calendar: uk_public_holidays_2026
calendar_type: standard
dates: 20260101, 20260403, 20260406, 20260504, 20260525, 20260831, 20261225, 20261228
EOF

Production Insight

Standard calendars with explicit dates are simple but require annual maintenance. Date lists must be sorted and contain no duplicates.

For large calendars (all business days of the year), creating them manually is error-prone. Automate generation with a script that calculates dates from business rules.

Rule: For long-term maintainability, use extended calendars (calendars built from logical rules like 'last business day of month') instead of explicit date lists.

Key Takeaway

Standard calendars are explicit date lists. Simple to understand but require annual updates.

Use extended calendars (logical rules) for dynamic date patterns like 'last business day of month'.

Rule: Automate calendar generation with scripts. Never maintain 365-date calendars by hand.

Using run_calendar and exclude_calendar

Once calendars are defined, apply them to jobs with run_calendar (run on these days) and exclude_calendar (don't run on these days).

io/thecodeforge/autosys/calendar_job.jilBASH

/* Run on all business days in 2026, but skip UK public holidays */
insert_job: daily_settlement
job_type: CMD
command: /scripts/settlement.sh
machine: finance-server
owner: finuser
date_conditions: 1
start_times: "18:00"
run_calendar: business_days_2026
exclude_calendar: uk_public_holidays_2026

/* Month-end job: runs only on last business day of each month */
insert_job: month_end_close
job_type: CMD
command: /scripts/month_end.sh
machine: finance-server
owner: finuser
date_conditions: 1
start_times: "20:00"
run_calendar: month_end_2026

Calendars need to be updated annually

Standard calendars with explicit dates need to be refreshed each year. Most enterprises have an automated process or a dedicated admin task to update business day and holiday calendars at the start of each year.

Production Insight

exclude_calendar overrides run_calendar. A date in exclude_calendar will never run, regardless of run_calendar.

When both run_calendar and days_of_week are set, the job runs only on the INTERSECTION (dates that satisfy both). This is rarely intended.

Rule: Use run_calendar OR days_of_week, never both. If you need both, it usually means your calendar logic is wrong.

Key Takeaway

run_calendar specifies which days to run; exclude_calendar skips specific dates (e.g., holidays).

exclude_calendar overrides run_calendar. A date in exclude_calendar never runs.

Rule: Avoid setting both days_of_week and run_calendar — the job runs only on the intersection, which is rarely intended.

Viewing and managing existing calendars

You can query, list, and report on existing calendars using autocal_asc in report mode. This is useful when you need to audit which jobs are using which calendars, or verify a calendar's dates before a major batch run.

io/thecodeforge/autosys/manage_calendars.shBASH

# List all calendars in the AutoSys instance
autocal_asc -r %

# View dates in a specific calendar
autocal_asc -r business_days_2026

# Delete an obsolete calendar
autocal_asc << 'EOF'
delete_calendar: old_2025_holidays
EOF

# Find all jobs using a specific calendar
autorep -J % -q | grep -B5 'run_calendar: business_days_2026'

Calendar names are case-sensitive

If you define a calendar as 'Business_Days_2026' but reference it in JIL as 'business_days_2026', AutoSys won't find it. Keep calendar names lowercase with underscores to match standard JIL naming conventions.

Production Insight

autocal_asc -r % lists all calendars, but doesn't show which jobs use them. Use autorep -J % -q to find jobs referencing a calendar.

Audit quarterly: list calendars and check for any with year-old dates (e.g., 2025 calendars in 2026). These should be archived.

Rule: Implement a weekly job that runs autorep -J % -q | grep run_calendar | grep 2025 to alert on expired calendars before they cause job failures.

Key Takeaway

autocal_asc -r lists calendars and their dates. Use it to verify calendar contents before batch runs.

autorep -J % -q finds jobs using a specific calendar; essential for impact analysis before deleting a calendar.

Rule: Calendar names should be lowercase with underscores. Case-sensitivity is a common source of 'calendar not found' errors.

Why Run_Calendar Is Not a Cron — The Expiry Trap

Every junior thinks a run_calendar is just a fancy cron. It's not. A cron keeps running until you kill it. A run_calendar has an expiry date baked into its definition. When that date passes, the calendar is dead. Jobs tied to it stop running. No warning. No email. Just silence.

Here's the WH: Autosys calendars are time-boxed by design. They're meant for maintenance windows, project timelines, seasonal batches. Not perpetual schedules. If you use a run_calendar for something that should run forever, you will get paged at 3 AM when the expiry creeps up on you.

How do you check? Run autocal_asc -q <calendar_name> and look for start_date and end_date. If end_date is yesterday, your calendar is a ghost. The job definition still exists. The calendar still exists. But Autosys evaluates the run_calendar against the current date, finds it expired, and skips the job. This is not a bug. It is the feature that will bite you if you don't respect it.

expiry_check.ymlYAML

// io.thecodeforge — devops tutorial
// Check expiry on a run_calendar
// Production: PAYROLL_CLOSE_CAL

autocal_asc -q PAYROLL_CLOSE_CAL

// Output:
// Calendar: PAYROLL_CLOSE_CAL
// Type: RUN
// Start Date: 01-JAN-2024
// End Date: 31-DEC-2024
// Frequency: MONTHLY
// Day/Week: 28
// Condition: LAST_WORKDAY

// Notice: end_date is DEC-31-2024
// If today is 2025-01-15, this calendar is dead.
// Jobs using it: they will NOT fire.

Output

Calendar: PAYROLL_CLOSE_CAL

Type: RUN

Start Date: 01-JAN-2024

End Date: 31-DEC-2024

Frequency: MONTHLY

Day/Week: 28

Condition: LAST_WORKDAY

Production Trap:

Never use run_calendar for evergreen processes (heartbeats, data syncs). Use 'every' syntax in the job definition instead. Run_calendar should only gate jobs that have a finite lifecycle.

Key Takeaway

A run_calendar with a past end_date is a dead calendar — jobs referencing it silently stop. Always check end_date before troubleshooting missed runs.

How Run_Calendar Eats Exclude_Calendar — Priority Pitfalls

Exclude_calendar sounds simple: blackout dates. But there's a nasty interaction when you combine it with run_calendar. Autosys evaluates both. The rule: if the current date matches run_calendar AND does NOT match exclude_calendar, the job runs. If both match, exclude wins. That's the theory.

Here's the WHY: People assume exclude_calendar is an override. It is, but only if Autosys reaches that evaluation. If the run_calendar is empty (no dates defined) or expired, Autosys never even checks exclude_calendar. The job simply doesn't trigger. You think you excluded the date. Reality: the run_calendar never included today.

Second pitfall: overlapping calendars. If run_calendar says "last Friday of every month" and exclude_calendar says "Dec 25", but Dec 25 happens to be the last Friday, Autosys will skip it. That's correct. But if you updated exclude_calendar but forgot to update run_calendar's end_date, the exclusion is meaningless. Check both. Every time.

Third: exclude_calendar can't compensate for a broken run_calendar. If run_calendar is misconfigured (e.g., wrong weekday), no amount of excludes will fix it. The logic is AND-based, not OR.

priority_showdown.ymlYAML

// io.thecodeforge — devops tutorial
// Show exclusion override
// Production: BILLING_RUN_CAL + HOLIDAY_EXCLUDE

autocal_asc -q BILLING_RUN_CAL
// Last Friday each month, ends Dec 2025

autocal_asc -q HOLIDAY_EXCLUDE
// Dec 25, 2025 is a Friday

// Job: BILLING_CYCLE
// run_calendar: BILLING_RUN_CAL
// exclude_calendar: HOLIDAY_EXCLUDE
// Condition: Dec 25, 2025 → matches run, also matches exclude
// Result: JOB SKIPPED

// BUT if BILLING_RUN_CAL end_date was Dec 2024
// On Dec 25, 2025: run_calendar is expired
// Job does not trigger AT ALL
// Exclude is irrelevant

Output

Job: BILLING_CYCLE

Date: 25-DEC-2025

Matched run_calendar: YES (last Friday)

Matched exclude_calendar: YES (holiday)

Final decision: SKIP

If run_calendar had expired:

Matched run_calendar: NO (expired)

Exclude not evaluated

Final decision: SKIP (silent)

Senior Shortcut:

Audit both calendars together: autocal_asc -q <run_cal> and autocal_asc -q <exclude_cal> in the same session. If run_cal is expired or returns empty, exclude_cal is lying dead in the config. Fix the run_cal first.

Key Takeaway

Exclude_calendar only matters if run_calendar first says 'yes'. An expired or empty run_calendar makes exclude_calendar useless — the job never runs either way.

● Production incidentPOST-MORTEMseverity: high

The Calendar That Died on December 31st

Symptom

The monthly reconciliation job normally ran on the first business day of every month. On January 2, 2026 (first business day of the year), the job remained INACTIVE. autorep showed the job with run_calendar: business_days_2025. The operator assumed the job was ON_HOLD or had a condition issue. After 2 hours of checking dependencies, they realised the calendar name itself was year-specific.

Assumption

The team assumed that 'business_days_2025' was a dynamic calendar that updated automatically. They didn't know that standard calendars are static date lists that must be manually refreshed. The previous admin had left the company 6 months ago, and no one knew the calendar needed annual maintenance. The team also didn't have monitoring for calendar expiry.

Root cause

The calendar business_days_2025 was created as a standard calendar with explicit dates for 2025. On January 1, 2026, the calendar had no dates. The job's date condition checked the run_calendar, found no match, and remained INACTIVE. No alarm fired because the job didn't fail — it just never started. The team had no automated process to update calendars annually. The calendar naming convention included the year, but no reminder or audit existed to create business_days_2026 before January 1.

Fix

1. Created new calendar business_days_2026 with 2026 business dates. 2. Updated job JIL: update_job: monthly_recon run_calendar: business_days_2026. 3. Automated calendar creation: added a scheduled AutoSys job that runs on December 15 each year to create next year's business day calendar using a script that calculates business dates (excluding weekends and holidays). 4. Added a monitoring alert: weekly check for any job with run_calendar containing previous year's dates, flagging them for review. 5. Changed naming convention to business_days (without year) for dynamic calendars using extended calendar logic (when available).

Key lesson

Standard calendars are static date lists. They do not auto-update. You must refresh them annually.
Calendar names with years (e.g., business_days_2025) are a ticking time bomb. Use year-less names and update the calendar content, not the name.
A job that never starts is worse than a job that fails — there's no alarm, no error log, just silence.
Automate calendar creation before year-end. A scheduled job that runs in December can create next year's calendars automatically.

Production debug guideSymptom → Action mapping for common calendar failures in production AutoSys environments.5 entries

Symptom · 01

Job not running on expected date — status INACTIVE, no failure

→

Fix

Check run_calendar: does it include today's date? autorep -J job_name -d | grep run_calendar. Then verify calendar contents: autocal_asc -r calendar_name. If calendar is year-specific (e.g., 2025), it may have expired.

Symptom · 02

Job runs on holiday when it should skip

→

Fix

Check exclude_calendar: is holiday calendar applied? autorep -J job_name -d | grep exclude_calendar. Verify exclude_calendar contains the holiday date: autocal_asc -r exclude_calendar_name.

Symptom · 03

Job runs on weekend but should only run weekdays

→

Fix

Check if run_calendar includes weekends. Verify calendar definition. Also check if days_of_week is set — if both run_calendar and days_of_week are set, job runs on intersection, not union.

Symptom · 04

Calendar creation fails — autocal_asc errors

→

Fix

Check for duplicate calendar name: autocal_asc -r calendar_name. Ensure date format is YYYYMMDD. For standard calendars, dates must be sorted. Check for trailing commas in date list.

Symptom · 05

Job runs but shouldn't — calendar logic wrong

→

Fix

Verify run_calendar and exclude_calendar combination. A date in exclude_calendar overrides run_calendar. Check if exclude_calendar is empty (no dates). Ensure calendar names are case-sensitive and spelled correctly in JIL.

★ Calendar Debug Cheat SheetFast diagnostics for calendar issues in production AutoSys environments.

Job not running on expected date — INACTIVE−

Immediate action

Check if run_calendar contains today's date

Commands

autorep -J job_name -d | grep -E 'run_calendar|exclude_calendar'

autocal_asc -r $(autorep -J job_name -q | grep run_calendar | awk '{print $2}')

Fix now

If calendar expired (no dates for current year), create new calendar with current year dates and update job. Or use extended calendar with business day logic.

Job runs on holiday — expected skip+

Job runs on weekend — unexpected+

autocal_asc error 'Duplicate date'+

Calendar not found — JIL error on update+

AutoSys Scheduling Methods

Scheduling Method	Use When...	Attributes Used	Maintenance Burden	Example
days_of_week	Simple day-of-week rules (every weekday, every weekend)	days_of_week: mon-fri	Low (no annual updates)	Run every weekday
run_calendar	Custom date lists (business days, month-end, quarter-end)	run_calendar: calendar_name	High (requires annual calendar updates)	Run only on last business day of month
exclude_calendar	Skip specific dates (public holidays)	exclude_calendar: calendar_name	Medium (update holiday list annually)	Run business days except holidays
Both run_calendar + exclude_calendar	Business days minus holidays	run_calendar + exclude_calendar	High (both calendars need updates)	Run business days, skip Christmas
Extended calendar (logical rules)	Dynamic date patterns (last weekday of month, nth day of month)	calendar_type: extended	Low (rules are static, no date updates)	Last business day of each month

Key takeaways

AutoSys calendars are named date lists that let you schedule jobs on business days, holidays, or any custom date pattern.

Use run_calendar to specify which days to run; use exclude_calendar to skip specific dates like public holidays.

Calendars are created and managed with the autocal_asc command.

Standard calendars with explicit dates must be updated annually

automate this process to avoid job failures.

Never set both days_of_week and run_calendar on the same job

they intersect, not union, leading to unexpected missing runs.

Common mistakes to avoid

5 patterns

Not updating standard calendars at year-end — jobs stop running

Symptom

Job remains INACTIVE on first business day of new year. autorep shows run_calendar with previous year. No alarm, no failure — just silence.

Fix

Automate calendar creation: scheduled job that runs in December to create next year's calendars. Use extended calendars (logical rules) instead of explicit date lists where possible. Add monitoring for calendars with expired dates.

Setting both days_of_week AND run_calendar on same job

Symptom

Job runs on fewer days than expected. Example: run_calendar includes Monday, days_of_week: mon-fri — job runs on Monday only. Operator assumes calendar logic is wrong.

Fix

Use run_calendar OR days_of_week, never both. If you need both, it usually means your calendar logic should incorporate the day-of-week rule (create a calendar that already excludes weekends).

Forgetting to create exclude_calendar before referencing it in JIL

Symptom

Job fails with error 'Calendar calendar_name not found' when inserting or updating. The JIL references a calendar that doesn't exist yet.

Fix

Always create calendars before referencing them in job definitions. Order of operations: autocal_asc first, then jil insert/update. Use version control for calendar definitions.

Using standard calendars where extended calendars would be more maintainable

Symptom

Team spends days each year manually updating 500-date business calendars. Errors common, missing dates cause job failures.

Fix

Use extended calendars for logical rules: 'last business day of month', 'first Monday of month', etc. These never need date updates. Reserve standard calendars for truly one-off date lists.

Case mismatch between calendar definition and run_calendar attribute

Symptom

Job fails with 'Calendar Business_Days not found' even though calendar exists as 'business_days'. Calendar names are case-sensitive in AutoSys.

Fix

Adopt a naming convention: all lowercase, underscores for spaces. Use autocal_asc -r % to see exact case of existing calendars. Copy-paste calendar name into JIL.

INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01JUNIOR

What is a run_calendar in AutoSys?

Q02JUNIOR

What is the difference between run_calendar and exclude_calendar?

Q03SENIOR

How do you create a calendar in AutoSys?

Q04SENIOR

What is the autocal_asc command used for?

Q05SENIOR

What happens if both days_of_week and run_calendar are set on a job?

Q01 of 05JUNIOR

What is a run_calendar in AutoSys?

ANSWER

run_calendar is a job attribute that specifies a named AutoSys calendar. The job will only run on the dates defined in that calendar, rather than using the standard days_of_week scheduling. Calendars can be standard (explicit date list) or extended (logical rules like 'last business day of month'). When run_calendar is set, the job ignores days_of_week. A date in exclude_calendar overrides run_calendar — the job will not run even if the date is in run_calendar.

FAQ · 6 QUESTIONS

Frequently Asked Questions

What is run_calendar in AutoSys?

How do I create an AutoSys calendar?

What is exclude_calendar in AutoSys?

What happens when both days_of_week and run_calendar are set?

Do AutoSys calendars need to be updated each year?

What's the difference between standard and extended calendars?

COMPLETE GUIDE

The Complete AutoSys Workload Automation Guide for Engineers →

JIL syntax, sendevent, autorep, box jobs, file watchers, scheduling, HA, security, cloud workload automation, and 22 interview questions — the definitive AutoSys reference for production engineers.

Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Notes here come from systems that actually shipped.

✓ Verified

production tested

May 23, 2026

last updated

1,554

articles · all by Naren

🔥

That's AutoSys. Mark it forged?

4 min read · try the examples if you haven't