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?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ 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 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARM= vs PARMDD= and symbol substitution 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. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Back in the old days, most families were close-knit. Grown children and their parents continued to live together, under the same roof, sometimes in the same small, crowded room, year in and year out, until they died, frequently by strangulation. -Dave Barry */ -----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
