Print files redirection issue
Author: email@example.com (Kittycat)
Dear All, I am working at a customers' site, where files are being created, printed and redirected via the assignmentfile settings. The problem we currently have is related to a combination of these three things. On Unix. Redirection normally works like a charm, except .. when creating files via e.g. the 'filedump' Proc statement ('Export Repository Objects' is also a good example). I know that this behavior has been true for many years. The error usually is something like "ERROR=-4;MNEM=;DESCRIPTION=Table or file open failure;COMPONENT=...". The underlying problem is a conflict between the directory-path as specified in the Proc statement and the redirection as specified in the assignmentfile. The workaround could be 'inclusion/exclusion' or 'explicit inclusion' in the assignmentfile. And this is where the weirdness begins. Imagine the following situations: Situation 1
In the above situation (1) we exclude all the files ending on '*.pd*' from being redirected to the directory for print files. Now, when creating e.g. the file '/specific/directory/somefile.pd1' with the 'filedump' Proc statement, it will fail due that conflict between the supplied path and the redirection. All print files will be redirected though. To circumvent this, we can explicitly redirect all the possible print files ('*.p01'v '*.p02', '*.p03' etc.) via inclusion only. See situation 2 below. Situation 2
This way we should be able to create all kind of files in whatever way we want (with exception of Uniface print file extensions of course), and not be interfered by the redirection of the print files generated by Uniface. The only problem we now have is that somehow Uniface does not follow its own assignment file in this case. It does not match an e.g. '*.p01' print file in the line of redirections in the assignment file. No matter what kind of variation we try, it simply does not work. It does create the print file though, but places it in the home/working directory of the user from which this component is being executed. This looks like a catch-22 bug. Has anyone had this same behavior before and has a solution to this?