These DB/2 errors are almost unheard of in well managed Microsoft SQL Server applications. Not all of them are even treated as SQL errors by the Microsoft native client.
For reference, from the DB/2 manual:
-904 would be equivalent to a lock failure in SQL Server. This hasn't happened regularly since the release of SQL Server version 3 (many, many years before Microsoft bought the product)
-904 UNSUCCESSFUL EXECUTION CAUSED BY AN UNAVAILABLE RESOURCE. REASON , TYPE OF RESOURCE , AND RESOURCE NAME
-911 THE CURRENT UNIT OF WORK HAS BEEN ROLLED BACK DUE TO DEADLOCK OR TIMEOUT. REASON , TYPE OF RESOURCE , AND RESOURCE NAME
-913 UNSUCCESSFUL EXECUTION CAUSED BY DEADLOCK OR TIMEOUT. REASON CODE , TYPE OF RESOURCE , AND RESOURCE NAME
-923 CONNECTION NOT ESTABLISHED: DB2 , REASON , TYPE , NAME
-911 and -913 are deadlock issues. There isn't a SQL error code for this, it is treated as a broken connection and reported as such by your COBOL library. Different compilers handle this in radically different ways, you'll have to check your COBOL documentation.
-923 is another variation of a broken connection. A zOS COBOL program would only report this error if the bind step failed when building the executable or if DB/2 access was revoked from the bound id. This is effectively meaningless in the Microsoft SQL environment, this error would only be retunred as a result of a coding error and the error reported would vary wildly based on which COBOL library your program is using (for the same reasons that I cited in the previous paragraph).
In theory, theory and practice are identical. In practice, theory and practice are unrelated.