Re: Sysplex Common Time Source
That was what we originally though too, but our local IBM support person told us we couldn't. Thinking further about configuration activities to migrate to mixed CTN mode, I'm not seeing how on the non STP capable processor we're going to be able to set the name of the mixed CTN, since it isn't going to have the STP tab for that CEC, I'm not sure that that matters. IIRC, the requirement is that all systems in the sysplex get their time from the same source. As long as the z10 gets it from the timers, and there's another CEC in the CTN getting it from the same timers and acting as the primary time server for the CTN, I believe that would work. z10 - timer zEC12 - timer | Primary time server \/ STP other STP CECs Before STP, there was no STP tab on the HMC and the CECs were able to participate in the sysplex by virtue of using the same timer. I *think* the migration would be to make the time source the timer connected to one zEC12, make that the PTS, then add the z10 pointing to the timer. But I haven't read the fine manuals for some time, and it seems like the PTS becomes a sinle point of failure, unless at least one other machine in the CTS has a timer connection too. The point about the mixed mode CTN being envisioned as a fall-back situation, not an expected long-term situation is also good one. And if IBM is telling you no, it's hard to argue that you'd want to try to do it. Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Number of entries in the TIOT
In 2110692851.22284.1391697210141.javamail.r...@comcast.net, on 02/06/2014 at 02:33 PM, DASDBILL2 dasdbi...@comcast.net said: I have written oodles of code that scan TIOTs, which almost always ran in key eight, and I never got a S0C4 in that code, so I cannot believe that the TIOT is allocated in key one storage. Cannot believe? Why not? Key 1 is used for Scheduler control blocks, and in no way requires fetch protection. -- 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: DCB for load library
In 52f3a21e.1080...@trainersfriend.com, on 02/06/2014 at 07:54 AM, Steve Comstock st...@trainersfriend.com said: Well, technically, yes: it can, however, contain program objects which are the PDSE analogy of load modules in a PDS. Analog, yes, but with a very different structure. Code that directly read one would not work with the other. -- 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: Dumb SMPE question
In CAE6x8Q6u0p0-CXOnkOv=qp9uhfqm3uasggomnug5_c4dgob...@mail.gmail.com, on 02/06/2014 at 04:11 PM, Mark Pace pacemainl...@gmail.com said: I hate having these PTFs in my SMPPTS that every time I install an RSU the APPLY tries to install this PTF again, and I spend more time researching why the PTF didn't APPLY. Then stop researching them. The ones to worry about are the ACTION and DOC holds. Am I being short sighted? Yes. If you REJECT a PTF then you have have to receive it at a later date, and that may be awkward. Let SMP deal with the hold data in a normal fashion. -- 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: RES: Implicit VVDS creation
In bc6b7b77ef4d5e4bb95b0559a0d6d5e10531ce9...@mx3.state.nv.us, on 02/06/2014 at 01:17 PM, David G. Schlecht dschle...@admin.nv.gov said: Or am I way off base? At least partially. On a simulated 3390 a cylinder boundary may not tell you much about seek time, but it can still have an effect on whether a channel program breaks and has to be restarted. OTOH, with code that builds an ECKD channel program that has a lot less impact on performance than it used to. -- 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: Sysplex Common Time Source
On Wed, 5 Feb 2014 14:03:28 -0500, Mark Jacobs wrote: We're replacing a z196 processor with a z10 without the STP feature, and we need to have one zOS 1.13 lpar that's hosted there join the sysplex Pretty well defined. Other users (customers) offered help/suggestions. What is the corporate line from IBMs man in Singapore ? quote Maybe time to ring up IBM for a pair of zEC12s and replace 3 with 2, /quote Bloody typical. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
In 52f40ffb.4090...@lerctr.org, on 02/06/2014 at 02:43 PM, Ray Mullins m...@lerctr.org said: It seems like conversion/interpretation has skipped the fact that I'm not overriding the second DD in the concatenation and is generating a data set name, instead of noting that it's a blank DD and just leaving the original DD alone. From a logic standpoint, this makes sense, No; from a logic standpoint it makes no sense to ignore the base DD when processing an override. but I'm wondering if this is WAD At best BAD. APARable? Only if you take the time to report it. -- 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: SYSB-II
On Thu, Feb 6, 2014 at 5:07 PM, Ward, Mike S mw...@ssfcu.org wrote: John McKown It also gives our end users the idea that z/OS is incapable of easy to use data access. John, what do you mean by this statement? The problem with data access here is that _all_ our data is stored in VSAM KSDS data sets. As opposed to, say, Windows where it is on MS-SQL Server and Oracle databases. So every time the users want a data extract, they must request that a program be written and then run. The resulting extract file must then be downloaded so that the data can be put in the proper place. Either in an SQL database, or maybe the user can use it directly. This makes ad hoc requests very difficult compared to just developing an SQL SELECT which can not only retrieve data, but also do some aggregation. Or can be integrated into an .NET program which the person, or a developer, can write faster than we can get a new COBOL program written and run. This thanks to the fact that z/OS has _good_ change control which is _enforced_. I don't know how they do Windows development. But, in any case, writing COBOL using ISPF in a compile/run/debug loop is much slower than using a Windows IDE. No, we won't get RD/z. Too expensive. We do have a product, PowerExchange, which can do SQL type queries against a VSAM KSDS, or even a sequential data set. The first problem is that it needs somebody to supply a schema of the data set. The second problem is that everybody who knew how to use the product has been RIF'd. But this is regarded as a mainframe problem because data access should be brain dead simple. I agree that __end-user__ access should be simple. But that costs money (as in get DB2 or some other package, for which we have no budget). Now, due to the above, an end user request for data access takes much longer on z/OS than on, say, Windows. And so the end user perceives that z/OS is inherently more difficult to get information out of. Add to that the fact that IT management here basically regards z/OS as obsolete technology, and you probably see the problem. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? 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: Dumb SMPE question
In 29b16432403d6c45a9bee5f0302d191721438...@vss-exchmb1.sfg.corp.LOCAL, on 02/06/2014 at 10:42 PM, Pommier, Rex rpomm...@sfgmembers.com said: Let me ask a general question about IBM packaging. Does IBM ever send a fixing PTF with a PRE(PE-PTF) instead of a SUP(PE-PTF)? Often. -- 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: VSAM Data Access (and SYSB-II)
On Fri, Feb 7, 2014 at 1:01 AM, Timothy Sipples sipp...@sg.ibm.com wrote: Also curious about the It also gives our end users the idea that z/OS is incapable of easy to use data access remark, John. If you're a keen or semi-keen observer of the IT world, relational databases are extremely popular and continuing to be popular, but non-relational databases (and data stores) are enjoying a robust renaissance. One size does not fit all. True. In a sense, VSAM KSDS could be touted as a basic NoSQL data store. I think it's always a good idea to take a look at the full range of VSAM-related options: SYSB-II, VSAM Record-Level Sharing (RLS), and Transactional VSAM (TVS). And, to anticipate a question, no, you do NOT need multiple machines for either VSAM RLS or TVS. You don't even need more than one z/OS LPAR -- a monoplex is sufficient. You do need to define and to start a CFCC LPAR (or z/VM equivalent if applicable) if you don't have one already -- otherwise known as a configuration task, and all approaches require configuration tasks. That CFCC LPAR can either use (part of) a general purpose engine or a CF engine, and it needs a bit of memory allocated. The fact CFCC-related processing can run on a CF engine is a good, very zIIP-like option to have available because all these approaches incur some overhead. Whether it makes business sense to get a CF engine or not depends on how much CFCC-related processing you'll have. Often yes it does, but not always. The processing may grow with time as you use RLS or TVS more (and/or use your CF for other things) -- yes, new functions often get used and enjoyed -- so that decision can change over time, too. We don't have a CF. Therefore we don't have the ability to run VSAM TVS. In any case, VSAM TVS does not help end user access like, say, DB2 would. I.e. TVS won't allow a faster response when a user asks a question. We own our z9BC. And the company really wants to eliminate z/OS and the z entirely. They want a Windows monoculture because it is easier to manage. So they simply refuse to do anything which costs money on z/OS, preferring to use the small budget we have on Windows. Oh, and we just lost the CIO who was more of a business person. He liked z/OS and CICS because he never heard complaints about it being down, as he had for Windows servers. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? 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: Dumb SMPE question
I hate having these PTFs in my SMPPTS that every time I install an RSU the APPLY tries to install this PTF again, and I spend more time researching why the PTF didn't APPLY. Then stop researching them. The ones to worry about are the ACTION and DOC holds. I completely agree. If a PTF cannot be applied because it is PE, then that is an example of the ++HOLD ERROR doing its job. Generally speaking I wouldn't spend any time researching such a PTF. Am I being short sighted? Yes. If you REJECT a PTF then you have to receive it at a later date, and that may be awkward. Let SMP deal with the hold data in a normal fashion. Again, I completely agree. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
... Or do what I do and build the exclude list required to get RC=0. Why even spend the time to do that? The result is the same, the PTFs don't get applied. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
I should probably go through the GLOBAL, identify all of these forlorn lost souls, and put them out of their everlasting misery via REJECT. The often neglected NOFMID DELETEFMID form of REJECT is your friend here... if or when you decide to address that loose end. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Implicit VVDS creation
As I commented recently in another thread, in the ICKDSF manual there is a table of MAXVTOC/MAXVTOCIX sizes in : Calculating the size of the VTOC index in appendix C of ICKDSF Users Guide GC35-0033-39. Unfortunately, there is no reference to the size of the VVDS required to support a MAXVTOC/MAXVTOCIX formatted volume. Would be nice to have! HTH, snip The theoretical worst case for a TSO pack is that every track on the volume could be a single-track data set, except for the following: volume label track, VTOC, VTOC index, and VVDS. And each such single-track data set would need at least one DSCB (Format 1) record in the VTOC, and you can only get about 50 of them on each VTOC track. Bill Fairchild /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
bottom posting -Original Message- From: Robert A. Rosenberg [mailto:hal9...@panix.com] Sent: Thursday, February 06, 2014 11:10 PM To: IBM Mainframe Discussion List Cc: Pommier, Rex Subject: Re: Dumb SMPE question At 22:42 + on 02/06/2014, Pommier, Rex wrote about Re: Dumb SMPE question: Mark, Let me ask a general question about IBM packaging. Does IBM ever send a fixing PTF with a PRE(PE-PTF) instead of a SUP(PE-PTF)? If the fixing PTF has a PRE of the PTF you deleted, would you not be causing yourself problems in that the PRE PTF is now missing? Rex That depends on if the fix PTF contains all the elements in the PE-PTF or only some of them. If it contains all then it can SUP. If it does not it must PRE to pick up the elements that it does not contain - Note this can only occur if PE-PTF has more than one element. When it contains only one, the fix can SUP(PE-PTF) and should contain all of PE-PTF's PREs and SUPs. This was my point - that I left implied. As another contributor wrote, it is infrequent, but it does happen. If I leave the PE-PTF in my global zone, when the fixing PTF comes along, it will simply satisfy the PE-hold and apply both the PE hold and the fix for the PE. If I have REJECTed the PE, I then have to go find it, probably redownload it, and re-RECEIVE it. I come down firmly in the camp of let SMP/E do its job. Leave the PE-PTFs there and don't worry about getting a RC=0 in your APPLY steps. Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex Common Time Source
ISTR that all time references in a SYSPLEX must be within a certain tolerance (I have no recollection of the actual value). If the local time source exceeded this tolerance, the ETR (STP/9037) would guide them to the same value, or failing that , remove the system from the plex. The act of syncing the STP and the 9037 to the same time ETR might/might not provide sufficient accuracy. HTH, snip That was what we originally though too, but our local IBM support person told us we couldn't. Thinking further about configuration activities to migrate to mixed CTN mode, I'm not seeing how on the non STP capable processor we're going to be able to set the name of the mixed CTN, since it isn't going to have the STP tab for that CEC, I'm not sure that that matters. IIRC, the requirement is that all systems in the sysplex get their time from the same source. As long as the z10 gets it from the timers, and there's another CEC in the CTN getting it from the same timers and acting as the primary time server for the CTN, I believe that would work. z10 - timer zEC12 - timer | Primary time server \/ STP other STP CECs Before STP, there was no STP tab on the HMC and the CECs were able to participate in the sysplex by virtue of using the same timer. I *think* the migration would be to make the time source the timer connected to one zEC12, make that the PTS, then add the z10 pointing to the timer. But I haven't read the fine manuals for some time, and it seems like the PTS becomes a sinle point of failure, unless at least one other machine in the CTS has a timer connection too. The point about the mixed mode CTN being envisioned as a fall-back situation, not an expected long-term situation is also good one. And if IBM is telling you no, it's hard to argue that you'd want to try to do it. Scott /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex Common Time Source
In my opinion you may run into some interesting issues with timestamped stuff in the CFs and whatnot if the times start coming in a slightly unpredictable sequence. I don't think I'd take that risk. When we migrated from ETR to mixed to all STP CTN, the key was two machines were ETR and had the STP feature, we had one machine that was ETR only with no STP but it was getting fed by the two ETR/STP machines. Note that we had two machines as time sources, I'm also not totally sure I'd go with one machine connected to the 9037 and rely on that. I do not believe that anything z196 and up can do ETR at all. I'm pretty sure I read that in the z196 Tech Guide redbook somewhere. (Page 14 - STP section) Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Staller, Allan allan.stal...@kbmg.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 02/07/2014 09:03 Subject:Re: Sysplex Common Time Source Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU ISTR that all time references in a SYSPLEX must be within a certain tolerance (I have no recollection of the actual value). If the local time source exceeded this tolerance, the ETR (STP/9037) would guide them to the same value, or failing that , remove the system from the plex. The act of syncing the STP and the 9037 to the same time ETR might/might not provide sufficient accuracy. HTH, snip That was what we originally though too, but our local IBM support person told us we couldn't. Thinking further about configuration activities to migrate to mixed CTN mode, I'm not seeing how on the non STP capable processor we're going to be able to set the name of the mixed CTN, since it isn't going to have the STP tab for that CEC, I'm not sure that that matters. IIRC, the requirement is that all systems in the sysplex get their time from the same source. As long as the z10 gets it from the timers, and there's another CEC in the CTN getting it from the same timers and acting as the primary time server for the CTN, I believe that would work. z10 - timer zEC12 - timer | Primary time server \/ STP other STP CECs Before STP, there was no STP tab on the HMC and the CECs were able to participate in the sysplex by virtue of using the same timer. I *think* the migration would be to make the time source the timer connected to one zEC12, make that the PTS, then add the z10 pointing to the timer. But I haven't read the fine manuals for some time, and it seems like the PTS becomes a sinle point of failure, unless at least one other machine in the CTS has a timer connection too. The point about the mixed mode CTN being envisioned as a fall-back situation, not an expected long-term situation is also good one. And if IBM is telling you no, it's hard to argue that you'd want to try to do it. Scott /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
Ray, Just out of curiosity, would it work if you added a third DD card to the original SYSLPARM DD concatenation? The JCL ref manual doesn't explicitly state the override needs something to override, but it might be worth a try. Can you try something like: //SYSLPARM DD DSN=tempds,DISP=(OLD,DELETE) // DD * some more binder parms overriding the first one /* // DD * A comment line or do-nothing line (or possibly nothing at all) /* And then your override would have the second DD * to be overridden. Or maybe the third DD could be DD DUMMY? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ray Mullins Sent: Thursday, February 06, 2014 4:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error overriding concatenated DD in PROC where one is instream data Hello, long time absent. In z/OS 1.13, I'm playing with instream data in a PROC for the first time to try to simplify some bind JCL and I've run into an error. It's an atypical situation, I realize. In the PROC I have //* Following is a data set created with ISRSCAN from a concatenation //SYSLPARM DD DSN=tempds,DISP=(OLD,DELETE) // DD * some more binder parms overriding the first one //* Because one of the program objects needs different stuff, I've coded //DRVASTRT EXEC MMB,symbolics //B.SYSLPARM DD // DD // DD * different parms to override a couple in the first two DDs //* The job hits this step and gives me IEF344I MMDB B DRVASTRT SYSLPARM+001 - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET SYS14037.T114830.RA000.MMDB.R0484370 It seems like conversion/interpretation has skipped the fact that I'm not overriding the second DD in the concatenation and is generating a data set name, instead of noting that it's a blank DD and just leaving the original DD alone. From a logic standpoint, this makes sense, but I'm wondering if this is WAD (thou shalt not override instream data) or maybe DD concatenation needs some extra checks if the underlying DD is instream (or does not have a DSN). I am curious as how this would be handled if the DD was a SUBSYS. Yes, I could put the instream data in a PDS member, but for various reasons that would complicate the underlying binder proc; let's just say we'd rather not go there. So, what's the consensus? WAD? APARable? Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex Common Time Source
As I recall it, all time references in a sysplex must be within a certain tolerance and this is ensured by requiring them to be connected to a single time source (ETR ID), not 2 sources that are equal within a certain tolerance. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, February 07, 2014 15:03 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex Common Time Source ISTR that all time references in a SYSPLEX must be within a certain tolerance (I have no recollection of the actual value). If the local time source exceeded this tolerance, the ETR (STP/9037) would guide them to the same value, or failing that , remove the system from the plex. The act of syncing the STP and the 9037 to the same time ETR might/might not provide sufficient accuracy. HTH, snip That was what we originally though too, but our local IBM support person told us we couldn't. Thinking further about configuration activities to migrate to mixed CTN mode, I'm not seeing how on the non STP capable processor we're going to be able to set the name of the mixed CTN, since it isn't going to have the STP tab for that CEC, I'm not sure that that matters. IIRC, the requirement is that all systems in the sysplex get their time from the same source. As long as the z10 gets it from the timers, and there's another CEC in the CTN getting it from the same timers and acting as the primary time server for the CTN, I believe that would work. z10 - timer zEC12 - timer | Primary time server \/ STP other STP CECs Before STP, there was no STP tab on the HMC and the CECs were able to participate in the sysplex by virtue of using the same timer. I *think* the migration would be to make the time source the timer connected to one zEC12, make that the PTS, then add the z10 pointing to the timer. But I haven't read the fine manuals for some time, and it seems like the PTS becomes a sinle point of failure, unless at least one other machine in the CTS has a timer connection too. The point about the mixed mode CTN being envisioned as a fall-back situation, not an expected long-term situation is also good one. And if IBM is telling you no, it's hard to argue that you'd want to try to do it. Scott /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
I have been doing a little research and looking at the z/OS 1.13's z/OS MVS JCL User's Guide it turns out you can code in-stream data in a JES2 procedure and I am going to assume you can't with JES3, but to do so, DO NOT use the // DD * use instead // DD DATA. So I am going to amend my original message by saying, instead of coding // DD * for your second DD in the procedure, try coding // DD DATA instead, so you would have this: In the PROC I have //* Following is a data set created with ISRSCAN from a concatenation //SYSLPARM DD DSN=tempds,DISP=(OLD,DELETE) // DD DATA some more binder parms overriding the first one /* //* Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nims,Alva John (Al) Sent: Friday, February 07, 2014 9:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Error overriding concatenated DD in PROC where one is instream data Question: In the actual PROC JCL, the JCL between the // PROC and // PEND statements (or assumed PEND if it is a PDS member), you coded a JCL statement with // DD *? I think if you do, that is not acceptable, because the * indicates that non-JCL data follows and you cannot have that within an actual PROC statements. Because I bet if you change that // DD * to be // DD DISP=SHR,DSN=.. and in that Data Set is the first set of control cards, your override will work. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ray Mullins Sent: Thursday, February 06, 2014 5:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error overriding concatenated DD in PROC where one is instream data Hello, long time absent. In z/OS 1.13, I'm playing with instream data in a PROC for the first time to try to simplify some bind JCL and I've run into an error. It's an atypical situation, I realize. In the PROC I have //* Following is a data set created with ISRSCAN from a concatenation //SYSLPARM DD DSN=tempds,DISP=(OLD,DELETE) // DD * some more binder parms overriding the first one //* Because one of the program objects needs different stuff, I've coded //DRVASTRT EXEC MMB,symbolics //B.SYSLPARM DD // DD // DD * different parms to override a couple in the first two DDs //* The job hits this step and gives me IEF344I MMDB B DRVASTRT SYSLPARM+001 - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET SYS14037.T114830.RA000.MMDB.R0484370 It seems like conversion/interpretation has skipped the fact that I'm not overriding the second DD in the concatenation and is generating a data set name, instead of noting that it's a blank DD and just leaving the original DD alone. From a logic standpoint, this makes sense, but I'm wondering if this is WAD (thou shalt not override instream data) or maybe DD concatenation needs some extra checks if the underlying DD is instream (or does not have a DSN). I am curious as how this would be handled if the DD was a SUBSYS. Yes, I could put the instream data in a PDS member, but for various reasons that would complicate the underlying binder proc; let's just say we'd rather not go there. So, what's the consensus? WAD? APARable? Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- 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: RES: Implicit VVDS creation
On 02/06/2014 05:42 PM, Shmuel Metz (Seymour J.) wrote: In bc6b7b77ef4d5e4bb95b0559a0d6d5e10531ce9...@mx3.state.nv.us, on 02/06/2014 at 01:17 PM, David G. Schlecht dschle...@admin.nv.gov said: Or am I way off base? At least partially. On a simulated 3390 a cylinder boundary may not tell you much about seek time, but it can still have an effect on whether a channel program breaks and has to be restarted. OTOH, with code that builds an ECKD channel program that has a lot less impact on performance than it used to. ...and if the physical storage media still has an access-time function which tends to be larger when separation on the physical media is larger, it is not unreasonable to expect that any emulated 3390 strategy which utilizes a fixed mapping would likely use some sequential allocation strategy which would at least show a statistical bias for faster access to blocks that were closer together on the emulated device, as that would improve the odds (but not guarantee) they are closer together on the physical media as well. Such access-time bias would no doubt vary in a manner that couldn't be usefully predicted from emulated DASD architecture, but it seems reasonable that it should exist. In a practical sense though, one could argue that any data that is being accessed frequently enough to be a performance concern would be interacting with DASD cache storage in ways that could completely mask the difference in physical access times; so the controlled placement of VTOC, VTOCIX, and VVDS these days is more a matter of aesthetics and emulated-media fragmentation avoidance than performance. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
On Fri, 7 Feb 2014 14:58:53 +, Nims,Alva John (Al) wrote: I have been doing a little research and looking at the z/OS 1.13's z/OS MVS JCL User's Guide it turns out you can code in-stream data in a JES2 procedure and I am going to assume you can't with JES3, but to do so, DO NOT use the // DD * use instead // DD DATA. So I am going to amend my original message by saying, instead of coding // DD * for your second DD in the procedure, try coding // DD DATA instead, so you would have this: I would be astonished if for the matter here // DD DATA were not the functional equivalent of // DD *. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM Data Access (and SYSB-II)
How about a weekly (or daily) scheduled download for the users to do ad hoc queries? On Fri, Feb 7, 2014 at 7:25 AM, John McKown john.archie.mck...@gmail.com wrote: On Fri, Feb 7, 2014 at 1:01 AM, Timothy Sipples sipp...@sg.ibm.com wrote: Also curious about the It also gives our end users the idea that z/OS is incapable of easy to use data access remark, John. If you're a keen or semi-keen observer of the IT world, relational databases are extremely popular and continuing to be popular, but non-relational databases (and data stores) are enjoying a robust renaissance. One size does not fit all. True. In a sense, VSAM KSDS could be touted as a basic NoSQL data store. I think it's always a good idea to take a look at the full range of VSAM-related options: SYSB-II, VSAM Record-Level Sharing (RLS), and Transactional VSAM (TVS). And, to anticipate a question, no, you do NOT need multiple machines for either VSAM RLS or TVS. You don't even need more than one z/OS LPAR -- a monoplex is sufficient. You do need to define and to start a CFCC LPAR (or z/VM equivalent if applicable) if you don't have one already -- otherwise known as a configuration task, and all approaches require configuration tasks. That CFCC LPAR can either use (part of) a general purpose engine or a CF engine, and it needs a bit of memory allocated. The fact CFCC-related processing can run on a CF engine is a good, very zIIP-like option to have available because all these approaches incur some overhead. Whether it makes business sense to get a CF engine or not depends on how much CFCC-related processing you'll have. Often yes it does, but not always. The processing may grow with time as you use RLS or TVS more (and/or use your CF for other things) -- yes, new functions often get used and enjoyed -- so that decision can change over time, too. We don't have a CF. Therefore we don't have the ability to run VSAM TVS. In any case, VSAM TVS does not help end user access like, say, DB2 would. I.e. TVS won't allow a faster response when a user asks a question. We own our z9BC. And the company really wants to eliminate z/OS and the z entirely. They want a Windows monoculture because it is easier to manage. So they simply refuse to do anything which costs money on z/OS, preferring to use the small budget we have on Windows. Oh, and we just lost the CIO who was more of a business person. He liked z/OS and CICS because he never heard complaints about it being down, as he had for Windows servers. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSB-II
Mike, Our company uses SYSB almost exactly as John McKown described how it is used at his company. We have one production CICS region and we see its CPU utilization percentage rise when multiple jobs using SYSB are running. As Systems Programmers, we have to be mindful of how our Applications Programmers have coded their procs when they use SYSB. There are parameters available so that SYSB will not lock records in CICS if they haven't been updated, or can perform the VSAM reads in the batch job and only send the VSAM updates to CICS. We work with the programmers to incorporate these parms when they seem beneficial. HW has been good about reviewing output from batch jobs and suggesting ways to improve utilization, which has helped us immensely. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Thursday, February 06, 2014 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU I know this is loading a gun :), but do any of you have any opinion on the SYSB-II product? Is detrimental to CICS? Is it a memory hog? Is it a CPU hog? And for those of you who use it. How does it perform in a zSystem environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
On Fri, Feb 7, 2014 at 9:39 AM, Paul Gilmartin paulgboul...@aim.com wrote: I would be astonished if for the matter here // DD DATA were not the functional equivalent of // DD *. -- gil // DD DATA,DLM='##' (is the default /*?) //* jcl statements of your choice. ## Just the same except it allows JCL statements. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM Data Access (and SYSB-II)
We do things like that. But it does not refute the z/OS is hard to get data out of thoughts because it induces the see, if data access on z/OS were easy, we'd have access to _current_ data and not need to be doing all this data duplication into an easy to access system like MS SQL Server. Actually we do captures of changes to some VSAM data sets by using the CICS journals and a CA product called FileSave. These are used to propagate changes made to selected VSAM master files to a Windows systems which uses the data to update the MS SQL Server databases on a nightly basis. Unloading and ftping our history data bases would simply take too long. It is a few 100 gigabytes of VSAM resident data. On Fri, Feb 7, 2014 at 9:38 AM, Mike Schwab mike.a.sch...@gmail.com wrote: How about a weekly (or daily) scheduled download for the users to do ad hoc queries? -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? 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: Error overriding concatenated DD in PROC where one is instream data
#1. Yes, /* is the default End-of-Data for both DD * and DD DATA, but with DD DATA you can include records that begin with // and that is why most people will code the DLM= to explicitly change the End-of-Data. #2. Is DD DATA a functional equivalent to DD *? I guess we could give that both a Yes and a No, because both are instream data sources, but since DD DATA would also read in JCL statements, the interpreter will treat them as two different sources. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Friday, February 07, 2014 11:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Error overriding concatenated DD in PROC where one is instream data On Fri, Feb 7, 2014 at 9:39 AM, Paul Gilmartin paulgboul...@aim.com wrote: I would be astonished if for the matter here // DD DATA were not the functional equivalent of // DD *. -- gil // DD DATA,DLM='##' (is the default /*?) //* jcl statements of your choice. ## Just the same except it allows JCL statements. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Error overriding concatenated DD in PROC where one is instream data
On Fri, 7 Feb 2014 10:09:34 -0600, Mike Schwab wrote: On Fri, Feb 7, 2014 at 9:39 AM, Paul Gilmartin wrote: I would be astonished if for the matter here // DD DATA were not the functional equivalent of // DD *. -- gil // DD DATA,DLM='##' (is the default /*?) //* jcl statements of your choice. ## Just the same except it allows JCL statements. Of course; well known. I would hope that if I override DD DATA with DD * (or vice versa): o The instream data used is that appearing with the overriding statement, not that appearing with the overridden statement o Overriding DD * with DD DATA does not spookily expose and activate JCL statement images appearing in the overriden DD * (Regardless that some might consider such behavior useful. Likewise, IIRC it's documented that: // SET HOW=DATA //... //SYSIN DD HOW ... does not have the effect the programmer might have intended.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USSTAB Refresh
For TN3270 the table is not in VTAM. I put the USS table in linklst and do a v tcpip,tn3270,obeyfile command and , if necessary, an LLA update/refresh command to change it. Cliff McNeill List; I compiled a new USSTAB for use with TN3270. I am attempting to refresh VTAM/TN3270 to point to the new USSTAB (which has the same module name as the old one (USSTCPPR)). I enter the refresh command: F VTAM,TABLE,OPTION=LOAD,NEWTAB=USSTCPPR,OLDTAB=USSTCPPR Upon entering that command I get the following output: IST097I MODIFY ACCEPTED IST863I MODIFY TABLE COMMAND FAILED-OLD TABLE WAS NOT IN USE 930 IST864I NEWTAB=USSTCPPR, OLDTAB=USSTCPPR, OPT=LOAD, TYPE=**NA** Somewhere I have a disconnect between how this works and how I am trying to get this to work...any insight would be appreciated Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org (717) 720-2663 This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 'In a time of universal deceit - telling the truth is a revolutionary act. ' George Orwell -- 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: OT? IBM looking at leaving the chip manufacturing business?
So current IBM management looks like they're trying to break the company into a bunch of smaller companies like Akers(?) tried to do several years ago??? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, February 07, 2014 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT? IBM looking at leaving the chip manufacturing business? http://www.itworld.com/hardware/403814/reports-ibm-explores-sale-semiconductor-business -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
What are the EAV disks capacity most big Z/OS MF customers use?
I do not mean use space of disk but the disk size in cylinders. thanks, Shai -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT? IBM looking at leaving the chip manufacturing business?
Nah, just the same-old, same-old -- if a line of business doesn't have high enough margins or the potential for same, get rid of it. That's been the mantra in Armonk for a long, long time. I forget which IBM CEO it was who promised share owners at an annual meeting (or was it a stock analysts meeting? Not sure now) that IBM would never stay in any low-margin business, and they have been remarkably consistent about keeping to that philosophy over the decades. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, February 07, 2014 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT? IBM looking at leaving the chip manufacturing business? So current IBM management looks like they're trying to break the company into a bunch of smaller companies like Akers(?) tried to do several years ago??? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, February 07, 2014 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT? IBM looking at leaving the chip manufacturing business? http://www.itworld.com/hardware/403814/reports-ibm-explores-sale-semiconductor-business -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
On Fri, 7 Feb 2014 13:55:27 +, Pommier, Rex wrote: That depends on if the fix PTF contains all the elements in the PE-PTF or only some of them. If it contains all then it can SUP. If it does not it must PRE to pick up the elements that it does not contain - Note this can only occur if PE-PTF has more than one element. When it contains only one, the fix can SUP(PE-PTF) and should contain all of PE-PTF's PREs and SUPs. It's possible that the PE PTF exposed a functional defect in another, older element not in the PE PTF. If the fix PTF replaces only that element, it is not required to PRE and must not SUP the PE PTF (provided that the fix is downward-compatible). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Implicit VVDS creation
Since the VVDS is a catalog extension supporting both VSAM and SMS, wouldn't the size of the VVDS depend on mix of VSAM and non-VSAM datasets and possibly even the type of VSAM datasets on the volume? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Staller, Allan :: Sent: Friday, February 07, 2014 5:53 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Implicit VVDS creation :: :: As I commented recently in another thread, in the ICKDSF manual there is :: a table of MAXVTOC/MAXVTOCIX sizes in : :: Calculating the size of the VTOC index in appendix C of ICKDSF Users :: Guide GC35-0033-39. :: :: Unfortunately, there is no reference to the size of the VVDS required to :: support a MAXVTOC/MAXVTOCIX formatted volume. :: Would be nice to have! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Implicit VVDS creation
At least the VVDS can take extents. One of our volume with 70% used lots of 1 track datasets 46 extents 460 tracks. On Fri, Feb 7, 2014 at 11:58 AM, retired mainframer retired-mainfra...@q.com wrote: Since the VVDS is a catalog extension supporting both VSAM and SMS, wouldn't the size of the VVDS depend on mix of VSAM and non-VSAM datasets and possibly even the type of VSAM datasets on the volume? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Staller, Allan :: Sent: Friday, February 07, 2014 5:53 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Implicit VVDS creation :: :: As I commented recently in another thread, in the ICKDSF manual there is :: a table of MAXVTOC/MAXVTOCIX sizes in : :: Calculating the size of the VTOC index in appendix C of ICKDSF Users :: Guide GC35-0033-39. :: :: Unfortunately, there is no reference to the size of the VVDS required to :: support a MAXVTOC/MAXVTOCIX formatted volume. :: Would be nice to have! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESGB400/IEFGB400
It seems odd to me the defaults for the CATLG_ERR failjob and errormsg are NO. In my tests with an ALLOC specified but CATLG_ERR not specified, I do get the IEF377I message anyway. Also, the failjob=yes option does not change the condition code and does not abnormally end the job. Basically we are wanting to detect the NOT CAT 2's and flag the job for repair. I am also looking at using MPF exits or the general IEAVMXIT. Trying to allow for multiple exits and how to specify them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Large Multi-Volume Physical Sequential allocation question
Had a problem allocating a NON SMS Large PS file that would not span volumes; is anyone on this list familiar with the parameter UNIT=(3390,P) which worked? This parameter pre-allocates the volsers; never saw this before and is this a new feature with z/OS R1.13? //DD01 DD DSN=DSN1,DISP=SHR // DD DSN=DSN2,DISP=SHR // DD DSN=DSN3,DISP=SHR //DD01ODD DSN=DSN.OUTPUT, // DISP=(,CATLG,DELETE),UNIT=(3390,P),DSNTYPE=LARGE, // DCB=(NFCP.PRODMODL,DSORG=PS,RECFM=FB,LRECL=200,BLKSIZE=0), // SPACE=(CYL,(4369,4369),RLSE),VOL=(,,,7) This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large Multi-Volume Physical Sequential allocation question
P asks the system to allocate the same number of devices as requested by the volume count or SER subparameters of the VOLUME parameter, whichever is higher - the effect is that all volumes for the data set are mounted at the same time Had a problem allocating a NON SMS Large PS file that would not span volumes; is anyone on this list familiar with the parameter UNIT=(3390,P) which worked? This parameter pre-allocates the volsers; never saw this before and is this a new feature with z/OS R1.13? //DD01 DD DSN=DSN1,DISP=SHR // DD DSN=DSN2,DISP=SHR // DD DSN=DSN3,DISP=SHR //DD01ODD DSN=DSN.OUTPUT, // DISP=(,CATLG,DELETE),UNIT=(3390,P),DSNTYPE=LARGE, // DCB=(NFCP.PRODMODL,DSORG=PS,RECFM=FB,LRECL=200,BLKSIZE=0), // SPACE=(CYL,(4369,4369),RLSE),VOL=(,,,7) ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Implicit VVDS creation
Just ran into a situation where the VVDS was filling up; 10,10 was not working. Our DBMB group was installing DB2 V10 which has to be SMS managed and were placing hundred of DSNs on one mod-3. So I INIT'ed them as INIT UNIT(560D) VOLID(DBJ555) VTOC(1,0,60) VFY(TS560D) - INDEX(0,1,14) STGR -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, February 06, 2014 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re:group Implicit VVDS creation Yes. step1 is ICKDSF. Step2 creates VVDS. On Thu, Feb 6, 2014 at 11:22 AM, David G. Schlecht dschle...@admin.nv.govwrote: Does anyone still build VVDS datasets explicitly when initializing volumes? I understand that the default allocation for a new VVDS is CYLS(10 10) which saves me from having to rebuild the VVDS if it fills up. What is everyone else doing with VVDS datasets? Is there still a valid argument for building them explicitly? David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov This communication, including any attachments, may contain confidential information and is intended only for the individual or entity to which it is addressed. Any review, dissemination or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and delete all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need a DB2 DBA under z/OS
We just hired a 70 year old COBOL Programmer. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of chris lindenhauer Sent: Tuesday, February 04, 2014 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Need a DB2 DBA under z/OS Hi Gang We have a desperate need for a DBA, Minneapolis MN. If anyone is interested, or knows of anyone interested, please get back to me at chrislindenha...@gmail.com Thanks all :) Chris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSB-II
Thank you. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Friday, February 07, 2014 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Mike, Our company uses SYSB almost exactly as John McKown described how it is used at his company. We have one production CICS region and we see its CPU utilization percentage rise when multiple jobs using SYSB are running. As Systems Programmers, we have to be mindful of how our Applications Programmers have coded their procs when they use SYSB. There are parameters available so that SYSB will not lock records in CICS if they haven't been updated, or can perform the VSAM reads in the batch job and only send the VSAM updates to CICS. We work with the programmers to incorporate these parms when they seem beneficial. HW has been good about reviewing output from batch jobs and suggesting ways to improve utilization, which has helped us immensely. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Thursday, February 06, 2014 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU I know this is loading a gun :), but do any of you have any opinion on the SYSB-II product? Is detrimental to CICS? Is it a memory hog? Is it a CPU hog? And for those of you who use it. How does it perform in a zSystem environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Friday, February 07, 2014 5:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumb SMPE question ... Or do what I do and build the exclude list required to get RC=0. Why even spend the time to do that? The result is the same, the PTFs don't get applied. RC=0 anality is the only reason. Old habits die hard :) Rarely is it more than 12 to 15, rarely more than 3 or 4 deep. Kurt Quackenbush -- IBM, SMP/E Development -- 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: Error overriding concatenated DD in PROC where one is instream data
Question: In the actual PROC JCL, the JCL between the // PROC and // PEND statements (or assumed PEND if it is a PDS member), you coded a JCL statement with // DD *? I think if you do, that is not acceptable, because the * indicates that non-JCL data follows and you cannot have that within an actual PROC statements. Because I bet if you change that // DD * to be // DD DISP=SHR,DSN=.. and in that Data Set is the first set of control cards, your override will work. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ray Mullins Sent: Thursday, February 06, 2014 5:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error overriding concatenated DD in PROC where one is instream data Hello, long time absent. In z/OS 1.13, I'm playing with instream data in a PROC for the first time to try to simplify some bind JCL and I've run into an error. It's an atypical situation, I realize. In the PROC I have //* Following is a data set created with ISRSCAN from a concatenation //SYSLPARM DD DSN=tempds,DISP=(OLD,DELETE) // DD * some more binder parms overriding the first one //* Because one of the program objects needs different stuff, I've coded //DRVASTRT EXEC MMB,symbolics //B.SYSLPARM DD // DD // DD * different parms to override a couple in the first two DDs //* The job hits this step and gives me IEF344I MMDB B DRVASTRT SYSLPARM+001 - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET SYS14037.T114830.RA000.MMDB.R0484370 It seems like conversion/interpretation has skipped the fact that I'm not overriding the second DD in the concatenation and is generating a data set name, instead of noting that it's a blank DD and just leaving the original DD alone. From a logic standpoint, this makes sense, but I'm wondering if this is WAD (thou shalt not override instream data) or maybe DD concatenation needs some extra checks if the underlying DD is instream (or does not have a DSN). I am curious as how this would be handled if the DD was a SUBSYS. Yes, I could put the instream data in a PDS member, but for various reasons that would complicate the underlying binder proc; let's just say we'd rather not go there. So, what's the consensus? WAD? APARable? Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- 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: Implicit VVDS creation
As indicated in the Appendix C of the ICKDSF Guide, these are theoretical maximums. The same could be done for VSM/SMS managed datasets. i.e. If *EVERY* dataset on the volume was a 1-track VSAM DS (or SMS managed DS), what is the size if the VVDS required for the larger of the two possibilities? snip Since the VVDS is a catalog extension supporting both VSAM and SMS, wouldn't the size of the VVDS depend on mix of VSAM and non-VSAM datasets and possibly even the type of VSAM datasets on the volume? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Staller, Allan :: Sent: Friday, February 07, 2014 5:53 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Implicit VVDS creation :: :: As I commented recently in another thread, in the ICKDSF manual there is :: a table of MAXVTOC/MAXVTOCIX sizes in : :: Calculating the size of the VTOC index in appendix C of ICKDSF Users :: Guide GC35-0033-39. :: :: Unfortunately, there is no reference to the size of the VVDS required to :: support a MAXVTOC/MAXVTOCIX formatted volume. :: Would be nice to have! /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need a DB2 DBA under z/OS
On 2/7/2014 12:09 PM, Cosby, Bob - OCFO wrote: We just hired a 70 year old COBOL Programmer. Ah! The Renaissance begins! -Steve Comstock, Founder The Trainer's Friend, Inc. www.trainersfriend.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of chris lindenhauer Sent: Tuesday, February 04, 2014 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Need a DB2 DBA under z/OS Hi Gang We have a desperate need for a DBA, Minneapolis MN. If anyone is interested, or knows of anyone interested, please get back to me at chrislindenha...@gmail.com Thanks all :) Chris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- 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: SYSB-II
I'm going to cross post to the CICS list -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, February 07, 2014 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Thank you. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Friday, February 07, 2014 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Mike, Our company uses SYSB almost exactly as John McKown described how it is used at his company. We have one production CICS region and we see its CPU utilization percentage rise when multiple jobs using SYSB are running. As Systems Programmers, we have to be mindful of how our Applications Programmers have coded their procs when they use SYSB. There are parameters available so that SYSB will not lock records in CICS if they haven't been updated, or can perform the VSAM reads in the batch job and only send the VSAM updates to CICS. We work with the programmers to incorporate these parms when they seem beneficial. HW has been good about reviewing output from batch jobs and suggesting ways to improve utilization, which has helped us immensely. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Thursday, February 06, 2014 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU I know this is loading a gun :), but do any of you have any opinion on the SYSB-II product? Is detrimental to CICS? Is it a memory hog? Is it a CPU hog? And for those of you who use it. How does it perform in a zSystem environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large Multi-Volume Physical Sequential allocation question
On Fri, 7 Feb 2014 18:46:13 +, Cosby, Bob - OCFO wrote: Had a problem allocating a NON SMS Large PS file that would not span volumes; is anyone on this list familiar with the parameter UNIT=(3390,P) which worked? This parameter pre-allocates the volsers; never saw this before and is this a new feature with z/OS R1.13? No, it is not new. It was in OS/360 at least since Release 19 in 1970. See http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSB-II
Folks, Forgive me if this sounds like a sales or marketing call ... but ... I do own a product that does the same as SYSB-II does and IMHO, better. If interested, take a look at VSHARE from CSI-International. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, February 07, 2014 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II I'm going to cross post to the CICS list -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, February 07, 2014 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Thank you. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Friday, February 07, 2014 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Mike, Our company uses SYSB almost exactly as John McKown described how it is used at his company. We have one production CICS region and we see its CPU utilization percentage rise when multiple jobs using SYSB are running. As Systems Programmers, we have to be mindful of how our Applications Programmers have coded their procs when they use SYSB. There are parameters available so that SYSB will not lock records in CICS if they haven't been updated, or can perform the VSAM reads in the batch job and only send the VSAM updates to CICS. We work with the programmers to incorporate these parms when they seem beneficial. HW has been good about reviewing output from batch jobs and suggesting ways to improve utilization, which has helped us immensely. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Thursday, February 06, 2014 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU I know this is loading a gun :), but do any of you have any opinion on the SYSB-II product? Is detrimental to CICS? Is it a memory hog? Is it a CPU hog? And for those of you who use it. How does it perform in a zSystem environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: SYSB-II
Is this it http://www.csi-international.com because I got'this page cant be displayed' On 07/02/2014 4:48 PM, Jim Thomas wrote: Folks, Forgive me if this sounds like a sales or marketing call ... but ... I do own a product that does the same as SYSB-II does and IMHO, better. If interested, take a look at VSHARE from CSI-International. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, February 07, 2014 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II I'm going to cross post to the CICS list -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, February 07, 2014 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Thank you. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Friday, February 07, 2014 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Mike, Our company uses SYSB almost exactly as John McKown described how it is used at his company. We have one production CICS region and we see its CPU utilization percentage rise when multiple jobs using SYSB are running. As Systems Programmers, we have to be mindful of how our Applications Programmers have coded their procs when they use SYSB. There are parameters available so that SYSB will not lock records in CICS if they haven't been updated, or can perform the VSAM reads in the batch job and only send the VSAM updates to CICS. We work with the programmers to incorporate these parms when they seem beneficial. HW has been good about reviewing output from batch jobs and suggesting ways to improve utilization, which has helped us immensely. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Thursday, February 06, 2014 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU I know this is loading a gun :), but do any of you have any opinion on the SYSB-II product? Is detrimental to CICS? Is it a memory hog? Is it a CPU hog? And for those of you who use it. How does it perform in a zSystem environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: SYSB-II
Yes .. that is it ... don't know why it cannot be displayed but w/check w/the responsible parties .. Please accept my sincere apologies ... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Graham Hobbs Sent: Friday, February 07, 2014 4:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Is this it http://www.csi-international.com because I got'this page cant be displayed' On 07/02/2014 4:48 PM, Jim Thomas wrote: Folks, Forgive me if this sounds like a sales or marketing call ... but ... I do own a product that does the same as SYSB-II does and IMHO, better. If interested, take a look at VSHARE from CSI-International. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, February 07, 2014 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II I'm going to cross post to the CICS list -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Friday, February 07, 2014 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Thank you. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Friday, February 07, 2014 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSB-II Mike, Our company uses SYSB almost exactly as John McKown described how it is used at his company. We have one production CICS region and we see its CPU utilization percentage rise when multiple jobs using SYSB are running. As Systems Programmers, we have to be mindful of how our Applications Programmers have coded their procs when they use SYSB. There are parameters available so that SYSB will not lock records in CICS if they haven't been updated, or can perform the VSAM reads in the batch job and only send the VSAM updates to CICS. We work with the programmers to incorporate these parms when they seem beneficial. HW has been good about reviewing output from batch jobs and suggesting ways to improve utilization, which has helped us immensely. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: Thursday, February 06, 2014 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU I know this is loading a gun :), but do any of you have any opinion on the SYSB-II product? Is detrimental to CICS? Is it a memory hog? Is it a CPU hog? And for those of you who use it. How does it perform in a zSystem environment? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For
