When encountering mysterious VISION:Inform problems, they may be rooted in running it across multiple systems.
These are things to consider when multiple systems are involved.
1. Check to make sure the ENQUE is getting cleared. Possible culprits:
- The VISION:Inform online system and batch controller running on different CPUs without a global enque manager,
or not listing VISION:Inform as a program needing such management). Having multiple CPUs executing any online or batch VISION:Inform program that writes to one of our files, but not having GRS (Global Resource Serialization by IBM), or another serialization product, active. These are necessary to ensure that updates do not occur from a VISION:Inform program on a CPU that the other VISION:Inform program has no way to know about.
- A single CPU running PRISM - same problem as above
- Using different ENQUE names in the PARMBLKs for online vs the batch controller
2. Using a product called HYPERCACHE with the option to hold the output buffers. Adding //VVHCDFRN DD DUMMY to the batch controller JCL does not resolve the problem. Even with this DD statement HYPERCACHE is still active. This will cause the batch controller to update in memory while the online system is updating the physical file. This will corrupt the file and 3513 abends in JX at x'842' will result. Therefore, HYPERCACHE cannot be used with VISION:Inform if the batch controller(s) will be running at the same time the online system is active.
3. Having a product that optimizes VSAM or performs caching, such as HiperSpace or VSAM I/O Plus. If these are active or affecting the COMFILE buffers, they will invalidate our integrity.
4. The COMFILE FCT entries STRNO=1 and BUFND=2 are not optional or changeable.
If using RDO, this translates to specifying 1 INDEX BUFFER and 2 DATA BUFFERS.
5. The IDCAMS define for the COMFILE must specify a buffer size twice the CI size.