Hello Everyone,
let's discuss this error " " wrong order of calls - call opendir( ..) ". We may get this error in different situations.
I observed this error when archive jobs were failing due to error :
Archive file \\Hostname\Archive\XXX\DA_~ABC~XXX_20XX08X5_ cannot be opened for write the program
Job canceled after system exception ERROR_MESSAGE
CAUSE :
most in 99% of these errors occurred due to lack of permission but in that case, Errors get changed to "permission denied"
basically, in AL11 we used shared drive if we have multiple Dialog instances then we create a shared folder on ASCS and shared that folder.
RESOLUTION
The file and Printer sharing option was off, Hence SAP system was unable to find the shared folder. we turned on File and Printer sharing and the issue was resolved.
You can refer to SAP NOTE 117395 2187737
Following an SAP system standard installation on Microsoft Windows, there are two different operating system users on an SAP system server:
- The <SID>adm user used for the interactive logon
- The SAPService<SID> user used to start the SAP services
If the start of an SAP system instance is initiated by the user <SID>adm (for example, using the "Start" button in SAP Service Manager), the SAP service "SAP<SID>_<instance_no>" receives a signal to start the SAP system kernel. Because, like all other SAP services, the SAP service "SAP<SID>_<instance_no>" is started with the user SAPService<SID>, the SAP system kernel runs in the security context of this user, too.
In other words: Even if the interactive user <SID>adm apparently initiates the start of the SAP system, the SAP system kernel accesses all resources with the authorizations of the user SAPService<SID>.
In the case described above, the user on which the SAP system kernel is running is not authorized to access the remote drive.
Solution
To solve the problem, we first need to distinguish between scenarios for the Windows domain membership of the SAP system servers:
- All involved SAP system instances are a member of just one Windows domain.
In this case, the problem should not occur as long as the users mentioned above have been implemented as domain users (recommended by SAP). If the SAP users have been created as local users only, this limits their scope of validity to this local server only. You must proceed in accordance with point 2).
______________________
/ \ Domain A
| o.k. |
HOST A ---------------> HOST B (shared resource)
| domain user : ABCadm |
\______________________/
The domain user account is valid in the whole domain.
- All involved SAP system instances are a member of a Microsoft Windows workgroup or standalone server.
In this case, the various operating system users are valid locally on the servers only; this means that the conditions for the error described above are met. One possible way to avoid this situation is to incorporate the servers into a domain and switch the local users for domain users. SAP Note 1233320 describes the migration of a local SAP installation to a domain-based installation.
You can work around the disadvantage of local validity by creating the users that require access to the remote resource with the same name and password on the target host (for example, on the server with the central transport directory).
Workgroup or standalone server:
No Access
HOST A ------/-----> HOST B (shared resource)
user: A*
pwd : ABC
Access
HOST A ------------> HOST B (shared resource)
user: A user: A
pwd : ABC pwd : ABC
* The SAP system uses the users <SID>adm and SAPService<SID>
- The involved SAP system instances are members of multiple Windows domains.
If there is a trust relationship between the domains, the users of one domain can access the resources of other domains. By default, a trust relationship is unidirectional, which means that only users of one of the domains can access the resources of the other domain in the relationship. However, you can set up a mutual trust relationship to enable access in both directions.
Without a trust relationship, the conditions for the problem mentioned above are still met, since the domain users are only valid locally in their own domain. However, the problem can again be worked around by creating a second user with the same name and password without setting up a generally applicable trust relationship.
Domain A Domain B
_____ _______
\ No Trust /
| Relationship |
HOST A ----------------> HOST B (shared resource)
| No Access ! |
_____ / \ _______
Domain A Domain B
____ _______
\ No Trust /
| Relationship |
HOST A ----------------> HOST B (shared resource)
| Access ! |
______ / \ _______
user: A* user: A
pwd : ABC pwd : ABC
* The SAP system uses the users <SID>adm and SAPService<SID>
Thanks
Rupesh Chavan