It's mostly a matter of how the routine comes to be in the first place. Usually I get tired of doing some repetitive task, so I write an exec for it. In such a case I almost always write it for foreground execution, and in the foreground I almost never look for DD names; I just allocate the DS dynamically by name. At that point, you see, I'm writing to please myself. Later on it turns out someone else would like to use it, so I put it in a common library, first making sure that any external calls are properly handled (either moved to the common library as well, or moved into the program). It's possible that at that point someone requests that it be made suitable for batch, and I add a check for DD names.
So the usual process is to start out allocating dataset names, and later (sometimes) to add a check for DD names. I don't think I've ever had a request to take a batch process, one that already used DD names, and make it suitable for the foreground with specific DSNs. So it's not a matter of ~shouldn`t~ look for DD names in the foreground; I just can't recall ever needing to do that. And I don't recall a user who prefers batch ever wanting to do an allocation by DSN instead; <troll>the whole point of DD names is that it allows the operator to substitute one dataset for another</troll>. Let me qualify: ~I~ often want to execute a batch process in the foreground, for my own convenience. So yeah, in that case I write a REXX wrapper that allows me to create a CA-CLEANUP listing via a foreground command, or a TSSSIM analysis, without having to set up the JCL for it. But aside from a DYL-280II syntax check, decades ago now, I don't recall any user asking me to do it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* The cities are for money but the high-up hills are purely for the soul. -from _Galloway_ by Louis L'Amour */ -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, March 31, 2020 14:58 Why shouldn't you look for special ddnames in foreground? Why shouldn't you allocate by dsn in batch if that's what the user wants? ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob Bridges [robhbrid...@gmail.com] Sent: Tuesday, March 31, 2020 12:20 PM Oh, that; I thought you meant some special JCL setting. Yeah, makes sense. Most of the utilities I write in REXX I write for foreground operation, command-driven, thus dynamic allocation like that. If someone prefers batch it's easy enough to write an IKJEFT01 for it, allocating SYSPROC and/or SYSEXEC as steplibs (so to speak). Or I can do it for them if their JCL-poor (as a surprising number of otherwise competent mainframers are these days). But when I'm converting a REXX for batch production, as in this case, I figure the client would prefer to have the advantages of JCL, that is, to be able to specify the DSNs at run time via DD names. Also it's what they're ~used~ to. So such a REXX is updated to say "if I'm running in batch, look for this DD name; otherwise use this DSN". That way it can look like regular batch to the folks who have to maintain batch JCL, and can still be run in the foreground as a command without a special wrapper as it was before it was added to the production schedule. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, March 30, 2020 21:53 Yeah, there's a way to avoid it but I suspect it is more trouble than what you are doing. Here is the longer version of my too telegraphic post: You write a program (assembler, C, Rexx?) to dynamically allocate SORTOUT to target.dataset with DISP=OLD and then link to or CALL SORT. BPXWDYN makes dynamic allocation pretty much a piece of cake (unlike the bad old days of multiple control blocks pointing to each other and pointing to "text units"). Your JCL now looks like // EXEC PGM=MYPROGRAM or perhaps PGM=MYPROGRAM,PARM='target.dataset' //SYSIN DD DSN=parmlib(mbr),DISP=SHR //SORTIN DD DSN=*.prev.prev,DISP=(OLD,DELETE) //SYSPRINT DD SYSOUT=* The job does not inherently tie up target.dataset. But your program would have to deal with what to do if target.dataset were not available. Wait a little while and try again? Repeat how many times? Make sense? -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Monday, March 30, 2020 3:34 PM It's clear you're trying to offer a solution, but I don't follow. Right, I'm using DISP=OLD. I take it "dynamic allocation" must mean "don't allocate the dataset until I'm ready to write to it", but when I do this: // EXEC PGM=SORT //SYSIN DD DSN=parmlib(mbr),DISP=SHR //SORTIN DD DSN=*.prev.prev,DISP=(OLD,DELETE) //SORTOUT DD DSN=target.dataset,DISP=OLD //SYSPRINT DD SYSOUT=* ...the target dataset is unavailable for Viewing until the job is complete. You're saying there's a way to avoid that? I mean, I did avoid it, but I did it by putting the SORT step in a separate job. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, March 30, 2020 18:01 Dynamic allocation? Just in time dynamic allocation DISP=OLD of the viewable dataset? -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Monday, March 30, 2020 8:51 AM It's beginning to sound like z/VSE is an improvement in several ways on z/OS. I wrote a production job recently that updates a dataset pretty much anyone can View (a list of current Top-Secret ACIDs to see what so-and-so's ACID is, or who belongs to ACID such-and-such). The update has to read a largish-security database. The last step is a SORT that takes less than a second - but I had to put it in a separate job, and have it triggered by the previous job, because otherwise the dataset would be unavailable for Viewing by any user while the long job was running. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, March 30, 2020 11:38 Actually, there is no 'allocation' of a file by z/VSE during the JCL processing. The file is only 'allocated' once it is opened and 'unalocated' once the program closes the file. For instance, if you have a 5 hour program, that just needs to update a 'totals' VSAM file at the end of the 5 hours, as long as the program does not open the file until it needs the file, any other program can use, including updating, the file until that time. So, basically, you 'own' the file only while you have it opened. One ramification is that you can't create a file simply by having in the jcl, like in z/OS. You have to open it to create it. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
