On Fri, 29 Mar 2019, at 17:29, Paul Gilmartin wrote: > On Fri, 29 Mar 2019 12:56:59 -0400, Jeremy Nicoll wrote: > > > >In the calling exec the rc from the (ispf) edit would be checked, because > >invoking edit might have failed, eg because of spfdsn enqueues on the > >target file. In the 'production' systems I wrote the execs usually then > >slept for a few seconds, then tried again (when they were part of the > >batch jobs). If the edit was something invoked from an ispf dialog run > >in the foreground, the dialog might have told the user to try again (as > >they'd probably already have seen a line-mode dataset contention > >message). > > > I have, on occasion, added a final step, IEFBR14,COND=(0,LE) with > a DD DISP=SHR for any such data set so my job would be held by > the initiator until the data sets were available. > > (Always JES2)
One system had a PDS containing members each of which were requests for something for a specific day. Different users could (via the dialogs) append more requests into a particular day's member even while a batch job had been demanded (via CA7) to deal with those requests. Right up to the point where the batch job actually began to process requests more could be added. And, if for some reason the batch job abended and went through restart, it would subsequently deal with more requests added to that same member in the interim period (ie while the data files, usually recalled from ML2, were still available for immediate use). It wasn't practical to prevent access to these 'sysin' members while the jobs using them ran. IIRC the running jobs also updated the members with state info about the results of running the jobs, eg locations in the sysout database [SAR] where individual users' results had actually been placed. I can't quite remember if the dialogs I'd written also front- ended extraction of reports from SAR so they needn't be printed (as had previously been the case) to the users' locations. In a different system I wrote, the front-end dialogs set up parameters for much more rarely-run batch jobs, but the process of parm setup then authorising a run of such a job renamed the parameter file (as did other steps like CA-7 demanding the relevant batch job started, using SA/390 to track that specific job's progress/abend/restart etc.) The renames of these files allowed us to control who (users, or schedulers/ops, or SA/390's auto-ops etc) could transition each such job through its different states. (This latter system also ran started tasks as part of the overall control. It was quite complicated...) -- Jeremy Nicoll - my opinions are my own. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
