Re: Getting a VSAM data set's system timestamp
Maybe via SMF records ? On 21.11.2013 13:48, Robin Atwood wrote: I want our file server to be able to tell the clients when a data set last changed. For non-VSAM it's easy (if a bit vague), there's the last reference date in the F1 DSCB. For VSAM you can see a SYSTEM-TIMESTAMP in the LISTCAT output but how do you get that from a program? We currently use IGGCSI00 for VSAM info but there is no field name for the timestamp. The SHOWCAT macro does not seem to show all that much at all. Any ideas out there? I am hoping I have missed something. TIA Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Is there any relation between IXGLOGR and SMF?
Dear all Our shop is z/OS 1.13+CICS 4.2+DB 10 with 6 members parallel sysplexs. SMF don't use logstream. SMF data always is writed to SYS1.MANX. If we change the interval of SMF, we found that IXGLOGR always use CPU following SMF interval Please see the RMF III report below. RMF V1R13 Processor Delays Line 1 of 79 Samples: 60 System: NP1A Date: 11/22/13 Time: 15.45.00 Range: 60Sec Service CPU DLY USG EAppl --- Holding Job(s) --- Jobname CX ClassType % %% % Name % Name % Name CANSDSST SO STCHICP 2 3 0.42 IXGLOGR2 SMF SA390SO SYSSTC CP 2 2 0.82 IXGLOGR2 SMF TCPIPSO SYSSTC CP 2 2 0.12 IXGLOGR2 SMF CANSC5 SO STCHICP 2 2 0.12 IXGLOGR2 SMF JES2 S SYSSTC CP 2 2 0.12 IXGLOGR2 SMF CINAETA2 SO STCTOR CP 2 2 0.12 IXGLOGR2 SMF IXGLOGR S SYSTEM CP 2 2 0.12 IXGLOGR2 SMF CINAEAA4 SO STCAOR CP 2 0 0.42 IXGLOGR2 SMF CINAEAA1 SO STCAOR CP 2 0 0.32 IXGLOGR2 SMF CINAEAA3 SO STCAOR CP 2 0 0.32 IXGLOGR2 SMF RMFGAT SO STCHICP 2 0 0.32 IXGLOGR2 SMF CINAEAA2 SO STCAOR CP 2 0 0.22 IXGLOGR2 SMF EP11IRLM S SYSSTC CP 2 0 0.22 IXGLOGR2 SMF CCBOPC1 T TSO CP 2 0 0.12 IXGLOGR2 SMF CANSO2 S STCHICP 2 0 0.12 IXGLOGR2 SMF CANSM2HI SO STCHICP 2 0 0.12 IXGLOGR2 SMF Command === Scroll === CSR RMF V1R13 Processor Delays Line 1 of 56 Samples: 60 System: NP1B Date: 11/22/13 Time: 15.45.00 Range: 60Sec Service CPU DLY USG EAppl --- Holding Job(s) --- Jobname CX ClassType % %% % Name % Name % Name JES2MON S SYSSTC CP 3 0 0.03 WLM2 IXGLOGR CANSDSST SO STCHICP 2 2 0.42 WLM2 IXGLOGR TP1NIRLM S SYSSTC CP 2 2 0.12 WLM2 IXGLOGR JES2 S SYSSTC CP 2 2 0.12 WLM2 IXGLOGR IXGLOGR S SYSTEM CP 2 2 0.02 WLM2 IXGLOGR SA390SO SYSSTC CP 2 0 0.62 WLM2 IXGLOGR RMFGAT SO STCHICP 2 0 0.32 WLM2 IXGLOGR CANSM2HI SO STCHICP 2 0 0.12 WLM2 IXGLOGR GPMSERVE SO STCLOCP 2 0 0.12 WLM2 IXGLOGR TCPIPSO SYSSTC CP 2 0 0.12 WLM2 IXGLOGR RMF S STCHICP 2 0 0.12 WLM2 IXGLOGR VTAM SO SYSSTC CP 2 0 0.12 WLM2 IXGLOGR HSM S STCMED CP 2 0 0.02 WLM2 IXGLOGR OAM S STCMED CP 2 0 0.02 WLM2 IXGLOGR CTMCMEM S STCMED CP 2 0 0.02 WLM2 IXGLOGR DFRMMS STCHICP 2 0 0.02 WLM2 IXGLOGR Command === Scroll === CSR RMF V1R13 Processor Delays Line 1 of 77 Samples: 60 System: NP1C Date: 11/22/13 Time: 15.45.00 Range: 60Sec Service CPU DLY USG EAppl --- Holding Job(s) --- Jobname CX ClassType % %% % Name % Name % Name CANSDSST SO STCHICP 3 3 0.52 SA390 2 CANSC5 2 CINCEAC4 EP21IRLM S SYSSTC CP 3 2 0.23 IXGLOGR2 GRS2 XCFAS EP21DBM1 S STCHICP 3 0 10.03 IXGLOGR2 GRS2 XCFAS VTAM SO SYSSTC CP 3 0 0.1
Re: Getting a VSAM data set's system timestamp
The F1 DSCB does contain a flag, DS1IND02, which indicates a dataset has been opened for other-than-input. This is the flag that alerts your backup software that the dataset needs a backup. The backup software will reset this flag. If you run your synchronization check prior to the backup process, you should be able to identify which datasets on the server are out of date. While ISPF and other library management tools may keep update timestamps in the PDS directory, other tools, such as the Binder, do not. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 11:49 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Getting a VSAM data set's system timestamp :: :: So both you and Lizette are saying that even I can obtain it, the :: available :: timestamp is not very useful. We need to synchronise the mainframe data :: set :: with its workstation copy and currently use hashes of each file to see :: if :: they are different. This is CPU intensive and I had hoped to avoid it by :: comparing the last write dates. It looks like my scheme won't work in :: this :: case (it works fine for libraries of members like PDSs and Endevor). Hmm. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting a VSAM data set's system timestamp
Interesting idea but the information is needed during a file transfer so analysing the SMF records might be a bit lengthy! I have just noticed that ISPF 3.4 'S' line command gives you a last reference date for the DATA component. This would be better than nothing. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: 22 November 2013 15:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp Maybe via SMF records ? On 21.11.2013 13:48, Robin Atwood wrote: I want our file server to be able to tell the clients when a data set last changed. For non-VSAM it's easy (if a bit vague), there's the last reference date in the F1 DSCB. For VSAM you can see a SYSTEM-TIMESTAMP in the LISTCAT output but how do you get that from a program? We currently use IGGCSI00 for VSAM info but there is no field name for the timestamp. The SHOWCAT macro does not seem to show all that much at all. Any ideas out there? I am hoping I have missed something. TIA Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- 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: Getting a VSAM data set's system timestamp
Thanks, that's very helpful. Thus prompted, I now notice that IGGCSI00 has a last backup timestamp field name (LTBACKDT), so with all these bits of information I should be able to determine if a sync with the workstation is necessary. Excellent stuff! Cheers Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: 22 November 2013 16:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp The F1 DSCB does contain a flag, DS1IND02, which indicates a dataset has been opened for other-than-input. This is the flag that alerts your backup software that the dataset needs a backup. The backup software will reset this flag. If you run your synchronization check prior to the backup process, you should be able to identify which datasets on the server are out of date. While ISPF and other library management tools may keep update timestamps in the PDS directory, other tools, such as the Binder, do not. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 11:49 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Getting a VSAM data set's system timestamp :: :: So both you and Lizette are saying that even I can obtain it, the :: available :: timestamp is not very useful. We need to synchronise the mainframe data :: set :: with its workstation copy and currently use hashes of each file to see :: if :: they are different. This is CPU intensive and I had hoped to avoid it by :: comparing the last write dates. It looks like my scheme won't work in :: this :: case (it works fine for libraries of members like PDSs and Endevor). Hmm. -- 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: smf records for updating racf profiles
Walt Farrell wrote: Not quite right, Elardus, if he asked the right question. He asked about creating/updating/deleting *profiles*, not resources. Ouch. Thanks, I have overlooked that word 'proflies'. Yuck, my fault, but thanks again! :-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting a VSAM data set's system timestamp
One possibility, which is not simply by any means, is to use the SMF data in real time, with the SMF IEFU8x exits, to trap the SMF type 15 records (non-VSAM open for OUTPUT or UPDAT) and type 62 (VSAM cluster opened). With the type 62, you need to test SMF62MC1 to see if the open is for output/update. This can be done using CA-7 (if you have it). We use it to trigger jobs when a file is created / updated via something like ftp from a Windows server. Another possibility is to create a discrete RACF profile for the dataset(s) you are concerned about and AUDIT them. This will produce a RACF SMF record. Which you could trap using the SMF IEFU8x exits, or simply process sometime later, say when you dump the individual SMF data sets, if you don't need real time. Oh, the same for the type 15 62 records too, I guess. On Fri, Nov 22, 2013 at 1:48 AM, Robin Atwood abend...@gmail.com wrote: So both you and Lizette are saying that even I can obtain it, the available timestamp is not very useful. We need to synchronise the mainframe data set with its workstation copy and currently use hashes of each file to see if they are different. This is CPU intensive and I had hoped to avoid it by comparing the last write dates. It looks like my scheme won't work in this case (it works fine for libraries of members like PDSs and Endevor). Hmm. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: 22 November 2013 00:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp For a non-VSAM dataset, the last reference date in the F1 DSCB does not mean the dataset was changed on that date, only that it was opened (and closed?), even if only for input. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 4:48 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Getting a VSAM data set's system timestamp :: :: I want our file server to be able to tell the clients when a data set :: last :: changed. For non-VSAM it's easy (if a bit vague), there's the last :: reference :: date in the F1 DSCB. -- 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
Re: Extents limit for HFS (UNCLASSIFIED)
Don't know the -71, but -16 is the fixed portion of a TIOT entry. The rest of the 255 bytes can hold pointers to UCB's. 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 Ted MacNEIL Sent: Thursday, November 21, 2013 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS (UNCLASSIFIED) Where do the -71 and -16 come from? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Storr, Lon A CTR USARMY HRC (US) lon.a.storr@mail.mil Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 21 Nov 2013 19:11:58 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE According to my personal notes The restriction of 127 extents per volume (device) comes from the DEB: DEBLNGTH is the number of double-words in the DEB (up to 255 === 255 * 8 = 2040; (2040 - 71) / 16 = 123). The restriction of 59 volumes (devices) per DD comes from the TIOT: TIOELNGH is the number of bytes in the TIOT entry (up to 255 === (255 - 16) / 4 = 59) Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Classification: UNCLASSIFIED Caveats: NONE -- 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 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
Re: Extents limit for HFS
For the BLKSIZE= constraint mod(32760,8) = 0, mod(32767,8) ¬= 0. For the extents-per-volume question it is hard to see any basis for an alignment issue, and in any case both 123 and 127 are odd. (Of the two 123 is composite and 127 = 2^7 - 1 is a Mersenne prime, but this difference too is unlikely to be relevant.) Finally, my point was not a cavil. I have no animus against the number 123. I was and am seeking enlightenment. There is presumably a rationale for the number 123; but 1) what it is has eluded me; and 2) a search of the IBM-MAIN archives was unhelpful, perhaps because my query was inept. 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
OT: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others.
Given the recent discussion on early Fortran implementations and other historical stuff on IBMVM, you folks may want to hunt down the current issue of the IEEE Annals of the History of Computing (volume 35, #4). This issue contains a really good article on industry approaches in the early days of the commercial computing industry, but also contains two other articles worth reading: one on the early development of compilers and programming languages at IBM Europe location (discussing a lot of the origins of structured languages like PL/1 and PL/M, and the origins of the various Fortran and COBOL compilers), and second, a close look at the training and engagement model for sales people used by IBM up until very recently. The articles are not freely downloadable, but they're worth the effort to obtain. The second article would be good required reading for the current IBM management team. It has a lot to say about what IBM used to be, and what might yet save them from themselves. Article references: Endres, Albert. Early Language and Compiler Developments at IBM Europe: A Personal Retrospection, in /IEEE Annals of the History of Computing/, v.35, #4 (Oct-Dec, 2013), pp 18-30. Cortada, James W. 'Carrying a Bag': Memoirs of and IBM Salesman, 1974-1981, in /IEEE Annals of the History of Computing/, v35, #4 (Oct-Dec, 2013) , pp 32-47. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
I was in a class a long time ago and the explanation at that time was as follows, to the best of my recollection. They can handle up to 127 extents, but any request for secondary can take up to 5 extents to satisfy it. The comment was that the developers didn't want to have to deal with the case where they were at, say, 125 extents and asked for another and got 5 back. In that case they would use 2 and have to give 3 back. It had something to do with they were using a service that wasn't theirs and didn't want to deal it. This way if it was at 122 extents and asked for another extend it would always fit be it 1 or 5 extents returned. As I said, this was from a long time ago and my page-in facility may have lost a few bits along the way. 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: Friday, November 22, 2013 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS For the BLKSIZE= constraint mod(32760,8) = 0, mod(32767,8) ¬= 0. For the extents-per-volume question it is hard to see any basis for an alignment issue, and in any case both 123 and 127 are odd. (Of the two 123 is composite and 127 = 2^7 - 1 is a Mersenne prime, but this difference too is unlikely to be relevant.) Finally, my point was not a cavil. I have no animus against the number 123. I was and am seeking enlightenment. There is presumably a rationale for the number 123; but 1) what it is has eluded me; and 2) a search of the IBM-MAIN archives was unhelpful, perhaps because my query was inept. 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
Re: Getting a VSAM data set's system timestamp
Ingenious and it would be technically fascinating to try and implement! However I imagine it would be a bit of a hard sell to the customers. :) Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 22 November 2013 20:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp One possibility, which is not simply by any means, is to use the SMF data in real time, with the SMF IEFU8x exits, to trap the SMF type 15 records (non-VSAM open for OUTPUT or UPDAT) and type 62 (VSAM cluster opened). With the type 62, you need to test SMF62MC1 to see if the open is for output/update. This can be done using CA-7 (if you have it). We use it to trigger jobs when a file is created / updated via something like ftp from a Windows server. Another possibility is to create a discrete RACF profile for the dataset(s) you are concerned about and AUDIT them. This will produce a RACF SMF record. Which you could trap using the SMF IEFU8x exits, or simply process sometime later, say when you dump the individual SMF data sets, if you don't need real time. Oh, the same for the type 15 62 records too, I guess. On Fri, Nov 22, 2013 at 1:48 AM, Robin Atwood abend...@gmail.com wrote: So both you and Lizette are saying that even I can obtain it, the available timestamp is not very useful. We need to synchronise the mainframe data set with its workstation copy and currently use hashes of each file to see if they are different. This is CPU intensive and I had hoped to avoid it by comparing the last write dates. It looks like my scheme won't work in this case (it works fine for libraries of members like PDSs and Endevor). Hmm. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: 22 November 2013 00:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp For a non-VSAM dataset, the last reference date in the F1 DSCB does not mean the dataset was changed on that date, only that it was opened (and closed?), even if only for input. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 4:48 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Getting a VSAM data set's system timestamp :: :: I want our file server to be able to tell the clients when a data set :: last :: changed. For non-VSAM it's easy (if a bit vague), there's the last :: reference :: date in the F1 DSCB. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting a VSAM data set's system timestamp
Ah, my bad, I didn't realize this was not for an in-house type project. On Fri, Nov 22, 2013 at 8:32 AM, Robin Atwood abend...@gmail.com wrote: Ingenious and it would be technically fascinating to try and implement! However I imagine it would be a bit of a hard sell to the customers. :) Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 22 November 2013 20:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp One possibility, which is not simply by any means, is to use the SMF data in real time, with the SMF IEFU8x exits, to trap the SMF type 15 records (non-VSAM open for OUTPUT or UPDAT) and type 62 (VSAM cluster opened). With the type 62, you need to test SMF62MC1 to see if the open is for output/update. This can be done using CA-7 (if you have it). We use it to trigger jobs when a file is created / updated via something like ftp from a Windows server. Another possibility is to create a discrete RACF profile for the dataset(s) you are concerned about and AUDIT them. This will produce a RACF SMF record. Which you could trap using the SMF IEFU8x exits, or simply process sometime later, say when you dump the individual SMF data sets, if you don't need real time. Oh, the same for the type 15 62 records too, I guess. On Fri, Nov 22, 2013 at 1:48 AM, Robin Atwood abend...@gmail.com wrote: So both you and Lizette are saying that even I can obtain it, the available timestamp is not very useful. We need to synchronise the mainframe data set with its workstation copy and currently use hashes of each file to see if they are different. This is CPU intensive and I had hoped to avoid it by comparing the last write dates. It looks like my scheme won't work in this case (it works fine for libraries of members like PDSs and Endevor). Hmm. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: 22 November 2013 00:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp For a non-VSAM dataset, the last reference date in the F1 DSCB does not mean the dataset was changed on that date, only that it was opened (and closed?), even if only for input. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 4:48 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Getting a VSAM data set's system timestamp :: :: I want our file server to be able to tell the clients when a data set :: last :: changed. For non-VSAM it's easy (if a bit vague), there's the last :: reference :: date in the F1 DSCB. -- 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 -- 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: When should we ACCEPT DB2 PTFs?
IMO, the short answer is just before the next APPLY. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
This excerpt from an 8-31-2010 post by Alan Starr, in reply to a question from R.S. who also started the current thread: (begin quote) I believe that the answers to your questions may be found in the Data Extent Block (DEB) and the murky depths of history. Due to its age, its close connections to original S370 hardware limitations and downward compatibility requirements, the DEB is a messy control block. As far as I can tell: 1) It may never exceed 2040 bytes because the single-byte field called DEBLNGTH at -4 specifies the total DEB length in doublewords. Maximum value is 255, which represents 2040 bytes. 2) At a very minimum, a direct access EXCP / BSAM / QSAM DEB comprises a. 23-byte prefix (appendage vector table) b. 32-byte basic section c. Direct Access device sections d. 16-byte EXCP, BSAM and QSAM dependent section 3) Expanding upon #2, the minimum length of a DEB (with no device sections) is 23+32+16 = 71 The maximum DEB length of 2040 minus 71 leaves 1969 bytes for device sections, each of which is 16 bytes 1969 / 16 = 123 and an odd byte (end quote) Full text here: https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/V3zK0zcEDPI/4DOoJbAVmgEJ Bill On Fri, 22 Nov 2013 09:07:10 -0500, Blaicher, Christopher Y. wrote: I was in a class a long time ago and the explanation at that time was as follows, to the best of my recollection. They can handle up to 127 extents, but any request for secondary can take up to 5 extents to satisfy it. The comment was that the developers didn't want to have to deal with the case where they were at, say, 125 extents and asked for another and got 5 back. In that case they would use 2 and have to give 3 back. It had something to do with they were using a service that wasn't theirs and didn't want to deal it. This way if it was at 122 extents and asked for another extend it would always fit be it 1 or 5 extents returned. As I said, this was from a long time ago and my page-in facility may have lost a few bits along the way. 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: Friday, November 22, 2013 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS For the BLKSIZE= constraint mod(32760,8) = 0, mod(32767,8) �= 0. For the extents-per-volume question it is hard to see any basis for an alignment issue, and in any case both 123 and 127 are odd. (Of the two 123 is composite and 127 = 2^7 - 1 is a Mersenne prime, but this difference too is unlikely to be relevant.) Finally, my point was not a cavil. I have no animus against the number 123. I was and am seeking enlightenment. There is presumably a rationale for the number 123; but 1) what it is has eluded me; and 2) a search of the IBM-MAIN archives was unhelpful, perhaps because my query was inept. 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: Getting a VSAM data set's system timestamp
John is correct. Many scheduling products (CA Workload Automation/ESP, CA7, Jobtrac, etc) will monitor SMF data and have a function called a dataset trigger. If you have such a tool, then you could review if it could help in your situation. Otherwise, you will need to look at the SMF Exits. Or if you have a product like DB2 that you could extract updates from the DB2 logs and apply them to your workstation. Or if your application could be modified to generate a record modified log that could be applied to your workstation. You did not indicate if your VSAM dataset was being used by something like CICS, home grown application. Whether the file was held open for long periods of time or opened and closed more frequently. Any additional details you could share with us, we might be able to come up with other options. How large is the VSAM file that needs to be sync'd with the workstation? How do you sync the file? FTP, NDM, CD, etc How often do you sync the files? Does the workstation sync with the mainframe or is it just the mainframe to the workstation? What is your SLA for this data to be sync'd? Are you using IMS, DB2, CICS or is this native VSAM? Do you have IMS, CICS, DB2 or MQ in your shop? Could they be used to help with this situation? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, November 22, 2013 6:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp One possibility, which is not simply by any means, is to use the SMF data in real time, with the SMF IEFU8x exits, to trap the SMF type 15 records (non-VSAM open for OUTPUT or UPDAT) and type 62 (VSAM cluster opened). With the type 62, you need to test SMF62MC1 to see if the open is for output/update. This can be done using CA-7 (if you have it). We use it to trigger jobs when a file is created / updated via something like ftp from a Windows server. Another possibility is to create a discrete RACF profile for the dataset(s) you are concerned about and AUDIT them. This will produce a RACF SMF record. Which you could trap using the SMF IEFU8x exits, or simply process sometime later, say when you dump the individual SMF data sets, if you don't need real time. Oh, the same for the type 15 62 records too, I guess. On Fri, Nov 22, 2013 at 1:48 AM, Robin Atwood abend...@gmail.com wrote: So both you and Lizette are saying that even I can obtain it, the available timestamp is not very useful. We need to synchronise the mainframe data set with its workstation copy and currently use hashes of each file to see if they are different. This is CPU intensive and I had hoped to avoid it by comparing the last write dates. It looks like my scheme won't work in this case (it works fine for libraries of members like PDSs and Endevor). Hmm. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: 22 November 2013 00:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp For a non-VSAM dataset, the last reference date in the F1 DSCB does not mean the dataset was changed on that date, only that it was opened (and closed?), even if only for input. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 4:48 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Getting a VSAM data set's system timestamp :: :: I want our file server to be able to tell the clients when a data set :: last :: changed. For non-VSAM it's easy (if a bit vague), there's the last :: reference :: date in the F1 DSCB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID dynamic Activation error
Hello Jake , This actually means The system could not add the specified path to a path group. Is the cable connected properly ? That's the first thing to be checked . Also look at logrec data Sounds to me like a no resources condition over the control unit . Try these commands a) DS P, b) DS QD, Thank you , Steyn ! On Thursday, November 21, 2013 5:32 PM, Lizette Koehler stars...@mindspring.com wrote: I would start by doing an internet search on your messages IOS444I. There should be some helpful hints out there. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Thursday, November 21, 2013 1:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CHPID dynamic Activation error Hello Group, For our New storage Box,While dynamically adding new CHPID to existing control UNIT, I tried displaying new CHIPD but its only show that path are online not operational. I have referred the below link but I am not able to get any Clue. http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IEA2M9C1/SPTM013022 D M=CHP(E2) IEE174I 23.18.04 DISPLAY M 250 CHPID E2: TYPE=1A, DESC=FICON POINT TO POINT, ONLINE DEVICE STATUS FOR CHANNEL PATH E2 0 1 2 3 4 5 6 7 8 9 A B C D E F 300 * * * * * * * * * * * * * * * * 301 * * * * * * * * * * * * * * * * 302 * * * * * * * * * * * * * * * * 303 * * * * * * * * * * * * * * * * 304 * * * * * * * * * * * * * * * * 305 * * * * * * * * * * * * * * * * 306 * * * * * * * * * * * * * * * * 307 * * * * * * * * * * * * * * * * 308 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL 309 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL 30A AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F38,E2) IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3E,E2) IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3F,E2) Could someone please shed light on the above. Any suggestions or directions are much appreciated. Jake -- 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: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others.
The latest volume does not yet appear to be available electronically on the IEEE sites - latest available seems to be volume 35 #3. Do you have a link to #4? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Boyes Sent: Friday, November 22, 2013 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others. Given the recent discussion on early Fortran implementations and other historical stuff on IBMVM, you folks may want to hunt down the current issue of the IEEE Annals of the History of Computing (volume 35, #4). This issue contains a really good article on industry approaches in the early days of the commercial computing industry, but also contains two other articles worth reading: one on the early development of compilers and programming languages at IBM Europe location (discussing a lot of the origins of structured languages like PL/1 and PL/M, and the origins of the various Fortran and COBOL compilers), and second, a close look at the training and engagement model for sales people used by IBM up until very recently. The articles are not freely downloadable, but they're worth the effort to obtain. The second article would be good required reading for the current IBM management team. It has a lot to say about what IBM used to be, and what might yet save them from themselves. Article references: Endres, Albert. Early Language and Compiler Developments at IBM Europe: A Personal Retrospection, in /IEEE Annals of the History of Computing/, v.35, #4 (Oct-Dec, 2013), pp 18-30. Cortada, James W. 'Carrying a Bag': Memoirs of and IBM Salesman, 1974-1981, in /IEEE Annals of the History of Computing/, v35, #4 (Oct-Dec, 2013) , pp 32-47. -- 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
Managing the OMVS Root zFS FileSystem
We have 5 isolated systems running clones of our z/OS operating system. Our current zFS root file system has not been controlled and now we are now using a Serverpac to upgrade. I am planning to implement the maintenance procedure at the bottom of this message but first here are my questions: 1) How do you control your root file system so that it is not updated? 2) How do you clone your root file system? 3) Is it your understanding that /u and /usr/local are made available by IBM for our use? 4) Does anyone see improvements to my planned procedure that follows? With z/OS 1.13 we will name all USS file systems (including the root zFS ie. SYS1.OMVS.ROOT) that migrate with system maintenance to have a HLQ of SYS1 and that nothing other than what is shipped by IBM is located in the root zFS. Exception! To make this less impacting, we will add mount points already created to the root system each upgrade but future mount points will be added to the /u or /usr/local directories. We will have a two volume SYSRES (one containing PDSs the other containing USS files). The implementation process will be to IPL from SMPR13 and SMPF13, Make sure all is working well, Copy SMPR13 and SMPF13 over the production system res volumes, re-catalog the SYS1 zFS datasets, and IPL. To support not having anything in the root, all future non-IBM mount points will be in the /u or /usr/local directories will be pointing to the SYS.U.zFS and SYS.local.zFS respectively. We will also explore making the root system read only on all systems other than the Tech LPAR (for system maintenance). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing the OMVS Root zFS FileSystem
See below -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Donald Likens Sent: Friday, November 22, 2013 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Managing the OMVS Root zFS FileSystem We have 5 isolated systems running clones of our z/OS operating system. Our current zFS root file system has not been controlled and now we are now using a Serverpac to upgrade. I am planning to implement the maintenance procedure at the bottom of this message but first here are my questions: 1) How do you control your root file system so that it is not updated? always mount it read only 2) How do you clone your root file system? using DFDSS at the filesystem level. Even on TECH, the root filesystem is mounted read only. You should have a SMPE only base environment that never gets IPL'd that you apply your maintenance to. Then clone everything to your sandbox for testing. Too easy for unintended changes to get made to a root filesystem. When doing maintenance, the maintenance root is mounted at /Service for the duration of the apply process, then unmounted when finished. 3) Is it your understanding that /u and /usr/local are made available by IBM for our use? possibly, but use those as a mountpoint only, for your own local filesystem. 4) Does anyone see improvements to my planned procedure that follows? Keep track of your root filesystem modifications, and treat them as a usermod so that it is a repeatable process with future z/OS upgrades. consider making all your filesystems ZFS (if not already) as that is the future, HFS is functionally stabilized. With z/OS 1.13 we will name all USS file systems (including the root zFS ie. SYS1.OMVS.ROOT) that migrate with system maintenance to have a HLQ of SYS1 and that nothing other than what is shipped by IBM is located in the root zFS. Exception! To make this less impacting, we will add mount points already created to the root system each upgrade but future mount points will be added to the /u or /usr/local directories. We will have a two volume SYSRES (one containing PDSs the other containing USS files). The implementation process will be to IPL from SMPR13 and SMPF13, Make sure all is working well, Copy SMPR13 and SMPF13 over the production system res volumes, re-catalog the SYS1 zFS datasets, and IPL. To support not having anything in the root, all future non-IBM mount points will be in the /u or /usr/local directories will be pointing to the SYS.U.zFS and SYS.local.zFS respectively. We will also explore making the root system read only on all systems other than the Tech LPAR (for system maintenance). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others.
http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=5255174 Date: Fri, 22 Nov 2013 12:26:51 -0500 From: peter.far...@broadridge.com Subject: Re: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others. To: IBM-MAIN@LISTSERV.UA.EDU The latest volume does not yet appear to be available electronically on the IEEE sites - latest available seems to be volume 35 #3. Do you have a link to #4? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Boyes Sent: Friday, November 22, 2013 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others. Given the recent discussion on early Fortran implementations and other historical stuff on IBMVM, you folks may want to hunt down the current issue of the IEEE Annals of the History of Computing (volume 35, #4). This issue contains a really good article on industry approaches in the early days of the commercial computing industry, but also contains two other articles worth reading: one on the early development of compilers and programming languages at IBM Europe location (discussing a lot of the origins of structured languages like PL/1 and PL/M, and the origins of the various Fortran and COBOL compilers), and second, a close look at the training and engagement model for sales people used by IBM up until very recently. The articles are not freely downloadable, but they're worth the effort to obtain. The second article would be good required reading for the current IBM management team. It has a lot to say about what IBM used to be, and what might yet save them from themselves. Article references: Endres, Albert. Early Language and Compiler Developments at IBM Europe: A Personal Retrospection, in /IEEE Annals of the History of Computing/, v.35, #4 (Oct-Dec, 2013), pp 18-30. Cortada, James W. 'Carrying a Bag': Memoirs of and IBM Salesman, 1974-1981, in /IEEE Annals of the History of Computing/, v35, #4 (Oct-Dec, 2013) , pp 32-47. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting a VSAM data set's system timestamp
Robin - What checksum are you using that is too CPU intensive? Have you considered http://en.wikipedia.org/wiki/MurmurHash ? It is about 4 to 8 times as fast as most hash schemes because (1) it is of non-cryptographic quality and (2) it operates on entire words at once, rather than bytes. You can do an implementation that operates on z architecture doublewords, making it very fast indeed. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
Bill [Godfrey], Thank you. Alan Starr's explication is persuasive. It has the right sort of murky period flavor: a length value in doublewords kept in a byte! 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: Getting a VSAM data set's system timestamp
There are tools to do this. Data Propagator and STRIVA come to mind. Overhead is pretty steep. In a message dated 11/22/13 08:32:31 Central Standard Time, abend...@gmail.com writes: However I imagine it would be a bit of a hard sell to the customers. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing the OMVS Root zFS FileSystem
On Fri, 22 Nov 2013 12:13:34 -0600, Donald Likens dlik...@infosecinc.com wrote: We have 5 isolated systems running clones of our z/OS operating system. Our current zFS root file system has not been controlled and now we are now using a Serverpac to upgrade. I am planning to implement the maintenance procedure at the bottom of this message but first here are my questions: 1) How do you control your root file system so that it is not updated? Read only. Even if you use a shared file system configuration. 2) How do you clone your root file system? Either DFDSS or FDRCOPY from the version that is mounted at a service mount point where maintenance is applied. (no different than SYS1.LINKLIB or any other sysres DSN). If you use FDR, be aware that you should add a step in your copy process to quiesce the zFS files prior to copy. 3) Is it your understanding that /u and /usr/local are made available by IBM for our use? Yes, but since /usr/local is in the read only root (as distributed by IBM), I have a symlink to /etc/local. Glad IBM fixed that issue for CRON (and MAIL+UUCP) in z/OS 1.13 by having the distributed z/OS root use symlinks to /var. One less step to do for each OS upgrade. (but I still have to do it for /usr/local) 4) Does anyone see improvements to my planned procedure that follows? I'll let others comment. There is more than one way to do this. I've used an A/B on smaller systems years ago when DASD was really hard to come by. In recent years, I never IPL from the SMP/E set of data sets. I clone, then IPL for testing. You can see some sample cloning jobs on my web site. With z/OS 1.13 we will name all USS file systems (including the root zFS ie. SYS1.OMVS.ROOT) that migrate with system maintenance to have a HLQ of SYS1 and that nothing other than what is shipped by IBM is located in the root zFS. Exception! To make this less impacting, we will add mount points already created to the root system each upgrade but future mount points will be added to the /u or /usr/local directories. We will have a two volume SYSRES (one containing PDSs the other containing USS files). The implementation process will be to IPL from SMPR13 and SMPF13, Make sure all is working well, Copy SMPR13 and SMPF13 over the production system res volumes, re-catalog the SYS1 zFS datasets, and IPL. To support not having anything in the root, all future non-IBM mount points will be in the /u or /usr/local directories will be pointing to the SYS.U.zFS and SYS.local.zFS respectively. We will also explore making the root system read only on all systems other than the Tech LPAR (for system maintenance). The z/OS Planning for Installation manual has information about data set placement and Appendix D specifically talks about making a copy of your system (cloning), so you may want to review that. BTW, I also have some info on this on my web site for creating / sharing a read only root. It is not the same steps for a sysplex shared file system config (where the root should also be read only) but is still basically valid for systems that don't use sysplex sharing of z/OS unix file systems.Now that zFS can be indirectly cataloged, I guess it is more relevant again. When I wrote that doc there was no such thing as zFS. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others.
Thanks for the link. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Harry Wahl Sent: Friday, November 22, 2013 2:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others. http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=5255174 Date: Fri, 22 Nov 2013 12:26:51 -0500 From: peter.far...@broadridge.com Subject: Re: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others. To: IBM-MAIN@LISTSERV.UA.EDU The latest volume does not yet appear to be available electronically on the IEEE sites - latest available seems to be volume 35 #3. Do you have a link to #4? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Boyes Sent: Friday, November 22, 2013 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT: Computer Industry Strategies: IEEE Annals of the History of Computing articles on IBM and others. Given the recent discussion on early Fortran implementations and other historical stuff on IBMVM, you folks may want to hunt down the current issue of the IEEE Annals of the History of Computing (volume 35, #4). This issue contains a really good article on industry approaches in the early days of the commercial computing industry, but also contains two other articles worth reading: one on the early development of compilers and programming languages at IBM Europe location (discussing a lot of the origins of structured languages like PL/1 and PL/M, and the origins of the various Fortran and COBOL compilers), and second, a close look at the training and engagement model for sales people used by IBM up until very recently. The articles are not freely downloadable, but they're worth the effort to obtain. The second article would be good required reading for the current IBM management team. It has a lot to say about what IBM used to be, and what might yet save them from themselves. Article references: Endres, Albert. Early Language and Compiler Developments at IBM Europe: A Personal Retrospection, in /IEEE Annals of the History of Computing/, v.35, #4 (Oct-Dec, 2013), pp 18-30. Cortada, James W. 'Carrying a Bag': Memoirs of and IBM Salesman, 1974-1981, in /IEEE Annals of the History of Computing/, v35, #4 (Oct-Dec, 2013) , pp 32-47. -- 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
Fwd: Bloomberg: Druckenmiller Shorting IBM in Bet Cloud Computing to Win
He's also betting against Warren Buffet, of course... and against IBM technology providing cloud computing. From Bloomberg, Nov 22, 2013, 16:18:03 Stan Druckenmiller, who has one of the best track records in the hedge-fund industry over the past three decades, said he’s betting against the shares of International Business Machines Corp. (IBM) http://www.bloomberg.com/quote/IBM:US because the company’s business will be replaced by technology such as cloud computing. To read the entire article, go to http://bloom.bg/18WNvXQ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
How about not until IBM tells you to? As in you must accept before apply this PTF? On Fri, Nov 22, 2013 at 8:40 AM, Staller, Allan allan.stal...@kbmg.com wrote: IMO, the short answer is just before the next APPLY. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID dynamic Activation error
Hello Roger,
The output are as :
COMMAND INPUT === /DS P,3000 SCROLL ===
CSR
RESPONSE=DEV1
IEE459I 19.13.40 DEVSERV PATHS 065
UNIT DTYPE M CNT VOLSER CHPID=PATH STATUS
RTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC CYL CU-TYPE
03000,33903 ,O,000,LX3000,A0=+ A1=+ A2=+ A3=+ A4= A5=- A6=- A7=-
2107 3000 Y YY. YY. N SIMPLEX 00 00 1113 2107
SYMBOL DEFINITIONS
O = ONLINE + = PATH AVAILABLE
- = LOGICALLY OFF, PHYSICALLY OFF = PHYSICALLY UNAVAILABLE
COMMAND INPUT === /DS QD,3000SCROLL
=== CSR
RESPONSE=DEV1
IEE459I 19.15.03 DEVSERV QDASD 067
UNIT VOLSER SCUTYPE DEVTYPE CYL SSID SCU-SERIAL DEV-SERIAL EFC
03000 LX3000 2107951 2107900 1113 3000 0175-WW631 0175-WW631 *OK
1 DEVICE(S) MET THE SELECTION CRITERIA
0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING
On Fri, Nov 22, 2013 at 10:51 PM, Roger Steyn roger.st...@yahoo.com wrote:
Hello Jake ,
This actually means The system could not add the specified path to a
path group.
Is the cable connected properly ? That's the first thing to be checked .
Also look at logrec data Sounds to me like a no resources condition
over the control unit . Try these commands
a) DS P,
b) DS QD,
Thank you ,
Steyn !
On Thursday, November 21, 2013 5:32 PM, Lizette Koehler
stars...@mindspring.com wrote:
I would start by doing an internet search on your messages IOS444I. There
should be some helpful hints out there.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jake anderson
Sent: Thursday, November 21, 2013 1:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CHPID dynamic Activation error
Hello Group,
For our New storage Box,While dynamically adding new CHPID to existing
control
UNIT, I tried displaying new CHIPD but its only show that path are
online
not
operational. I have referred the below link but I am not able to get any
Clue.
http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IEA2M9C1/SPTM013022
D M=CHP(E2)
IEE174I 23.18.04 DISPLAY M 250
CHPID E2: TYPE=1A, DESC=FICON POINT TO POINT, ONLINE DEVICE
STATUS FOR CHANNEL PATH E2
0 1 2 3 4 5 6 7 8 9 A B C D E F
300 * * * * * * * * * * * * * * * *
301 * * * * * * * * * * * * * * * *
302 * * * * * * * * * * * * * * * *
303 * * * * * * * * * * * * * * * *
304 * * * * * * * * * * * * * * * *
305 * * * * * * * * * * * * * * * *
306 * * * * * * * * * * * * * * * *
307 * * * * * * * * * * * * * * * *
308 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL
309 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL 30A AL AL AL AL AL AL
AL AL AL AL AL AL AL AL AL AL
IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F38,E2)
IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3E,E2)
IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3F,E2)
Could someone please shed light on the above. Any suggestions or
directions are
much appreciated.
Jake
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
