Tried that, it didn't work.
Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&[email protected] On Wednesday, February 19th, 2025 at 10:31 AM, Ituriel do Neto <[email protected]> wrote: > Perhaps the parameter DSENQSHR=ALLOW in JOBCLASS (JES2PARM) is helpful. > > > Best Regards > > Ituriel do Nascimento Neto > z/OS System Programmer > > > > > > > Em quarta-feira, 19 de fevereiro de 2025 às 12:22:40 BRT, Peter Vander Woude > [email protected] escreveu: > > > > > > > We run into this type of issue a lot, with the MQ/MFT transfer tool and batch > jobs, as the agent portion runs as a STC. If the batch job submits to send a > file, but has any step, after the step running the request to send the file, > that references the file to do something like delete the dataset, the > transfer will fail, as the stc will fail on it's dynamic allocation of the > dataset can fail. > > We also run into the situation where a file transfer to the mainframe fails, > as it wants to create a gdg, but it hits when a job is processing the entire > gdg, with disp=old. > > Peter > > On Wed, 19 Feb 2025 14:41:55 +0000, Mark Jacobs [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. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get&[email protected] > > > > On Wednesday, February 19th, 2025 at 9:01 AM, Paul Gilmartin > > [email protected] wrote: > > > > > On Wed, 19 Feb 2025 12:17:48 +0000, Mark Jacobs [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://www.ibm.com/docs/en/zos/2.4.0?topic=fields-additional-flags-s99flag2 > > > > > > 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 > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
