-
Users Handbook
-
-
-
- Intro & Basics
- All Objects have Descriptions
- Check for unused procedures
- Compiled Procedures up to date
- Invalid Source Layers
- Required Columns
- Check for abnormally ended Jobs
- Check for blocked Jobs
- Check for disabled Tasks
- Check for duplicate tasks in different Jobs
- Check for duplicate tasks in same Job
-
-
-
Administrators Handbook
-
- Register URL
- Configure SSL/HTTPS
- Configure Proxy-Server
- How to edit the appsettings.json file
- System Settings
- Global Parameters
- Allow Service Account to Logon as a Service
- LDAP & SSO Authentication
- Migrating Testcases and Configuration
- Licenses Management
- Manual Configuration
- Exposing the BiG EVAL REST API to other Network Segments
-
- Articles coming soon
-
Developers Handbook
-
Known Problems
-
Demo Virtual Machine
-
Release Notes
-
General
Check for blocked Jobs
- Home
- Users Handbook
- Templates & Packages
- WhereScape RED Pack
- Check for blocked Jobs
Introduction
This test case checks whether there are any blocked jobs in WhereScape RED’s scheduler.
How does it work?
The test case uses the parameter list WhereScape RED Jobs (ws-red-jobs) to loop through a list of jobs (marked by “Check blocked” == “Yes”) and running the following check for all of these jobs.
The test case queries the job log for jobs that are still running and have been running for longer than a parameterizable number of minutes.
Configuration
Basic configuration is done in the parameter list WhereScape RED Jobs (ws-red-jobs) as described above.
If needed, you can change the maximum amount of minutes the job can run without counting as blocked, in the parameter “MaxMinutes” in the probe SQL script directly, or you can define a test parameter or global parameter named MaxMinutes.