Files on AS/400 Raise Events
AS/400 file events are created in the same way as other file events. To check for files that match AS/400 file events, Redwood Server connects to the AS/400 for each file event using the credential matching the AS/400 process server parametersAS400Server and AS400User.
The connector then checks for files according to the directory and pattern specified by the file event. If a file is found it is optionally moved (if this is specified on the file event) and a file event is raised.
There are some differences:
- AS/400 file events are on the remote AS/400, which does not need an agent present.
- The AS/400 file system does not work in the same way that a UNIX or Windows file system does. AS/400 systems have a number of different file systems exposed via the IFS.
- No lock checks are performed on files, you use the Minimum age and Minimum size to specify when a file should raise the event.
Files in the library file system
The library file system provides you with access to database files and all of the other IBM i object types that libraries can contain, see Library file system (QSYS.LIB) for more information.
Files are often located in libraries, and libraries may be located inside either the QSYS or QGPL libraries. If the file you are looking for is in a library, you need to find the full path to the file you are looking for.
You can browse the file system from within Redwood Server or ask the operator. If you do not specify a file member, a SAVF file is assumed; the process server will log an error if you simply specify the path to a file that is not of type SAVF.
On the AS/400, issue the WRKLIB command, and find the library you are looking for, it may be in another library (typically QSYS or QGPL ). Once you have found the library you need to add.LIB to the end of each of the libraries, and separate them with /.
For example, if you are looking for physical file members named P* in file MYFILE.FILE of the USERX.LIB library in QSYS, the file event should be specified as:
Directory: /QSYS.LIB/USERX.LIB/MYFILE.FILE
Pattern: P*
Notes on wildcards:
The following wildcards are supported:
*- any number of characters.?- exactly one character.
You cannot specify wildcards in the library or file part of the path, only on physical file members (after the last / ).
You test your patterns using the
Files in the root (/) file system
Files in this file system behave much like UNIX or Windows files, it has an hierarchical structure that users of these systems will be familiar with.
For example, if you are looking for files named P* in /home/REDWOOD/incoming, the file event should be specified as follows:
Directory: /home/REDWOOD/incoming
Pattern: P*
Notes on wildcards:
The following wildcards are supported:
*- any number of characters.?- exactly one or zero characters.
You cannot specify wildcards on the directory name, only the file name.
Creating Chains to Manage the Deletion of Flag Files
If you cannot use a move directory, you will need to use a chain and process to delete the file that triggers the event. To detect and remove files, create a chain and process definition with a wait event that calls the process that should be submitted when the file arrives. In the second step of this chain, use a process definition that uses the file.delete action to delete the file after it has arrived.
Troubleshooting
The process server will create operator messages each time a check is performed and the file cannot be read (missing authorization, invalid path). An operator message is also created when the move failed.