Re: GIMZIP (was: free zIP/UNZIP in z/OS)
In 01ee01ce72d0$ac412e80$04c38b80$@mindspring.com, on 06/26/2013 at 05:53 PM, Lizette Koehler stars...@mindspring.com said: Because many of us asked for IBM to do this. We found that groups outside of Sysprogs were using SMPE to verify fixes. We did not want them altering the environment. Why did you give them write access to the relevant data sets. How does restricting SMPE prevent them from altering the environment? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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: GIMZIP (was: free zIP/UNZIP in z/OS)
Here I agree strongly with Shmuel. Make the data read-only or inaccessible if you must, but leave the tools alone. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
On Thu, 27 Jun 2013 12:06:21 -0400, John Gilmore wrote: Here I agree strongly with Shmuel. Make the data read-only or inaccessible if you must, but leave the tools alone. In the intense discussion of this topic here in April 2010, IBM employes took the position that that is ineffective or not feasible. Since IBM's policies in such cases prohibit more detailed technical discussion, we are unable to assess the merits of that assertion. I continue to suspect that IBM could have provided a more narrowly targeted remedy, but chose not to do so, perhaps for reasons they're not allowed to discuss. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
I think Gil is on to something here. At SHARE conferences following announcement of the change, I got the impression that rank and file thought it was major overkill--even killing by friendly fire--to control product usage in this way. But the shotgun solution was mandated from on high to appease a minuscule subset of customers upset by some local shoot-your-foot catastrophe. It's not hard to manage. Create a RACF Group that has appropriate access to SMP/E, then connect each legitimate user to that group. Until someone moves in or out of the role, you're done. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/27/2013 09:41 AM Subject:Re: GIMZIP (was: free zIP/UNZIP in z/OS) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Thu, 27 Jun 2013 12:06:21 -0400, John Gilmore wrote: Here I agree strongly with Shmuel. Make the data read-only or inaccessible if you must, but leave the tools alone. In the intense discussion of this topic here in April 2010, IBM employes took the position that that is ineffective or not feasible. Since IBM's policies in such cases prohibit more detailed technical discussion, we are unable to assess the merits of that assertion. I continue to suspect that IBM could have provided a more narrowly targeted remedy, but chose not to do so, perhaps for reasons they're not allowed to discuss. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
On Thu, 27 Jun 2013 14:03:14 -0700, Skip Robinson wrote: I think Gil is on to something here. At SHARE conferences following announcement of the change, I got the impression that rank and file thought it was major overkill--even killing by friendly fire--to control product usage in this way. But the shotgun solution was mandated from on high to appease a minuscule subset of customers upset by some local shoot-your-foot catastrophe. It's not hard to manage. Create a RACF Group that has appropriate access to SMP/E, then connect each legitimate user to that group. Until someone moves in or out of the role, you're done. Appeasing a minuscule subset of customers does not rise to the level of a System Integrity APAR (cf. Boy Who Cried Wolf) unless that minuscule subset controls a disproportionate subset of revenues. I suspect there's something more afoot. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
Hi dear IBM-MAINers, First of all a BIG THANK YOU for your 30+ reactions !!! This situation is one between z/OSs! The other site is zipping with PKZIP. GIMZIP is charming my client. Question though: While PKZIP en GIMZIP have both zipin common in their namings, is GIMZIP's zip-format compatible with PKZIP's zip-format ? Rgds, Jan On Tue, Jun 25, 2013 at 10:31 PM, Kurt Quackenbush ku...@us.ibm.com wrote: Given my (unfounded?) assumption that GIMZIP was devised to support SMP/E installation and service, it's puzzling that GIMZIP supports objects SMP/E doesn't process. Are they intended for use in a post-APPLY script? Have you heard of ServerPac? GIMZIP and GIMUNZIP are integral to the internet delivery and installation of an IBM ServerPac offering, that is why GIMZIP supports non-SMP/E consumable file formats in addition to the standard SMP/E stuff. 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: GIMZIP (was: free zIP/UNZIP in z/OS)
A quick internet search came up with a presentation by Sam Knutson ftp://ftp.cbttape.org/pub/present/SHARE97_Fully_Wired.pdf ftp://ftp.cbttape.org/pub/present/SHARE98_Fully_Wired.pdf This presentation is from 2001/2 but may help answer some questions. . GIMZIP Free from IBM available as PTF back to R5, not really a ZIP utility, seems to be a poor choice for a name. (Potential gotcha! ICSF nee crypto is required) . Produces .z file (.pax.z) contains compressed data should be compatible with UNCOMPRESS on UNIX platforms and others that support format . http://www.ibm.com/servers/eserver/zseries/zos/smpe/gimzip.html . GZIP Free, some oddities found by Roland Schiradin with MVS implementation, wide cross platform support including Linux, Windows, UNIX, etc. . http://www.gzip.org Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jan Vanbrabant Sent: Wednesday, June 26, 2013 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GIMZIP (was: free zIP/UNZIP in z/OS) Hi dear IBM-MAINers, First of all a BIG THANK YOU for your 30+ reactions !!! This situation is one between z/OSs! The other site is zipping with PKZIP. GIMZIP is charming my client. Question though: While PKZIP en GIMZIP have both zipin common in their namings, is GIMZIP's zip-format compatible with PKZIP's zip-format ? Rgds, Jan On Tue, Jun 25, 2013 at 10:31 PM, Kurt Quackenbush ku...@us.ibm.com wrote: Given my (unfounded?) assumption that GIMZIP was devised to support SMP/E installation and service, it's puzzling that GIMZIP supports objects SMP/E doesn't process. Are they intended for use in a post-APPLY script? Have you heard of ServerPac? GIMZIP and GIMUNZIP are integral to the internet delivery and installation of an IBM ServerPac offering, that is why GIMZIP supports non-SMP/E consumable file formats in addition to the standard SMP/E stuff. 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: GIMZIP (was: free zIP/UNZIP in z/OS)
On Wed, 26 Jun 2013 07:52:13 -0700, Lizette Koehler wrote: A quick internet search came up with a presentation by Sam Knutson ftp://ftp.cbttape.org/pub/present/SHARE97_Fully_Wired.pdf ftp://ftp.cbttape.org/pub/present/SHARE98_Fully_Wired.pdf This presentation is from 2001/2 but may help answer some questions. . GIMZIP Free from IBM available as PTF back to R5, not really a ZIP utility, seems to be a poor choice for a name. (Potential gotcha! ICSF nee crypto is required) As Tom M. says, there's a software alternative, although it may not have existed at the time of those presentations. But GIMZIP/GIMUNZIP require SMP/E RACF authorization (WHY!?) which may be an obstacle in some environments. Are SMP/E upgrades still available free, or was that only a bridge to get customers over to network delivery? . Produces .z file (.pax.z) contains compressed data should be compatible with UNCOMPRESS on UNIX platforms and others that support format . http://www.ibm.com/servers/eserver/zseries/zos/smpe/gimzip.html In my experience, that's most archiving/extraction utilities. . GZIP Free, some oddities found by Roland Schiradin with MVS implementation, wide cross platform support including Linux, Windows, UNIX, etc. . http://www.gzip.org Another poor choice for a name. But gzip has some very limited compatiblilty with zip. -Original Message- From: Jan Vanbrabant Sent: Wednesday, June 26, 2013 7:40 AM Hi dear IBM-MAINers, This situation is one between z/OSs! The other site is zipping with PKZIP. John and Tom have largely persuaded me that between z/OSes GIMZIP is a preferable alternative. My remaining reservation concerns the (expletive elided) RACF requirement. GIMZIP is charming my client. Question though: While PKZIP en GIMZIP have both zipin common in their namings, is GIMZIP's zip-format compatible with PKZIP's zip-format ? Probably not on z/OS; other environments (e.g. Linux on z) are likely to provide better support. I believe a zip archive containing exactly one file, compressed with the Deflation algorithm, can be extracted with gzip. On Tue, Jun 25, 2013 at 10:31 PM, Kurt Quackenbush wrote: Have you heard of ServerPac? GIMZIP and GIMUNZIP are integral to the internet delivery and installation of an IBM ServerPac offering, that is why GIMZIP supports non-SMP/E consumable file formats in addition to the standard SMP/E stuff. As you have probably surmised, heard of correctly assesses my familiarity with ServerPac. So, thanks for providing me a lead to information that I may someday find useful. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
Gil To answer the one question But GIMZIP/GIMUNZIP require SMP/E RACF authorization (WHY!?) which may be an obstacle in some environments. Because many of us asked for IBM to do this. We found that groups outside of Sysprogs were using SMPE to verify fixes. We did not want them altering the environment. So the facility classes were created. Also, I think there were some audit issues within some shops. So this was done to also support them. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, June 26, 2013 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GIMZIP (was: free zIP/UNZIP in z/OS) On Wed, 26 Jun 2013 07:52:13 -0700, Lizette Koehler wrote: A quick internet search came up with a presentation by Sam Knutson ftp://ftp.cbttape.org/pub/present/SHARE97_Fully_Wired.pdf ftp://ftp.cbttape.org/pub/present/SHARE98_Fully_Wired.pdf This presentation is from 2001/2 but may help answer some questions. . GIMZIP Free from IBM available as PTF back to R5, not really a ZIP utility, seems to be a poor choice for a name. (Potential gotcha! ICSF nee crypto is required) As Tom M. says, there's a software alternative, although it may not have existed at the time of those presentations. But GIMZIP/GIMUNZIP require SMP/E RACF authorization (WHY!?) which may be an obstacle in some environments. Are SMP/E upgrades still available free, or was that only a bridge to get customers over to network delivery? . Produces .z file (.pax.z) contains compressed data should be compatible with UNCOMPRESS on UNIX platforms and others that support format . http://www.ibm.com/servers/eserver/zseries/zos/smpe/gimzip.html In my experience, that's most archiving/extraction utilities. . GZIP Free, some oddities found by Roland Schiradin with MVS implementation, wide cross platform support including Linux, Windows, UNIX, etc. . http://www.gzip.org Another poor choice for a name. But gzip has some very limited compatiblilty with zip. -Original Message- From: Jan Vanbrabant Sent: Wednesday, June 26, 2013 7:40 AM Hi dear IBM-MAINers, This situation is one between z/OSs! The other site is zipping with PKZIP. John and Tom have largely persuaded me that between z/OSes GIMZIP is a preferable alternative. My remaining reservation concerns the (expletive elided) RACF requirement. GIMZIP is charming my client. Question though: While PKZIP en GIMZIP have both zipin common in their namings, is GIMZIP's zip-format compatible with PKZIP's zip-format ? Probably not on z/OS; other environments (e.g. Linux on z) are likely to provide better support. I believe a zip archive containing exactly one file, compressed with the Deflation algorithm, can be extracted with gzip. On Tue, Jun 25, 2013 at 10:31 PM, Kurt Quackenbush wrote: Have you heard of ServerPac? GIMZIP and GIMUNZIP are integral to the internet delivery and installation of an IBM ServerPac offering, that is why GIMZIP supports non-SMP/E consumable file formats in addition to the standard SMP/E stuff. As you have probably surmised, heard of correctly assesses my familiarity with ServerPac. So, thanks for providing me a lead to information that I may someday find useful. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
On Wed, 26 Jun 2013 17:53:00 -0700, Lizette Koehler wrote: To answer the one question But GIMZIP/GIMUNZIP require SMP/E RACF authorization (WHY!?) which may be an obstacle in some environments. Because many of us asked for IBM to do this. We found that groups outside of Sysprogs were using SMPE to verify fixes. We did not want them altering the environment. So the facility classes were created. No. If you read the archives, you will find: From: Walt Farrell wfarr...@us.ibm.com Date: Wed, 14 Apr 2010 09:46:01 -0500 In the original discussion, it was speculated that IBM obviously did not understand that one should protect the data sets rather than trying to protect the program or functions. And that therefore anyone who did have proper data set protections is safe. In most cases that is true. In this case it is not (that's why there is an exposure, and that's why we had the System Integrity APAR IO11698 and its PTF(s).). And: Date: Tue, 13 Apr 2010 09:43:46 -0500 Quoting from IO12263: ... However, of all the functions described above, several need to be controlled very carefully. Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. Therefore, they should be as trusted, for example, as users who have authority to update APF authorized libraries. It's pretty clear that there's an integrity flaw in SMP/E, and that IBM chose not to fix it, but to allow customers to restrict access to SMP/E services. Also, I think there were some audit issues within some shops. So this was done to also support them. Neither of these rises to the level of a System Integrity APAR. Use of SMP/E must be restricted to persons who are trusted not to do something, without being told what that something is. Granted, Walt said much later, in response to my goading, that something such as due caution is sufficient protection. But that's still prety vague. I imagine that IBM could have introduced a new class of resource protection of properly narrow scope rather than trying to protect the program or functions, but felt that doing so would unacceptably disclose the original flaw. Yet there's precedent. IBM did very much that sort of thing when OA30897 introduced the BPX.EXECMVSAPF.program_name FACILITY class that made it glaringly obvious what the defect had been. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
Given my (unfounded?) assumption that GIMZIP was devised to support SMP/E installation and service, it's puzzling that GIMZIP supports objects SMP/E doesn't process. Are they intended for use in a post-APPLY script? Have you heard of ServerPac? GIMZIP and GIMUNZIP are integral to the internet delivery and installation of an IBM ServerPac offering, that is why GIMZIP supports non-SMP/E consumable file formats in addition to the standard SMP/E stuff. 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: GIMZIP (was: free zIP/UNZIP in z/OS)
On Sat, 22 Jun 2013 15:02:22 -0500, Paul Gilmartin paulgboul...@aim.com wrote: o I didn't try a VSAM cluster (VSAM is black magic to me). If one archives a VSAM cluster with GIMZIP and extracts it with GIMUNZIP on a different system, is it immediately useful? It depends. For example, if it is an SMP/E CSI, it won't be very useful by itself. You would need any other data sets are referenced by the CSI to use it. o How do IBM and other vendors largely deliver PTFs nowadays? In SMPPTFIN format with inline elements, or in FROMNETWORK format? I don't understand the question. Neither SMPPTFIN nor FROMNETWORK are formats. A network package, which will be processed by RECEIVE FROMNETWORK or RECEIVE FROMNTS includes data in an SMPPTFIN directory and is processed the same as if it were extracted and included in SMPPTFIN. o Are there noways element types (UNIX?, VSAM?) which can be delivered only in SMPNTS format, never in SMPPTFIN format? o If I RECEIVE a SYSMOD containing a GIMZIPped UNIX directory, what goes in the GLOBAL zone? Nothing. Only components identified as type SMPPTFIN, SMPHOLD or SMPRELF are processed by SMP/E. In what format? If I APPLY it, what goes in the target zone? Nothing. If I ACCEPT it, what goes in the DLIB zone? By now you should know the answer. Nothing. would customers prefer SYSMODS (FUNCTION and PTF) in format: o SMPNTS further wrapped in a pax (or other) envelope? I assume when you write SMPNTS you mean a network package that is suitable to be processed by RECEIVE FROMNETWORK or RECEIVE FROMNTS. The only reason that I can see for using pax to process the network package is for convenience in transporting the package to the customer's site, perhaps via media such as a CD, so that it can then be processed with RECEIVE FROMNTS. If you intend the customer to retrieve it via the internet, they can use either RECEIVE FROMNETWORK TRANSFERONLY or GIMGTPKG, in which case, the package must be in the form that GIMZIP created it. o SMPNTS as many separate (EBCDIC) files? What do you mean by this? Now it seems you mean something other than a network package. Perhaps a directory created by GIMZIP from several files with type README? I can see no value in that. o A single SMPPTFIN in the aforementioned zip package? Again, I have no clue what you are thinking about here. A customer who is using RECEIVE FROMNETWORK wouldn't likely care what the contents of the network package looks like. Rather, they would care whether it works correctly. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
On Mon, 24 Jun 2013 09:56:14 -0500, Tom Marchant wrote: o If I RECEIVE a SYSMOD containing a GIMZIPped UNIX directory, what goes in the GLOBAL zone? Nothing. Only components identified as type SMPPTFIN, SMPHOLD or SMPRELF are processed by SMP/E. Given my (unfounded?) assumption that GIMZIP was devised to support SMP/E installation and service, it's puzzling that GIMZIP supports objects SMP/E doesn't process. Are they intended for use in a post-APPLY script? That would seem to be an abdication of control by SMP/E, and provides no support for RESTORE. A customer who is using RECEIVE FROMNETWORK wouldn't likely care what the contents of the network package looks like. Rather, they would care whether it works correctly. We have had a customer complain that he would prefer to receive RELFILEs unloaded by TSO TRANSMIT rather than by GIMZIP, regardless that the latter works correctly and appears to be the technique chosen and supported by IBM. The customer was able to cite in defense of his position an IBM product delivered in TSO TRANSMIT unloaded RELFILEs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIMZIP (was: free zIP/UNZIP in z/OS)
On Mon, 24 Jun 2013 10:17:42 -0500, Paul Gilmartin wrote: Given my (unfounded?) assumption that GIMZIP was devised to support SMP/E installation and service, That *is* what it was designed for, AFAIK. it's puzzling that GIMZIP supports objects SMP/E doesn't process. From the SMP/E Reference: quote 11.7 GIMZIP packaging service routine The GIMZIP service routine creates portable packages of software and associated materials. Typically the packages will contain SYSMODs, RELFILE data sets, HOLDDATA, and associated materials such as documentation, samples, and text files. These GIMZIP packages may be transported through a network, processed by the GIMUNZIP service routine, and then processed by the SMP/E RECEIVE command. /quote Do you remember RIMLIBs? Those can be packaged in an archive, but are not part of the product. How about books, either in .pdf or .boo format? If you choose, you can even package CSI that contains your product pre-installed. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GIMZIP (was: free zIP/UNZIP in z/OS)
On Fri, 21 Jun 2013 10:05:16 -0500, Tom Marchant wrote: This is not correct, Paul. The data would be extracted using GIMUNZIP, and AFAIK, they are not encoded with GIMDTS. It all depends on whether the intended recipient has access to SMP/E and is authorized to perform an APPLY (APAR IO11698). Nope. It requires that the recipient be authorized to use GIMUNZIP. I stand corrected on this; somewhat happily. I archived a UNIX directory with GIMZIP and examined the product. It was strange_name.pax.Z file plus a couple control files. I extracted it successfully (but not usefully) on a non-IBM system. But it raises a lot of questions: o For file transfer to a foreign system, has this any advantage over the simpler direct use of pax. Pax from the command line also supports code page conversion which might be useful. o I didn't try a VSAM cluster (VSAM is black magic to me). If one archives a VSAM cluster with GIMZIP and extracts it with GIMUNZIP on a different system, is it immediately useful? o How do IBM and other vendors largely deliver PTFs nowadays? In SMPPTFIN format with inline elements, or in FROMNETWORK format? o Are there noways element types (UNIX?, VSAM?) which can be delivered only in SMPNTS format, never in SMPPTFIN format? o If I RECEIVE a SYSMOD containing a GIMZIPped UNIX directory, what goes in the GLOBAL zone? In what format? If I APPLY it, what goes in the target zone? If I ACCEPT it, what goes in the DLIB zone? o All these questions should be answered by RTFM. 22 months ago, I submitted an RCF concerning: Title: z/OS Packaging Rules Document Number: SC23-3695-10 Build Date: 05/22/03 10:45:55 ... concerning absence of rules for network delivery. I received an encouraging reply, ... This document does need to be updated and I have brought it to the attention of development, who agrees with your observation. So far, no change (but am I looking in the wrong place?) I work in a niche division of a large corporation. The corporate standard is that any software package, installation or patch, shall be delivered as a .zip package containing either a README.txt or a README.html file plus an unspecified number of payload files in unspecified format. Our division certainly lacks the leverage to effect a change in this. Subject to these constraints, and absent current information in SC23-3695-10, would customers prefer SYSMODS (FUNCTION and PTF) in format: o SMPNTS further wrapped in a pax (or other) envelope? o SMPNTS as many separate (EBCDIC) files? o A single SMPPTFIN in the aforementioned zip package? o Other (specify)? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
