Re: ZOS 1.13 SMPTABL Mystery
On Wed, 25 Apr 2012 19:24:57 -0400, Shmuel Metz (Seymour J.) wrote: In 4f96b36c.3000...@acm.org, on 04/24/2012 at 09:06 AM, Joel C. Ewing jcew...@acm.org said: SMP/E dialogs do not work that way. Users do not share the same variables directly, they share the same list of named maintenance projects Is that a new function? I don't recall ever seeing named projects in the dialogs. Joel is referring to is the Run comment. Yes, you can deduce most of the state information from the CSI, possibly with help from the SMP/E log datasets; but it takes much more work and adds unnecessary opportunity for human error. Isn't it the other way around? The state information in the ISPF variables may be stale if you RECEIVE updated HOLDDATA, while the state information in the CSI is current. The state information that is stored in SMPTABL is not the state of SYSMODs. It is the state of the Sysmod Management dialog. For example, someone could start a SYSMOD Management dialog process to install RSU maintenance and select the APPLY/ACCEPT path. It might take several iterations of APPLY CHECK, reading HOLDDATA, adding or excluding SYSMODs, etc. before being ready to do the APPLY. That might include receiving additional HOLDDATA or SYSMODs. If you take over a dialog that someone else started, you can you don't necessarily have to go through all of the iterations that they did. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
In 5616521949719829.wa.m42tomibmmainyahoo@bama.ua.edu, on 04/26/2012 at 07:10 AM, Tom Marchant m42tom-ibmm...@yahoo.com said: The state information that is stored in SMPTABL is not the state of SYSMODs. It is the state of the Sysmod Management dialog. I understand that; it is precisely the reason that I don't see the need to share those data. For example, someone could start a SYSMOD Management dialog process to install RSU maintenance and select the APPLY/ACCEPT path. It might take several iterations of APPLY CHECK, reading HOLDDATA, adding or excluding SYSMODs, etc. before being ready to do the APPLY. That might include receiving additional HOLDDATA or SYSMODs. If you take over a dialog that someone else started, you can you don't necessarily have to go through all of the iterations that they did. If I take over an RSU process that somebody else started, then I will almost certainly download and RECEIVE new HOLDDATA. At that point I wiould want to redo the APPLY CHECK. If they did a RECEIVE of selected corrected service, that service will still be in the PTS so I don't need to go through that iteration even if I don't use their SMPTABL. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
In 4f96b36c.3000...@acm.org, on 04/24/2012 at 09:06 AM, Joel C. Ewing jcew...@acm.org said: SMP/E dialogs do not work that way. Users do not share the same variables directly, they share the same list of named maintenance projects Is that a new function? I don't recall ever seeing named projects in the dialogs. Yes, you can deduce most of the state information from the CSI, possibly with help from the SMP/E log datasets; but it takes much more work and adds unnecessary opportunity for human error. Isn't it the other way around? The state information in the ISPF variables may be stale if you RECEIVE updated HOLDDATA, while the state information in the CSI is current. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
In 4f915489.3060...@us.ibm.com, on 04/20/2012 at 08:20 AM, Kurt Quackenbush ku...@us.ibm.com said: The intent is to allow users to share workload and pickup an install process from a coworker as Joel clearly explained. Actually, it wasn't clear. If I have to pick up an install process from a colleague, the CSI contains the data I need if you're referring to service, and the CPAC data sets contain the data I need if you're referring one of the customized product offerings. I'm curious, what problems have you run into caused by sharing SMPTABL? As I recall, it was installing selective service concurrently for multiple products, but it's been a few years since I last went through it and I no longer recall the details. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
In 1009339904279500.wa.markmzelden@bama.ua.edu, on 04/20/2012 at 08:34 AM, Mark Zelden m...@mzelden.com said: What problems have you run into when sharing? It's been a few years, but I vaguely recall issues when two people were concurrently installing service to the same targets, for different components. I've never seen a case where I needed data from SMPTABL in order to pick up somebody else's work. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
In 4f90d295.6000...@acm.org, on 04/19/2012 at 10:05 PM, Joel C. Ewing jcew...@acm.org said: If you have multiple people who might have to back each other up and be able to take over and eventually complete a maintenance project started by another using SMP/E ISPF dialogs, then they had better share the same SMPTABL dataset. Otherwise, the only way to continue their maintenance would be to manually start a new project, determine what SYSMODS should be selected, determine the last step done by the prior person, and spin through the already-done dialog steps without actually submitting jobs in order to get to the right starting step. The flip side of that is that if you have multiple people working concurrently the variables tracking the work of one are highly inappropriate for the work of another. If I have to back up somebody who has started to install service, the CSI will tell me what I need to know. Chances are that I will receive updated HOLDDATA before doing anything else, so I may not care what he had previously selected. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
On 04/23/2012 04:35 PM, Shmuel Metz (Seymour J.) wrote: In4f90d295.6000...@acm.org, on 04/19/2012 at 10:05 PM, Joel C. Ewingjcew...@acm.org said: If you have multiple people who might have to back each other up and be able to take over and eventually complete a maintenance project started by another using SMP/E ISPF dialogs, then they had better share the same SMPTABL dataset. Otherwise, the only way to continue their maintenance would be to manually start a new project, determine what SYSMODS should be selected, determine the last step done by the prior person, and spin through the already-done dialog steps without actually submitting jobs in order to get to the right starting step. The flip side of that is that if you have multiple people working concurrently the variables tracking the work of one are highly inappropriate for the work of another. If I have to back up somebody who has started to install service, the CSI will tell me what I need to know. Chances are that I will receive updated HOLDDATA before doing anything else, so I may not care what he had previously selected. SMP/E dialogs do not work that way. Users do not share the same variables directly, they share the same list of named maintenance projects within each distinct target zone name, and variable values are associated with a specific maintenance project, not with a user (internally, SMP/E dialogs generate unique project ISPF table names in SMPTABL as needed for storing the variables). If you want a new independent project, you start a new project and give it a name to distinguish it and it has its own set of variables. If you want to resume/continue a previously started project (yours or someone else's), you instead select an existing project from the list and the dialog automatically picks up all the saved variables appropriate to the options and state of that project. When projects are completed either by advancing to the final step or by an explicit CANCEL, the project variables and corresponding ISPF table members are discarded. It works quite well for tracking the state of multiple projects to multiple zones from one maintainer or multiple maintainers, and I have also used it to pick up and resume maintenance started by another when the other went on vacation and priority of the project was raised in their absence. It is especially useful when there is a relatively long lag between APPLY and ACCEPT and you want to be sure to ACCEPT the same SYSMOD set as in APPLY, because a maintenance configuration has proven to be a stable one and you want it as a potential RESTORE point. There is nothing to prevent SMP/E ISPF dialogs with a shared SMPTABL DS from correctly tracking the distinct variables of two different SysProgs that are concurrently working in ISPF on two independent projects. This is true even if both projects are within the same TZONE/DZONE; although, I wouldn't recommend that last level of concurrency as a standard practice as it complicates the issue of when affected libraries should be backed up, and potentially their batch jobs would waste initiator time with enqueue delays waiting for exclusive access to the same CSI datasets. Yes, you can deduce most of the state information from the CSI, possibly with help from the SMP/E log datasets; but it takes much more work and adds unnecessary opportunity for human error. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
The only explanation given for installation-wide is SMP/E uses this table data set to save process status information for the SYSMOD management dialogs. What problems occur[1] if you don't use a shared SMPTABL?I've run into problems when it's shared. The intent is to allow users to share workload and pickup an install process from a coworker as Joel clearly explained. If you don't want this ability, then by all means define a unique SMPTABL per user. There are no problems if you do so, but you won't get the intended benefit. I'm curious, what problems have you run into caused by sharing SMPTABL? Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
On Thu, 19 Apr 2012 09:16:51 -0400, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4f8eb53d.9000...@us.ibm.com, on 04/18/2012 at 08:36 AM, Kurt Quackenbush ku...@us.ibm.com said: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimusr51/3.6.3?SHELF=gim2bk90DT=20110811181158 The only explanation given for installation-wide is SMP/E uses this table data set to save process status information for the SYSMOD management dialogs. What problems occur[1] if you don't use a shared SMPTABL? I've run into problems when it's shared. [1] Assuming that the unshared SMPTABL is in the ISPTLIB concatenation. No problems really, just none of the benefits of sharing it. IOW, if someone starts an install from the sysmod mgmt dialogs and doesn't finish it, another person can't pick up from where they left off. What problems have you run into when sharing? BTW, even when I have been at shops that have a shared SMPTABL allocated via logon clist or logon proc, I usually free it and use my own CNTL library instead and concatenate that into a ISPTLIB LIBDEF in my CLIST I use that invokes the SMP/E dialogs. I think I started doing that because different shops did it different ways or just had too much junk in their SMPTABL lib that was never cleaned up. It really doesn't matter for me these days because I haven't done an interactive sysmod install in probably 15 years. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
In 4f8eb53d.9000...@us.ibm.com, on 04/18/2012 at 08:36 AM, Kurt Quackenbush ku...@us.ibm.com said: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimusr51/3.6.3?SHELF=gim2bk90DT=20110811181158 The only explanation given for installation-wide is SMP/E uses this table data set to save process status information for the SYSMOD management dialogs. What problems occur[1] if you don't use a shared SMPTABL? I've run into problems when it's shared. [1] Assuming that the unshared SMPTABL is in the ISPTLIB concatenation. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
On 04/19/2012 08:16 AM, Shmuel Metz (Seymour J.) wrote: In4f8eb53d.9000...@us.ibm.com, on 04/18/2012 at 08:36 AM, Kurt Quackenbushku...@us.ibm.com said: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimusr51/3.6.3?SHELF=gim2bk90DT=20110811181158 The only explanation given for installation-wide is SMP/E uses this table data set to save process status information for the SYSMOD management dialogs. What problems occur[1] if you don't use a shared SMPTABL? I've run into problems when it's shared. [1] Assuming that the unshared SMPTABL is in the ISPTLIB concatenation. If you have multiple people who might have to back each other up and be able to take over and eventually complete a maintenance project started by another using SMP/E ISPF dialogs, then they had better share the same SMPTABL dataset. Otherwise, the only way to continue their maintenance would be to manually start a new project, determine what SYSMODS should be selected, determine the last step done by the prior person, and spin through the already-done dialog steps without actually submitting jobs in order to get to the right starting step. Also, if a different SMPTABL is used, if the original person were to later use the SMP/E dialogs, it would still look like he had an incomplete project and he might attempt to complete it and attempt to run maintenance jobs that are no longer needed or appropriate. If you have multiple people applying maintenance to the same global/target/dlib zones, sharing SMPTABL may be advisable so you can be fully aware of other activity that might affect or have some impact on the same zones and libraries you are changing. If you have other people doing maintenance with the SMP/E dialogs to other global zone, if there is any chance there are prereq/coreq requirements between those zones and zones of interest to you, a shared SMPTABL is occasionally useful to make it easier to check if there is maintenance in progress to those zones. We had a small enough number of System Programmers that used the SMP/E dialogs that we just found it simpler to share the same SMPTABL among all SysProgs (and there is no reason for anyone other than a SysProg to have SMPTABL allocated). It wasn't that difficult to manually coordinate on rare occasions when library compression or expansion was required. YMMV. Occasionally one may have to clean up abandoned maintenance projects and obsolete SMPTABL members associated with abandoned target zones, but that can happen whether the SMPTABL dataset is shared or not. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
Presumably an output PDS for file tailoring within the SMP/E dialogs. You might want to make it a per-user data set. No no no. SMPTABL is an ISPF table data set intended to be shared by all your SMP/E dialog users. (http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimusr51/3.6.3?SHELF=gim2bk90DT=20110811181158) Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
In 4c9510dff1800349929e187eaf4a7cc214ac73d...@exchange.classic.pchad.com, on 04/13/2012 at 11:46 AM, Dazzo, Matt mda...@pch.com said: I have installed Z1.13 and it's up and running in our test lpar. Seems dsn= SYS1.SMP.SMPTABL is not on the new res volume. I checked the CPAC alloc and restore jobs and can't find it in there either. Searched the migration guide and no mention of it there either. Anyone else run into this or have any ideas why this might be missing? Thanks Matt Presumably an output PDS for file tailoring within the SMP/E dialogs. You might want to make it a per-user data set. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
ZOS 1.13 SMPTABL Mystery
I have installed Z1.13 and it's up and running in our test lpar. Seems dsn= SYS1.SMP.SMPTABL is not on the new res volume. I checked the CPAC alloc and restore jobs and can't find it in there either. Searched the migration guide and no mention of it there either. Anyone else run into this or have any ideas why this might be missing? Thanks Matt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
I've never heard of that data set. Is it an ISPF table data set? Would something like GIM.SGIMTENU / SYS1.GIM.SGIMTENU / SYS1.SGIMTENU be what you need? I would guess SYS1.SMP.SMPTABL was created in-house. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dazzo, Matt Sent: Friday, April 13, 2012 10:47 AM To: IBM-MAIN@bama.ua.edu Subject: ZOS 1.13 SMPTABL Mystery I have installed Z1.13 and it's up and running in our test lpar. Seems dsn= SYS1.SMP.SMPTABL is not on the new res volume. I checked the CPAC alloc and restore jobs and can't find it in there either. Searched the migration guide and no mention of it there either. Anyone else run into this or have any ideas why this might be missing? Thanks Matt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ZOS 1.13 SMPTABL Mystery
I did the upgrade from z1.9 to z1.11 here and never remember copying that dsn from res to res. But John, according to the smpe user guide it is a user defined dataset so you are right on. tks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, April 13, 2012 11:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ZOS 1.13 SMPTABL Mystery I've never heard of that data set. Is it an ISPF table data set? Would something like GIM.SGIMTENU / SYS1.GIM.SGIMTENU / SYS1.SGIMTENU be what you need? I would guess SYS1.SMP.SMPTABL was created in-house. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dazzo, Matt Sent: Friday, April 13, 2012 10:47 AM To: IBM-MAIN@bama.ua.edu Subject: ZOS 1.13 SMPTABL Mystery I have installed Z1.13 and it's up and running in our test lpar. Seems dsn= SYS1.SMP.SMPTABL is not on the new res volume. I checked the CPAC alloc and restore jobs and can't find it in there either. Searched the migration guide and no mention of it there either. Anyone else run into this or have any ideas why this might be missing? Thanks Matt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
