Re: Getting a VSAM data set's system timestamp
It's really up to the customer, if they want to sync a database with one on a workstation, they will make sure it's possible. I feel we can live with a few false positives. Actually, VSAM is a bit of a rare case, the main use of the product is syncronise enormous source libraries which are being developed on workstations. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 25 November 2013 20:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp I do not think that will be much better. For example. If I am using HSM in my shop and do an HBACKDS command, it will change the Last Backup Date even though the data in the file was not altered. This may also be true for DFDSS dumps and possibly other backup functions You may also have challenges if the VSAM files is handled under RLS (Record Level Sharing). Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robin Atwood Sent: Monday, November 25, 2013 1:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp Thanks to everyone who replied. The server is a part of a product and so installation must have a minimal impact on a customer's system. I am currently going with using the last backup date as an indicator that the data set has been written and a sync is required. Thanks Robin -- 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: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's?
I was delighted to learn---authoritatively from Chris Blaicher---that SYNCSORT no longer makes routine use of BSAM or QSAM to read/write its sortin/sortout datasets. His point that there are no generic, one-size-fits-all solutions is also important. It conceded, my own experience nevertheless strongly suggests that strung-out, multiple job-step schemes of the sort that the OP outlined are almost always inferior to those that attach the sort and use its exits, at least for traditional I/O-bound commercial processing, MFUs and the like. (Well used, COBOL QSAM i/o can be very efficient indeed; but it is almost always used in what I shall politely call suboptimal fashion.) The question whether the sort can itself do any required preprocessing needs always, of course, to be examined 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 11/25/2013 8:36 PM, Ze'ev Atlas wrote: From the little user point of view, he/she knows the name of the file. As a matter of policy in most facilities (probably all), all files that the little user do and/or care for are cataloged and are somewhere in the DFSMS managed storage. Thus, if he/she needs the file, all need to be done is mentioning the name. The 44 character name is indeed a stupid limitation that need to go away. The same thing about stupid limitation is the lack of standard catalog in Unix. That limitation needs to go away. 1) little user sounds pejorative - was that your intent? 2) the 44 character limitation for the data set name is a justifiable limitation based on the original S/360 hardware and software limitations. I would hardly call it stupid. However, I would welcome your detailed strategy for eliminating it, and what limit, if any, would you compromise on? How would you redesign the catalog, VTOC, JCL, etc. and justify the cost of the near rewrite of the OS and many user programs that use the JFCB? Complaining is easy, but developing a viable solution isn't. By comparison, a *nix catalog facility would be child's play. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I interpreted little user as average Windows desktop user. I don't think Ze'ev was trying to be pejorative, just trying to indicate a person who isn't a techno-geek like most of us on the list. On Tue, Nov 26, 2013 at 6:56 AM, Gerhard Postpischil gerh...@valley.netwrote: On 11/25/2013 8:36 PM, Ze'ev Atlas wrote: From the little user point of view, he/she knows the name of the file. As a matter of policy in most facilities (probably all), all files that the little user do and/or care for are cataloged and are somewhere in the DFSMS managed storage. Thus, if he/she needs the file, all need to be done is mentioning the name. The 44 character name is indeed a stupid limitation that need to go away. The same thing about stupid limitation is the lack of standard catalog in Unix. That limitation needs to go away. 1) little user sounds pejorative - was that your intent? 2) the 44 character limitation for the data set name is a justifiable limitation based on the original S/360 hardware and software limitations. I would hardly call it stupid. However, I would welcome your detailed strategy for eliminating it, and what limit, if any, would you compromise on? How would you redesign the catalog, VTOC, JCL, etc. and justify the cost of the near rewrite of the OS and many user programs that use the JFCB? Complaining is easy, but developing a viable solution isn't. By comparison, a *nix catalog facility would be child's play. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. 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: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's?
Chris, Thanks for confirming my assumption that your product uses its optimized I/O facilities for SORTIN/OUT. I agree that there is no single best way to design a process. As usual, it depends Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Monday, November 25, 2013 11:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's? John, SyncSort has for many years not used any regular access methods in the normal course of processing SORTIN or SORTOUT. There are exceptions to this such as compressed files where we have to use BSAM, but for the most part, we do not use traditional access methods. As to the original subject matter, it is impossible to make a single general statement about what way is the best way to design a process. If you are using a COBOL program or exit to transform data or select a subset of records, in general it is faster both in elapsed time and CPU time to use the many features of a sort (INCLUDE/OMIT/INREC/OUTREC/OUTFILE) rather than an exit. As with everything in computing, your mileage may vary. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Monday, November 25, 2013 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's? Note that the highly efficient i/o operations of SYNCSORT and DFSORT are their internal ones. They must and do use access methods to read sortin and write sortout. They do of course use these access methods more efficiently than many/most COBOL programs, but the big i/o savings are elsewhere. John Gilmore, Ashland, MA 01721 - USA -- 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: ISPF 3.4 with HLQ *
So that's TDIAS, correct ? On 11/26/2013 12:17 AM, nitz-...@gmx.net wrote: Doesn't somthing in this thread tend to refutetZe'ev Atlas's recent assertion: Apparently z/OS is capable of finding the file without any manual assistance! ... Well, the devil is a squirrel (as we say in German). While an ADCD system is praised (by IBM) as the best thing for application development since it runs without the buyer having to have sysprog knowledge (and that it does), it is not exactly a shining example of how a z/OS system should be configured to satisfay best practises (health checker coughs up at least 20 severe/errors/warnings when first started; and a few of them cannot easily be remedied). So in general, I would agree with Ze'ev, with the caveat of 'in a well configured system'. Barbara -- 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Mon, Nov 25, 2013 at 7:36 PM, Ze'ev Atlas zatl...@yahoo.com wrote: snip The same thing about stupid limitation is the lack of standard catalog in Unix. That limitation needs to go away. I am confused by this. What would you put in such a catalog? The absolute path name plus file name, such as /u/myid/some/subdir/somefile.txt ? If so, why? If you know the name, the system knows where it is. Or do you must mean the file name without the path, such as somefile.txt? If this latter, how do you distinguish /u/myid/somefile.txt from /u/yourid/somefile.txt? Would the catalog have both entries? If so, then if you reference the file via this catalog, which file do you actually access? Or is this UNIX file catalog really something like I described which is used by the updatedb and locate commands? I.e. something where the end user interactively asks for possible matches, then selects the one they really need from the list of possibilities. I don't expect this to be made a kernel function, but it can be done as I do it via a midnight cron which uses updatedb to scan for the changed (added and deleted) files and updates the catalog for the locate command. If you really need real-time update, then this could possibly be done, at least on Linux, via something like the icrond daemon, which uses the inotify interface which can be used to monitor the filesystem in real time. ZA -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Missing Fix Report Question
We are getting a new DS8870 2424-961 device in the near future. I pulled down 1yr of hold data and ran a missing fixcat report for device IBM.Device.Disk.DS8000-2107. This produced a report requiring 21 pft's be applied. I pulled down and applied the 21 ptf's. I reran the missing fixcat report expecting to see no ptf's required. But to my surprise the fixcat report produced a list of additional 24 ptf's. What am I missing here, why would the fixcat report produce additional ptf requirements? By the way we are running zos1.13 at RSU level 0713. Thanks Matt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF 3.4 with HLQ *
That got me curious. I found this: http://heathen-hub.com/blog.php?b=225 quote What the saying actually means though is that, like a red squirrel jumping back and forth and all over the place, unconnected strange things happen with no rhyme nor reason, or in other words: Randomicity happens. And often it happens a lot. /quote On Tue, Nov 26, 2013 at 7:47 AM, Tony Babonas tonybabo...@icloud.comwrote: So that's TDIAS, correct ? On 11/26/2013 12:17 AM, nitz-...@gmx.net wrote: Doesn't somthing in this thread tend to refutetZe'ev Atlas's recent assertion: Apparently z/OS is capable of finding the file without any manual assistance! ... Well, the devil is a squirrel (as we say in German). While an ADCD system is praised (by IBM) as the best thing for application development since it runs without the buyer having to have sysprog knowledge (and that it does), it is not exactly a shining example of how a z/OS system should be configured to satisfay best practises (health checker coughs up at least 20 severe/errors/warnings when first started; and a few of them cannot easily be remedied). So in general, I would agree with Ze'ev, with the caveat of 'in a well configured system'. Barbara -- 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 -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A possible solution to the mystery of 123 extents per volume (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE List, I've done some research and may have discovered the reason behind the current limit of 123 extents per volume. We all know that the original MVS DEB (a very messy control block because it's so old and so much has evolved) was not designed for VSAM, DF/SMS, etc. It was designed to mesh with the limitations built into other control blocks at that time: * Single-byte extent counts (i.e. one dataset across multiple volumes or multiple datasets concatentated) in the DCB, DSCB, IOB (i.e. MBBCCHHR) and elsewhere. * Limitation of one F1-DSCB and one F3-DSCB (i.e. 16 total extents) per dataset, per volume. In its original design, the DEB probably comprised four fundamental pieces: a 16-byte prefix, a basic section composed of a 32-byte header followed by a variable number of 16-byte device-dependent entries and an access-method-dependent suffix (16 bytes or more, depending on access method). The total length of the DEB was saved in a byte at -4 in the prefix called DEBLNGTH. It contained the total length of the aforementioned setions, measured in doublewords. X'FF' * 8 = a maximum DEB size of 2040 bytes. Minus 64 bytes for the prefix, header and suffix = 1976 bytes. 1976 / 16 = 123 potential device-dependent entries. At the time, each device-dependent entry defined exactly one extent. Hence, in practice, a single DD statement (concatenated or not) was limited to 123 extents. I believe that this DEB limitation prevented datasets from exceeding 123 total extents, even though other control blocks would support up to 255 extents. I can't prove this because I can find no manuals old enough. I have a vague recollection that this jives with a LNKLST restriction from the Dark Ages but my memory is suspect. In any case, an ABEND S013-E4 results when the limitation is exceeded and the text associated with this code has changed over time. The fundamental impetus for the change may have been OS/390, which repackaged what had previously been individually selectable components into one monolithic glob of standardly-delivered elements and features. The LNKLST concatenation was probably one of the longest in the system and (what I believe was) the current limitation of 123 extents in LNKLST just didn't cut it anymore because the standard OS/390 LNKLST included a lot more stuff. OS/390 V1R2 introduced the LNKLST statement in PROGxx and I suspect that this is when the DEB started changing. Perusal of the old documentation suggests that the change ONLY applied to a LNKLST specified via a PROGxx member until OS/390 V1R5 when the change became more generally available; I can't be sure of the exact timing but it makes little difference. DEBLNGTH was effectively retired (I think) and replaced by two single-byte fields: DEBAMLNG and DEBNMEXT (i.e. the length of the access-method-dependent section, in bytes, and the number of device-dependent entries). The number of extents that could be defined by a single DEB was now in alignment with other control blocks (i.e. 255). The limitation regarding the total number of extents in a dataset and/or concatenation was increased from 123 to 255. Even this limitation has changed over time because the newer DSNTYPEs utilize only a single DEB entry, regardless of the number of extents the dataset occupies (e.g. PDS-E, HFS and Extended-Format). So, where does the limitation of 123 extents per volume come from? Since it is a PER VOLUME limitation, I looked at things related to the volume: 1) The VTOC: Nope. All of the fields that I found related to extents are a single byte (i.e. maximum value of 255). F3-DSCBs may be chained, so that's not the issue either. 2) The VVDS: I don't think so. I could find no detailed mapping of the VVDS so I dumped one after creating two datasets: one was non-SMS-managed and comprised 123 extents; the other was SMS-managed, comprised 123 extents and had associated accounting information, exit name and log-stream name. In an NVR or VVR, extents on a volume are apparently described by entries that are about 20-bytes long and contain a single-byte extent number. Even with the maximum amount of information possible, there's plenty of room for more than 123 extent entries in under 4K (i.e. the CISIZE of the VVDS and possibly the maximum size of an NVR or VVR). 3) The BCS (albeit a long shot): Not as far as I can see. I believe that the answer lies in DADSM, an ancient component that traces its roots back to the same days as the DEB. When DASD was designed, a DEB could describe 123 extents; storage was a premium resource at the time, so DADSM restrictions mirrored DEB restrictions. The DEB has evolved but DADSM apparently has not. There are two macros in MODGEN: IECPRLWA (the partial release work area) and IECSCRWA (scratch work area). Both refer to a DADSM area called the Extent Descriptor Table (EDT), that is identified by eyecatcher ICVEDT02. IECPRLWA has
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Tue, 26 Nov 2013 07:56:47 -0500, Gerhard Postpischil wrote: 2) the 44 character limitation for the data set name is a justifiable limitation based on the original S/360 hardware and software limitations. I would hardly call it stupid. However, I would welcome your detailed strategy for eliminating it, and what limit, if any, would you compromise on? How would you redesign the catalog, VTOC, JCL, etc. and justify the cost of the near rewrite of the OS and many user programs that use the JFCB? Doesn't z/OS already provide a UNIX filesystem that transcends the name space constraint? It bypasses catalog and VTOC, and is supported by JCL, allocation, and access methods. Legacy programs that have in intrinsic 44 character limitation can continue to use the legacy filesystem until they get better. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Tue, 26 Nov 2013 07:47:39 -0600, John McKown wrote: I am confused by this. What would you put in such a catalog? The absolute path name plus file name, such as /u/myid/some/subdir/somefile.txt ? If so, why? If you know the name, the system knows where it is. Or do you must mean the file name without the path, such as somefile.txt? If this latter, how do you distinguish /u/myid/somefile.txt from /u/yourid/somefile.txt? Would the catalog have both entries? If so, then if you reference the file via this catalog, which file do you actually access? Well, if the z/OS catalog paradigm is the ideal [f]rom the little user point of view, the existence of the second instance of somefile.txt should be prohibited. That way the little user never needs to know where to look for somefile.txt -- there's only one! I'll go even further: the same member name should never be allowed to exist in two different PDSes. That way, the little user wouldn't need to know in which library to look to find a given named member. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I think you forgot the grin in that post, Gil. z/OS is not for the little user. Neither is UNIX (nor Linux). For a true little user, the OS of choice might be CP/M-80 on an Altair. Or maybe an Apple ][. grin/. On Tue, Nov 26, 2013 at 9:15 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Tue, 26 Nov 2013 07:47:39 -0600, John McKown wrote: I am confused by this. What would you put in such a catalog? The absolute path name plus file name, such as /u/myid/some/subdir/somefile.txt ? If so, why? If you know the name, the system knows where it is. Or do you must mean the file name without the path, such as somefile.txt? If this latter, how do you distinguish /u/myid/somefile.txt from /u/yourid/somefile.txt? Would the catalog have both entries? If so, then if you reference the file via this catalog, which file do you actually access? Well, if the z/OS catalog paradigm is the ideal [f]rom the little user point of view, the existence of the second instance of somefile.txt should be prohibited. That way the little user never needs to know where to look for somefile.txt -- there's only one! I'll go even further: the same member name should never be allowed to exist in two different PDSes. That way, the little user wouldn't need to know in which library to look to find a given named member. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
In 3241976883286959.wa.zatlas1yahoo@listserv.ua.edu, on 11/25/2013 at 07:36 PM, Ze'ev Atlas zatl...@yahoo.com said: The same thing about stupid limitation is the lack of standard catalog in Unix. What do you mean by standard catalog? How does the master catalog differ in principle from the file system mounted as root? What we really need is Multics-style search rules. -- 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: ISPF 3.4 with HLQ *
In 5294a658.3030...@icloud.com, on 11/26/2013 at 07:47 AM, Tony Babonas tonybabo...@icloud.com said: So that's TDIAS, correct ? In Germany, but at the UA data center it's TOIAS. That's Brunswick stew à la transformer. -- 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Tue, 26 Nov 2013 10:38:58 -0500, Shmuel Metz (Seymour J.) wrote: What do you mean by standard catalog? How does the master catalog differ in principle from the file system mounted as root? One uses dots but the other uses slashes. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
We'll, the JES2 has a address field consisting of 60 characters. // DSNAME=data.set.name, 80-10-10=60, VTOC use a new DSCB value, like F7-9 for the Extended non-VSAM. Catalogs require new key size so only new catalogs with the longer key size. Control blocks: additional field with remainder of Dataset name? Since IBM has SDSP for small migrated datasets, why not do something similar for Live datasets? If you close a newly created dataset, and it is 1 (maybe 2) tracks of actual usage, how about saving it in a dataset. VSAM ESDS, Key=data.set.name+block number, contents compressed block up to 32KB. Opening would read entire uncompressed contents into memory, update rewrites blocks, etc. Conversion to normal DSN if the entire file can't be held in memory or reaches a set size. On Tue, Nov 26, 2013 at 6:56 AM, Gerhard Postpischil gerh...@valley.net wrote: On 11/25/2013 8:36 PM, Ze'ev Atlas wrote: From the little user point of view, he/she knows the name of the file. As a matter of policy in most facilities (probably all), all files that the little user do and/or care for are cataloged and are somewhere in the DFSMS managed storage. Thus, if he/she needs the file, all need to be done is mentioning the name. The 44 character name is indeed a stupid limitation that need to go away. The same thing about stupid limitation is the lack of standard catalog in Unix. That limitation needs to go away. 1) little user sounds pejorative - was that your intent? 2) the 44 character limitation for the data set name is a justifiable limitation based on the original S/360 hardware and software limitations. I would hardly call it stupid. However, I would welcome your detailed strategy for eliminating it, and what limit, if any, would you compromise on? How would you redesign the catalog, VTOC, JCL, etc. and justify the cost of the near rewrite of the OS and many user programs that use the JFCB? Complaining is easy, but developing a viable solution isn't. By comparison, a *nix catalog facility would be child's play. Gerhard Postpischil Bradford, Vermont -- 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
SMP/E question
I have a load module that contains a WXTRN reference. If the WXTRN resolves, it gets called to do specialized processing in some specialized environments; the goal was to maximize code reuse. So here's the question. It will reveal (once again) how weak my SMP/E knowledge is, so prepare to be entertained but please be gentle! I need to generate both versions of the load module via SMP/E. Will that work? So the APPLY step needs to point to a different SYSLMOD DD for that second link, I assume, but are there other gotchas here? ISTR being surprised that I couldn't have BANANA (assembler source deck member) and BANANA (macro) in the same SMP/E, um, thingy (CSI?), even though they were in different libraries. But since this is output, not input, I'm hoping it's possible. Thanks in advance for any direction... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
Use different types and you can have tens of same names elements. ITschak On Tue, Nov 26, 2013 at 8:38 PM, Phil Smith p...@voltage.com wrote: I have a load module that contains a WXTRN reference. If the WXTRN resolves, it gets called to do specialized processing in some specialized environments; the goal was to maximize code reuse. So here's the question. It will reveal (once again) how weak my SMP/E knowledge is, so prepare to be entertained but please be gentle! I need to generate both versions of the load module via SMP/E. Will that work? So the APPLY step needs to point to a different SYSLMOD DD for that second link, I assume, but are there other gotchas here? ISTR being surprised that I couldn't have BANANA (assembler source deck member) and BANANA (macro) in the same SMP/E, um, thingy (CSI?), even though they were in different libraries. But since this is output, not input, I'm hoping it's possible. Thanks in advance for any direction... ...phsiii -- 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: SMP/E question
On Tue, 26 Nov 2013 20:44:12 +0200, Itschak Mugzach wrote: Use different types and you can have tens of same names elements. I believe that's somewhat new; perhaps newer than Phil's experience, so don't fault him. On Tue, Nov 26, 2013 at 8:38 PM, Phil Smith wrote: I have a load module that contains a WXTRN reference. If the WXTRN resolves, it gets called to do specialized processing in some specialized environments; the goal was to maximize code reuse. I need to generate both versions of the load module via SMP/E. Will that work? So the APPLY step needs to point to a different SYSLMOD DD for that second link, I assume, but are there other gotchas here? ISTR being surprised that I couldn't have BANANA (assembler source deck member) and BANANA (macro) in the same SMP/E, um, thingy (CSI?), even though they were in different libraries. But since this is output, not input, I'm hoping it's possible. I believe the load module names must be unique, even if they are in different SYSLMODs. But I don't believe aliases are so constrained. Would using a meaningless name with an ALIAS to the name you use work for you? (You might need to provide ENTRY statements for both names.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
Why new? A mod entry can be called same as LMOD entry, and these days there are entry types almost for anything. ITschak On Tue, Nov 26, 2013 at 8:54 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Tue, 26 Nov 2013 20:44:12 +0200, Itschak Mugzach wrote: Use different types and you can have tens of same names elements. I believe that's somewhat new; perhaps newer than Phil's experience, so don't fault him. On Tue, Nov 26, 2013 at 8:38 PM, Phil Smith wrote: I have a load module that contains a WXTRN reference. If the WXTRN resolves, it gets called to do specialized processing in some specialized environments; the goal was to maximize code reuse. I need to generate both versions of the load module via SMP/E. Will that work? So the APPLY step needs to point to a different SYSLMOD DD for that second link, I assume, but are there other gotchas here? ISTR being surprised that I couldn't have BANANA (assembler source deck member) and BANANA (macro) in the same SMP/E, um, thingy (CSI?), even though they were in different libraries. But since this is output, not input, I'm hoping it's possible. I believe the load module names must be unique, even if they are in different SYSLMODs. But I don't believe aliases are so constrained. Would using a meaningless name with an ALIAS to the name you use work for you? (You might need to provide ENTRY statements for both names.) -- gil -- 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: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's?
Syncsort whilst performing optimally, does not work well with transparency products. Many moons ago I discovered this fact and was forced to go the E15 way. A couple of examples that Syncsort did not work with: CA-Datacom VSAM transparency and IBM - VSAM transparency. CA-Sort worked as did DFSORT. In these circumstances, one is forced to develop an E15 exit to present the rows to sort or perform the Extract/Sort multi step job. On Tue, Nov 26, 2013 at 3:09 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: John, SyncSort has for many years not used any regular access methods in the normal course of processing SORTIN or SORTOUT. There are exceptions to this such as compressed files where we have to use BSAM, but for the most part, we do not use traditional access methods. As to the original subject matter, it is impossible to make a single general statement about what way is the best way to design a process. If you are using a COBOL program or exit to transform data or select a subset of records, in general it is faster both in elapsed time and CPU time to use the many features of a sort (INCLUDE/OMIT/INREC/OUTREC/OUTFILE) rather than an exit. As with everything in computing, your mileage may vary. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Monday, November 25, 2013 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's? Note that the highly efficient i/o operations of SYNCSORT and DFSORT are their internal ones. They must and do use access methods to read sortin and write sortout. They do of course use these access methods more efficiently than many/most COBOL programs, but the big i/o savings are elsewhere. 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 ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
On Tue, 26 Nov 2013 20:56:29 +0200, Itschak Mugzach wrote: Why new? A mod entry can be called same as LMOD entry, and these days there are entry types almost for anything. In my dim memory (or perhaps delusion), perhaps SMP without the /E, even entries of the same type couldn't have the same name But Phil wants two load modules (LMOD entries) with the same name. I think that two LMOD entries with different names but identical ALIASes might work -- SMP/E treats ALIAS as raw text; simply passed to Binder. Of course BPAM requires that the ALIASes be in different data sets, which SMP/E supports and Phil wants. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible solution to the mystery of 123 extents per volume (UNCLASSIFIED)
On 26-Nov-13 15:30, Storr, Lon A CTR USARMY HRC , US wrote: Classification: UNCLASSIFIED Caveats: NONE List, I've done some research and may have discovered the reason behind the current limit of 123 extents per volume. We all know that the original MVS DEB (a very messy control block because it's so old and so much has evolved) was not designed for VSAM, DF/SMS, etc. It was designed to mesh with the limitations built into other control blocks at that time: * Single-byte extent counts (i.e. one dataset across multiple volumes or multiple datasets concatentated) in the DCB, DSCB, IOB (i.e. MBBCCHHR) and elsewhere. * Limitation of one F1-DSCB and one F3-DSCB (i.e. 16 total extents) per dataset, per volume. In its original design, the DEB probably comprised four fundamental pieces: a 16-byte prefix, a basic section composed of a 32-byte header followed by a variable number of 16-byte device-dependent entries and an access-method-dependent suffix (16 bytes or more, depending on access method). The total length of the DEB was saved in a byte at -4 in the prefix called DEBLNGTH. It contained the total length of the aforementioned setions, measured in doublewords. X'FF' * 8 = a maximum DEB size of 2040 bytes. Minus 64 bytes for the prefix, header and suffix = 1976 bytes. 1976 / 16 = 123 potential device-dependent entries. At the time, each device-dependent entry defined exactly one extent. Hence, in practice, a single DD statement (concatenated or not) was limited to 123 extents. I believe that this DEB limitation prevented datasets from exceeding 123 total extents, even though other control blocks would support up to 255 extents. I can't prove this because I can find no manuals old enough. I have a vague recollection that this jives with a LNKLST restriction from the Dark Ages but my memory is suspect. In any case, an ABEND S013-E4 results when the limitation is exceeded and the text associated with this code has changed over time. The fundamental impetus for the change may have been OS/390, which repackaged what had previously been individually selectable components into one monolithic glob of standardly-delivered elements and features. The LNKLST concatenation was probably one of the longest in the system and (what I believe was) the current limitation of 123 extents in LNKLST just didn't cut it anymore because the standard OS/390 LNKLST included a lot more stuff. OS/390 V1R2 introduced the LNKLST statement in PROGxx and I suspect that this is when the DEB started changing. Perusal of the old documentation suggests that the change ONLY applied to a LNKLST specified via a PROGxx member until OS/390 V1R5 when the change became more generally available; I can't be sure of the exact timing but it makes little difference. DEBLNGTH was effectively retired (I think) and replaced by two single-byte fields: DEBAMLNG and DEBNMEXT (i.e. the length of the access-method-dependent section, in bytes, and the number of device-dependent entries). The number of extents that could be defined by a single DEB was now in alignment with other control blocks (i.e. 255). The limitation regarding the total number of extents in a dataset and/or concatenation was increased from 123 to 255. Even this limitation has changed over time because the newer DSNTYPEs utilize only a single DEB entry, regardless of the number of extents the dataset occupies (e.g. PDS-E, HFS and Extended-Format). So, where does the limitation of 123 extents per volume come from? Since it is a PER VOLUME limitation, I looked at things related to the volume: 1) The VTOC: Nope. All of the fields that I found related to extents are a single byte (i.e. maximum value of 255). F3-DSCBs may be chained, so that's not the issue either. 2) The VVDS: I don't think so. I could find no detailed mapping of the VVDS so I dumped one after creating two datasets: one was non-SMS-managed and comprised 123 extents; the other was SMS-managed, comprised 123 extents and had associated accounting information, exit name and log-stream name. In an NVR or VVR, extents on a volume are apparently described by entries that are about 20-bytes long and contain a single-byte extent number. Even with the maximum amount of information possible, there's plenty of room for more than 123 extent entries in under 4K (i.e. the CISIZE of the VVDS and possibly the maximum size of an NVR or VVR). 3) The BCS (albeit a long shot): Not as far as I can see. I believe that the answer lies in DADSM, an ancient component that traces its roots back to the same days as the DEB. When DASD was designed, a DEB could describe 123 extents; storage was a premium resource at the time, so DADSM restrictions mirrored DEB restrictions. The DEB has evolved but DADSM apparently has not. There are two macros in MODGEN: IECPRLWA (the partial release work area) and IECSCRWA (scratch work area). Both refer to a DADSM area called the Extent Descriptor Table (EDT),
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I interpreted little user as average Windows desktop user. I don't think Ze'ev was trying to be pejorative, just trying to indicate a person who isn't a techno-geek like most of us on the list. That's what I meant Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
how do you distinguish /u/myid/somefile.txt from /u/yourid/somefile.txt? Would the catalog have both entries? If so, then if you reference the file via this catalog, which file do you actually access? I did give some preliminary thought to this. To accommodate the current concepts of Unix (and Windows) hierarchical file system, such a catalog would, for sure, need to have entries for all files, distinguished by, not only file name, but also the absolute path, so the user could give partial path and find the file. Let's say (and this is common) you have a development and prod environments, which are different only by some branch: /aaa/bbb/dev/ccc/ddd/eee/fff/myfile vs. /aaa/bbb/prod/ggg/ddd/eee/fff/myfile a possible way to find that would be something like (I use backslash as the escape, in Windows we'll need to use slash :): \dev\myfile vs. \prod\myfile ore perhaps, in more complicated environments: \dev\ccc\myfile vs. \prod\ggg\myfile if the same file also exists in /aaa/bbb/dev/ppp/ddd/eee/fff/myfile and /aaa/bbb/prod/rrr/ddd/eee/fff/myfile this is only a concept and it comes to accommodate the peculiarities of the Unix file system. I may think of better ways to design the file systems of both OSes to begin with, but we all know about the hindsight vision. I did not give too much thought for the z/OS file naming because I know the situation there is much more hopeless. I am well aware about how the file naming scheme is entrenched in the rest of the OS. In that case Unix is much more flexible and could be adapted to some standard catalog use is such catalog would be developed and used. I actually gave a thought for the possibility of developing such a product, but I do not have the time and resources. I would be willing to advise and support anybody who may undertake such a project. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I think you forgot the grin in that post, Gil. z/OS is not for the little user. Neither is UNIX (nor Linux). For a true little user, the OS of choice might be CP/M-80 on an Altair. Or maybe an Apple ][. grin/. It is Windows and now Android or iOS. all three have the same issues that I've discussed and a product to catalog files would be a boon for the 'little users' ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 11/26/2013 4:42 PM, Ze'ev Atlas wrote: how do you distinguish /u/myid/somefile.txt from /u/yourid/somefile.txt? Would the catalog have both entries? If so, then if you reference the file via this catalog, which file do you actually access? In z/OS and precursors, you need to know the full file name, unless you have some software assistance (e.g., TSO and Wylbur will prepend an unquoted file name with a user specified prefix, or the user id. This isn't too different from the *nix case. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS the refinished antique
On the Antique Road show(PBS) one Queen Anne sideboard was appraised at several thousand dollars. The appraiser went on to say if it hadn't been refinished it would be worth over a hundred thousand. The hardware advances coupled with the hundreds of new instructions allow z/OS to progress and evolve. In Dr Webb's rollout paper for the G6/Z6 he points to the use of 62% commonality and addition of cache strategies to accomplish thruput improvements mated with z/OS instruction set on a base processor with 176,000,000 transistors. These are not trivial pursuits. The Global Foundries fabrication center is a multi-billion facility with continual updates and modifications. _www.globalfoundries.com_ (http://www.globalfoundries.com) Guess my point is for all it's warts and wrinkles z/OS is here and evolving as it carries a large workload for Fortune 500 companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I totally agree Gerhard, my Opsys have similarities in components and structure. One just has to be aware enough , open minded enough and experienced enough to see it. As a ex-VMer I see a lot of similarities between VM and * nix Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Nov 26, 2013, at 5:07 PM, Gerhard Postpischil gerh...@valley.net wrote: On 11/26/2013 4:42 PM, Ze'ev Atlas wrote: how do you distinguish /u/myid/somefile.txt from /u/yourid/somefile.txt? Would the catalog have both entries? If so, then if you reference the file via this catalog, which file do you actually access? In z/OS and precursors, you need to know the full file name, unless you have some software assistance (e.g., TSO and Wylbur will prepend an unquoted file name with a user specified prefix, or the user id. This isn't too different from the *nix case. Gerhard Postpischil Bradford, Vermont -- 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: SMP/E question
I have not tried the exact combination of SRC and MAC with the same name but as far back as 1995 (MVS/ESA 4.3) I have used various DATAx with the same name as a MAC, SRC, PROC, SAMP, etc with no apparent conflict. In any event, the ++LMOD control statement supports up to two DD names in the SYSLIB operand. Between that and ++JCLIN control cards, you should have no trouble generating the two versions you want. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Phil Smith :: Sent: Tuesday, November 26, 2013 10:39 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: SMP/E question :: :: I have a load module that contains a WXTRN reference. If the WXTRN :: resolves, it gets called to do specialized processing in some :: specialized environments; the goal was to maximize code reuse. :: :: So here's the question. It will reveal (once again) how weak my SMP/E :: knowledge is, so prepare to be entertained but please be gentle! :: :: I need to generate both versions of the load module via SMP/E. Will that :: work? So the APPLY step needs to point to a different SYSLMOD DD for :: that second link, I assume, but are there other gotchas here? ISTR :: being surprised that I couldn't have BANANA (assembler source deck :: member) and BANANA (macro) in the same SMP/E, um, thingy (CSI?), even :: though they were in different libraries. But since this is output, not :: input, I'm hoping it's possible. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
At 13:07 -0600 on 11/26/2013, Paul Gilmartin wrote about Re: SMP/E question: But Phil wants two load modules (LMOD entries) with the same name. I think that two LMOD entries with different names but identical ALIASes might work -- SMP/E treats ALIAS as raw text; simply passed to Binder. Of course BPAM requires that the ALIASes be in different data sets, which SMP/E supports and Phil wants. The question that was not answered is how the decision is made to run the LMOD with the WXTRN'ed code vs the one where the WXTRN was not resolved. This would seem to imply that the LMOD was Job Step PGM= and two STEPLIBS were used. If the LMOD was being called by an already running step (ie: Is LINK'ed or ATTACH'ed) then just call it by the correct ALIAS name and both can be in the same library (since it is invoked by its alias not lmod name) -- gil -- 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: SMP/E question
On Tue, 26 Nov 2013 16:48:30 -0800, retired mainframer wrote: I have not tried the exact combination of SRC and MAC with the same name but as far back as 1995 (MVS/ESA 4.3) I have used various DATAx with the same name as a MAC, SRC, PROC, SAMP, etc with no apparent conflict. In any event, the ++LMOD control statement supports up to two DD names in the SYSLIB operand. Between that and ++JCLIN control cards, you should have no trouble generating the two versions you want. I find no ++LMOD MCS mentioned in the TOC of: Title: SMP/E V3R6.0 for z/OS V1R13.0 Reference Document Number: SA22-7772-16 Are you thinking, perhaps of UCLIN to define LMOD entries in Title: SMP/E V3R6.0 for z/OS V1R13.0 Commands Document Number: SA22-7771-15 ??? And while either UCLIN or ++JCLIN may define up to two SYSLIB (target library) subentries in an LMOD entry, I see no way that the the two load modules may have different content or attributes, which is what Phil requires. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
At 16:48 -0800 on 11/26/2013, retired mainframer wrote about Re: SMP/E question: In any event, the ++LMOD control statement supports up to two DD names in the SYSLIB operand. Between that and ++JCLIN control cards, you should have no trouble generating the two versions you want. If the SYSLIB is were the LMOD is to be placed, you still have a problem since the two versions are different - one had the WXTRNs resolved and the other does not. Thus there needs to be TWO Binder operations and thus two sets of JCLIN. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
