Hierarchy
SAP_BASIS (Software Component) SAP Basis Component⤷
BC-DWB-TOO (Application Component) Workbench Tools: Editors, Painters, Modelers⤷
SZS (Package) R/3 Central Basis Development: Objects
Basic Data
| Data Element | INT4 |
| Short Description | Natural number |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | INT4 | |
| Data Type | INT4 | 4-byte integer, integer number with sign |
| Length | 10 | |
| Decimal Places | 0 | |
| Output Length | 10 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | Number |
| Medium | 15 | Number |
| Long | 20 | Natural number |
| Heading | 0 | Natural Number |
Supplementary Documentation - INT4_DATA 0123
Use
Job States
Jobs running on the system can be in any of the following states:
- Active
- Wait
- Ineligible
An active job exists in main storage and processes work requested by the application. A job in the wait state needs a resource that is not available. An ineligible job has work to do, but the system is unable to accept more work at that time.
Wait States
When a job is waiting for a resource, it may wait in main storage or it may be removed from main storage until the resource is available. The terms short wait, short wait extended, and long wait are used to describe a job waiting for a system resource.
Short Wait: A job in short wait holds an available activity level while waiting for an activity to occur. A job can remain in short wait for a maximum of 2 seconds. Some typical actions that cause short waits are:
- Sending a WRITE instruction to a display when *NO is specified on the Defer Write (DFRWRT) parameter.
- Sending break messages to workstations.
- Specifying *YES on the Restore Display (RSTDSP) parameter on display files.
When using remote lines, avoid actions that cause short waits because they cause the wait time in main storage to be much longer for a job than if the job was waiting for resources at a local workstation.
Short Wait Extended: A job is in short wait extended if it has been in short wait for the maximum 2 seconds. After it has been in short wait for 2 seconds and activity has not occured, the system cancels the short wait, takes the job out of the activity level, and puts the job into a long wait. In the performance reports, this job state transition is called a short wait extended.
Long Wait: A job that immediately leaves the activity level is in what is called long wait. During a long wait, the job leaves the activity level.
A specialized form of long wait, called key/think wait, occurs outside the activity level when a job completes a work assignment and returns to request more work. This is a user-specified time period giving the user time to decide what data should be entered and to type this data. When the job receives a new assignment, it attempts to run again. If no activity level space is available, the job becomes ineligible.
Other examples of long waits are:
- Record lock conflicts (when two or more jobs attempt to lock the same record of a file)
- Distributed Data Management data requests
Activity Levels and Ineligible Queues
A job that cannot get an available activity level is ineligible. An activity level assures the job system resource, and if not enough resources are available, jobs become ineligible.
For interactive environments, typically there are more jobs running than there is space for them to run. When a job attempts to run, there must be space for the job in main storage. Activity levels are set for each pool in the system, which restricts the number of jobs in main storage at one time. Before a job becomes active, an activity level must be available.
If an activity level is available, the job becomes active and begins processing in main storage. If no activity level is available, the job becomes ineligible. When a job becomes ineligible, it is placed in the ineligible queue until an activity level is available.
By correctly managing the ineligible queue, the system may avoid unnecessary job transitions and disk operations. As a result, proper tuning keeps the number of jobs on the queue down. Throughput and response time are more consistent.
Ineligible Queue and Job Priority
Sometimes jobs gain priority if they are held by locks. Normally, if a job enters the long wait state by other than a lock conflict, it is placed behind all other jobs of equal priority already on the eligible queue. This is called a first-in, first-out priority queue.
However, if a job becomes ineligible after a short wait extended or a long wait caused by a lock conflict, it is placed in in front of jobs of equal priority already in the eligible queue. The most common reasons for this change to normal queue placement are:
- The job entered a long wait as a result of a lock conflict because it was active (referring to objects in main storage) before the conflict occured. If the wait was short (and many are), you may be able to get the job back into an activity level before all of the objects the job was using are removed from main storage.
- When the job has been granted the lock, it leaves the wait state. If other jobs on the ineligible queue are to use the same object, they must wait until the object is once again available. Therefore, you want jobs holding locks on objects to use them and make them available for other jobs to use. To accomplish this, the job moves ahead of any potential requesters.
Supplementary Documentation - INT4_DATA 0124
Use
Job States
Jobs running on the system can be in any of the following states:
- Active
- Wait
- Ineligible
An active job exists in main storage and processes work requested by the application. A job in the wait state needs a resource that is not available. An ineligible job has work to do, but the system is unable to accept more work at that time.
Wait States
When a job is waiting for a resource, it may wait in main storage or it may be removed from main storage until the resource is available. The terms short wait, short wait extended, and long wait are used to describe a job waiting for a system resource.
Short Wait: A job in short wait holds an available activity level while waiting for an activity to occur. A job can remain in short wait for a maximum of 2 seconds. Some typical actions that cause short waits are:
- Sending a WRITE instruction to a display when *NO is specified on the Defer Write (DFRWRT) parameter.
- Sending break messages to workstations.
- Specifying *YES on the Restore Display (RSTDSP) parameter on display files.
When using remote lines, avoid actions that cause short waits because they cause the wait time in main storage to be much longer for a job than if the job was waiting for resources at a local workstation.
Short Wait Extended: A job is in short wait extended if it has been in short wait for the maximum 2 seconds. After it has been in short wait for 2 seconds and activity has not occured, the system cancels the short wait, takes the job out of the activity level, and puts the job into a long wait. In the performance reports, this job state transition is called a short wait extended.
Long Wait: A job that immediately leaves the activity level is in what is called long wait. During a long wait, the job leaves the activity level.
A specialized form of long wait, called key/think wait, occurs outside the activity level when a job completes a work assignment and returns to request more work. This is a user-specified time period giving the user time to decide what data should be entered and to type this data. When the job receives a new assignment, it attempts to run again. If no activity level space is available, the job becomes ineligible.
Other examples of long waits are:
- Record lock conflicts (when two or more jobs attempt to lock the same record of a file)
- Distributed Data Management data requests
Activity Levels and Ineligible Queues
A job that cannot get an available activity level is ineligible. An activity level assures the job system resource, and if not enough resources are available, jobs become ineligible.
For interactive environments, typically there are more jobs running than there is space for them to run. When a job attempts to run, there must be space for the job in main storage. Activity levels are set for each pool in the system, which restricts the number of jobs in main storage at one time. Before a job becomes active, an activity level must be available.
If an activity level is available, the job becomes active and begins processing in main storage. If no activity level is available, the job becomes ineligible. When a job becomes ineligible, it is placed in the ineligible queue until an activity level is available.
By correctly managing the ineligible queue, the system may avoid unnecessary job transitions and disk operations. As a result, proper tuning keeps the number of jobs on the queue down. Throughput and response time are more consistent.
Ineligible Queue and Job Priority
Sometimes jobs gain priority if they are held by locks. Normally, if a job enters the long wait state by other than a lock conflict, it is placed behind all other jobs of equal priority already on the eligible queue. This is called a first-in, first-out priority queue.
However, if a job becomes ineligible after a short wait extended or a long wait caused by a lock conflict, it is placed in in front of jobs of equal priority already in the eligible queue. The most common reasons for this change to normal queue placement are:
- The job entered a long wait as a result of a lock conflict because it was active (referring to objects in main storage) before the conflict occured. If the wait was short (and many are), you may be able to get the job back into an activity level before all of the objects the job was using are removed from main storage.
- When the job has been granted the lock, it leaves the wait state. If other jobs on the ineligible queue are to use the same object, they must wait until the object is once again available. Therefore, you want jobs holding locks on objects to use them and make them available for other jobs to use. To accomplish this, the job moves ahead of any potential requesters.
Supplementary Documentation - INT4_DATA 0125
Use
Job States
Jobs running on the system can be in any of the following states:
- Active
- Wait
- Ineligible
An active job exists in main storage and processes work requested by the application. A job in the wait state needs a resource that is not available. An ineligible job has work to do, but the system is unable to accept more work at that time.
Wait States
When a job is waiting for a resource, it may wait in main storage or it may be removed from main storage until the resource is available. The terms short wait, short wait extended, and long wait are used to describe a job waiting for a system resource.
Short Wait: A job in short wait holds an available activity level while waiting for an activity to occur. A job can remain in short wait for a maximum of 2 seconds. Some typical actions that cause short waits are:
- Sending a WRITE instruction to a display when *NO is specified on the Defer Write (DFRWRT) parameter.
- Sending break messages to workstations.
- Specifying *YES on the Restore Display (RSTDSP) parameter on display files.
When using remote lines, avoid actions that cause short waits because they cause the wait time in main storage to be much longer for a job than if the job was waiting for resources at a local workstation.
Short Wait Extended: A job is in short wait extended if it has been in short wait for the maximum 2 seconds. After it has been in short wait for 2 seconds and activity has not occured, the system cancels the short wait, takes the job out of the activity level, and puts the job into a long wait. In the performance reports, this job state transition is called a short wait extended.
Long Wait: A job that immediately leaves the activity level is in what is called long wait. During a long wait, the job leaves the activity level.
A specialized form of long wait, called key/think wait, occurs outside the activity level when a job completes a work assignment and returns to request more work. This is a user-specified time period giving the user time to decide what data should be entered and to type this data. When the job receives a new assignment, it attempts to run again. If no activity level space is available, the job becomes ineligible.
Other examples of long waits are:
- Record lock conflicts (when two or more jobs attempt to lock the same record of a file)
- Distributed Data Management data requests
Activity Levels and Ineligible Queues
A job that cannot get an available activity level is ineligible. An activity level assures the job system resource, and if not enough resources are available, jobs become ineligible.
For interactive environments, typically there are more jobs running than there is space for them to run. When a job attempts to run, there must be space for the job in main storage. Activity levels are set for each pool in the system, which restricts the number of jobs in main storage at one time. Before a job becomes active, an activity level must be available.
If an activity level is available, the job becomes active and begins processing in main storage. If no activity level is available, the job becomes ineligible. When a job becomes ineligible, it is placed in the ineligible queue until an activity level is available.
By correctly managing the ineligible queue, the system may avoid unnecessary job transitions and disk operations. As a result, proper tuning keeps the number of jobs on the queue down. Throughput and response time are more consistent.
Ineligible Queue and Job Priority
Sometimes jobs gain priority if they are held by locks. Normally, if a job enters the long wait state by other than a lock conflict, it is placed behind all other jobs of equal priority already on the eligible queue. This is called a first-in, first-out priority queue.
However, if a job becomes ineligible after a short wait extended or a long wait caused by a lock conflict, it is placed in in front of jobs of equal priority already in the eligible queue. The most common reasons for this change to normal queue placement are:
- The job entered a long wait as a result of a lock conflict because it was active (referring to objects in main storage) before the conflict occured. If the wait was short (and many are), you may be able to get the job back into an activity level before all of the objects the job was using are removed from main storage.
- When the job has been granted the lock, it leaves the wait state. If other jobs on the ineligible queue are to use the same object, they must wait until the object is once again available. Therefore, you want jobs holding locks on objects to use them and make them available for other jobs to use. To accomplish this, the job moves ahead of any potential requesters.
History
| Last changed by/on | SAP | 20010130 |
| SAP Release Created in |
