Re: COBOL's NUMPROC compiler option
Very good question. Related... Has it been detailed just exactly what the differences between NUMPROC(MIG) and NUMPROC(NOPFD) are? And an even better question, what (if any) differences are there in the end results? From what I've observed by looking at the pseudo-assembler output. Hopefully I've observed correctly! Compare signed to signed (same length) - MIG: CP - NOPFD: CP - PFD: CLC Compare unsigned to unsigned (same length) - MIG: CP - NOPFD: fix-up both, then CLC - PFD: CLC Compare signed to signed (differing lengths) - MIG: CP - NOPFD: CP - PFD: CP Compare unsigned to unsigned (differing lengths) - MIG: CP - NOPFD: fix-up both, then CP (*) - PFD: CP Compare signed to unsigned (any length) - MIG: CP - NOPFD: fix-up unsigned, then CP (*) - PFD: CP (*) Seems to me no fix-up is necessary since CP is being used anyway. Maybe I'm missing some understanding? Frank - Original Message - From: Timothy Sipples sipp...@sg.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Cc: Sent: Tuesday, April 21, 2015 4:13 AM Subject: Re: COBOL's NUMPROC compiler option OK, but what are we talking about here, in performance terms? NUMPROC(MIG) versus NUMPROC(NOPFD) offered some performance benefit in the past, but Enterprise COBOL 5.x offers a performance benefit, too. Basically, is this 2 steps forward 1 step back, or is it 1 step forward 2 steps back? The overall performance outcome is what matters, surely. I assumed that a hypothetical NUMPROC(MIG) would continue to offer some sort of performance benefit with Enterprise COBOL 5.x, but that's not actually a given. The 5.x compiler has a different design, and what was beneficial in the past may be less beneficial now -- or not beneficial at all. Let's just note that assumption for now. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- 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
Re: A Data Studio question
IDUG runs the DB2-L list. Most helpful people over there... http://www.idug.org/p/cm/ld/fid=78 Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
In CAGx7iU0u=mgg3ztz3_cadorybuseauewzm8ulhv9yc7re5p...@mail.gmail.com, on 04/20/2015 at 05:13 PM, Steff Gladstone steff.gladst...@gmail.com said: How do I use the ISGENQ macro in such a way that the ENQ lasts for the life of the entire job (or several job steps) and not just for the life of a single job-step? Cautiously and with trepidation. Would specifying the TCB address of the initiator TCB on the TCB parameter work? That depends on your definition of work. It will do what you expect most of the time and will provide some excitement when it doesn't. Any better ideas? Allocaring a data set with DISP=(OLD,PASS) would be a lot safer. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
In 8918505894176310.wa.m42tomibmmainyahoo@listserv.ua.edu, on 04/20/2015 at 03:11 PM, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu said: It is easy for us to fault the designers of System/360 and OS/360 for not considering the future requirement for more than 16 MB. Especially if you were familiar with other vendors, who were ahead of IBM is several ways. I was certainly appalled by the S/360 limitations, except that I failed to identify the limited number of channels as a choke point. In 1964, that seemed like plenty of addressable memory. Not to me. Storage capacities of more than the commonly available 32,000 words would be required. Other vendors were using addresses larger than 15 bits. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
In 7935647633061500.wa.paulgboulderaim@listserv.ua.edu, on 04/20/2015 at 09:39 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: I'm a skeptic about Postel's Principle. Google for MBZ. Your point on F zones is well taken, but given the card heritage IBM may effectively not had a choice there. I'll even go so far as to say that if the original s/360 had raised an addressing excption when bits 0-7 of a base or index register were nonzero, transition from 24-bit to 32-bit addressing would have been much facilitated. Big time. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
In caajsdjhnhdj9azcgh+hwmwm46xyxkwzkmpmrk_-9x1m6pul...@mail.gmail.com, on 04/20/2015 at 10:09 AM, John McKown john.archie.mck...@gmail.com said: I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the i nternal information for a DD and place that as if it had been in a DD in the JCL. Possible, yes. Easy or prudent, no. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
OK, but what are we talking about here, in performance terms? NUMPROC(MIG) versus NUMPROC(NOPFD) offered some performance benefit in the past, but Enterprise COBOL 5.x offers a performance benefit, too. Basically, is this 2 steps forward 1 step back, or is it 1 step forward 2 steps back? The overall performance outcome is what matters, surely. I assumed that a hypothetical NUMPROC(MIG) would continue to offer some sort of performance benefit with Enterprise COBOL 5.x, but that's not actually a given. The 5.x compiler has a different design, and what was beneficial in the past may be less beneficial now -- or not beneficial at all. Let's just note that assumption for now. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
From your other posts I understand that you don't want to change JCL, but you are able to change the code of the relevant programs and you know all the programs that are part of this operation and could do other operations or changes affecting your change management system operation. So: have you considered, for example, to insert the name of the program into a DB2 table, when starting the CCM operation, deleting it from there, when finishing, and checking by the other operations, which are not allowed to run in parallel? If you don't like DB2, take any other system that is able to hold some program names for some amount of time. You need three functions: insert, delete, check ... and the table of names actually in process must be stored anywhere. When considering the DB2 solution, I would add a timestamp for the starting time ... so it would be able for a job to diagnose and report CCM processes that never terminated at a certain point in time ... (every hour or so). BTW: I was - with others - responsible for the CCM system of a large company for 10 years (1995 to 2005); we did the mainframe change management using a homegrown system based on C, DB2 and REXX; ISPF, too; this worked pretty well. The system is still in use today. Kind regards Bernd Am 20.04.2015 um 17:36 schrieb Steff Gladstone: The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. On Mon, Apr 20, 2015 at 6:19 PM, Jousma, David david.jou...@53.com wrote: Maybe if you can explain in more detail what situation you are trying to solve for would help? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: User SMF Type 202?
Elardus Engelbrecht wrote: Hmmm, I always wanted to ask on IBM-MAIN: Are there any non-IBM software which enforces you to use SMF type number without giving you ability to override that number in parms or exit? Something like 'Use *my* number or die'... That list is indeed in Cheryl's SMF booklet. Thanks to the person who was very kind to tell me offlist how to look for them. Ok, ok, ok. It is a case of '*look yourself* or die' for me... ;-D Here my grateful thanks to that person who shall remains unnamed on IBM-MAIN. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Experiences
On 21 April 2015 at 06:51, Timothy Sipples sipp...@sg.ibm.com wrote: To pick another analogy, I don't think I've ever seen a rail system where the locomotive is outsourced but the train cars continue to be run in-house, or vice versa. Well I imagine things are much different in Singapore. Here in North America the majority of rail cars are not owned by the company who owns the locomotive. Rails, locomotives, cars, and train crews can all be owned and/or managed by different organizations. It seems to work rather better than the 19th century rail monopolies. To pick yet another example, building cleaning is often outsourced -- but the whole service is outsourced, with a clear, measurable set of objectives (clean buildings). Would you ever outsource only mopping the floors but keep sweeping, dusting, and wiping in-house? That'd be a predictable disaster, wouldn't it? Perhaps. On the other hand the window cleaning in this building is done by a window cleaning company, but other external and internal cleaning is done either in-house or by other companies who don't do exterior windows. Based on recent observation this seems to also be the model for other nearby office buildings. It too seems to work pretty well, perhaps because exterior window cleaning is a very specialized business. I don't actually disagree much with your views on IT outsourcing, but your analogies range from weak to facile. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: User SMF Type 202?
I searched a little on MXG.com and found only ICFIDs for 202. In 12.227 circa 1994 there is an update for FDR IAM support added. In a message dated 4/21/2015 8:51:06 A.M. Central Daylight Time, neil.e.er...@wellsfargo.com writes: IAM?? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
User SMF Type 202?
Is there any other list of in-use User SMF record types in addition to Cheryl's? (http://www.watsonwalker.com/SMFreference.pdf) Is anyone aware of any product that generally uses Type 202? (And yes, I know that generally programs that involve User SMF Record Types allow the specification of a user-preferred number.) Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Mon, Apr 20, 2015 at 8:37 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In caajsdjhnhdj9azcgh+hwmwm46xyxkwzkmpmrk_-9x1m6pul...@mail.gmail.com, on 04/20/2015 at 10:09 AM, John McKown john.archie.mck...@gmail.com said: I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the i nternal information for a DD and place that as if it had been in a DD in the JCL. Possible, yes. Easy or prudent, no. I totally agree. I myself personally would only do such coding if forced to under threat of termination (mine, not the job's). But I am great believer in telling a person that they can indeed shoot themselves, if they really want to, by buying a gun and ammo. I won't sell it to them, but I will let them know that such technology exists. -- Shmuel (Seymour J.) Metz, SysProg and JOAT -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 as primary with JES3 as a secondary
Karl, If you are not aware - there are also a JES2 and JES3 list. If you would like to join, go to these URLs JES2http://listserv.vt.edu/cgi-bin/wa?A0=jes2-l JES3http://www.listserv.uga.edu/archives/jes3-l.html The biggest difference I see is that JES3 needs to know it owns resources before it will let things run. JES2 does not. That may be a consideration in trying to run JES3 under JES2 Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Henn, Karl Sent: Tuesday, April 21, 2015 3:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 as primary with JES3 as a secondary Hello JES experts, My practical experience with JES3 is near zero, or even below zero. The software we develop rarely ever has to take into consideration the differences between JES2 and JES3. I can remember only 3 such cases in the past more than 15 years I have been working here. Every now and then, though, it would be nice to be able to perform a quick test on a JES3 system. However, I cannot spare an LPAR, and I do not have the time and the resources to set up and maintain a z/OS JES3 system on a permanent basis. So, not surprisingly, my thoughts wandered off to the possibility of a secondary JES; I had done that before, yet only with all JES2s. Frustration came quick: The JES3 to JES2 Migration Considerations (SG24- 8083-00) on page 6 reads: You can also define a JES3 as the primary and JES2 as a secondary subsystem (however running JES2 and JES3 on the same z/OS image is not currently supported, though there are no known problems). If JES3 is running on a system, it must be the primary job entry subsystem. You cannot run JES2 as the primary subsystem and JES3 as a secondary subsystem.. My question; Does anybody know a - dirty? - trick to still do that, run JES2 as primary with JES3 as a secondary? What/Where is the ruse? I mean, it works the other way around. I'm not afraid of experimenting; I might possibly even find a test LPAR that I can shred on a weekend. I'm looking forward to your suggestions. Thanks a lot in advance. Best Regards Karl -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Tue, Apr 21, 2015 at 7:00 AM, Steff Gladstone steff.gladst...@gmail.com wrote: Even without modifying the SWA with information for the DD, as you suggested earlier? Yes, you can do the directed ENQ yourself without modifying the SWA. Which, by the by, I _mentioned_, not _suggested_. At least, I didn't mean for it to be a suggestions. It's the fly with a shotgun approach. The main problem with the directed ENQ to the initiator TCB is still how to get the DEQ done at end of job?. That is the sticking point in this whole thing. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: User SMF Type 202?
IAM?? Neil E. Ervin Mainframe Performance Analyst Mainframe/Midrange Services Wells Fargo Compute Platform Services l North Carolina (Eastern Time Zone) MAC D1112-023 Cell 910-477-2536 l Text Pager: 9104772...@vtext.com neil.e.er...@wellsfargo.com TOG Recognition -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, April 21, 2015 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: User SMF Type 202? Is there any other list of in-use User SMF record types in addition to Cheryl's? (http://www.watsonwalker.com/SMFreference.pdf) Is anyone aware of any product that generally uses Type 202? (And yes, I know that generally programs that involve User SMF Record Types allow the specification of a user-preferred number.) Thanks, Charles -- 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
Re: User SMF Type 202?
Charles Mills wrote: Is there any other list of in-use User SMF record types in addition to Cheryl's? Cheryl is the only one person who is really kind enough to produce that handy document. Thanks Cheryl! I can't live without those small booklets. Is anyone aware of any product that generally uses Type 202? No, AFAIK. (a$$uming you mean, default of [override-able] 202) But, why are you asking? Having a conflicting usage or what? Trouble with SMFWTM and friends? (And yes, I know that generally programs that involve User SMF Record Types allow the specification of a user-preferred number.) Hmmm, I always wanted to ask on IBM-MAIN: Are there any non-IBM software which enforces you to use SMF type number without giving you ability to override that number in parms or exit? Something like 'Use *my* number or die'... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Tue, 21 Apr 2015 11:00:20 +0300, Steff Gladstone wrote: how does the operating systen itself maintain a continuous ENQ over several job steps for a dataset allocated in the first step with disp=(mod,pass)? It isn't so much a question of How as Who. The Initiator performs the ENQ and ATTACHes the Job Step TCB. When the job step ends, it ATTACHes the Job Step TCB for the next step. When the last step ends, it cleans up. Lots of fancy error recovery code is also involved. You said that your process has to be multiple job steps, but if you had a main program that called (or attached) the other programs that need to run to perform the process, you could do the same thing, with an ENQ that covered the whole process. Any necessary allocation and deallocation could be done by the main program. You have also not said how you plan to ensure that other processes do not change the program. What is to stop me from compiling and binding the program outside of your process? Or using IEBCOPY? The ENQ will not do it. These programs will not issue an ENQ against your resource name. There is nothing magic about ENQ. It only works if all of the users of the resource, in this case the program, issue an ENQ against the same resource name. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES2 as primary with JES3 as a secondary
Hello JES experts, My practical experience with JES3 is near zero, or even below zero. The software we develop rarely ever has to take into consideration the differences between JES2 and JES3. I can remember only 3 such cases in the past more than 15 years I have been working here. Every now and then, though, it would be nice to be able to perform a quick test on a JES3 system. However, I cannot spare an LPAR, and I do not have the time and the resources to set up and maintain a z/OS JES3 system on a permanent basis. So, not surprisingly, my thoughts wandered off to the possibility of a secondary JES; I had done that before, yet only with all JES2s. Frustration came quick: The JES3 to JES2 Migration Considerations (SG24-8083-00) on page 6 reads: You can also define a JES3 as the primary and JES2 as a secondary subsystem (however running JES2 and JES3 on the same z/OS image is not currently supported, though there are no known problems). If JES3 is running on a system, it must be the primary job entry subsystem. You cannot run JES2 as the primary subsystem and JES3 as a secondary subsystem.. My question; Does anybody know a - dirty? - trick to still do that, run JES2 as primary with JES3 as a secondary? What/Where is the ruse? I mean, it works the other way around. I'm not afraid of experimenting; I might possibly even find a test LPAR that I can shred on a weekend. I'm looking forward to your suggestions. Thanks a lot in advance. Best Regards Karl -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Tue, Apr 21, 2015 at 3:00 AM, Steff Gladstone steff.gladst...@gmail.com wrote: Thank you all for for help. The obvious question that remains is: how does the operating systen itself maintain a continuous ENQ over several job steps for a dataset allocated in the first step with disp=(mod,pass)? Is there a special privileged ENQ operation that only the operating system has access to? No, there is not a special ENQ. The initiator TCB, which exists for as long as the initiator is running, issues the ENQ. The initiator (in general terms) is what reads the parsed JCL and creates the SWA control blocks which represent the job. This code then knows the DSNs in the job and issues a single ENQ for _all_ of them before starting the first step. As each step ends, the initiator does a DEQ on the DSNs which are not going to be used in subsequent steps. At the end of the job, it DEQs whatever DSNs are left. This means that you _could_ use a directed ENQ to put the DSN on the ENQ chain for the initiator TCB, as you mentioned in a previous post. But since the initiator does not know anything about that, it will not know to do a DEQ to release it at end of job. This is why you would need a terminating step to do the DEQ. Thinking about it a bit more, given what Mr. Relson said about RTM, doing this _should_ work even if the initiator terminates abnormally since RTM should clean up the ENQs during EOM processing. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
Even without modifying the SWA with information for the DD, as you suggested earlier? On Tue, Apr 21, 2015 at 2:50 PM, John McKown john.archie.mck...@gmail.com wrote: On Tue, Apr 21, 2015 at 3:00 AM, Steff Gladstone steff.gladst...@gmail.com wrote: Thank you all for for help. The obvious question that remains is: how does the operating systen itself maintain a continuous ENQ over several job steps for a dataset allocated in the first step with disp=(mod,pass)? Is there a special privileged ENQ operation that only the operating system has access to? No, there is not a special ENQ. The initiator TCB, which exists for as long as the initiator is running, issues the ENQ. The initiator (in general terms) is what reads the parsed JCL and creates the SWA control blocks which represent the job. This code then knows the DSNs in the job and issues a single ENQ for _all_ of them before starting the first step. As each step ends, the initiator does a DEQ on the DSNs which are not going to be used in subsequent steps. At the end of the job, it DEQs whatever DSNs are left. This means that you _could_ use a directed ENQ to put the DSN on the ENQ chain for the initiator TCB, as you mentioned in a previous post. But since the initiator does not know anything about that, it will not know to do a DEQ to release it at end of job. This is why you would need a terminating step to do the DEQ. Thinking about it a bit more, given what Mr. Relson said about RTM, doing this _should_ work even if the initiator terminates abnormally since RTM should clean up the ENQs during EOM processing. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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
Re: ENQ for the life of the job
On Tue, 21 Apr 2015 11:20:24 -0400, Robert A. Rosenberg wrote: ... a IMO major design flaw in the ENQ process the Initiator can be forced to hold an ENQ for subsequent steps where it is no longer needed. The case I am talking about is there is no way to convert an EXC ENQ into a SHR one. What z/OS release are you thinking of? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Tue, Apr 21, 2015 at 10:20 AM, Robert A. Rosenberg hal9...@panix.com wrote: At 06:50 -0500 on 04/21/2015, John McKown wrote about Re: ENQ for the life of the job: ŠThe initiator (in general terms) is what reads the Šparsed JCL and creates the SWA control blocks which represent the job. This code then knows the DSNs in the job and issues a single ENQ for _all_ of them before starting the first step. As each step ends, the initiator does a DEQ on the DSNs which are not going to be used in subsequent steps. At the end of the job, it DEQs whatever DSNs are left. While this description of ENQ and DEQ handling is correct it leaves out the fact that due to a IMO major design flaw in the ENQ process the Initiator can be forced to hold an ENQ for subsequent steps where it is no longer needed. The case I am talking about is there is no way to convert an EXC ENQ into a SHR one. The Initiator is forced to keep an EXC ENQ active for steps where only SHR is what is enough/desired. This design flaw in ENQ mains that if a DSN is DISP=OLD/MOD in step 1 and DISP=SHR in all the following steps the DISP=OLD/MOD ENQ is unnecessarily held until the last DISP=SHR step (or the JOB) is over. This prevents other jobs that should be allowed to run from being allowed to run due to the no longer needed EXC ENQ being held during DISP=SHR steps. In theory allowing the EXC-SHR ENQ change would be simple since all that is needed is to alter the ENQ entry in the queue from EXC to SHR and then drive the part of the DEQ routine that runs the queue to release pending SHR entries that are waiting for the DEQ of the EXC ENQ at the head of the chain. The ability to atomically downgrade an ENQ from EXC to SHR is now/soon to be available in z/OS. I don't remember if it is a PTF or release 2.1.1 . -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
At 06:50 -0500 on 04/21/2015, John McKown wrote about Re: ENQ for the life of the job: ÐThe initiator (in general terms) is what reads the Ðparsed JCL and creates the SWA control blocks which represent the job. This code then knows the DSNs in the job and issues a single ENQ for _all_ of them before starting the first step. As each step ends, the initiator does a DEQ on the DSNs which are not going to be used in subsequent steps. At the end of the job, it DEQs whatever DSNs are left. While this description of ENQ and DEQ handling is correct it leaves out the fact that due to a IMO major design flaw in the ENQ process the Initiator can be forced to hold an ENQ for subsequent steps where it is no longer needed. The case I am talking about is there is no way to convert an EXC ENQ into a SHR one. The Initiator is forced to keep an EXC ENQ active for steps where only SHR is what is enough/desired. This design flaw in ENQ mains that if a DSN is DISP=OLD/MOD in step 1 and DISP=SHR in all the following steps the DISP=OLD/MOD ENQ is unnecessarily held until the last DISP=SHR step (or the JOB) is over. This prevents other jobs that should be allowed to run from being allowed to run due to the no longer needed EXC ENQ being held during DISP=SHR steps. In theory allowing the EXC-SHR ENQ change would be simple since all that is needed is to alter the ENQ entry in the queue from EXC to SHR and then drive the part of the DEQ routine that runs the queue to release pending SHR entries that are waiting for the DEQ of the EXC ENQ at the head of the chain. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Tue, 21 Apr 2015 11:20:24 -0400, Robert A. Rosenberg wrote: ... due to a IMO major design flaw in the ENQ process the Initiator can be forced to hold an ENQ for subsequent steps where it is no longer needed. The case I am talking about is there is no way to convert an EXC ENQ into a SHR one. From the z/OS 2.1 announcement: quote z/OS V2.1 Global Resource Serialization (GRS) supports synchronously changing an exclusive enqueue to a shared enqueue, in addition to the existing support for changing an enqueue from shared to exclusive. Corresponding support is available in JCL for a new JOB statement keyword to enable you to specify that access to data sets can transition from exclusive to shared after the last step in which they are allocated with a disposition of OLD, NEW, or MOD. Also, support is available for a JES2 initialization statement to specify whether this function should be allowed, and whether it should be used by default if not specified in JCL. This function is intended to permit more parallelism in resource processing by allowing resources to be available for read access before the process that originally requested exclusive use ends in single-system and GRS Star environments. /quote -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
In CAGx7iU1q55ZSw_pYRWmnMEs0DB1GYHnC28k7MJP_cHe=clv...@mail.gmail.com, on 04/21/2015 at 11:00 AM, Steff Gladstone steff.gladst...@gmail.com said: The obvious question that remains is: how does the operating systen itself maintain a continuous ENQ over several job steps for a dataset allocated in the first step with disp=(mod,pass)? The Initiator does the ENQ. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Grid Config four clusters
We are currently operating a Grid configuration with four clusters. Unfortunately some of the tapes that were inserted into our local cluster went into the wrong catagory code. Also unfortunately we cannot get the entry exit disabled on the remote host so of course it's possible that any host in the grid can service this request. Thus far we have not been successful in getting these tapes to the correct catagory code. So I thought I would post something here in case any of you have run into this and found a way to work around it. Two Clusters in the Grid are IBM 7740 The Two others are IBM 7720. We are using Jes3 and CA-1 for this system. Any help would be greatly appreciated. Thanks John Benik -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
MVS Solutions' Thruput Manager product is able to dynamically add limiting agents to JCL based on a set of rules, so that might be worth looking at. Jonathan Eosze | Sr Computer Sys Engr | IT Operations Mainframe Management 1 (IMS), Information Technology, USAA -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson Sent: Monday, April 20, 2015 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: ENQ for the life of the job OP is clear about not wanting to change JCL. I've never tried anything like this, but maybe code in a system exit would work. I'm thinking of either JES or SMF, both of which have exit points at job initialization and termination. One issue not mentioned so far is how any transparent mechanism is supposed to know which 'program name' to enqueue on. I assume that varies by job. Also, could a particular job execute more than one such program and therefore need multiple enqueues? Just another consideration... . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Monday, April 20, 2015 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job As previously suggested, initial IEFBR14 step (e.g.) //step1 exec pgm=iefbr14 //dd1dd dsn=hlq.program,disp=(mod,pass),space=(trk,1,1),unit=sysda And simply never reference hlq.program in the jobstream. This will prevent multiple concurrent processes on the same program and is a lot less work than some of the other suggestions in this thread. HTH, snip The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. + On Mon, Apr 20, 2015 at 6:19 PM, Jousma, David david.jou...@53.com wrote: Maybe if you can explain in more detail what situation you are trying to solve for would help? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 /snip -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: Monday, April 20, 2015 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. -- 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 /
Re: ENQ for the life of the job
On Tue, 21 Apr 2015 11:05:51 -0500, John McKown wrote: The ability to atomically downgrade an ENQ from EXC to SHR is now/soon to be available in z/OS. I don't remember if it is a PTF or release 2.1.1 . In: z/OS 2.1.0z/OS MVSz/OS MVS JCL ReferenceJOB statementDSENQSHR parameterOverrides A similar parameter for the JES JOBCLASS. If the JOBCLASS includes a DSENQSHR parameter set to DISALLOW, the job specification will be ignored. A job class with DSENQSHR set to AUTO or ALLOW must be used to exploit this function. Note: The DSENQSHR jobclass attribute is JES2-only. When using a JES3 environment, the DSENQSHR function is never active. Restriction! Additionally, when GRS is in RING mode, the DSENQSHR function is disabled. Restriction, restriction! Table 1. JOBCLASS attribute for DSENQSHR LANGUAGEJOBCLASS attribute for DSENQSHR JCL AUTOALLOW DISALLOW ALLOW yes yes no USEJC yes no no DISALLOWno no no When yes is indicated, the system is allowed to change the data set serialization to shared control and other jobs may share that data set with this job. I might expect that when the JCL specifies UseJobClass (the default) and the JOBCLASS attribute is ALLOW, the matrix entry would be yes, not no. I suppose there's an underlying parameter to the DEQ macro. I haven't looked it up. It's probably not sensitive to DSENQSHR. Something (Using Data Sets?) probably describes what happens if the programmer DYNALLOCs a DSN also appearing in JCL, and one is SHR and the other is EXC. I haven't looked it up. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
If I were in the position to decide which option to use, I would clearly vote for MIG. NOPFD does unnecessary fix-ups in certains cases, which causes some performance penalties, and I personally don't like the use of CLC for the comparison of decimal values, even if the lengths are the same, for the well-known reasons (the sign representation has to be identical on both sides). I would spend this little CPU overhead for CP over CLC for correctness reasons. I don't see a valid reason for providing two options NOPFD and MIG, because IMHO the outcome of the coding below is the same for NOPFD and MIG ... with some performance problems for NOPFD (I guess, even in the case fixup + CLC vs. CP, NOPFD will take more CPU than MIG). Kind regards Bernd Am 21.04.2015 um 19:47 schrieb Frank Swarbrick: Very good question. Related... Has it been detailed just exactly what the differences between NUMPROC(MIG) and NUMPROC(NOPFD) are? And an even better question, what (if any) differences are there in the end results? From what I've observed by looking at the pseudo-assembler output. Hopefully I've observed correctly! Compare signed to signed (same length) - MIG: CP - NOPFD: CP - PFD: CLC Compare unsigned to unsigned (same length) - MIG: CP - NOPFD: fix-up both, then CLC - PFD: CLC Compare signed to signed (differing lengths) - MIG: CP - NOPFD: CP - PFD: CP Compare unsigned to unsigned (differing lengths) - MIG: CP - NOPFD: fix-up both, then CP (*) - PFD: CP Compare signed to unsigned (any length) - MIG: CP - NOPFD: fix-up unsigned, then CP (*) - PFD: CP (*) Seems to me no fix-up is necessary since CP is being used anyway. Maybe I'm missing some understanding? Frank - Original Message - From: Timothy Sipples sipp...@sg.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Cc: Sent: Tuesday, April 21, 2015 4:13 AM Subject: Re: COBOL's NUMPROC compiler option OK, but what are we talking about here, in performance terms? NUMPROC(MIG) versus NUMPROC(NOPFD) offered some performance benefit in the past, but Enterprise COBOL 5.x offers a performance benefit, too. Basically, is this 2 steps forward 1 step back, or is it 1 step forward 2 steps back? The overall performance outcome is what matters, surely. I assumed that a hypothetical NUMPROC(MIG) would continue to offer some sort of performance benefit with Enterprise COBOL 5.x, but that's not actually a given. The 5.x compiler has a different design, and what was beneficial in the past may be less beneficial now -- or not beneficial at all. Let's just note that assumption for now. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- 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
Re: ENQ for the life of the job
At 10:49 -0500 on 04/21/2015, Paul Gilmartin wrote about Re: ENQ for
the life of the job:
On Tue, 21 Apr 2015 11:20:24 -0400, Robert A. Rosenberg wrote:
... a IMO major design flaw in the ENQ process
the Initiator can be forced to hold an ENQ for subsequent steps where
it is no longer needed. The case I am talking about is there is no
way to convert an EXC ENQ into a SHR one.
What z/OS release are you thinking of?
I was thinking of all the releases up until 2.1. I was unaware that
this long standing Design Flaw was going to be addressed in that
release as mentioned below.
At 11:05 -0500 on 04/21/2015, John McKown wrote about Re: ENQ for the
life of the job:
On Tue, Apr 21, 2015 at 10:20 AM, Robert A. Rosenberg hal9...@panix.com
wrote:
At 06:50 -0500 on 04/21/2015, John McKown wrote about Re: ENQ for the life
of the job:
The initiator (in general terms) is what reads the parsed JCL and creates
the SWA control blocks which represent the job.
{snip]
While this description of ENQ and DEQ handling is correct it leaves out
the fact that due to a IMO major design flaw in the ENQ process the
Initiator can be forced to hold an ENQ for subsequent steps where it is no
longer needed. The case I am talking about is there is no way to convert an
EXC ENQ into a SHR one. The Initiator is forced to keep an EXC ENQ active
for steps where only SHR is what is enough/desired. This design flaw in ENQ
mains that if a DSN is DISP=OLD/MOD in step 1 and DISP=SHR in all the
following steps the DISP=OLD/MOD ENQ is unnecessarily held until the last
DISP=SHR step (or the JOB) is over. This prevents other jobs that should be
allowed to run from being allowed to run due to the no longer needed EXC
ENQ being held during DISP=SHR steps.
In theory allowing the EXC-SHR ENQ change would be simple since all that
is needed is to alter the ENQ entry in the queue from EXC to SHR and then
drive the part of the DEQ routine that runs the queue to release pending
SHR entries that are waiting for the DEQ of the EXC ENQ at the head of the
chain.
ÐThe ability to atomically downgrade an ENQ from EXC to SHR is now/soon to
be available in z/OS. I don't remember if it is a PTF or release 2.1.1 .
Thank you for this information. Note that I am aware that my code
change above would be easy to do so long as we are dealing with a
single system. All that would be needed in addition to the above
coding change would be the assigning of a flag in the ENQ parm list
to request the EXC to be changed to SHR. The complications would
involve GRS and the need for Tolerance PTFs.
Maranatha!
John McKown
--
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
Re: ENQ for the life of the job
My following suggestions may be missing the desired goal. But, what the heck here they are: 1. Use IEFBR14 with the required dsn and disp=old in step1 and in the last stepx after all required steps 2. Use IEHPROGM to rename the dsn(member) 3. Use IDCAMS alter dsn(member) 4. Use RACF batch step1 to change access to none and then access to job userid and then last step to reset to normal access. David Mingee Mainframe Consulting 9206 Aintree Drive Indianapolis, IN 46250 From: Steff Gladstone steff.gladst...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, April 21, 2015 4:00 AM Subject: Re: ENQ for the life of the job Thank you all for for help. The obvious question that remains is: how does the operating systen itself maintain a continuous ENQ over several job steps for a dataset allocated in the first step with disp=(mod,pass)? Is there a special privileged ENQ operation that only the operating system has access to? On Mon, Apr 20, 2015 at 10:26 PM, Tom Brennan t...@tombrennansoftware.com wrote: Jousma, David wrote: ... I'd use standard JCL DISP=OLD processing on a dummy dataset name that includes the program name as part of it. Maybe someone mentioned this already, but I was thinking even simpler - use the same job name each time if the user has no control over the JCL, with JES2 DUPL_JOB=DELAY which I think might be the default. -- 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
Re: Outsourcing Experiences
On the other hand the window cleaning in this building is done by a window cleaning company, but other external and internal cleaning is done either in-house or by other companies who don't do exterior windows. Sure, but the point is that it's possible to establish clear lines of management responsibility and control when separating in that way. Most commercial buildings have sealed windows, so exterior window cleaning is typically a separable service. Mopping and sweeping within the interior of the building are not easily separable. Mere asset ownership isn't outsourcing, by the way. In principle at least the State of Maryland could hold title to the State of Montana's servers and data centers, and that wouldn't really matter for these purposes. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Experiences
Timothy Sipples wrote: Sure, but the point is that it's possible to establish clear lines of management responsibility and control when separating in that way. Most commercial buildings have sealed windows, so exterior window cleaning is typically a separable service. Mopping and sweeping within the interior of the building are not easily separable. That just reminded me that when I started with IT in 1983, everyone I came across was a company employee. That included the guards, the doctor I went to, and even the folks who vacuumed and emptied the trash. The word resource hadn't been used for a person yet, and managers ran projects themselves and knew who was best for each particular task. What a strange world it was. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Tue, 21 Apr 2015 18:01:10 -0500, Walt Farrell wrote: Yes, but only for abnormal termination of the Initiator TCB, or for failure of the entire address space. In normal or abnormal termination of the jobstep task those resource managers won't help the OP, and the ENQ would remain outstanding because it's not owned by the task that's terminating. Hmmm. Can a program fork() a child that can outlive the job step? Or the child could be another job submitted via INTRDR. Such a child could issue the ENQ and read() from a FIFO. The final job step of the parent job could write a token to the FIFO; the child could accept that and terminate. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Tue, 21 Apr 2015 16:39:00 +, Rob Scott rsc...@rocketsoftware.com wrote: No matter what you fiddle about with in SWA, these GRS resource manager routines will enable GRS to cleanup any underlying resources obtained by the task or address space. Yes, but only for abnormal termination of the Initiator TCB, or for failure of the entire address space. In normal or abnormal termination of the jobstep task those resource managers won't help the OP, and the ENQ would remain outstanding because it's not owned by the task that's terminating. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Experiences
Don Grisnell wrote: We are currently exploring the option of outsourcing our mainframe environment. I know you asked for feedback offline, but I'd like to offer an important bit of online feedback. In my personal view, I do not think mainframe-only (or any platform-specific) outsourcing is a good idea. Outsourcing can take many forms, and outsourcing either makes sense or it doesn't. But I am hard pressed to come up with an example of where outsourcing makes sense when very artificially limited to a single platform. Metaphorically speaking, would you outsource your lungs (only), or would you outsource respiration? There is a difference. The former doesn't make any sense to me. It just inevitably leads to lots of weird behaviors that harm the business (or government mission), for a variety of reasons, mostly related to the fact it's at least very hard to write a sensible contract with that line of non-separation. The latter might make sense. Fetuses and some surgical patients outsource respiration, for example. If you've got a particular set of government functions or services you want to outsource, end-to-end, maybe that makes sense. The mainframe-based components within those functions or services, by themselves? No, that probably doesn't make any sense whatsoever and would inevitably lead to bad behaviors and perverse incentives. It's not a sensible way to cleave. It's a very IT-centric view, and a contrived one at that. That's not the first view I'd pick when assessing the value (or not) of outsourcing. If you look at the successful examples of outsourcing I think you'll see they are business/government service-oriented. To pick another analogy, I don't think I've ever seen a rail system where the locomotive is outsourced but the train cars continue to be run in-house, or vice versa. Where there's rail outsourcing it's a franchise agreement of some kind, to carry passengers along particular routes -- locomotives and passenger cars both included. The rail underneath and its operations(*) might not be outsourced, but one or more particular whole services are, with identifiable, measurable, *external* outcomes. To pick yet another example, building cleaning is often outsourced -- but the whole service is outsourced, with a clear, measurable set of objectives (clean buildings). Would you ever outsource only mopping the floors but keep sweeping, dusting, and wiping in-house? That'd be a predictable disaster, wouldn't it? I'm assuming a conventional definition of outsourcing. There are some other things that probably shouldn't be called outsourcing that some organizations call outsourcing. (*) This'd be analogous to outsourcing the data centers, i.e. facilities management outsourcing. There are successful examples of outsourcing along those lines since that's a reasonable place to divide responsibilities, with the possibility of clear, measurable outcomes that can be contracted fairly easily. Platform-specific separation of responsibilities? No, that doesn't work -- or at least it's very, very hard to make work, especially over the medium term or longer. Most if not all the application and information system interactions -- the actual end-user services and outcomes that you worry about -- aren't built and run that way. There is no such separation at the service level. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP to USS directory
The Video is awesome. Thanks All for your help.. Is there any other alternate way to Transfer the scartX,zip file directly to Mainframe PDS member and apply the CAR2014 for CA1 instead of transferring to USS directory and then unzip the file and apply the CAR. I'm facing a problem with CAUNZIP utiity to unzip the scartX.zip file and thats stopping all CA CAR maintanenece for all PRODS. Kindly guide me to move forward. Thanks, Samat On Fri, Apr 17, 2015 at 1:21 AM, Scott Barry sba...@sbbworks.com wrote: The PAX ESD Guide on SUPPORT.CA.COM (CA SUPPORT ONLINE), Downloads site is quite lean with the FTP example, presuming the reader has sufficient knowledge / experience with retrieving to USS directly, as compared to traditional MVS dataset retrieval. As well, some of the other Download Help references / links there are minimally helpful or non-existent (...check back often... as I recall seeing) Scott Barry SBBWorks, Inc. -- 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
Re: ENQ for the life of the job
On Tue, Apr 21, 2015 at 10:11 AM, Steff Gladstone steff.gladst...@gmail.com wrote: Sorry, John. My question was unclear. It was referring to your earlier remarks above: Thinking about it a bit more, given what Mr. Relson said about RTM, doing this _should_ work even if the initiator terminates abnormally since RTM should clean up the ENQs during EOM processing. Are you saying that RTM should clean up the ENQ even without modifying the SWA with information for the DD, as you suggested to do earlier? Ah. thanks for the clarification. No, in a normal EOJ case, RTM will not clean up the directed ENQs. I didn't do a good enough refer back. In one of my posts, I mentioned that if the initiator abends, in my case with a S40D, that (years ago) the ENQs were left outstanding despite the fact that the initiator went to EOM. Mr. Relson indicated that should not occur any more. If your job simply goes to normal EOJ with the initiator continuing as it normally does, then the directed ENQs will NOT be released by the initiator code because _it_ knows nothing about them. And RTM won't clean them up because the initiator TCB does not terminate. So, in that case (normal EOJ), you must ensure that the last step of the job executes and that the program it runs does a directed DEQ of the appropriate resources. This is why I mentioned updating the SWA in addition to doing the directed ENQ. By modifying the SWA, you can basically trick the initiator into doing the DEQs for you at EOJ. I really hope that I said all of that correctly. But as Seymour said, this directed ENQ to the initiator TCB is fraught with peril. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
I think it is worth pointing out the most likely cleaning up logic used for enqueues (note that I do not have access to GRS source - but this is how I am guessing things work). GRS will establish a TYPE=ADDRSPC and a TYPE=TASK resource manager routine to cover all address spaces and all tasks in the system. These two resource manager routines give GRS a fighting chance to maintain integrity when ungraceful termination occurs for either the task (TCB) that requested an enqueue or the entire address space of the requestor. When the task terminates, the task level resource manager gets control in the home address space and (as long as there is enough wiggle room in the private area) it can send a clean-up resources for this TCB in this ASID request over to GRS (most likely via some sort of PC-ss). This is good news as it not only informs GRS of tasks that are abending - but also catches the situation during normal termination when the task did not issue a dequeue for all enqueues previously obtained. These resource managers are protected from cancels, detaches and any SRB to task percolated abends - in other words they are pretty much guaranteed to run. If the ASID terminates, the ASID level resource manager gets control in the *MASTER* address space (ASID 0001) and it can send a clean-up resources for the ASID request over to GRS (again most likely by a PC-ss). Another piece of good news as a belt-and-braces approach to GRS structure integrity is beneficial to long term system up-time. No matter what you fiddle about with in SWA, these GRS resource manager routines will enable GRS to cleanup any underlying resources obtained by the task or address space. Note that unlike enqueues, GRS latches do NOT get automatically cleaned up during task termination. Rob Scott Principal Software Engineer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: 21 April 2015 16:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job Sorry, John. My question was unclear. It was referring to your earlier remarks above: Thinking about it a bit more, given what Mr. Relson said about RTM, doing this _should_ work even if the initiator terminates abnormally since RTM should clean up the ENQs during EOM processing. Are you saying that RTM should clean up the ENQ even without modifying the SWA with information for the DD, as you suggested to do earlier? On Tue, Apr 21, 2015 at 4:42 PM, John McKown john.archie.mck...@gmail.com wrote: On Tue, Apr 21, 2015 at 7:00 AM, Steff Gladstone steff.gladst...@gmail.com wrote: Even without modifying the SWA with information for the DD, as you suggested earlier? Yes, you can do the directed ENQ yourself without modifying the SWA. Which, by the by, I _mentioned_, not _suggested_. At least, I didn't mean for it to be a suggestions. It's the fly with a shotgun approach. The main problem with the directed ENQ to the initiator TCB is still how to get the DEQ done at end of job?. That is the sticking point in this whole thing. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
