Hi fellow forum members
While I have been using RMS & AppWorx for quite some time, I am only now setting up posupld (without ReSA).
I have noticed that AppWorx does not call posupld directly, but has a job called pos_upload_move.
While I could easily set up a new job to call posupld directly, I have noticed that the underlying Appworx unix script pos_upload_move looks quite clever.
It takes files found in the /pos folder and moves them to the /in folder. It double-checks that the file is still not being FTP'd from another location or being generated from the POS Tlogs (or other programs).
I ensures that the filename and the store code within the file match. It checks that it definitely is a POSU file. It ensures that only one file at a time is "fed" to posupld.pc as this must be run without other copies also running.
The above is what I have found out. However, I am still struggling to get the damn thing to work!
Firstly, I found that when ensuring it is a POSU file, it was grepping for the string 'posupld' - however, this string is not ever found in the posu file. I changed this to a grep for 'posu' and got a little further.
I then ran into problems where it was parsing the filename out of the output from an 'ls -l' unix command. It uses the 'cut -c' in a pipe, but I found it was starting at the wrong character position for my output from 'ls -l' - possibly broken due to my AIX being 6.1 and this was written for 5.x or 4.x ? I fixed the cut command starting position to 59 where my filename started.
I then struggled with its logic of comparing the store code as found in the filename (filename seems to be expected to be POSU_<store code>_<date>.DAT). It lists stores from the RMS store table and returns the rownum from this table (rather precarious?). The returned rownum is then referenced in the pos_store_number variable later in the program, for what purpose I have not yet figured out.
I have now got to the point where it is submitting (i.e. spawning from the pos_upload_move job) the actual posupld job to AppWorx, but it has got the prompts (i.e. parameters) completely garbled.
I am now wondering if (a) the pos_upoad_move job I found is not in fact a GA release job, but simply an artifact or (b) I am approaching the configuration of the process completely wrong.
It is not helped by the fact that UC4 provide no documentation in relation to the Retail config of AppWorx, nor is it easy via the Support process to find somebody who knows what you are talking about vis-a-vis Oracle Retail/Retek - the experts in this field (like the guys who performed our initial installation and training) are very hard to access (without contracting them and paying for the privilege).
If any of you folks has any experience of configuring and running the pos_upload_move job/script, can you please share your experiences or if you have written any setup documents, to please share them with me?
ORMS 12.1, UC4 AM v8
We are using POSUPLD.PC for uploading POSU files after parsing by using uc4 v8 only .We have scheduled and its running fine !! we have configured in uc4 even
please let me know where ur exactly going wrong inconfiguring POSUPLD.PC
It's a common problem - UC4 seems like a hammer to crack a nut in many instances.
Even with a template to upload, I've seen it take weeks or months to get a smoothly running batch schedule - the whole thing is held together by shell scripts like the one you have been working on and as you say, there is little or no documentation and a license structure based on servers and agents rather than sites which make it prohibitively expensive for having a batch for testing environments as well as production.
I am working on a solution to this with a specific batch scheduler for Oracle Retail with a user friendly, simple front end.
The aim is to have it working out of the box for the specifics of Oracle Retail such as multithreading, progress monitoring and estimate time to complete the current batch which will make support and monitoring of the batch much easier and incorporating my 15 years of experience of supporting Oracle Retail implementations and batch schedules.
It's still at an early stage but will update the linkedIn Oracle Retail groups and here when i have something ready to test.