Best Of
Re: I want the system to first consider available on-hand quantities in other inventory organizations.
Hi @User_ZJSHA ,
In the above scenario that you have outlined, plan will transfer the ENTIRE demand (IR will be created for entire demand quantity). Subsequently in the source organization the on hand is netted a planned order (for external purhcase or make) is recommended after netting the on hand.
In summary, ASCP does planning item-org wise hence looking at on hand at other locations prior to recommending planned orders wont work.
What you are looking for is inventory re-balancing which works only in DRP.
The scenario recommended by @VHK-Oracle works to certain extent ONLY if the flow of goods is in one direction.
ASCP does planning only at org level. OU level planning is not possible in ASCP.
Hope the above clarifies.
Best Regards,
Mohan Balaji
Re: I want the system to first consider available on-hand quantities in other inventory organizations.
Hi @User_ZJSHA ,
Please refer the below thread where the same query is being discussed:
In short, the answer is No. ASCP will not consider the on hand in other orgs.
However if the above requirement is the most critical requirement for your business, you can implement DRP which has the capability for inventory re-balancing between the orgs.
Hope the above helps!
Regards,
Mohan Balaji
Re: SELinux on ODA
Hi Ted,
SELinux can be enabled in permissive mode in an incoming release via odacli. Likely 19.28 or 19.29.
Br,
krisz
Re: How can I get all 9 digits of precision in systimestamp?
Thanks Bruno. The fact that I can get the additional precision from my OS makes me think Oracle should be able to get it, too, and use it to populate the timestamp(9) for me. I consider this to be a bug - why offer 9 digits but only populate 6 of them?
The White Rabbit Project is indeed amazing! Thanks for the link - I'd never heard of it. We humans are doing some amazing things!
Re: Server Busy Error After Session Timeout in IP 25.1
Hi,
Server busy is very bad news and means whatever you did caused Siebel to crash. We need to see your crash.txt, extracted/sorted FDR for just the thread that caused the crash and the 4-1-1 Siebel log file for the user that caused the crash in order to be able to help further.
Also especially since this is production you should check s_diag to see how often you are crashing and how many users are being impacted with each crash.
Until you find and fix the root cause suggest you increase MTS so that the users are "thinned" across more server processes to reduce the impact of each crash. E.g. increasing MTS from 10 to 20 will cut the number of users in half as long as MIN and MAX MTS are both set the same.
HTH,
R
P.S. You can also consider changing your timeout value so that timeouts happen less frequently to state the obvious.
Re: Should gpu utility be run on all siebel servers in a migration installation
Hello @User_YJ1G2,
Thank you for posting your queries about spu and gpu utilities for password AES encryption.
I hope it is one time encryption if fine and make use of same one while creating other others services.
Also, gpu as it is enterprise level, you can make use of once or same.
$SIEBEL_ROOT/siebsrvr/lib/gpu -g localhost:2320 -e esia81 -u SADMIN -p
Below one also at enterprise level
change param password=<pwd_value> for compdef <comp_name>
Where as this is server level
change param password=<pwd_value> for comp <comp_name> server <server_name>
But you can make use of compdef level which is enterprise and reflects to all servers where ever it enabled.
But still you can test it to make sure.
Regards,
Mallik Kalluri
Re: Should gpu utility be run on all siebel servers in a migration installation
SPU is run once, in "gateway" context:
"Source the siebenv script from the Siebel Gateway installation directory"
it gives you a new password.
GPU is run in siebel server context and you run gpu again on each siebel server.
https://docs.oracle.com/cd/G30554_01/books/SiebInst/c-Updating-the-Siebel-Server-System-Service-and-Server-Components-to-Use-AES-Password-Encryption-ahw4068698.html
