John Regarding your paranoia - pay-back time for false accusations of "ranting"! - over the PPT:
> Some STCs must still be single step, such as ... anything running a program > in the PPT. The best policy here would be actually to read up on what is said about multiple/single steps in the description of the attributes of a PPT entry as covered by the description of the PPT statement of the SCHEDxx member in the z/OS MVS Initialization and Tuning Reference manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2C1/76.6 Out of infinite kindness, I present the pointers here: <quote> ... For NODSI, the job must be a one-step job. If the job is not a one-step job, NODSI is nullified and the system issues message IEF188I. All other properties remain in effect. ... For SYST, the program must be a one-step job started by a START or MOUNT command. If these conditions are not met, SYST is nullified and the system issues message IEF188I. All other properties remain in effect. If procedures are multistep or if NOSYST is specified, TIME=1440 may be required to prevent timeout. ... </quote> As I have mentioned on a few occasions in IBM-MAIN in posts which have clearly been ignored, long ago in the days when I education/test systems, I encountered the irritating multiple step restriction caused by the SYST attribute. With the aid of the PPT statement of the SCHEDxx member of SYS1.PARMLIB, I simply denuded the infected program name of the SYST attribute and was happily able to run VTAM (ISTINM01), NetView(DSIMNT or BNJLINTX) and the address space corresponding to the IP component of Communications Server - "TCP/IP for MVS" at the time - (EZBTCPIP) as multiple steps without "issue". (What a shame they are childless!) One - perhaps the only one - of my objectives was to enable the introduction of an IEFBR14 step at the beginning of the procedure in order to ensure[1] that "trace and dump" data sets from any previous executions of the procedures were deleted - by the use of DISP=(MOD,DELETE). I was then able to allocate them as DISP=NEW data sets with minimal primary space allocation - keeping the limited DASD space at the disposal of my multiple systems all "neat and tidy". I appreciate that the considerations relating to my education/test environment do not apply to a production environment but, if the design of an "application" would suit multiple steps in the procedure, being put off because the PPT table CSECT, IEFSDPPT (module IEFSD060), entry for the program name happens to have the SYST attribute set should *not* be an inhibitor.[2] There is one consideration when SYST is removed which is that the EXEC statement associated with the previously infected program will now need TIME=1440 - or the equivalent. > Perhaps some shops ran a process as a job just in order to run multiple steps > which were procs. It is certain that actually reading the manual would have been more productive in the long run - but there's no accounting for folk! > In the past, an STC had to be a single PROC. How far into the past would that be? I used to play "fast and loose" with the SYST attribute from around the late 1980s IMMSMC. - [1] I've just read a post where the word "insure" was used when it was "ensure" that made sense of what appeared to be being said. Is this yet another case of folk between the shining seas "evolving" the originally English language? From Googling: - ensure: Make certain that (something) shall occur or be the case. - insure: Provide insurance coverage [2] I did ask about whether there might be some disadvantages undocumented in the description of the SYST attribute in the z/OS MVS Initialization and Tuning Reference manual in IBM-MAIN some time ago. There were a few replies but no evidence of hidden dangers was forthcoming. Archive reference (Search on Subject Contains: SYST, Author's Address: Mason): Subject: SYST From: Chris Mason Date: Sat, 25 Feb 2006 16:58:39 +0100 Hm! Having made sure that I could refer folk to my "SYST" thread, I couldn't resist reminding myself of the responses. It turns out that some character going by the name of "John McKown" responded. Now, who would that be, I wonder? - Chris Mason On Fri, 10 Aug 2012 11:05:28 -0500, McKown, John <john.mck...@healthmarkets.com> wrote: >What you have said was true in the past, about jobs having more data in SMF >than STCs sometimes did. Some STCs must still be single step, such as an >external writer or anything running a program in the PPT. This is not true of >CICS. We run multi-step CICS regions as started jobs (not tasks) as our >standard. Perhaps some shops ran a process as a job just in order to run >multiple steps which were procs. In the past, an STC had to be a single PROC. >Also, with STC (started procs), all the STCs ran with the same, generated, >pseudo-JOB card. Some shops wanted to run with different job accounting >parameters, for billing purposed. They either had to do some fancy exit >programming, or ran as a batch job. But with started jobs, you can now run an >STC as a "started job" (complete with JOB card with all parameters except >CLASS=) with multiple EXEC PROC= steps. Also, you can now nest PROCs and so >have an STC be a PROC, but that that PROC can run the other PROCs required in >order. > >We run CICS as a "started job". I changed to this on the first release of z/OS >in which it was available. > >-- >John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
