Solution to this issue
Note: Before performing the following action, kindly ensure that SAPservice has all the needed privileges.

Stop SAP & DB

Reinstall sqlctr.ini
1) Stop SQL Server
2) Open a command prompt and navigate to the BINN directory for that SQL Server
3) Execute unlodctr sqlctr.ini
4) Execute lodctr sqlctr.ini

Restart DB & SAP

If you want to reset user TMSADM to the default, or if the configuration of this user was damaged, then:

Log on to the SAP System in which you want to reset user TMSADM.
Enter Transaction STMS.
Choose Overview
-> Systems. The system overview appears.
Choose Extras -> Reset user TMSADM.

The CPIC user TMSADM is regenerated with the default authorizations.

Data Dictionary is the central catalog that contains the descriptions of an organization’s data and provides information about the relationships between the data and its use in programs and screens.

The data descriptions in a Data Dictionary is also called metadata, i.e., data that describes other data.
The ABAP/4 Dictionary stores system-wide data definitions. When you create a new data definition, the Dictionary tool does all the processing necessary to create the definition. You can use the Dictionary tool to look up the “definition” of objects in your R/3 System.

Okay todays topic is Message types in SAP

A message can have five different types. These message types have the following effects during list processing:

A (=Abend):
The system displays a message of this message type in a dialog window. After the user confirms the message using ENTER, the system terminates the entire transaction (for example SE38).

E (=Error) or W (=Warning):
The system displays a message of this message type in the status line. After the user chooses ENTER, the system acts as follows:
While creating the basic list, the system terminates the report.
While creating a secondary list, the system terminates the corresponding processing block and keeps displaying the previous list level.

I (=Information):
The system displays a message of this message type in a dialog window. After the user chooses ENTER , the system resumes processing at the current program position.

S (=Success):
The system displays a message of this message type on the output screen in the status line of the currently created list.

The System log had logs continually saying “Transaction Canceled BT 510()”, from the subsequent logs we were able to observe this was because a job did not have step data. But we were not able to find the job which was causing this.

We tried to perform consistency checks, but it dint really help. This issue kept repeating in the system.

To find out which job is causing this issue, we implemented note 1299997. This note will give you details of the job. As per the note, this note the problem may not sometimes display the inconsistent data in SM37. Therefore we must try repairing the succeeding released job. If this works out then the issue will get resolved.

We tried removing this job and rescheduling it again but it dint help, the logs kept repeating.

This note also provides you with a report Z_DELETE_JOBS_WITHOUT_STEPS. Implement the report in the system and execute it, the inconsistent job will now be removed. This solved our issue and the system logs stopped reoccurring. Please note: Once the report deletes the inconsistencies we would need to recreate the job again.

 Upon checking the /sapmnt/SID/global/<client>JOBLG directory observed that two files very extremely large in size, from the modified time we were able to find they were updated recently.

We should not delete job log files from OS level as it would create Temse Incosistencies.

Since it was our production system, customer wanted to know which job was causing this. 

The Job log files are not readable from the OS level, we had to detect which job these two files belonged to.

To find this, we went to SP12 –> Temse Data Storage –> List all objects. Suppose the job log file name at os level is 0001X16292501X99534, in the above SP12 screen choose Find String and give the job log file name. You will be able to find the object here, choose object display.  The file might have a lot of non understandable code, but in the second line, you will be able to find the name of the program, variant and user name of the job. Use the program name and user name make a search in SM37, you will be able to trace the job name. We were able to find that the job was long running and was the cause for the huge files.

Example: The second line in the file may look like this

0355001S098003001008RSCONN01014SAP&CONNECTINT004BASIS001E000000000

In this you might able to find RSCONN01, this is the program name, SAP&CONNETINT is the parameter name, Basis is the user name.

Later with the confirmation from customer we deleted these job log files alone using RSBTCDEL2 program and thus cleared the space in the filesystem.

Upon checking the idoc numbers in WE02 and BD84, we observed idocs were in status 30(IDOCS ready for dispatch).

 On further checking we found that the partner profiles in WE20 transaction dint have the Output mode for the message types set as “Transfer IDOC immed.”.

After we enabled this option and the issue got solved and the idocs got transferred without any issues

Steps1 :
Note, How to check Message Server Name:

RZ10 >>> default profile >>>

Mssg. srv (host) = comp-sap <<<< its Message Server Host Name
Mssg. srv (service) = sapmsABC <<<< its Message Service Name

Steps2:
Check SAP application server /etc/service <<< suse
Check SAP application server c:/windws/system32/driver//etc/service <<< windows

Steps3:

write entry on SAP Applications Server and Presentation machine (front end machine)

sapmsABC 3600/tcp # SAP System Messaging Service Port

that is ABA is your SID in 3600 here 00 is system number.

then open GUI >>> Connection Type = Group / Server Selection
……
Message Server = comp-sap
OR
Message Server = 172.16.1.1; means enter IP here
=========================================

The job was shown to be executing for every 5 mins and got canceled with the above error. But there was no released jobs (Job frequency was not shown). There was no background processes triggering this as well. The user sapsys does not exist in client 000.

We referred to SAP note 1154422 for this issue. According to this note, To correct the problem, please do the following:

1. Log on to the affected system as an administrator and start transaction RZ21. You may log on in any client.

2. In transaction RZ21, deactivate the jobs by selecting Technical infrastructure -> Downtime dispatching -> Deactivate dispatcher job and Deactivate data collection job.

3. Re-start the jobs by selecting Technical infrastructure -> Downtime dispatching -> Activate dispatcher job and Activate data collection job.

4. In RZ21, select the Method definition overview and use CTRL-F to search for the method definitions SDTS_MAPPING_JOBCHECK and SDTS_MONPAUSE_JOBCHECK.

5. In each of these method definitions, open the ‘Control’ tab. In the Control of Method Execution frame, change the radio button setting from ‘Periodic in dialog process (short process)’ to ‘Periodic in background process (as job)’.

6. Save each method definition.

The jobs should now run under your administrative user and will no longer abort.