I don't think I see the flaw yet. How would you define it? Because all DSDD does is tell me whether a character string represents a (catalogued) DSN and/or an (allocated) DDN; and if the problem you're thinking of is that the situation may have changed milliseconds later, how will any other routine avoid that? I'm sure you have something in mind, but I don't know what.
--- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Don't be daunted and intimidated by the thought police. Despite what they'd have you believe, you are not a criminal. Stick to your principle; don't be afraid to unapologetically admit your belief in those corny old traditional values. Ultimately, this will get you respect. Once you have respect, then you will have the ability to persuade. That's the way to reclaim our culture. -from "See, I Told You So" by Rush Limbaugh */ -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin Sent: Thursday, August 22, 2024 18:26 And of programmers for using such a flawed improvised routine when they could use a standard one without the flaw. --- On Thu, 22 Aug 2024 16:57:05 -0400, Bob Bridges wrote: >Wait, so was Gil just asking whether there's a "danger" of (for example) the >DSN not being there when I run DSDD, but then coïncidentally having been >catalogued 20 milliseconds later when I start to try to create it? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
