Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
The total value (market capitalization) of Yahoo has steadily declined over the past several years. Maybe they could try something different, like protecting their users' mailboxes and address books (while they deliver ads to them). Yahoo's fundamental business problem is that they've been losing eyeballs and, thus, all important advertising revenue to other companies, particularly to Google. That's been reflected in their loss of e-mail users, too. If users can't trust Yahoo to keep their private information private -- and they can't if they use Yahoo Mail's Web UI -- then users will continue leaving Yahoo. Fixing that security problem isn't going to solve all of Yahoo's business problems. But it's a prerequisite. Some things you've just got to do simply to keep the lights on, and that's one of them. My views are my own, of course. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Problem Going to VSAM from IAM
Hello, we have a job that was previously using Innovation's IAM file access method. The file is over 6 million records. The job runs twice yearly and usually takes an hour or less to complete. The product was removed to save on SW costs, and the file was converted to VSAM. The programmer did not make any other changes, and the job now takes over 10 hours to complete. I know the IAM product is supposed to improve performance, but can't imagine it making the difference between 1 and 14 hours run time. I'm suspecting there may have been some JCL changes to blksize, buffers, and things like that required, but the programmer is unaware of any of those changes he should have made. The job is only reading the file. Does anybody have any ideas on where to start looking for other changes that should have been made after converting from IAM to VSAM? The programmer is reviewing his source code. Our performance support has not suggested anything. Innovation claims %50-%80 reduction in processing time, so maybe it is just a matter of IAM vs VSAM.(?) Here are the JCL and VSAM definitions: //MISC DD DSN=ASLP00.FT.MISC,DISP=SHR, // AMP='BUFSP=409600,BUFND=181,BUFNI=9' Cluster:'ASLP00.FT.MISC'+ multi-volume Data: 'ASLP00.FT.MISC.DATA' Data Volume: PEST06 + Index: 'ASLP00.FT.MISC.INDEX' Index Volume: PEST06 + Data Component Information: Current Allocation Options: Device type: 3390Load option: SPEED Organization:KSDS EXT-ADDR Write check: NO KSDS key length: 27 Buffer space: 10752 KSDS key location: 1 Erase on delete: NO Average record size: 80 Imbedded index: NO Maximum record size: 4084 Replicated index: NO Allocated Space: UnitPrimary SecondaryReuse option: YES Data: CYLINDERS 20002000 Share option: 2-3 Index: CYLINDERS 300 30 Spanned records: NO Dataset Date Information:Key ranges present: NO CLUSTER - ASLP00.FT.MISC Storage: PESTBU Data: X4GB Management: MGTPSF Owner ID: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Current Allocations in Tracks:Current Utilization in Tracks: Allocated space: 24 Used data space:198827 (83 %) Allocated extents: 2 Used extents: 2 ( 100 %) Allocation type: UNIQUEPrime records: 6,770,095 KSDS Index Allocation in Tracks:Deleted records: 3134 Allocated space: 4500Inserted records: 8700 Number of records:14795Updated records: 706460 - - - - - - - - - - - Current Reorganization Information - - - - - - - - - - - Data - Control Area Information: Control Interval Information: Physical record size: 4096 Size-data:4096 Index: 2560 Thanks, Larry Brown This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
In 886132E644ECAE808EED6EEFA317@graham, on 07/17/2012 at 11:15 AM, Graham Hobbs gho...@cdpwise.net said: When someone uses the underscores between some words .. what does that mean? Underscore. ITYM when somebody uses underscore *around* a word. In that case it means the same as underscoring the word, a form of emphasis. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
In ofae475794.d0761284-on48257a3e.001cb9f7-48257a3e.001fa...@us.ibm.com, on 07/17/2012 at 01:45 PM, Timothy Sipples timothy.sipp...@us.ibm.com said: Most coffee shops, hotels, etc. still don't use encrypted wi-fi. Bletch! I'd better check what my local library uses, if anything. 3. The Internet is a public, untrusted network. Alas, it is a public, untrustworthy network that is nonetheless trusted by all too many. Such as Yahoo :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
In 9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com, on 07/18/2012 at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said: Uh, I don't think so. You're thinking CLIST not REXX. I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable, which in this case is PDQR.', which does not refer to either CLIST or REXX variables. Try adding the statement: PDQR=A To set the ISPF variable PDQR from REXX he needs to dreop the ampersand: PDQR=A You will see in the trace that PDQR was not substituted. In what trace? The REXX trace is not relevant to substitutions performed by ISPF. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
On Thu, 19 Jul 2012 10:19:28 +0100, Rupert Reynolds wrote: There is no need to send edit commands via ISPEXEC anyway:-) What was the rationale for making the initial host command environment when an edit macro is entered TSO rather than the obvious ISREDIT? Was it merely that the ISPF developers were not well versed in Rexx lore when Rexx burst upon the TSO/E v.2 (whatever) scene? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Shmuel ! A previous reply also suggested SCAN OFF. I tried it, just tried it again, and it makes no difference. Please look at the example I sent before and try it yourself. From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/19/2012 05:26 AM Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In ofc169f9df.8de870ec-on88257a3f.006f4f36-88257a3f.00705...@ea.epson.com, on 07/18/2012 at 01:26 PM, John Mattson john_matt...@ea.epson.com said: Thanks to all, I now have something that works, sort of, but there is really something wrong with ISPF here. Not from what you have written. Try what Tom suggested[1] and add SCAN OFF to your macro. [1] Don't bother with the SCAN ON unless you need it later in the macro. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT option NOBLKSET?
Dave, The application is CIMS. Are there any users of CIMS out there who could shed some light on why VLSHRT is required? Do you mean CIMS Mainframe, which IBM rebranded as TDSz Usage and Accounting Collector (UAC)? If so, you might contact me off-list for specific application questions. This particular SORT isn't one normally used in CIMS / UAC, perhaps this is a custom process or feed (like a TRANS record, though they're usually FB not VB)? Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Use a TOR connection. With that, you have a SSL/TLS encoded connection from your PC to a local TOR router. And it bounces around in the TOR network until it exits for a TOR end point to then go to the actual site you want. The site doesn't know where you came from initially because it only sees the TOR exit point's IP address. All packets are encrypted from your PC to the TOR exit point router. They may (http) then be in clear text or encrypted (https) during the last hop. Which will likely be closer to your destination and therefore harder to intercept than if it were clear text all the way. https://www.torproject.org/docs/tor-doc-windows.html.en -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, July 19, 2012 8:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek In OFAE475794.D0761284-ON48257A3E.001CB9F7-48257A3E.001FA9B9@us. ibm.com, on 07/17/2012 at 01:45 PM, Timothy Sipples timothy.sipp...@us.ibm.com said: Most coffee shops, hotels, etc. still don't use encrypted wi-fi. Bletch! I'd better check what my local library uses, if anything. 3. The Internet is a public, untrusted network. Alas, it is a public, untrustworthy network that is nonetheless trusted by all too many. Such as Yahoo :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Shmuel ! I sent my original source, and it was REXX. Having a few spare moments, I quickly converted the REXX to CLIST and all of the FIND's worked as a clist. Oddly, they work with or withOUT SCAN OFF. Whether the problem belongs to ISPF, REXX, or both is not my problem. These commands should work as a REXX. I'll let IBM sort it out. From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/19/2012 07:17 AM Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In 9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com, on 07/18/2012 at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said: Uh, I don't think so. You're thinking CLIST not REXX. I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable, which in this case is PDQR.', which does not refer to either CLIST or REXX variables. Try adding the statement: PDQR=A To set the ISPF variable PDQR from REXX he needs to dreop the ampersand: PDQR=A You will see in the trace that PDQR was not substituted. In what trace? The REXX trace is not relevant to substitutions performed by ISPF. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
That's strange, they work fine as Rexx for me:
JCL: Note line 4
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
//* TEST LINE TO BE X ALL'ED AND NOT FOUND IN FIND ALLS
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Macro Source: Note the double ampersands as documented in the ISPF Edit
and Edit Macros manual.
/* REXX */
ISREDIT MACRO (MEM) NOPROCESS
trace i
CONTROL ERRORS RETURN
ISREDIT X ALL
ISREDIT SCAN OFF
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
Trace:
4 *-* CONTROL ERRORS RETURN
L CONTROL ERRORS RETURN
IKJ56500I COMMAND CONTROL NOT FOUND
+++ RC(-3) +++
5 *-* ISREDIT X ALL
L ISREDIT X ALL
6 *-* ISREDIT SCAN OFF
L ISREDIT SCAN OFF
7 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
8 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
9 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
10 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
11 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
12 *-* ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
L ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
13 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
14 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
JCL member now shows:
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
- - - - - - - - - - - - - - - - - - - 1 Line(s) not
Displayed
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: John Mattson john_matt...@ea.epson.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 10:49
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Shmuel ! I sent my original source, and it was REXX. Having a few spare
moments, I quickly converted the REXX to CLIST and all of the FIND's
worked as a clist. Oddly, they work with or withOUT SCAN OFF. Whether
the problem belongs to ISPF, REXX, or both is not my problem. These
commands should work as a REXX. I'll let IBM sort it out.
From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 07:17 AM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
In
9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com,
on 07/18/2012
at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said:
Uh, I don't think so.
You're thinking CLIST not REXX.
I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT
evaluates/substitutes any ISPF variable, which in this case is
PDQR.', which does not refer to either CLIST or REXX variables.
Try adding the statement: PDQR=A
To set the ISPF variable PDQR from REXX he needs to dreop the
ampersand:
PDQR=A
You will see in the trace that PDQR was not substituted.
In what trace? The REXX trace is not relevant to substitutions
performed by ISPF.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BDAM READ with BLKREF of X'0'
Thomas David Rivers wrote: I'm debugging a program (no source), and trying to figure out what BDAM does when the READ macro is invoked without a BLKREF relative-block-address specified. This is an RBA-type BDAM, and I'm seeing a READ where the BLKREF in the DECB is simply X'0'. Binyamin Dissen asked: What is the second parameter of the read? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com The parms passed to the READ SVC (addressed by R1) are 0X'' 4X'0048' 6X'' (zero length, use the blksize from the DCB?) 8X'BFF8' (address of the DCB) 12 X'00016000' (AREA ADDRESS) 16 X'' (IOB ADDRESS) 20 X'' (KEY ADDRESS) 24 X'c40c' (BLKREF ADDRESS) It seems I had mis-counted, and its the KEY ADDRESS that is X'0' - not the BLKREF ADDRESS (which is actually not X'0') (I'm laying out my error for the proper group humiliation :-) :-) :-) ) But, since I don't seem to be able to count... is that the proper layout of the parms to the READ SVC? And - back to the original question, is there _ever_ a situation in a BDAM READ where the BLKREF address _could_ be X'0'? (Today, I'm guessing not...) - Thanks! - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem Going to VSAM from IAM
Hi, Like others have suggested BLSR or SMB ACCBIAS=DO is the way to go if the VSAM is accessed in a non-sequential manner (which seems to be the case, giving the IAM vs. VSAM performance difference you've encountered). Also, from the LISTCAT, if I read it correctly, many records seem to be updated so a DEFER WRITE (DFR) should be considered (and may or may not be enabled by default). Take a look at http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ib m.zos.r12.idad400%2Fsmbt.htm. Best Regards, Yifat -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brown, Larry - RD, St. Louis, MO Sent: Thursday, July 19, 2012 3:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Problem Going to VSAM from IAM Hello, we have a job that was previously using Innovation's IAM file access method. The file is over 6 million records. The job runs twice yearly and usually takes an hour or less to complete. The product was removed to save on SW costs, and the file was converted to VSAM. The programmer did not make any other changes, and the job now takes over 10 hours to complete. I know the IAM product is supposed to improve performance, but can't imagine it making the difference between 1 and 14 hours run time. I'm suspecting there may have been some JCL changes to blksize, buffers, and things like that required, but the programmer is unaware of any of those changes he should have made. The job is only reading the file. Does anybody have any ideas on where to start looking for other changes that should have been made after converting from IAM to VSAM? The programmer is reviewing his source code. Our performance support has not suggested anything. Innovation claims %50-%80 reduction in processing time, so maybe it is just a matter of IAM vs VSAM.(?) Here are the JCL and VSAM definitions: //MISC DD DSN=ASLP00.FT.MISC,DISP=SHR, // AMP='BUFSP=409600,BUFND=181,BUFNI=9' Cluster:'ASLP00.FT.MISC'+ multi-volume Data: 'ASLP00.FT.MISC.DATA' Data Volume: PEST06 + Index: 'ASLP00.FT.MISC.INDEX' Index Volume: PEST06 + Data Component Information: Current Allocation Options: Device type: 3390Load option: SPEED Organization:KSDS EXT-ADDR Write check: NO KSDS key length: 27 Buffer space: 10752 KSDS key location: 1 Erase on delete: NO Average record size: 80 Imbedded index: NO Maximum record size: 4084 Replicated index: NO Allocated Space: UnitPrimary SecondaryReuse option: YES Data: CYLINDERS 20002000 Share option: 2-3 Index: CYLINDERS 300 30 Spanned records: NO Dataset Date Information:Key ranges present: NO CLUSTER - ASLP00.FT.MISC Storage: PESTBU Data: X4GB Management: MGTPSF Owner ID: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Current Allocations in Tracks:Current Utilization in Tracks: Allocated space: 24 Used data space: 198827 (83 %) Allocated extents: 2 Used extents: 2 ( 100 %) Allocation type: UNIQUEPrime records: 6,770,095 KSDS Index Allocation in Tracks:Deleted records: 3134 Allocated space: 4500Inserted records: 8700 Number of records:14795Updated records: 706460 - - - - - - - - - - - Current Reorganization Information - - - - - - - - - - - Data - Control Area Information: Control Interval Information: Physical record size: 4096 Size-data: 4096 Index: 2560 Thanks, Larry Brown This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the
Re: Problem Going to VSAM from IAM
From original post, the job in question is only reading the file. Any updates are done elsewhere, which at this point haven't yet been described as a performance issue. BLSR Deferred writes could be useful in other cases (not here) when a large number of updates are being done in a batch job, but also generally requires knowledge that others don't need access to the file during this process. Joel C. Ewing On 07/19/2012 10:45 AM, Yifat Oren wrote: Hi, Like others have suggested BLSR or SMB ACCBIAS=DO is the way to go if the VSAM is accessed in a non-sequential manner (which seems to be the case, giving the IAM vs. VSAM performance difference you've encountered). Also, from the LISTCAT, if I read it correctly, many records seem to be updated so a DEFER WRITE (DFR) should be considered (and may or may not be enabled by default). Take a look at http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ib m.zos.r12.idad400%2Fsmbt.htm. Best Regards, Yifat -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brown, Larry - RD, St. Louis, MO Sent: Thursday, July 19, 2012 3:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Problem Going to VSAM from IAM Hello, we have a job that was previously using Innovation's IAM file access method. The file is over 6 million records. The job runs twice yearly and usually takes an hour or less to complete. The product was removed to save on SW costs, and the file was converted to VSAM. The programmer did not make any other changes, and the job now takes over 10 hours to complete. I know the IAM product is supposed to improve performance, but can't imagine it making the difference between 1 and 14 hours run time. I'm suspecting there may have been some JCL changes to blksize, buffers, and things like that required, but the programmer is unaware of any of those changes he should have made. The job is only reading the file. Does anybody have any ideas on where to start looking for other changes that should have been made after converting from IAM to VSAM? The programmer is reviewing his source code. Our performance support has not suggested anything. Innovation claims %50-%80 reduction in processing time, so maybe it is just a matter of IAM vs VSAM.(?) Here are the JCL and VSAM definitions: //MISC DD DSN=ASLP00.FT.MISC,DISP=SHR, // AMP='BUFSP=409600,BUFND=181,BUFNI=9' Cluster:'ASLP00.FT.MISC'+ multi-volume Data: 'ASLP00.FT.MISC.DATA' Data Volume: PEST06 + Index: 'ASLP00.FT.MISC.INDEX' Index Volume: PEST06 + Data Component Information: Current Allocation Options: Device type: 3390Load option: SPEED Organization:KSDS EXT-ADDR Write check: NO KSDS key length: 27 Buffer space: 10752 KSDS key location: 1 Erase on delete: NO Average record size: 80 Imbedded index: NO Maximum record size: 4084 Replicated index: NO Allocated Space: UnitPrimary SecondaryReuse option: YES Data: CYLINDERS 20002000 Share option: 2-3 Index: CYLINDERS 300 30 Spanned records: NO Dataset Date Information:Key ranges present: NO CLUSTER - ASLP00.FT.MISC Storage: PESTBU Data: X4GB Management: MGTPSF Owner ID: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Current Allocations in Tracks:Current Utilization in Tracks: Allocated space: 24 Used data space: 198827 (83 %) Allocated extents: 2 Used extents: 2 ( 100 %) Allocation type: UNIQUEPrime records: 6,770,095 KSDS Index Allocation in Tracks:Deleted records: 3134 Allocated space: 4500Inserted records: 8700 Number of records:14795Updated records: 706460 - - - - - - - - - - - Current Reorganization Information - - - - - - - - - - - Data - Control Area Information: Control Interval Information: Physical record size: 4096 Size-data: 4096 Index: 2560 Thanks, Larry Brown ... -- Joel C. Ewing,Bentonville, AR jcew...@acm.org
Re: Problem Going to VSAM from IAM
Yes, the updates are done outside this job. I've received a lot of good tips from the list. Thank you very much everyone. Apparently, BLSR is not activated, we get subsys not found message when we try that. I've asked our systems folks to verify that and why not if that is the case. But, we have several other suggestions to try from here as well. Thanks again all! Larry Brown -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Thursday, July 19, 2012 10:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problem Going to VSAM from IAM From original post, the job in question is only reading the file. Any updates are done elsewhere, which at this point haven't yet been described as a performance issue. BLSR Deferred writes could be useful in other cases (not here) when a large number of updates are being done in a batch job, but also generally requires knowledge that others don't need access to the file during this process. Joel C. Ewing This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
And the grand prize goes to Tom Ambros
Yes, use DOUBLE AMPERSANDS in REXX and the FINDs work properly.
So simple when we finally see it. Many thanks to everyone.
From: Tom Ambros thomas_amb...@keybank.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 07:58 AM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
That's strange, they work fine as Rexx for me:
JCL: Note line 4
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
//* TEST LINE TO BE X ALL'ED AND NOT FOUND IN FIND ALLS
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Macro Source: Note the double ampersands as documented in the ISPF Edit
and Edit Macros manual.
/* REXX */
ISREDIT MACRO (MEM) NOPROCESS
trace i
CONTROL ERRORS RETURN
ISREDIT X ALL
ISREDIT SCAN OFF
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
Trace:
4 *-* CONTROL ERRORS RETURN
L CONTROL ERRORS RETURN
IKJ56500I COMMAND CONTROL NOT FOUND
+++ RC(-3) +++
5 *-* ISREDIT X ALL
L ISREDIT X ALL
6 *-* ISREDIT SCAN OFF
L ISREDIT SCAN OFF
7 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
8 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
9 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
10 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
11 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
12 *-* ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
L ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
13 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
14 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
JCL member now shows:
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
- - - - - - - - - - - - - - - - - - - 1 Line(s) not
Displayed
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: John Mattson john_matt...@ea.epson.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 10:49
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Shmuel ! I sent my original source, and it was REXX. Having a few spare
moments, I quickly converted the REXX to CLIST and all of the FIND's
worked as a clist. Oddly, they work with or withOUT SCAN OFF. Whether
the problem belongs to ISPF, REXX, or both is not my problem. These
commands should work as a REXX. I'll let IBM sort it out.
From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 07:17 AM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
In
9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com,
on 07/18/2012
at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said:
Uh, I don't think so.
You're thinking CLIST not REXX.
I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT
evaluates/substitutes any ISPF variable, which in this case is
PDQR.', which does not refer to either CLIST or REXX variables.
Try adding the statement: PDQR=A
To set the ISPF variable PDQR from REXX he needs to dreop the
ampersand:
PDQR=A
You will see in the trace that PDQR was not substituted.
In what trace? The REXX trace is not relevant to substitutions
performed by ISPF.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
Re: REXX ISPF edit FIND failing
On Thu, 19 Jul 2012 09:12:54 -0700, John Mattson wrote: And the grand prize goes to Tom Ambros Yes, use DOUBLE AMPERSANDS in REXX and the FINDs work properly. So simple when we finally see it. Many thanks to everyone. So is the behavior of EDIT different when identical command strings are issued from Rexx vs. CLIST? Ugh! But might this be because the ISPF developers recognized that '' symbolics would be elaborated by CLIST but not by Rexx and made a misguided attempt to make the Rexx behavior superficially more CLIST-like by processing Rexx command strings in a front-end? Did they break an API to offset their misunderstanding of Rexx? What's the behavior when the macro is written in Assembler/ PL/I/C using the CALL interface? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Different in CLIST or Rexx? Not according to the documentation. From the Edit and Edit Macros doc: Section 3.3.80 SCAN--Set Command Scan Mode Examples To set a line whose number is in variable LNUM to: SYSDATE is a CLIST built-in function set scan mode off and issue the LINE command with SYSDATE as the CLIST function name. The CLIST processor strips off the first , but, because scan mode is off, the editor does not remove the second :; ISREDIT SCAN OFF ISREDIT LINE LNUM = SYSDATE is a CLIST built-in function ISREDIT SCAN ON Because the ISPEXEC call interface for REXX EXECs allows you to specify parameters as symbolic variables, a single scan always takes place before the syntax check of a statement. Therefore, the rule of using two ampersands () before variable names to avoid substitution of variable names also applies to REXX EXECs. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/19/2012 12:35 Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Thu, 19 Jul 2012 09:12:54 -0700, John Mattson wrote: And the grand prize goes to Tom Ambros Yes, use DOUBLE AMPERSANDS in REXX and the FINDs work properly. So simple when we finally see it. Many thanks to everyone. So is the behavior of EDIT different when identical command strings are issued from Rexx vs. CLIST? Ugh! But might this be because the ISPF developers recognized that '' symbolics would be elaborated by CLIST but not by Rexx and made a misguided attempt to make the Rexx behavior superficially more CLIST-like by processing Rexx command strings in a front-end? Did they break an API to offset their misunderstanding of Rexx? What's the behavior when the macro is written in Assembler/ PL/I/C using the CALL interface? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem Going to VSAM from IAM
If the record count given is accurate (6.7M) and if the average record length given (80) is realistic, then on the average a full data CI should be able to hold around 51 records, a 3390 track around 612 records, and the full data portion fit in as few as 11,062 tracks, which is 5.6% of the current file size. That means if the file is relatively stable and will not immediately be hit by another massive set of updates, reorganizing it might reduce the size, number of data CIs, number of CAs (and hence number of index CIs) by almost a factor of 20. This certainly could potentially improve things by reducing the total number of CIs that might have to be read to get the same number of data records (only true if there is good locality of reference and sufficient buffers with random reads), but since IAM had to deal with update activity as well I suspect this would not explain the large difference in performance from IAM to VSAM so much as perhaps the default buffering techniques used by IAM. Now if IAM does some kind of default reorganization under the covers periodically, or if it uses a totally different data structure and update strategy that somehow eliminates partially used physical blocks without formal reorganization, that could be another matter. If this file was converted to VSAM some time ago and is never reorganized and somehow the equivalent reorganization was done under the covers by IAM, that could cause efficiency of the VSAM replacement compared to IAM to degrade over time. Another thing that could affect my estimates would be if the 4096 Index CI size was manually forced rather than allowing VSAM to choose the Index CI size based on Data CI and key length. If that were the case, the Index CI could be too small, potentially making a significant portion of each CA unusable for data; and that rather than just Data CI fragmentation may be contributing to the excessive size of the file based on number of records. Another possibility of course is that the average record length (which is definer-specified and not verified or calculated by VSAM) may be grossly inaccurate, making my estimates of average records per CI equally inaccurate. Joel C. Ewing On 07/19/2012 10:53 AM, Sambataro, Anthony (NIH/NBS) [E] wrote: In addition to more buffers, would a re-org help? Any CI/CA splits? -Original Message- From: Brown, Larry - RD, St. Louis, MO [mailto:larry.bro...@stl.usda.gov] Sent: Thursday, July 19, 2012 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Problem Going to VSAM from IAM Hello, we have a job that was previously using Innovation's IAM file access method. The file is over 6 million records. The job runs twice yearly and usually takes an hour or less to complete. The product was removed to save on SW costs, and the file was converted to VSAM. The programmer did not make any other changes, and the job now takes over 10 hours to complete. I know the IAM product is supposed to improve performance, but can't imagine it making the difference between 1 and 14 hours run time. I'm suspecting there may have been some JCL changes to blksize, buffers, and things like that required, but the programmer is unaware of any of those changes he should have made. The job is only reading the file. Does anybody have any ideas on where to start looking for other changes that should have been made after converting from IAM to VSAM? The programmer is reviewing his source code. Our performance support has not suggested anything. Innovation claims %50-%80 re duction i n processing time, so maybe it is just a matter of IAM vs VSAM.(?) Here are the JCL and VSAM definitions: //MISC DD DSN=ASLP00.FT.MISC,DISP=SHR, // AMP='BUFSP=409600,BUFND=181,BUFNI=9' Cluster:'ASLP00.FT.MISC'+ multi-volume Data: 'ASLP00.FT.MISC.DATA' Data Volume: PEST06 + Index: 'ASLP00.FT.MISC.INDEX' Index Volume: PEST06 + Data Component Information: Current Allocation Options: Device type: 3390Load option: SPEED Organization:KSDS EXT-ADDR Write check: NO KSDS key length: 27 Buffer space: 10752 KSDS key location: 1 Erase on delete: NO Average record size: 80 Imbedded index: NO Maximum record size: 4084 Replicated index: NO Allocated Space: UnitPrimary SecondaryReuse option: YES Data: CYLINDERS 20002000 Share option: 2-3 Index: CYLINDERS 300 30 Spanned
Re: End of Support for Encryption Key Manager (EKM)
not sure if you had an updated response for this, though there is no EOS announcement IBM has a note regarding their strategic direction and recommending to not use EKM for new encryptions @ following URL EKM should no longer be downloaded for new tape encryption installations. http://www-01.ibm.com/support/docview.wss?uid=ssg1S4000504 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: End of Support for Encryption Key Manager (EKM)
AFAIK that's old news. We're still running EKM and haven't found a compelling reason to migrate to ISKLM. As long as Java SDK 6.0 is supported, and we don't get any new hardware that requires the priced product we're staying on EKM, Mark Jacobs On 07/19/12 14:08, Raja Mohan wrote: not sure if you had an updated response for this, though there is no EOS announcement IBM has a note regarding their strategic direction and recommending to not use EKM for new encryptions @ following URL EKM should no longer be downloaded for new tape encryption installations. http://www-01.ibm.com/support/docview.wss?uid=ssg1S4000504 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Tampa, FL The Doctor: You know when grown-ups tell you everything's going to be fine, and you think they're probably lying to make you feel better? Young Amy: Yes. The Doctor: Everything's going to be fine. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem Going to VSAM from IAM
Wow, the programmer dropped the bufsp parm, and his run time actually was better than before with IAM - under an hour. Again, many thanks to all who replied. If any of you are ever in St. Louis, let me know, and I'll buy you a cold adult beverage. Larry Brown Rural Development U.S. Department of Agriculture 4300 Goodfellow Blvd. St. Louis, MO 63120 Phone: 314.457.4939 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Thursday, July 19, 2012 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problem Going to VSAM from IAM Larry, Your dd statement specifies space for 100 data buffers (4096 x 100 =409600) but you then specify bufnd=181, which is one cyl for a 4096 CI size, plus Bufni=9. I would lose the bufsp parameter and let VSAM allocate buffers according to the Bufnd and Bufni parameters. You might also code Rmode31=buff to allocate the buffers above the line. You didn't mention whether you were paging during the job execution. Regards, Dave O'Brien -Original Message- From: Brown, Larry - RD, St. Louis, MO [mailto:larry.bro...@stl.usda.gov] Sent: Thursday, July 19, 2012 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Problem Going to VSAM from IAM Hello, we have a job that was previously using Innovation's IAM file access method. The file is over 6 million records. The job runs twice yearly and usually takes an hour or less to complete. The product was removed to save on SW costs, and the file was converted to VSAM. The programmer did not make any other changes, and the job now takes over 10 hours to complete. I know the IAM product is supposed to improve performance, but can't imagine it making the difference between 1 and 14 hours run time. I'm suspecting there may have been some JCL changes to blksize, buffers, and things like that required, but the programmer is unaware of any of those changes he should have made. The job is only reading the file. Does anybody have any ideas on where to start looking for other changes that should have been made after converting from IAM to VSAM? The programmer is reviewing his source code. Our performance support has not suggested anything. Innovation claims %50-%80 reduction in processing time, so maybe it is just a matter of IAM vs VSAM.(?) Here are the JCL and VSAM definitions: //MISC DD DSN=ASLP00.FT.MISC,DISP=SHR, // AMP='BUFSP=409600,BUFND=181,BUFNI=9' Cluster:'ASLP00.FT.MISC'+ multi-volume Data: 'ASLP00.FT.MISC.DATA' Data Volume: PEST06 + Index: 'ASLP00.FT.MISC.INDEX' Index Volume: PEST06 + Data Component Information: Current Allocation Options: Device type: 3390Load option: SPEED Organization:KSDS EXT-ADDR Write check: NO KSDS key length: 27 Buffer space: 10752 KSDS key location: 1 Erase on delete: NO Average record size: 80 Imbedded index: NO Maximum record size: 4084 Replicated index: NO Allocated Space: UnitPrimary SecondaryReuse option: YES Data: CYLINDERS 20002000 Share option: 2-3 Index: CYLINDERS 300 30 Spanned records: NO Dataset Date Information:Key ranges present: NO CLUSTER - ASLP00.FT.MISC Storage: PESTBU Data: X4GB Management: MGTPSF Owner ID: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Current Allocations in Tracks:Current Utilization in Tracks: Allocated space: 24 Used data space:198827 (83 %) Allocated extents: 2 Used extents: 2 ( 100 %) Allocation type: UNIQUEPrime records: 6,770,095 KSDS Index Allocation in Tracks:Deleted records: 3134 Allocated space: 4500Inserted records: 8700 Number of records:14795Updated records: 706460 - - - - - - - - - - - Current Reorganization Information - - - - - - - - - - - Data - Control Area Information:
Re: Problem Going to VSAM from IAM
cold adult beverage. Hum, 18 year old iced tea? Or perhaps you meant Macallan 18. Very generous of you: $139.99 for 750 ml at Amazon. Of course, 18 is in the U.S. More adult would be 21, but that's $235.99 for 750 ml. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brown, Larry - RD, St. Louis, MO Sent: Thursday, July 19, 2012 1:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problem Going to VSAM from IAM Wow, the programmer dropped the bufsp parm, and his run time actually was better than before with IAM - under an hour. Again, many thanks to all who replied. If any of you are ever in St. Louis, let me know, and I'll buy you a cold adult beverage. Larry Brown Rural Development U.S. Department of Agriculture 4300 Goodfellow Blvd. St. Louis, MO 63120 Phone: 314.457.4939 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Thursday, July 19, 2012 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problem Going to VSAM from IAM Larry, Your dd statement specifies space for 100 data buffers (4096 x 100 =409600) but you then specify bufnd=181, which is one cyl for a 4096 CI size, plus Bufni=9. I would lose the bufsp parameter and let VSAM allocate buffers according to the Bufnd and Bufni parameters. You might also code Rmode31=buff to allocate the buffers above the line. You didn't mention whether you were paging during the job execution. Regards, Dave O'Brien -Original Message- From: Brown, Larry - RD, St. Louis, MO [mailto:larry.bro...@stl.usda.gov] Sent: Thursday, July 19, 2012 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Problem Going to VSAM from IAM Hello, we have a job that was previously using Innovation's IAM file access method. The file is over 6 million records. The job runs twice yearly and usually takes an hour or less to complete. The product was removed to save on SW costs, and the file was converted to VSAM. The programmer did not make any other changes, and the job now takes over 10 hours to complete. I know the IAM product is supposed to improve performance, but can't imagine it making the difference between 1 and 14 hours run time. I'm suspecting there may have been some JCL changes to blksize, buffers, and things like that required, but the programmer is unaware of any of those changes he should have made. The job is only reading the file. Does anybody have any ideas on where to start looking for other changes that should have been made after converting from IAM to VSAM? The programmer is reviewing his source code. Our performance support has not suggested anything. Innovation claims %50-%80 reduction in processing time, so maybe it is just a matter of IAM vs VSAM.(?) Here are the JCL and VSAM definitions: //MISC DD DSN=ASLP00.FT.MISC,DISP=SHR, // AMP='BUFSP=409600,BUFND=181,BUFNI=9' Cluster:'ASLP00.FT.MISC' + multi-volume Data: 'ASLP00.FT.MISC.DATA' Data Volume:PEST06 + Index: 'ASLP00.FT.MISC.INDEX' Index Volume: PEST06 + Data Component Information: Current Allocation Options: Device type: 3390 Load option: SPEED Organization:KSDS EXT-ADDR Write check: NO KSDS key length: 27 Buffer space: 10752 KSDS key location: 1 Erase on delete:NO Average record size: 80 Imbedded index: NO Maximum record size: 4084 Replicated index: NO Allocated Space: UnitPrimary Secondary Reuse option: YES Data: CYLINDERS 20002000 Share option: 2-3 Index: CYLINDERS 300 30
Re: BDAM READ with BLKREF of X'0'
SImple READ DI - no key. I would think that you would have to give a starting block address for a direct read. But it has been many years since I wrote BDAM code. On Thu, 19 Jul 2012 11:00:08 -0400 Thomas David Rivers riv...@dignus.com wrote: :Thomas David Rivers wrote: : : I'm debugging a program (no source), and trying to : figure out what BDAM does when the READ macro : is invoked without a BLKREF relative-block-address : specified. : : This is an RBA-type BDAM, and I'm seeing a READ : where the BLKREF in the DECB is simply X'0'. : : :Binyamin Dissen asked: : : : : What is the second parameter of the read? : : -- : Binyamin Dissen bdis...@dissensoftware.com : http://www.dissensoftware.com : : :The parms passed to the READ SVC (addressed by R1) are : : 0X'' : 4X'0048' : 6X'' (zero length, use the blksize from the DCB?) : 8X'BFF8' (address of the DCB) : 12 X'00016000' (AREA ADDRESS) : 16 X'' (IOB ADDRESS) : 20 X'' (KEY ADDRESS) : 24 X'c40c' (BLKREF ADDRESS) : : :It seems I had mis-counted, and its the KEY ADDRESS that :is X'0' - not the BLKREF ADDRESS (which is actually not X'0') :(I'm laying out my error for the proper group humiliation :-) :-) :-) ) : :But, since I don't seem to be able to count... is that :the proper layout of the parms to the READ SVC? : :And - back to the original question, is there _ever_ a situation :in a BDAM READ where the BLKREF address _could_ be X'0'? :(Today, I'm guessing not...) : :- Thanks! - :- Dave Rivers - -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem Going to VSAM from IAM
Prompted a quick look in manual which reveals A valid BUFSP specification generally overrides any BUFND or BUFNI specification, and then of course the default rules for how buffers are apportioned to Index and Data from BUFSP space is rarely what you want, as VSAM may not have enough info at the time buffers are allocated to understand how the program will really be accessing the file. I knew there was a good reason I avoided BUFSP. Joel C. Ewing On 07/19/2012 01:49 PM, Brown, Larry - RD, St. Louis, MO wrote: Wow, the programmer dropped the bufsp parm, and his run time actually was better than before with IAM - under an hour. Again, many thanks to all who replied. If any of you are ever in St. Louis, let me know, and I'll buy you a cold adult beverage. Larry Brown Rural Development U.S. Department of Agriculture 4300 Goodfellow Blvd. St. Louis, MO 63120 Phone: 314.457.4939 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Thursday, July 19, 2012 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problem Going to VSAM from IAM Larry, Your dd statement specifies space for 100 data buffers (4096 x 100 =409600) but you then specify bufnd=181, which is one cyl for a 4096 CI size, plus Bufni=9. I would lose the bufsp parameter and let VSAM allocate buffers according to the Bufnd and Bufni parameters. You might also code Rmode31=buff to allocate the buffers above the line. You didn't mention whether you were paging during the job execution. Regards, Dave O'Brien -Original Message- From: Brown, Larry - RD, St. Louis, MO [mailto:larry.bro...@stl.usda.gov] Sent: Thursday, July 19, 2012 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Problem Going to VSAM from IAM Hello, we have a job that was previously using Innovation's IAM file access method. The file is over 6 million records. The job runs twice yearly and usually takes an hour or less to complete. The product was removed to save on SW costs, and the file was converted to VSAM. The programmer did not make any other changes, and the job now takes over 10 hours to complete. I know the IAM product is supposed to improve performance, but can't imagine it making the difference between 1 and 14 hours run time. I'm suspecting there may have been some JCL changes to blksize, buffers, and things like that required, but the programmer is unaware of any of those changes he should have made. The job is only reading the file. Does anybody have any ideas on where to start looking for other changes that should have been made after converting from IAM to VSAM? The programmer is reviewing his source code. Our performance support has not suggested anything. Innovation claims %50-%80 re duction i n processing time, so maybe it is just a matter of IAM vs VSAM.(?) Here are the JCL and VSAM definitions: //MISC DD DSN=ASLP00.FT.MISC,DISP=SHR, // AMP='BUFSP=409600,BUFND=181,BUFNI=9' Cluster:'ASLP00.FT.MISC'+ multi-volume Data: 'ASLP00.FT.MISC.DATA' Data Volume: PEST06 + Index: 'ASLP00.FT.MISC.INDEX' Index Volume: PEST06 + Data Component Information: Current Allocation Options: Device type: 3390Load option: SPEED Organization:KSDS EXT-ADDR Write check: NO KSDS key length: 27 Buffer space: 10752 KSDS key location: 1 Erase on delete: NO Average record size: 80 Imbedded index: NO Maximum record size: 4084 Replicated index: NO Allocated Space: UnitPrimary SecondaryReuse option: YES Data: CYLINDERS 20002000 Share option: 2-3 Index: CYLINDERS 300 30 Spanned records: NO Dataset Date Information:Key ranges present: NO CLUSTER - ASLP00.FT.MISC Storage: PESTBU Data: X4GB Management: MGTPSF Owner ID: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Current Allocations in Tracks:Current Utilization in Tracks: Allocated space: 24 Used data space:198827 (83 %) Allocated extents:
Re: Help with elementary CPU speed question
Tom, Thanks for catching my mistake. I read too quickly. Yes, the SRM constants aren't speed ratings at all. The part that is relevant is this: the ratio of MIPS per CP is the best way for Charles to estimate the CPU time of his job on the new processor. As another lister pointed out, batch jobs generally run on a single TCB, so they can only be served as fast as a single CP can deliver. I took the average MIPS/CP from one of Cheryl Watson's CPU charts just to give a simple example. The result should be close, although in practice I have always had to compare actual job CPU times and derive the local fudge factor as closely as possible through experimentation. db -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Wednesday, July 18, 2012 7:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Help with elementary CPU speed question On Wed, 18 Jul 2012 18:47:13 -0400, Dave Barry wrote: In theory, you divide the rated SU/second by the number of processors giving SUs/processor/second, adjusting for MP effect overhead. No, the SU/second is called the SRM constant and it is used to convert CPU time (in seconds) to service units. It is already adjusted for the MP effect. Mark gave a reference earlier that describes this. Here it is again: http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.erba900/erbzpm8020.htm http://tinyurl.com/ccsgeb4 273.8 (2064-2C3) divided by 426.1 (2094-722) equals 0.643. Where did you get those numbers? The SRM constant for a 2094-722 is 19,777.5031 SU/second The SRM constant for a 2064-2C3 is 13,377.9264 SU/second Here are a few others. It should be obvious that it does not make sense to divide by the number of processors: 2064-2C1 (1 CP) 14692.3783 2064-2C2 (2 CP) 13961.6056 2064-2C3 (3 CP) 13377.9264 2064-2C4 (4 CP) 13082.5838 -- Tom Marchant -- 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: REXX ISPF edit FIND failing
There is a subtle and dangerous difference with ISREDIT FIND / CHANGE in
REXX.
Say you have a simple change command and forget to use rather than
/* REXX */
TRACE I
ADDRESS ISPEXEC
ISREDIT MACRO (MEM) NOPROCESS
CONTROL ERRORS RETURN
ISREDIT SCAN OFF
ISREDIT C ALL 'DISP=SHR,DSN=AAA' '@#$'
EXIT
And THIS is the file you wish to use it on...
// DD DISP=SHR,DSN=AAA.XXX
// DD DISP=SHR,DSN=BBB.YYY
// DD DISP=SHR,DSN=CCC.ZZZ
IF you use rather than here s what you get
// DD @#$AAA.XXX
// DD @#$BBB.YYY
// DD @#$CCC.ZZZ
If you use you get
// DD @#$.XXX
// DD DISP=SHR,DSN=BBB.YYY
// DD DISP=SHR,DSN=CCC.ZZZ
The moral of all this is: Do not assume ISREDIT commands will work
the same in REXX as in clists, or ISPF. I find this very annoying, how
about your folks?
From: Skip Robinson jo.skip.robin...@sce.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 02:26 PM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
I have found that the ISPF development folks are pretty responsive. This
problem is certainly worth an SR.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: John Mattson john_matt...@ea.epson.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:34 PM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
While I am at it...
WHY the Ampersand SYSTEM WORKS in the find,
but if you use PDQR rather than $PDQR it fails is just madness.
7 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
8 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
+++ RC(4) +++
From: John Mattson/Epson
To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:26 PM
Subject:Re: REXX ISPF edit FIND failing
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
--
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-entrant modules and the binder
I am making changes to make re-entrant our assembler routines that are called by COBOL programs. I'm trying to decide what are the best default options for the program binder. It appears that if the option REUS=RENT is given to the binder then the executable (PO or load module) is given the binder specified attributes of RENT=YES and REUS=YES, even if there are some (sub)programs statically linked that are assembled/compiled with NORENT. Further, it appears that one can use the COMPAT(LKED) option to change this behavior so that in the above case the module would be given the RENT=NO and REUS=NO attributes. The above seems to me to be a much better way to go. But I wonder if I am losing any capabilities by specifying COMPAT(LKED). We currently don't specify the COMPAT option at all, so I guess it defaults to COMPAT(MIN). Being as we're talking just COBOL applications with the occasional assembler subroutine I can't imagine that we'd ever use one of the other COMPAT options. But then again, I don't know. Anyway, in the end I imagine we'll convert all assembler routines to be reentrant; and we already compile all COBOL programs with the RENT option. But, even though we don't have a large number of assembler routines, I'd prefer not to have to make them all reentrant before we can start using the REUS=RENT binder option. BTW; this is all being done so that we can use the CICS RENTPGM=PROTECT option and actually have the programs loaded into read only memory. Currently we don't specify a REUS option in our COBOL program binder step, so even though they are all compiled RENT CICS does not consider them reentrant and thus does not load them in to (E)RDSA. Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
