I run into this issue regularly when recreating or refreshing a dataset allocated to a DEV CICS. The close/unenable of the CICS file (using a batch CEMT utility) has to happen in one job followed by the recreate/refresh job which can also re-open/enable the CICS file in the last step.
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Scott Barry Sent: Wednesday, February 19, 2025 11:48 AM To: [email protected] Subject: Re: Enqueue Question My understanding (always has been) is that one cannot allocate a same-named dataset (to be cataloged) in a given "shared environment" SYSPLEX. I have faced this same situation with SMF data-archival where a copy is forwarded via FTP from the creating-LPAR over the fence to another central-repository (SMF data maintained for long-period) LPAR environment, where the two dataset names must be unique and an allocation failure occurs on the "other" system, when attempted. Scott Barry SBBTech LLC On Wed, 19 Feb 2025 14:41:55 +0000, Mark Jacobs <[email protected]<mailto:[email protected]>> wrote: >Please excuse me for confusing people, I confused myself too. Reading the logs >again, here's the actual scenario. > >1) Step one initiates a data transfer to another system in the sysplex. >2) Step two allocates a dataset with the same dataset name for *reasons*. > >The dynamic allocation failure that's returned in the log actually occurs on >the remote system. There's a shared enqueue already for the target dataset so >the attempt by the receiving system to allocate the dataset, I assume its >requesting exclusive fails. > >Mark Jacobs > > >Sent from ProtonMail, Swiss-based encrypted email. > >On Wednesday, February 19th, 2025 at 9:01 AM, Paul Gilmartin ><[email protected]<mailto:[email protected]>> > wrote: > >> On Wed, 19 Feb 2025 12:17:48 +0000, Mark Jacobs >> [email protected]<mailto:[email protected]> wrote: >> >> > One of the things I'm going to test is whether setting S99NORES in >> > S99FLAG2 might work. If so all we need to do is convince the software >> > vendor to support setting it on a job-by-job basis. >> >> https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.4.0?topic=fields-additional-flags-s99flag2__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KGM1S7sHEIYdyZ0k8MvV_9erVh0CBzom1bMxJGEYYcfxITGzLz48GQmqlLCqBKbJ3qRqHv0qK0RMSPRyUMC5qft7$<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/2.4.0?topic=fields-additional-flags-s99flag2__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KGM1S7sHEIYdyZ0k8MvV_9erVh0CBzom1bMxJGEYYcfxITGzLz48GQmqlLCqBKbJ3qRqHv0qK0RMSPRyUMC5qft7$> >> >> Note: Data sets being allocated are normally serialized via ENQ with MAJOR >> name SYSDSN, MINOR name -data set name-. When S99NORES is set, there is NO >> data set serialization and multiple tasks may reference or update the data >> set simultaneously, resulting in unpredictable effects. It is the >> responsibility of the authorized program setting S99NORES to provide the >> necessary serialization. >> >> Do you want to do that? It might be a hard sell with the vendor. >> >> "Vendor"? Is that vendor using multiple address spaces? >> >> -- gil This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
