Skip to main content
Do checkout my poem section. You are going to love it.

Scheduling jobs in SM36

Scheduling Jobs in SM36 in SAP BASIS

I. What is SM36 and Background Jobs?

  • SM36 (Define Background Job): The primary transaction in SAP for creating, scheduling, and defining background jobs.
  • Background Job: A program or series of programs that run in the SAP system without direct user interaction (i.e., in the "background").
    • Purpose: Ideal for long-running, resource-intensive, or regularly scheduled tasks that don't require immediate user feedback.
    • Examples: Batch input processing, data archiving, report generation, system cleanup, data transfers, interface processing, EWA data collection (SDCCN), index rebuilds, statistics updates, security audits.

II. Components of a Background Job

A background job in SAP typically consists of the following key elements:

  1. Job Name: A unique, descriptive name for the job (e.g., Z_HR_PAYROLL_PROCESS, SAP_REORG_JOBS).
  2. Job Class: Priority of the job, influencing which work processes execute it.
    • Class A (High Priority): Few, critical jobs. Should have dedicated background work processes.
    • Class B (Medium Priority): Most business-critical jobs.
    • Class C (Low Priority): Non-critical, cleanup, long-running jobs.
  3. Job Steps: The actual programs or commands that the job executes. A job can have one or more steps.
    • ABAP Program: Most common. Executes a standard or custom ABAP report (via its program name).
    • External Program: Executes an external command or script on the operating system level (e.g., LS, CP, custom shell scripts).
    • External Command: Executes a predefined OS command.
  4. Variant: For ABAP programs, a variant saves a specific set of input parameters for the program. This allows the same program to be run with different inputs.
  5. Start Condition: Defines when the job should run.
    • Immediate: Runs as soon as it's saved.
    • Date/Time: Runs once at a specific date and time. Can be periodic.
    • After Job: Runs only after a specified preceding job finishes successfully.
    • After Event: Runs when a specific SAP event is triggered (e.g., SAP_END_OF_JOB, custom events).
    • At Operation Mode: Runs when a specific SAP operation mode (defined in RZ04) starts.
    • Factory Calendar: Can be linked to a factory calendar to skip non-working days.
  6. Target Server: Specifies which application server (or server group) the job should run on.
    • If left blank, any available background work process on any application server can pick up the job.
    • Useful for load balancing or ensuring jobs run on specific, powerful servers.
  7. Spool List Recipient: Defines where the job's output (spool list) should be sent (e.g., email address, specific printer).
  8. Periodicity: For recurring jobs (daily, weekly, monthly, hourly, others).

III. Step-by-Step Job Scheduling in SM36

  1. Enter Transaction SM36:
  2. Define Job:
    • Enter a Job Name (max 32 chars, recommended prefix with Z or Y for custom).
    • Enter Job Class (A, B, or C).
    • Enter a short Job Description.
    • Spool Recipient: Optional. Enter a user ID or distribution list.
  3. Define Job Steps:
    • Click Steps button.
    • Click ABAP Program (or External Program/Command).
    • Enter Program Name (e.g., RSPO_SPOOLDATA_CONSISTENCY, RSPOR_CLEANUP_JOB).
    • Enter Variant name. If no variant exists, click Maintain Variant to create/select one. For cleanup jobs, often "SAP&STANDARD" or a custom one.
    • Enter User (the user context under which the program will run; usually a technical/batch user like SAP_BATCH, DDIC, or a specific interface user). This user needs the necessary authorizations to run the program.
    • Click Check to verify program/variant.
    • Click Save to add the step. Repeat for multiple steps.
    • Click Back.
  4. Define Start Condition:
    • Click Start Condition button.
    • Choose one of the options:
      • Immediate: Check "Start immediately". You can then Check and Save.
      • Date/Time: Enter desired Start Date and Start Time.
        • To make it periodic, click Periodic Job and choose Hourly, Daily, Weekly, Monthly, Other Period. Specify the period and click Save.
        • To restrict to specific days of the week, use Restrictions button.
        • Factory Calendar: Optional, to skip non-working days.
      • After Job: Enter the Job name of the preceding job. You can select Start when previous job has finished (on success) or Start when previous job has finished with status 'canceled'.
      • After Event: Enter Event name and Event parameter (optional).
      • At Operation Mode: Select the Operation Mode.
    • Click Check and Save.
  5. Define Target Server (Optional but Recommended for Load Balancing):
    • Click Target Server button.
    • Enter the specific application server name (e.g., sapprd_PRD_00).
    • Click Save.
  6. Save the Job:
    • Click Save on the main SM36 screen.
    • The job status will change to Released. It will then be picked up by an available background work process based on its start condition and class.

IV. Important Configuration to Keep in Mind

  1. Job Variants:
    • Always use meaningful variants for ABAP programs. Avoid &DEFAULT for critical jobs as it can change.
    • Variants save input parameters; ensure they are correct for the job's purpose.
    • Maintain variants using SE38 (program name -> Variants -> Display/Change).
  2. Job User Authorizations:
    • The user specified in the job step must have all necessary authorizations (S_PROGRAM, S_RFC, S_TABU_DIS, application-specific objects) to execute the program and access required data.
    • Using DDIC or SAP_BATCH for all jobs is a security risk. Create specific technical users for different job categories.
    • If a job fails with Authorization Error, check SU53 for the job user or perform an ST01 trace.
  3. Job Classes (A, B, C):
    • Work Process Allocation: Ensure sufficient background work processes are configured (RZ04 / SM50 -> Operations -> Administration -> Parameters -> Display) for each class. Class A jobs often have dedicated work processes.
    • Performance: Misuse of Class A (too many Class A jobs) can lead to system performance degradation for other critical background jobs.
    • Priority: Class A jobs are prioritized over B, B over C.
  4. Target Server (Load Balancing & Resource Allocation):
    • If a job is very resource-intensive, assign it to a server with high capacity or dedicated background work processes.
    • For high availability, avoid assigning critical jobs to a single server that might go down. Consider using server groups (SM61).
    • Leaving it blank allows any server to execute, which is good for general load balancing, but might lead to unpredictable execution times for critical jobs.
  5. Event-Based Scheduling:
    • Highly flexible and efficient for dependent jobs (e.g., job B runs only after job A creates a file).
    • Events are raised via SAP_CREATE_EVENT in ABAP or BTCTRNS1 from OS level.
    • Monitor events using SM64.
  6. External Commands/Programs:
    • Security Risk: These can be very powerful and are a potential security loophole if not managed carefully.
    • SM69: External OS commands must be defined and authorized in SM69.
    • User/Permissions: The OS user context under which the SAP Host Agent (or Gateway process) runs must have permissions to execute the external command/script on the OS level.
  7. Job Naming Convention:
    • Use a clear and consistent naming convention (e.g., Z_<Module>_<Function>_<Frequency>, SAP_REORG_JOB_DAILY). Makes monitoring and troubleshooting easier.
  8. Spool List Management:
    • Configure spool recipients for critical jobs.
    • Implement spool cleanup jobs (RSPO_SPOOLDATA_CONSISTENCY, RSPO0041) to prevent excessive spool growth.
  9. Job Dependencies and Chains:
    • For complex chains, After Job is useful. For more advanced dependencies, consider SAP Process Orchestration (PO) or third-party schedulers (like Redwood Cronacle, UC4/Autosys) which integrate with SAP.
  10. Monitoring and Alerting:
    • Regularly monitor job status using SM37 (Job Overview).
    • Set up alerts for job failures/cancellations (e.g., via Solution Manager, CCMS alerts).
    • Check system logs (SM21) and short dumps (ST22) for job-related errors.
  11. Job Cleanup:
    • Schedule SAP_REORG_JOBS (program RSBTCDEL2) regularly to delete old job logs, keeping the database tidy and improving SM37 performance.
    • Schedule SAP_REORG_SPOOLS (program RSPO0041) for spool cleanup.
  12. Background Work Process Configuration:
    • Adjust the number of background work processes (rdisp/wp_no_btc) in RZ10 based on system load and job requirements.
    • Consider dedicating specific application servers for background processing in operation modes (RZ04).

30 Interview Questions and Answers (One-Liner) for Scheduling Jobs in SM36

  1. Q: What is the main transaction code for scheduling background jobs in SAP?
    • A: SM36.
  2. Q: What is the purpose of a background job?
    • A: To execute programs without direct user interaction for long-running or scheduled tasks.
  3. Q: Name the three job classes in SAP.
    • A: Class A (High), Class B (Medium), Class C (Low).
  4. Q: Which job class has the highest priority?
    • A: Class A.
  5. Q: What is a "Job Step"?
    • A: An individual program or command executed within a background job.
  6. Q: Name three types of job steps.
    • A: ABAP Program, External Program, External Command.
  7. Q: What is a "Variant" in the context of an ABAP program job step?
    • A: A saved set of input parameters for an ABAP program.
  8. Q: Which transaction is used to maintain ABAP program variants?
    • A: SE38.
  9. Q: Name three types of job start conditions.
    • A: Immediate, Date/Time, After Job, After Event, At Operation Mode.
  10. Q: How do you make a job run periodically (e.g., daily)?
    • A: By selecting the Periodic Job option in Date/Time start condition.
  11. Q: What is the purpose of specifying a "Target Server" for a job?
    • A: To run the job on a specific application server for load balancing or resource allocation.
  12. Q: What is the status of a job after it is saved in SM36?
    • A: Released.
  13. Q: What is the transaction code to monitor background jobs?
    • A: SM37.
  14. Q: What should be done if a job fails due to an authorization error?
    • A: Check SU53 for the job user or run ST01 trace.
  15. Q: Which transaction defines external OS commands in SAP?
    • A: SM69.
  16. Q: What is the program used to delete old job logs?
    • A: RSBTCDEL2 (Job SAP_REORG_JOBS).
  17. Q: What is the program used to delete old spool requests?
    • A: RSPO0041 (Job SAP_REORG_SPOOLS).
  18. Q: How can you trigger a job after a specific event occurs?
    • A: Use the After Event start condition.
  19. Q: Which transaction shows current work process distribution?
    • A: SM50 or SM66.
  20. Q: What is the typical user context for a background job?
    • A: A dedicated technical/batch user (e.g., SAP_BATCH).
  21. Q: What is the risk of using DDIC for all background jobs?
    • A: Major security risk due to excessive authorizations.
  22. Q: What happens if a job's target server is down?
    • A: The job will remain in Released status until the server is up, or might be picked by another server if no specific target is set.
  23. Q: What is a Job Chain?
    • A: A sequence of dependent jobs, often linked using "After Job" start conditions.
  24. Q: How can you create a job that runs on non-working days specified in a calendar?
    • A: Link the job's periodic start condition to a Factory Calendar.
  25. Q: What does it mean if a job is in Scheduled status?
    • A: It's defined but no start condition has been fully specified yet.
  26. Q: Where can you define SAP operation modes?
    • A: RZ04.
  27. Q: What is the maximum length of a job name in SM36?
    • A: 32 characters.
  28. Q: What is the purpose of a Spool List Recipient?
    • A: To send the job's output (spool) to a user or printer.
  29. Q: How can you manually release a job that is in Scheduled status?
    • A: Go to SM37, select the job, and click Job -> Release (or define Immediate start condition).
  30. Q: What is a common pitfall when assigning too many jobs to Class A?
    • A: It can lead to performance degradation for other background jobs as Class A monopolizes work processes.

5 Scenario-Based Hard Questions and Answers for Scheduling Jobs in SM36

  1. Scenario: A critical daily reconciliation report (ABAP program ZFI_RECON_DAILY) needs to run every night at 02:00 AM. This report generates a large spool list that must be automatically emailed to the Finance team (FIN_DIST_LIST) upon completion, regardless of success or failure. The job is CPU-intensive and should ideally run on a specific application server, APPSERV_PRD_01, which has dedicated background work processes.

    • Q: Detail the exact steps and specific configurations you would make in SM36 to schedule this job to meet all requirements. Assume the variant DAILY_RUN already exists for ZFI_RECON_DAILY.
    • A:
      1. Go to SM36: Enter transaction SM36.
      2. Define Job Attributes:
        • Job Name: Z_FI_RECON_DAILY_REPORT (or similar descriptive name).
        • Job Class: A (High Priority, due to criticality and CPU intensity).
        • Job Description: "Daily Finance Reconciliation Report - Email to FIN team".
        • Spool Recipient: Enter FIN_DIST_LIST (assuming this is an SAP user distribution list or a single user ID).
      3. Define Job Step:
        • Click Steps button.
        • Click ABAP Program.
        • Program Name: ZFI_RECON_DAILY.
        • Variant: DAILY_RUN.
        • User: SAP_BATCH_FI (assuming a dedicated technical user for Finance jobs exists and has authorizations for ZFI_RECON_DAILY).
        • Click Check, then Save. Click Back.
      4. Define Start Condition (Date/Time & Periodic):
        • Click Start Condition button.
        • Select Date/Time.
        • Date: Enter today's date (or tomorrow's date if scheduling for the first time).
        • Time: Enter 02:00:00.
        • Check Periodic Job.
        • Click Periodic Values button. Select Daily.
        • Click Save. Click Check and Save.
      5. Define Target Server:
        • Click Target Server button.
        • Enter APPSERV_PRD_01.
        • Click Save.
      6. Final Save:
        • Click Save on the main SM36 screen.
        • The job status will become Released.

  2. Scenario: A background job (SAP_ARCHIVE_DATA) that archives old sales order data has been running in Canceled status for the past two nights. Upon checking SM37, the job log shows "Authorization error" and ST22 shows a short dump related to a missing authorization object for table access. The job user is SAP_ARCHIVE_USER.

    • Q: What are your immediate troubleshooting steps to identify the missing authorization, and how would you resolve this issue to ensure the job runs successfully?
    • A:
      1. Immediate SU53 Check:
        • Action: Log in as SAP_ARCHIVE_USER (if possible, but usually not a dialog user) or, more practically, execute SU53 as your own user immediately after the job has cancelled (if you have the necessary authorizations to view other users' SU53 data, otherwise need to get it from the system user). Alternatively, ask someone with SAP_ARCHIVE_USER credentials to log in and check SU53 after the cancellation.
        • Expected Outcome: SU53 will show the last failed authorization check, including the missing authorization object and its values. This is the fastest way to pinpoint the exact authorization issue.
      2. ST01 Authorization Trace (If SU53 is inconclusive or difficult):
        • Action: Go to ST01 (Trace -> Activate Trace).
        • Filters: Set filters to trace for user SAP_ARCHIVE_USER and select Authorization Check.
        • Action: Reproduce the error by rescheduling or manually running the SAP_ARCHIVE_DATA job.
        • Action: Immediately after the job cancels, deactivate the trace in ST01 and Analyze Trace.
        • Expected Outcome: The trace analysis will show all authorization checks performed by SAP_ARCHIVE_DATA and clearly highlight the failed checks with the missing objects/values.
      3. Analyze Short Dump (ST22):
        • Action: Go to ST22. Find the short dump corresponding to the job cancellation (filter by user SAP_ARCHIVE_USER and timestamp).
        • Expected Outcome: The short dump details will confirm the authorization error, often explicitly stating the authorization object (e.g., S_TABU_DIS for table access, S_PROGRAM for program execution) and the failing field values. It might also show the program and line of code that triggered the check.
      4. Resolution Steps:
        • Identify Missing Authorization: Based on SU53, ST01 trace, or ST22 dump, pinpoint the exact authorization object (e.g., S_TABU_DIS), activity (e.g., 03 for display, 02 for change), and field values (e.g., DICBERCLS for authorization group SD).
        • Modify Role: Work with the security team to identify the existing role assigned to SAP_ARCHIVE_USER (via SU01 -> Roles tab).
        • Add Authorization: In PFCG, add the missing authorization object and its required values to the appropriate role.
        • Generate Profile: Regenerate the profile for the role in PFCG.
        • Assign Role: Ensure the updated role is assigned to SAP_ARCHIVE_USER.
        • Retest: Reschedule or manually release the SAP_ARCHIVE_DATA job and monitor SM37 for successful completion.

  3. Scenario: You need to implement a complex batch process that involves three distinct steps:

    1. An ABAP program (Z_DATA_EXTRACT) extracts data and creates an internal file.
    2. An external OS command (/usr/sap/trans/scripts/ftp_file.sh) transfers this file to a third-party server.
    3. A final ABAP program (Z_STATUS_UPDATE) updates the status in SAP based on the transfer's success. All steps must execute sequentially, and the entire process should run only after a specific SAP event, SAP_INTERFACE_READY, is triggered by an upstream system.
    • Q: Outline how you would configure this multi-step, event-driven job in SM36 to ensure proper sequencing and triggering.
    • A:
      1. Prerequisites:
        • Ensure Z_DATA_EXTRACT and Z_STATUS_UPDATE ABAP programs and their variants exist.
        • Ensure the external OS command ftp_file.sh is defined and authorized in SM69 (e.g., as Z_FTP_SCRIPT).
        • Ensure the SAP Host Agent (or Gateway) OS user has permissions to execute ftp_file.sh.
        • Ensure the technical batch user for the job has authorizations for all programs and external commands.
      2. Go to SM36:
      3. Define Job Name and Class:
        • Job Name: Z_COMPLEX_DATA_TRANSFER
        • Job Class: B (Medium Priority, as it's an interface process).
      4. Define Job Steps (Crucial for Sequencing):
        • Click Steps.
        • Step 1 (ABAP Program):
          • Click ABAP Program.
          • Program Name: Z_DATA_EXTRACT.
          • Variant: (Select appropriate variant).
          • User: SAP_BATCH_INT.
          • Click Save.
        • Step 2 (External Command):
          • Click External Command.
          • Command: Z_FTP_SCRIPT (the SM69 command name).
          • Operating System: (e.g., UNIX, LINUX, WINDOWS).
          • Parameters: (Any parameters required by the script, e.g., filename generated by Step 1, if it's passed via a variant or a shared file system).
          • User: SAP_BATCH_INT.
          • Click Save.
        • Step 3 (ABAP Program):
          • Click ABAP Program.
          • Program Name: Z_STATUS_UPDATE.
          • Variant: (Select appropriate variant).
          • User: SAP_BATCH_INT.
          • Click Save.
        • Click Back.
      5. Define Start Condition (After Event):
        • Click Start Condition.
        • Select After Event.
        • Event Name: SAP_INTERFACE_READY.
        • Event Parameter: (Optional, if the event carries a parameter that should be checked).
        • Click Check and Save.
      6. Final Save:
        • Click Save on the main SM36 screen.
        • The job status will become Released. It will then wait for the SAP_INTERFACE_READY event to be triggered.
      • Note on Event Triggering: The upstream system would need to trigger this event using CALL FUNCTION 'BP_EVENT_RAISE' in ABAP or btctrns1 at the OS level.

  4. Scenario: Your SAP system has several standard cleanup jobs (e.g., SAP_REORG_JOBS, SAP_REORG_SPOOLS, SAP_REORG_ABAPDUMPS) scheduled. Over time, you notice that SM37 is becoming slower when loading the job overview, and the database size is growing significantly due to job logs and spool requests.

    • Q: Beyond just scheduling the standard cleanup jobs, what best practices and configurations would you review and potentially adjust to effectively manage job logs and spool requests, ensuring optimal SM37 performance and controlled database growth?
    • A:
      1. Review Existing Cleanup Job Variants:
        • Action: For SAP_REORG_JOBS (program RSBTCDEL2), check its variant. Ensure the "deletion date" or "job status selection" (CANCELLED, ABORTED, FINISHED) are appropriate.
        • Action: For SAP_REORG_SPOOLS (program RSPO0041), check its variant. Ensure the "retention period" for spools is configured correctly (e.g., delete after 7-30 days).
        • Rationale: Incorrectly configured variants might not be deleting enough old data.
      2. Adjust Job Log and Spool Retention Parameters:
        • Action: Review SAP profile parameters related to job log and spool retention:
          • rdisp/autoabaptime (for short dump retention, affects SAP_REORG_ABAPDUMPS)
          • rdisp/wp_no_btc_max_duration (if long-running jobs are creating huge logs)
          • spool/max_pages (limits spool size of individual requests)
        • Action: For spool retention, check SPAD -> Administration -> Spool Administration -> Global Settings -> Delete Old Spool Requests. Ensure this is aligned with the RSPO0041 job variant.
        • Rationale: These parameters control the overall retention policies.
      3. Optimize Cleanup Job Frequency and Timing:
        • Action: Ensure cleanup jobs are running frequently enough (e.g., SAP_REORG_JOBS daily, SAP_REORG_SPOOLS daily or twice daily if volume is high).
        • Action: Schedule them during off-peak hours to minimize impact on system performance.
        • Rationale: Timely cleanup prevents accumulation.
      4. Consider RSPO_SPOOLDATA_CONSISTENCY:
        • Action: Regularly run RSPO_SPOOLDATA_CONSISTENCY (even once a week or month) to ensure consistency between the spool database and actual spool files, which can sometimes free up space.
        • Rationale: Addresses potential inconsistencies.
      5. Review "Write Spool List" Option for Other Jobs:
        • Action: For non-critical jobs that generate large spool lists, consider if the "Write Spool List" option is truly necessary for every execution. If not, disable it in the job step.
        • Rationale: Reduces unnecessary spool generation.
      6. Implement Job Naming Conventions and Job Classes for Better Filtering:
        • Action: Encourage strict adherence to job naming conventions.
        • Action: Ensure jobs are assigned appropriate job classes (C for most cleanup jobs).
        • Rationale: Allows SM37 users to effectively filter and search for specific jobs, improving performance of SM37 itself.
      7. Monitor Database Table Sizes:
        • Action: Regularly monitor the size of tables related to job logs and spools (e.g., TBTCO, TBTCP, D010S for job logs; RSPOPAG, TSPEP for spools) using DB02 or DBACOCKPIT.
        • Rationale: Direct check of database growth.

  5. Scenario: A background job (Z_INTERFACE_FEED) is scheduled to run every 15 minutes to process interface files. Recently, other short-running, high-priority jobs (Class A) are experiencing delays because Z_INTERFACE_FEED is taking longer than expected, sometimes overlapping with the next execution window, causing a backlog of Released jobs. You've confirmed the program Z_INTERFACE_FEED itself is performing fine and doesn't have an issue.

    • Q: What are the potential reasons for Z_INTERFACE_FEED impacting other jobs, and what configuration adjustments related to work processes and job scheduling would you consider to optimize performance and prevent future delays without changing Z_INTERFACE_FEED's frequency?
    • A:
      • Potential Reasons for Impact:
        1. Insufficient Background Work Processes: The overall number of background work processes (rdisp/wp_no_btc) is too low for the combined load of all scheduled jobs.
        2. Z_INTERFACE_FEED Class: Z_INTERFACE_FEED might be running as Class A or B, consuming work processes that higher-priority jobs need. Or, if it's Class C, it's getting starved if many Class A/B jobs are running.
        3. Uncontrolled Class A Jobs: Too many Class A jobs running simultaneously, monopolizing the background work processes.
        4. Target Server Overload: If Z_INTERFACE_FEED is assigned to a specific target server that is now overloaded or shares resources with the Class A jobs.
        5. Work Process Bottleneck on a Single Server: Even if overall work processes are sufficient, a single server might be saturated with Z_INTERFACE_FEED instances if it's running on the same server as the higher-priority jobs.
      • Configuration Adjustments to Optimize Performance:
        1. Review and Adjust Job Classes:
          • Action: Change Z_INTERFACE_FEED to Job Class C (Low Priority) in SM36.
          • Rationale: This ensures that higher-priority Class A and Class B jobs are picked up first by available background work processes, preventing Z_INTERFACE_FEED from blocking them.
        2. Increase Background Work Processes (System-wide):
          • Action: If SM50 or SM66 shows background work processes consistently busy or in WAIT status for long periods, consider increasing the total number of background work processes (rdisp/wp_no_btc) in the instance profile via RZ10. A restart is required.
          • Rationale: Provides more capacity for all background jobs.
        3. Implement Operation Modes with Dedicated Background Servers:
          • Action: Define Operation Modes (RZ04) to dedicate specific application servers (e.g., APPL_SERVER_BATCH) primarily for background processing during peak hours for Z_INTERFACE_FEED or other batch loads.
          • Action: Configure the instance profile of APPL_SERVER_BATCH to have a higher number of background work processes (rdisp/wp_no_btc) and potentially fewer dialog work processes.
          • Action: Assign Z_INTERFACE_FEED to this dedicated APPL_SERVER_BATCH in its SM36 Target Server configuration.
          • Rationale: Isolates background processing to specific servers, preventing resource contention with dialog users and other critical jobs.
        4. Distribute High-Frequency Jobs Across Servers:
          • Action: If you have multiple application servers, avoid assigning all high-frequency jobs to a single server. Distribute them strategically based on their resource consumption.
          • Rationale: Spreads the load evenly.
        5. Consider Using a Third-Party Scheduler (for very complex scenarios):
          • Action: If the problem persists or the landscape's scheduling needs become extremely complex, consider integrating a robust third-party scheduler (e.g., SAP CPS by Redwood, UC4/Autosys, Broadcom CA Workload Automation). These provide more advanced capabilities for dependency management, load balancing, and dynamic scheduling.
          • Rationale: Provides enterprise-grade workload automation beyond basic SM36 capabilities.

Comments

Post a Comment

Popular posts from this blog

An experiment with the life

"Best Thing about experiment is that it only improves the outcome." Well, I am Rakshit, hope you already know. I am not special and surely not especially gifted. Neither things go according to my wish. Neither I am the best writer.  But I am myself who is totally unique from anyone else. And I am Rakshit Ranjan Singh. I have my own fun, fights and fall in the most fundamentalistic way. Mechanical is my degree. IT is my Job. Beauty in nature is what I search. Words of my heart are what I write. Four different things I carry on my shoulder and a smile on my face, hope you might have seen that. What do I care for? Family, friends and nature. Do I have regrets? More than I can imagine. Let us move further to see what really is my life.
Read more

Learn Java

Hello Friends, You might already know what Java is. Without taking much of your time, I would like to ask you to please click below if you are ready to learn it from end to end. The Material over here is available on the internet and is free to access.  I would request you to bookmark this page and follow it. Please comment if you are happy with the learning. click here
Post a Comment
Read more

Driving

My Driving Journey: From Zero to (Almost) Hero! Hello everyone! I'm excited to share my ongoing adventure of learning to drive. It's been a mix of nervous excitement, hilarious near-misses, and the slow but steady feeling of progress. Buckle up, because here's a peek into my journey behind the wheel! The First Lesson: Clutch Confusion! My first time in the driver's seat was... memorable. Let's just say the clutch and I weren't immediate friends. Lots of jerky starts and a few stalls later, I began to understand the delicate dance between the pedals. My instructor was incredibly patient (thank goodness!). Mastering the Steering Wheel (Sort Of) Steering seemed straightforward enough, but navigating turns smoothly was a different story. I definitely had a few moments of feeling like I was wrestling with the wheel. Slowly but...
Post a Comment
Read more