There is a bug with the LIKE function in Query and SQL. The PTF to fix it (MF- 03591) is available from IBM. Also, there is a bug using some files in SQL with the UNION clause. IBM hasn't fixed this one yet. Do not be surprised if you encounter some problems in the Query arena. Everything else seems to be fairly solid.
We initially did not have any problems with V2R1M1 (even Query). Lately, we have found one nasty little gotcha that seems to be related to the version switch.
I am not sure what makes it happen, but every once in a while, all commands related to printer writers become inoperable. This includes WRKWTR, STRPTRWTR and the F22 key in WRKOUTQ. When you try to execute any of these, you get a machine dump for message MCH0605. The only way we have found to return these commands to a working state is to delete the top file in the output queue.
IBM Level 2 is aware of the problem and is working to correct it. It has happened to us three times since our switch to V2R1M1 in March. Luckily, the top spool file in all three cases was such that we could regenerate later.
So far Rochester hasn't found a solution yet.
We went from V1R3 to V2R1M1 two weeks ago and ran into a boatload of problems, mostly related to the S/36E which we run in 99 percent of the time.
Evoked jobs started going to QCTL subsystem and running in "BCI" (Batch Command Interactive). This was corrected by altering our S/36 configuration environment.
Also, if you run a CLRPFM command and the member being cleared does not exist, the default response changes from a soft ignore to a hard continue or cancel.
As far as I am aware, there are no fixes for the EVOKE or CLRPFM problem, other than manually altering your S/36E environment. For the EVOKE problem, shut down your S/36E environment, then change the "Evoke" parameter in the S/36 configuration. (For more details on this fix, see "Significa," MC, May 1992, "V2R1.1-Proceed With Caution.") For the CLRPFM, you can change the default response for the error message. This seemed to correct the problem for us.
Anyone who is using the S/36E will want to look at SF09670 in 5738SS1. This is required when a procedure does a GO command. The system will kinda lose its way. See the cover letter for a full explanation.
Level 2 recommended this to us even though we don't run S/36E. Our B35 hiccupped and went into continual dumps for a couple of jobs. Two 4700-page joblogs!!! So, if you are not running S/36E, you might still want to look at SF09670. I am not convinced that we had the same problem, or that this was solved. But better to be safe than to worry.