FYI LinKEdln passwords hacked
LinkedIn Users: Change Password Now Attackers appear to have obtained--and may have already decrypted--at least 6.5 million LinkedIn passwords. http://www.informationweek.com/news/security/attacks/240001623? cid=nl_IW_daily_2012-06-06_htmlelq=a86e12d6260b46e991eaf6fac15b1ab7 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on dataset owned (SHR) by Started Task?
This is age old issue. I think the summary is that in order to to maintain data integrity of the PDS don't try updating any PDS that is allocated by someone else. If it works great otherwise don't come crying to IBM (or anyone else). Dataset integrity is only as good as you treat the dataset like any thing else . Ed On Jun 6, 2012, at 12:33 PM, Sri h Kolusu wrote: Q). What is the best way to delete a PDS member while the started task has it allocated DISP=SHR? You can try using IDCAMS delete function with FILE Parameter //DELPMEM EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //DDN DD DSN=YOUR PDS, //DISP=SHR //SYSIN DELETE 'YOUR.PDS(membername)' FILE(DDN) //* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to suppress Message in REXX App
Gil: Maybe I am not understanding of your complaint. The ARC message is sent to you as *YOU* requested some function from HSM. HLIST for example is your request to DFHSM to list something (usually a DSN) and DFHSM is responding to your request. So please explain why you are objecting to receiving the message? Ed On Jun 1, 2012, at 2:40 PM, Paul Gilmartin wrote: On Fri, 1 Jun 2012 13:27:54 -0500, McKown, John wrote: I don't know about that message in particular, but I know that the HSM started task often issues message via a directed TPUT having an option to deliver it to the userid which issued the HSM command. Similar to what the z/OS SEND commands does when sent by another TSO user or operator command. I don't know of any way to suppress it. Perhaps TSO PROFILE NOINTERCOM but I'm not in a position to try it. Makes me madder than you-know-where. Sometimes I'd like to strangle IBM developers. Than behavior is _so_ 20th century. The function needs to be redesigned, at the very least to send the message to the address space that requested the operation. But IBM doesn't care enough to do it right. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ISV software costs based on MIPS
A long time ago a vendor wanted to charge 1+ Million dollars for an upgrade for their software. The company dumped the vendor and went with another (after a lot of haggling and the vendor took a you have to pay period line) the company went with another vendor who was a little more flexible (the money helped of course). This was in the 1970's (or early 80's) back when a dollar was worth something (name of company provided off list). Another company discussed here on the list was quite rigid. The CIO and others went along until they advertised on the Super Bowel and that was the wrong thing to do as my management came down with orders to get rid of all the products as we were not going to be subsidizing their ads anymore. In less than 2 months we got rid of the products and cancelled all their products. Some were extremely easy to displace and litterly no change was involved others were found to be obsolete and were being paid for, for no reason. I think we saved $500K (US) a year. The 500K probably went to bonuses as the peons (us) never saw it but the bigger cars in the parking lot next year spoke volumes. Ed On May 31, 2012, at 1:49 PM, Vernooij, CP - SPLXM wrote: We did. After changing our z9's to z196's, a vendor asked such a ridiculous price for one product that we took the jump to convert to the IBM version of this functionality, where installing a new product, training on it and converting the database and procedures and even getting used to the IBM peculiarities was more than benificial... Kees. Hal Merritt hmerr...@jackhenry.com wrote in message news:1e7a8b5a967dfb42b888c2c05cfe0f5b047...@mmoex10mbs03.jhacorp.com .. . Our economic culture demands growth. If a publicly traded company cannot sustain grown in revenues and profitability then investors get annoyed and move their money elsewhere. An incumbent ISV can take a calculated risk and increase prices because we are very reluctant to change products. There is the cost of training and sometimes conversion. And the cost is sometimes not so much money as it is clock time. Not to mention political issues. But we all are being pushed and pushed hard to cut costs and grow profits. At some point it starts to make business sense to look at competing products. And at some other point I guess it makes sense to change products. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Wednesday, May 30, 2012 3:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ISV software costs based on MIPS In 1e7a8b5a967dfb42b888c2c05cfe0f5b047...@mmoex10mbs03.jhacorp.com, on 05/30/2012 at 03:26 PM, Hal Merritt hmerr...@jackhenry.com said: No ISV wants a pricing strategy that potentially reduces income. Does that include a pricing policy that gives customers an incentive to switch to a competitor? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Re: How to leave ISPF
Shmuel: I remember going through the PCF TMP code and it was in there. I also found it in the PCF manual as a feature. My memory doesn't function to well before we had PCF so I will not argue other than to say that is not how I remember the field mark key. As far as accounting. We never used the feature as we had way to many SMF records as it was. I also do not remember as TSO being that much of a resource user (yes I know). We had more issues and to add that into the mix was just to much. My immediate gut reaction is that we had some users that would get around it (don't ask unless you really want to know) so turning on accounting would be a waste. Ed On May 28, 2012, at 7:57 AM, Shmuel Metz (Seymour J.) wrote: In 4f439d1e-1523-49ed-815c-6fa3dcd87...@comcast.net, on 05/27/2012 at 10:36 AM, Ed Gould edgould1...@comcast.net said: I think that was because that way back when IBM had a TSO product called PCF. If memory serves me one of the feature that PCF offered was to be able to stack commands and to separate them it used the field mark key as a delimiter. No; you could use FM as a separator without PCF. As I recall, PCF allowed you to use other characters, e.g., semicolon, as a separator, but did not disable the recognition of the FM. Although admittedly the biggest feature of PCF was to do data set dasd pooling Not command accounting? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to leave ISPF
Paul: I think that was because that way back when IBM had a TSO product called PCF. If memory serves me one of the feature that PCF offered was to be able to stack commands and to separate them it used the field mark key as a delimiter. Although admittedly the biggest feature of PCF was to do data set dasd pooling (it also had a few other really nice features). We used it as well for TSO command authorization as we hadn't gotten RACF yet. The only issue I had was to change dasd meant an IPL or you had to have plenty of spare pools. I didn't like to zap LPA modules unless it was really needed and we needed another freebie from IBM to do that. Ed On May 26, 2012, at 10:42 AM, Paul Gilmartin wrote: On Fri, 25 May 2012 19:01:13 -0400, Shmuel Metz (Seymour J.) wrote: This part wasn't answered. You need to use the field mark key (x'1E'). Does ISPF treat it the same way that TSO does? I thought that it was just another character except for TSO line mode. Don't know. But I once tried to set Field Mark as my Command Delimiter (seemed to make sense, and semicolon is much too valuable otherwise). ISPF wouldn't let me do that. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: REPRO MERGECAT performance
The third vendor (NOT DINO or the other) sorry I wasn't clear on that. Using undocumented fields in the catalog is just plain inexcusable (IMO). Reserved fields are just that NO one is supposed to use them except IBM (IMO). Ed On May 26, 2012, at 4:26 PM, Linda Mooney wrote: Hi Ed, /snip We took the other one and in addition there were side bennies. We also got burned by an OEM that depended on some slight alterations to the catalog that were really not documented /esnip Did you mean that you got burned by the other one (not Dino-Soft) or another (3rd) vendor? Thanks, Linda - Original Message - From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Friday, May 25, 2012 11:17:37 AM Subject: Re: REPRO MERGECAT performance Dave: We took the other one and in addition there were side bennies. We also got burned by an OEM that depended on some slight alterations to the catalog that were really not documented although I think IBM and the vendor agreed to disagree on the peculiarity (use of undocumented fields) in the catalog. I got caught in the middle as I raised the flag. IMO the vendor was at fault but its water under the bridge. I will never use the other vendor again as a result (although its a great vendor) I do not like getting burned. Ed On May 25, 2012, at 12:51 PM, Gibney, Dave wrote: In the spirit of evenhandedness, faster mergecat is one of the good reasons to acquire T-Rexx from Dinosoft, or the other one :) Dave Gibney Information Technology Services Washington State University On May 25, 2012, at 11:02 AM, Mary Anne Matyaz wrote: Can MERGECAT performance be improved by altering the buffer space values for either the input or output catalog, or both? If you have a lot of VSAM, probably not. As I recall, doing a large repro mergecat with a lot of VSAM was very slow, but it was mostly due to the need to go change every vvds entry. In other words, I don't think you'll get a lot of bang for your buck. Mary Anne --- - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: REPRO MERGECAT performance
Looking back at some emails from around that time. I *think* the issue with repro mergecat is that it access VVD's all over the place. I did not take time to track it down but the best explanation I got is that it must update all the VVDS's . Ed On May 26, 2012, at 4:26 PM, Linda Mooney wrote: Hi Ed, /snip We took the other one and in addition there were side bennies. We also got burned by an OEM that depended on some slight alterations to the catalog that were really not documented /esnip Did you mean that you got burned by the other one (not Dino-Soft) or another (3rd) vendor? Thanks, Linda - Original Message - From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Friday, May 25, 2012 11:17:37 AM Subject: Re: REPRO MERGECAT performance Dave: We took the other one and in addition there were side bennies. We also got burned by an OEM that depended on some slight alterations to the catalog that were really not documented although I think IBM and the vendor agreed to disagree on the peculiarity (use of undocumented fields) in the catalog. I got caught in the middle as I raised the flag. IMO the vendor was at fault but its water under the bridge. I will never use the other vendor again as a result (although its a great vendor) I do not like getting burned. Ed On May 25, 2012, at 12:51 PM, Gibney, Dave wrote: In the spirit of evenhandedness, faster mergecat is one of the good reasons to acquire T-Rexx from Dinosoft, or the other one :) Dave Gibney Information Technology Services Washington State University On May 25, 2012, at 11:02 AM, Mary Anne Matyaz wrote: Can MERGECAT performance be improved by altering the buffer space values for either the input or output catalog, or both? If you have a lot of VSAM, probably not. As I recall, doing a large repro mergecat with a lot of VSAM was very slow, but it was mostly due to the need to go change every vvds entry. In other words, I don't think you'll get a lot of bang for your buck. Mary Anne --- - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: REPRO MERGECAT performance
Tim, I would love to hear about any as well. I have done a few and the length of time (even at 0200 ) was poor. I had to ask for 6 hours and was put off for quite some time. I ended up leaving and really never cared what happened. Ed On May 25, 2012, at 8:14 AM, Tim Hare wrote: We've just done a couple of REPRO MERGECATs that were fairly large, and took some time, so I was wondering: Can MERGECAT performance be improved by altering the buffer space values for either the input or output catalog, or both? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: REPRO MERGECAT performance
Mary Ann, From a long time ago the length of time was accessing other items than the catalog. Ed On May 25, 2012, at 11:02 AM, Mary Anne Matyaz wrote: Can MERGECAT performance be improved by altering the buffer space values for either the input or output catalog, or both? If you have a lot of VSAM, probably not. As I recall, doing a large repro mergecat with a lot of VSAM was very slow, but it was mostly due to the need to go change every vvds entry. In other words, I don't think you'll get a lot of bang for your buck. Mary Anne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: REPRO MERGECAT performance
Dave: We took the other one and in addition there were side bennies. We also got burned by an OEM that depended on some slight alterations to the catalog that were really not documented although I think IBM and the vendor agreed to disagree on the peculiarity (use of undocumented fields) in the catalog. I got caught in the middle as I raised the flag. IMO the vendor was at fault but its water under the bridge. I will never use the other vendor again as a result (although its a great vendor) I do not like getting burned. Ed On May 25, 2012, at 12:51 PM, Gibney, Dave wrote: In the spirit of evenhandedness, faster mergecat is one of the good reasons to acquire T-Rexx from Dinosoft, or the other one :) Dave Gibney Information Technology Services Washington State University On May 25, 2012, at 11:02 AM, Mary Anne Matyaz wrote: Can MERGECAT performance be improved by altering the buffer space values for either the input or output catalog, or both? If you have a lot of VSAM, probably not. As I recall, doing a large repro mergecat with a lot of VSAM was very slow, but it was mostly due to the need to go change every vvds entry. In other words, I don't think you'll get a lot of bang for your buck. Mary Anne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Mystery from TSO
Are you using RACF or UADS (I still prefer UADS myself). With UADS I have seen strange occurrences. The UPT(?) gets written back to UADS and rarely it gets clobbered and is written back as it was in storage. Ed On May 25, 2012, at 1:10 PM, John Norgauer wrote: I have a user that somehow had her TSO profile prefix changed to the letter 'A'. She swears that she did not use the PROFILE command. Is there any other way that this prefix could have changed? Oh, and she does not drink on the job. John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Mystery from TSO
I have seen this myself (albeit years ago). Someone updated the UPT (in storage via cross memory services long story don't ask) and logged off. During the logoff process the system rewrites the UPT in UADS not sure about RACF). Its been ages but one of the (at least I could find) undocumented fields in the UPT was CPU time (total since the user was created). I don't recall how I found that but I think it was found in the Fiche (before OCO naturally). I think it was when I was working on the tso pre prompt exit. Its got to be 30+ years. Ed On May 25, 2012, at 1:30 PM, Mark Zelden wrote: chuckle Nice Friday line. To answer the OP: Other than a CLIST / REXX exec issuing the PROFILE PREFIX command, I don't think so. Unless you are using SYS1.UADS still and then someone could potentially edit the UADS member for that userid and modify it. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http:// expertanswercenter.techtarget.com/ On Fri, 25 May 2012 14:17:09 -0400, Gord Tomlin gt.ibm.li...@actionsoftware.com wrote: Then you would need to change her prefix to AA. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-05-25 14:10, John Norgauer wrote: I have a user that somehow had her TSO profile prefix changed to the letter 'A'. She swears that she did not use the PROFILE command. Is there any other way that this prefix could have changed? Oh, and she does not drink on the job. John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Brain drain: Where Cobol systems go from here
Brain drain: Where Cobol systems go from here -When the last Cobol programmers walk out the door, so may 50 years of business processes within the software they created. Will you be ready? http://www.computerworld.com/s/article/9227263/The_Cobol_Brain_Drain? taxonomyId=154 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Screen Scraping TN3270
Agreed...(about screen scraping). I have run into a few over the last 40 something years. bIt is just plain a DON'T DO IT. Twice I have been called in at something in the morning because some IDIOT thought it was a good idea. Not only didn't they tell anybody they were buying some product that did it they never thought something would change. 20 or so years ago we went from TCAM to VTAM and actually had two applications die one of the people claimed it was my fault (he had signed off on the change request no less). One presented such a security exposure that when I found out I just went to the auditor and let me have a run at the people. Nothing gets people motivated more than a visit from an IRATE auditor with a security exposure. I just let the auditor go at them for a couple of weeks as the vendor who wrote the screen scraping software was no longer to be found. I had a good laugh at that one. The people were almost traumatized (good for them). Before they went out and bought a replacement I had the auditor pass me the manuals under the table and found issues with the solution. They had to find another solution. Mean while they had to manually login and programmers had to monitor the beast as the application was reasonably important. The auditor thanked me privately and I continued to pass him jewels like that it made him happy and he looked more important to the powers that be, Ed On May 21, 2012, at 4:39 PM, zMan wrote: On Mon, May 21, 2012 at 4:57 PM, Longnecker, Dennis dennis.longnec...@courts.wa.gov wrote: Curious as to what people might be using, if anything, on the JAVA side for screen scraping TN3270 applications. Last year, because of performance problems, we switched from IBM Hats to a different JAVA based screen scraping product four WebSphere screen scraping. Recently we ran into some application issues, and after over a month of e-mail and telephone calls for support and no response, we decided we better switch it out. What might people be using out there for TN3270 screen scraping on their java applications? Don't do it, it hurts... Seriously, it's a major pain, and very fragile. No, I'm not answering your question, just suggesting that you're headed for madness in that direction... -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Screen Scraping TN3270
Saving the password in an unsecure environment IN RAW TEXT. Ed On May 21, 2012, at 7:32 PM, Paul Gilmartin wrote: On Mon, 21 May 2012 17:23:37 -0500, Ed Gould wrote: Agreed...(about screen scraping). I have run into a few over the last 40 something years. bIt is just plain a DON'T DO IT. Twice I have been called in at something in the morning because some IDIOT thought it was a good idea. Not only didn't they tell anybody they were buying some product that did it they never thought something would change. 20 or so years ago we went from TCAM to VTAM and actually had two applications die one of the people claimed it was my fault (he had signed off on the change request no less). One presented such a security exposure that when I found out I just went to the auditor and let me have a run at the people. ... How was it a security exposure? For example, was it worse than photographing the screen with a smart phone (but are camera phones prohibited effectively at your site?) and passing the result to an OCR program? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink outages in 2012
This brings back memories pre IBMLINK. I vaguely remember an IBM product (INFO-MVS) which was (if memory serves me) was a single (??) reel 6250 tape sent monthly by IBM. I was the one designated to load the tape into an VSAM dataset. The team was 8 (or was it 9) sysprogs and all of us disliked calling into IBM to look up problems so there was a lot of push to get the tape loaded ASAP. One day the delivery of the tape was delayed because our in house delivery system broke down. ll we knew after some frantic phone calls it was somewhere between the 3rd and 18th floor. The group split up and went to every floor in the the system trying to find the tape. We found out that it was still on the internal lift system it was unavailable. We all ended up on the 3rd floor pestering the technician to get the system back up and running. After 15 minutes we left the trainee to pester the technician. The building was rather new and I know things break down but the tape was deemed rather critical. The rest of us had to go back and share one microfiche reader and the infamous 1-800 (it could have been a local number but its immaterial) number and we opened so many problems with IBM that day that I think IBM sort of wondered if the building burned down. The INFO MVS dataset was really critical to our group and having to to sit there at a fiche reader was not exactly appealing to any of us. I am really shocked that IBM is apparently treating the outages like they are not worth talking about. Although with IPL failures you would not have been able to us INFO/MVS you still have had a fall back of the 1-800 number or groan even fiche. To me the SIS and the other (maybe not all) features of IBMLINK would be similar to a airline reservation system. Does anyone have another comparison they would prefer to use? Ed On May 21, 2012, at 9:09 PM, Clark Morris wrote: On 21 May 2012 13:27:19 -0700, in bit.listserv.ibm-main Sam Knutson wrote: My consideration is many applications in IBMLink don't seem to merit the cost of true continuous operations. I think it is unreasonable to ask for 24/7/365(6), for all of IBMLink. As someone who has been away from the actual trouble shooting for over 20 years (I still remember my site's customer number) so I don't know what the critical functions are or what all is included in IBMLINK. From your posting below, I can see that IBMLINK covers a number of areas. I wonder how Amazon or LL Bean define what has to have virtually total availability. Similar questions arise for Apple and Microsoft. I would definitely think that problem databases require it and that frozen ones should be available for reading even when they are unavailable for update due to maintenance. I'm wondering if this is sort of like EREP was back when I was dealing with it, a necessary stepchild that seemed to not have any one group responsible for it. Possibly it would be worthwhile to identify all of the functions in IBMLINK and identify which ones need the availability. It sounds like something SHARE is well suited for. Also we need to identify the customer and IBM costs incurred by lack of availability both soft and hard. Have any of the people on this list found that the problems with IBMLINK affect the perception of the z series within their organizations and of IBM's ability to come up with appropriate products for business needs? Clark Morris We need high availability for applications that enable us to effectively support our own high availability systems. This seems to be operational support for our System z hardware and software, reporting problems electronically, researching problem databases for known solutions and open APARs, and retrieving service. ResourceLink which we use for hardware support IBM moved to a higher availability infrastructure some time ago and has made process changes to make the infrequent outages less problematic for customers. SR on the current highly available infrastructure seems to be filling the need to submit problems electronically. I didn't like SR as much when I first saw it. The community at SHARE and customers directly gave IBM very critical feedback. IBM's leaders listened and delayed the replacement of ETR by SR until many significant issues had been addressed. There are remaining bugs and opportunities to improve i.e. the double sign-in requirement for some use cases. SR is any many ways better than ETR and I now prefer it i.e. attach small files, multiple users updates on status of PMR, etc. IBM is doing OK here. IBMLink SIS is critical to us. This weekend it was fortunate that IBMLink was up early as we had a planned infrastructure outage and ran into a problem that we found in five minutes using SIS probably would have taken hours using phone support at 0400 on a Sunday. IBMLink SIS or some other tool that is highly available and lets me search in
Re: CSVEDIT using COBOL
John, At the time we used Panvalet and it was extremely simple to use it. The (probably) only real advantage of Panvalet at the time, simple and straight forward. We also had strict job card rules which made it a lot easier to insert . I never cared for IEBEDIT myself. Especially since Panvalet was simple to use. Our jobcard standards was cumbersome but it helped out the accounting people so one really can't complain. Ed On May 14, 2012, at 11:28 AM, John Gilmore wrote: People who are familiar with and knowledgeable about IEBEDIT make significant use of it. Others of course do not. This difference is largely generational. When SYSGENs were still required their stage 2s, the job streams generated by the expansion of the system-defining stage 1 macro instructions, often failed (chiefly but not only because real DASD storage requirements had been underestimated). It was then necessary to restart this job stream, beginning typically with the failing job step (and altered DD statements for one or more data sets). In these circumstances one necessarily became very familiar with IEBEDIT, which was used to edit the stage 2 job stream to produce a recovery one. It remains a useful utility, and those who don't use it should study the few manual pages that describe it. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
IBM’s first tape drive turns 60 (makes you feel old!)
http://www.theregister.co.uk/2012/05/21/ ibm_first_tape_drive_model_726_turns_60/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEW4005I FETCH FOR MODULE Failed
I guess I would link it to a temporary data set ie // exec pgm=iewl,parm='list,xref,map' //sysprint dd sysout=* //sysut1 unit=sysda,space=(cyl,(20,10)) //input1 dd disp=shr,dsn=where the loadmod is //syslmod dd dsn=tem,unit=sysda,space=(cyl,(1,1,1)) //syslin dd * include unput1(loadmod in error) name Tempnam(r) // *Note use caps where appropriate. If thats OK then you have a problem on the executing system (probably) If it doesn't work then you probably have no choice but to recreate the module. *OR* it could be temporary in nature and its probably time to call IBM. Ed On May 12, 2012, at 1:31 AM, Lim Ming Liang wrote: Hi Scott, This modules are from ca software. It works in other LPARs, so I suspect it's hardware related, I can't tell for sure. I can DFDSS dump them and iebcopy them. So need some advice to validate it, before I re-install them into another volume. Regards Lim ML On 12-May-12 11:59 AM, Scott Ford wrote: Lim, A couple of questions, who's module ? IBM ? Other ? Has this program ever worked before ? If so, what changed ? Scott ford www.identityforge.com On May 11, 2012, at 11:31 PM, Lim Ming Lianglimm...@unifi.my wrote: Hi, I had quite a few similar error messages on load modules fetching problem on a same volume; DSINIT FROM DDNAME STEPLIB FAILED BECAUSE IEWFETCH ISSUED RC 0D AND REASON 00 On the System Messages manual; IEW4005I FETCH FOR MODULE program-name FROM DDNAME ddname FAILED BECAUSE IEWFETCH ISSUED RC return-code AND REASON reason code. Explanation: Fetch for the load module failed. The possible hexadecimal return codes and hexadecimal reason codes are as follows: Return Code Error Description 00 Processing completed normally. 0B Program check. 0C Not enough storage available. Reason Code Error Description 04 No storage for DATD 08 No storage for DEB 0C No storage for IOSB 10 No storage for EXTLIST 14 No storage for module *0D ** Bad record area. *What does this Bad record area means ? Does it mean the affected volume has an hardware issue ? What utility I can used to check the volume integrity ? The load modules library is corrupted ? But I can browse the Load dataset and members without any problem. Please advise. -- Regards Lim ML -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Loyd: Fort Wauchooka (sp??) rings a bell somewhere in my cob ridden memory. But I also now remember Ft Ben Harrison (now). I remember the guys talking about the desert and thats about all. Ed On Apr 17, 2012, at 7:17 AM, Lloyd Fuller wrote: In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Graduated in March 1969 as a Staff Sergeant converted to a SP6. Programming since then. lLOYD - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 12:16:33 AM Subject: Re: GO TO cobol On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. --John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. -- John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Origins of numeric assignation of z196 z114
I will throw out a guess here. IBM has been through the years exceedingly cautious in naming anything. The new names are at best a way to confuse people, in my opinion. Ed On Apr 16, 2012, at 9:54 AM, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 16 april 2012 16:42 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Origins of numeric assignation of z196 z114 W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? Why not z11? I don't know. Why 196 and 114? I heard about it: 1xx means FIRST generation (of what? naming convention?) 96 means number of processors inside. Note, you can buy only 80 of them, but it really contains 96 processors, inlcuidng SAPs and spares. 14 is for M10 model (4 are for spares and SAPs). BTW: I really can't understand marketing names like z196, TS1140, or DS8000. Why don't they use names like Jaguar (ok, it's partially used), MAGSTAR, T-REX, MtBlanc or Cindy Crawford? Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S. -- Radoslaw Skorupka Lodz, Poland I would then suggest names more like: zEUS, HERA, HERMES, GILGAMESH, etc. :) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
Bob: You are correct. Example: TSO code that won't be touched unless some BCP code breaks it. Even then some of it is so poorly documented IBM might just withdraw the broken part (example a TSO COMMAND (depending on what it is) ) The last major overhaul was the convertor interpreter they had to do that because of PSF and new JCL requirements needed for PSF). Ed On Apr 12, 2012, at 9:26 AM, Bob Shannon wrote: and seems to me the code is not very modern First, there are structures in the BCP code that are 40 years old. They haven't changed and are extremely difficult to change. Second, z/OS 1.13 will IPL on a z900/z800. This means the BCP can only use instructions supported by those processors. Third, according to yesterday's SOD, z/OS 2.1 requires at least a z9 processor. This implies the BCP in 2.1 can use instructions introduced on those processors. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: VSAM help wanted for random reads
Frank,
Thanks for reporting back.
One request is there somehow to paste the results so they match up
with the headers ?
Ed
On Apr 3, 2012, at 6:33 PM, Frank Swarbrick wrote:
Several good ideas given.
My sysprog installed BLSR and I got very good results:
Without BLSR:
-
-TIMINGS
(MINS.)--
-PAGING COUNTS
-STEPNAME
PROCSTEPRC EXCP
CONN
TCB SRB
CLOCK SERV
WORKLOAD PAGE SWAP VIO SWAPS
-PROC01
STEP01 00 1123K
1121K
.83 .11
23.2 1599506 TSTBAT
0
IEF404I
ICM06F - ENDED -
TIME=16.43.46
-ICM06F
ENDED.
NAME-ICM06
TOTAL TCB CPU TIME= .83 TOTAL ELAPSED TIME=
23.2
With BLSR:
CSR020I
BUFSI=1024, BUFSD=20480, BUFNI=10, BUFND=256, HBUFNI=0, HBUFND=0,
SHRPOOL=14.
DDNAME=ICMMSTR
CSR022I
STRNO=16, ACB RMODE31=ALL, RMODE31=ALL.
DDNAME=ICMMSTR
+CSR021I
ACB CONVERTED TO USE VSAM LSR.
DDNAME=ICMMSTR
-
-TIMINGS
(MINS.)--
-PAGING COUNTS
-STEPNAME
PROCSTEPRC EXCP
CONN
TCB SRB
CLOCK SERV
WORKLOAD PAGE SWAP VIO SWAPS
-PROC01
STEP01 00 10704
3532
.04 .00
1.1 73844
TSTBAT 0
0 0 0
IEF404I
ICM06F - ENDED -
TIME=16.55.07
-ICM06F
ENDED.
NAME-ICM06
TOTAL TCB CPU TIME= .04 TOTAL ELAPSED
TIME= 1.1
23.2 minutes versus 1.1 minutes. 1,123,000 EXCP versus 10,704 EXCP.
BTW, to Steve Comstock, there is no AIX on this file. Just a 17
byte key where the first byte is the record type ('0' - '5') and
the remaining 16 is the 'actual' key in the format appropriate for
that particular record type.
The idea of putting the record type at the end rather than the
beginning is an interesting idea. Unless there's some way of doing
that without having to change any programs I don't think we'd want
to take the time. However I am interested enough to try it with
this one program and see what effect it has.
Thanks!
Frank
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Pre-Friday fun: Halon dumps and POK Resets
This is not HALON related but it is along similar lines of others on here. We had a T1 that worked perfectly ATT (in the 1980's) said it was to spec and almost zero errors. One of my many part time responsibilities was for maintaining the 3725 software. Every so often the T1 (it was muxed) would go zonkers. I had ATT and everyone looking at it and they could see it go crazy and were trying to pin down what was causing it. I had traces up the ying yang showing the issue but everything (software) was up to snuf and I had IBM level 2 scratching their heads as they could not see the issue either. It was getting semi serious as the NP was out pacing the floor and yelling at people. One of our people was talking to the people on the other end (NYC) and he made a comment about it seemed to happen when ever the freight elevator went by.. Turns out they didn't use shielded wiring in the elevator shaft (DAMM ATT). They were out and replaced it and really never had an issue after that and we POURED data through it! Never a software issue (NCP or VTAM) it was solid as a rock just like good code should be. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Pre-Friday fun: Halon dumps and POK Resets
(back in the 70's) had a union operator shop. The company wanted to put HALON into the DC and the union went on strike. If I remember correctly both sides backed down. Ed On Mar 22, 2012, at 12:33 PM, zMan wrote: So over the years I've heard a few good stories about accidental (or deliberate) Halon dumps and BRS pressings. Like operators playing Frisbee in the machine room and discovering that the Halon button really, really needs a cover on it... Who else has stories to share? -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: calling all Vtam old-timers(or heavy-weights)
John, I have never heard of putting VTAMLIB in the linklist and never did it in the 20++ years I was in the business. Ed On Mar 22, 2012, at 4:27 PM, John Norgauer wrote: I am trying to get rid old an VTAMLIB dataset. We have in the vtam PROC a DD that has a VTAMLIB. A different VTAMLIB exists in our LNKLST. My question is: does VTAM use the VTAMLIB from the LNKLST? My gut feeling is that it does not. John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Hypothetical Performance Question
There are several issues here. Resource usage can (and does) mean several things. As to CPU time minimal at best then there are other resources like time drives and dasd space (among others) that reserve for the exclusivity of the job. Simple example: job 2 has (example) 3 tape drives and they are unavailable for the rest of the system so they are in use but not used. Bottom line its not just a cpu time issue. Ed On Mar 15, 2012, at 2:11 PM, Kent Ramsay wrote: Hi, A hypothetical question but first the setting: A customer has two jobs auto-submitted within five minutes of each other. Job 1 grabs the dozen or so data sets and executes, leaving Job 2 with a formal waiting for data sets situation. Obviously, when Job 1 finishes, Job 2 actually starts. Now the question: While Job 2 is queued up waiting for the data sets, is there any appreciable use of CPU by z/ OS or JESx services to continually check to see if the data sets are free, yet? In this case, Job 1 runs for almost 4 hours so Allocation services is checked at least occasionally. I'm not interested in doing a charge-back, just wondering if there's any real cpu usage. Since this cropped up, the customer has changed the job schedule to submit Job 2 after Job 1 completes but the mind wonders. Thanks. Kent Kent Ramsay 425.681.2278 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Endevor(Change Management Software)
John: I would further qualify your statement about OEM's to something like this: Some OEMs know about SMPE and some use it as to its design point others use it as a selling point and do not embrace SMPE at all. Ed On Mar 15, 2012, at 12:38 PM, John Gilmore wrote: There is a long tradition among sysprogs of what is done and not done, and what is done is done within the framework of SMP. There are some few exceptions, but most ISVs use SMP too. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: VTAMLST - Who needs to read it
Chris: This is similar in my estimation to a library sys1.maclib. We were a 100 percent cobol shop so we used the noaccess rule. What we found is that the only people that tried accessing it were people from outside the company that were looking around and had no real need for it as I said we were 100 percent cobol. To give you a fair idea only the senior application people could even remotely look at a dump even then they had no clue. In *OUR* shop it worked. IMO sys1.vtamlst was similar. Every two years we had a consultant who demanded access to it. We were nice and said NO. One consultant came in and asked for access and we said no and he went the politic route and they said sure. Sure enough 3 days later we get an internal memo saying we had to change it and then the memo wars started up. One of my VP's came down and I sat down with him and explained why we didn't want to change it. We were short on man power in the group and could not spare the time I had hours and dates and everything to prove we didn't have the time. He said yes he knew but just this once. I asked which project did he want pushed back and he pointed at one and of course it was a really important one and I asked if he understood the cost and everything and of course he said he did. So somewhere in my 100 hour work week I changed it and of course it did not work. This caused a really nasty backlog to literally break. My 10 minute change caused an outage and we had a outage of one of our customers got their reports 2 hours late and all hell broke loose. The VP was called in and he tried to push it onto us. I got called up to the presidents office and I explained our side and the president actually told the VP to keep his people in line and not to request such items again. The VP eventually moved on and life went back to normal. Ed On Mar 9, 2012, at 12:03 PM, Chris Mason wrote: Juan IBM suggests UACC(NONE) for them (RACF Security Administrator Guide, apendix D- Security for system datasets). Why should the RACF developers be the arbiters of what is the correct access policy for VTAMLST? I would say that they were as likely to get such a proposal correct as any other development shop commenting on the products of another development shop. In other words, they are very, very likely to get it quite wrong - a phenomenon I have observed time and again! Indeed, I have sometimes been very pleasantly surprised when a manual written by one development shop happened to come up with a clear explanation of how to use products from another development shop. Actually the only case I can remember over many years is GDDM talking about the 3270 data stream. (RACF Security Administrator Guide, apendix D- Security for system datasets) Please - and this applies to all posters - provide an URL when referring to something state in a manual. I suggest you post this query on the RACF-L list and challenge the gurus I notice there are not backward in coming forward and see if any of them can provide a reasoned argument why the following recommendation - which I dug out! - is present: quote D.0 Appendix D. Security for system data sets Table 48. UACC values for system data sets Data set/UACC/Comments ... SYS1.VTAMLST/NONE/ ... /quote http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza7c0/ D.0 Note that the people responsible for this table couldn't even imagine any justifying comment to add. I suspect they had wet fingers in the air! If the RACF-L gurus cannot provide a reasoned argument, I suggest you treat this recommendation with the pinch of salt which in my opinion it deserves. Remember There is no substitute for understanding what you are doing., a maxim that isn't necessarily ingrained on the conscience of IBM developers! - Anyhow the users who need to access VTAMLST are obviously the user of the VTAM/NET address space and any system programmer's TSO address space where the system programmer is responsible for maintaining the VTAMLST partitioned data set. I cannot see any reason why a user of the VTAM API would require access to VTAMLST for the reason that he/she was using the VTAM API. - Incidentally, while you are challenging the RACF-L gurus over access to VTAMLST, you might care equally to challenge them over the recommendation to specify universal access of READ for the VTAMLIB partitioned data set where, again, the comment field is completely absent in the now famous table. Again, I suspect a wet finger! - Moreover, take a look at the comments where the authors bothered to add comments and note whether there appear to have been any guidance other than common sense and - it must be said - note the considerable equivocation! - Chris Mason On Fri, 9 Mar 2012 09:00:34 -0800, Juan Mautalen jgmauta...@yahoo.com.ar wrote: Hi: We currently have our VTAMLST libraries
Re: TINC?
Randy: We used to run MFT and everyday we changed the partition sizes without an IPL. Now if you are saying to change from MFT to MVT then indeed an IPL was needed, as well PCP to MFT (or for that matter MVT)? The OS is the key issue and indeed VM you can ipl an OS and it probably does not require an IPL(machine wise) a virtual machine needs to be brought in . Maybe I am missing some distinction here. Ed On Mar 5, 2012, at 9:06 AM, Gross, Randall [GCG-PFS] wrote: In college, we had a 360/40 running PCP (Primary Control Program) in 64K; iirc, PCP could not be patrtitioned. I worked one summer for a company that had a 256k 360/40 running MFT with (typically) 4 partitions. Iirc, it took an IPL to reconfigure MFT. (M = multimple, F = fixed) I belive MVT (V = variable) was the first OS360 operating system that suppored dynamic repartitioning, but I could be wrong. I never experienced MVT - just went from MFT to SVS to MVS. Randy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lloyd Fuller Sent: Friday, March 02, 2012 8:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TINC? It could be that the spooler was really a resident writer. I was just a newby programmer, and know that we were told that requiring more than a certain amount of memory required a major operations change and was frowned on. It was definitely not DOS/360. It was OS/360 and used JCL with DCBs, etc, not the DOS/360 stuff. Lloyd - Original Message From: John Gilmore johnwgilmore0...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Thu, March 1, 2012 4:09:02 PM Subject: Re: TINC? Shmuel/Seymour wrote: begin extract NFW. There was only a single partition on PCP. Based on the model I'd guess that you were running DOS/360. /end extract and it is correct, albeit in a Pickwickian sense, that OS/PCP had only a single partition; but it did support both transient and resident readers and writers; there were even some very primitive to-2311-DASD RYO spoolers in use; and at this remove Lloyd Fuller's confusion may be only a terminological one. Still, I too guess that he may have been using DOS. --jg On 3/1/12, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 1330520469.27305.yahoomai...@web180907.mail.ne1.yahoo.com, on 02/29/2012 at 05:01 AM, Lloyd Fuller leful...@sbcglobal.net said: No. When we used PCP on the Model 40 with 64K. We had a single job partition and, most of the time, a spool partition. NFW. There was only a single partition on PCP. Based on the model I'd guess that you were running DOS/360. It was a very simple partition (like 10K or so) that ran the 1401 What are you trying to say? The 1401 was a computer, not a program. If you meant that you ran the 1401 Emulator program, that confirms that it was DOS. If we needed more memory for a specific purpose, we would reipl from a different pack and bring up OS360 with just the program partition. Another sign that you were not running OS/360; on an OS/360 system with multiple partitions you can amalgamated partitions with the DEFINE command; you don't need to re-IPL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
O/T (but interesting) Quantum computers: IBM on verge of creating machine faster than any supercomputer | Mail Online
http://www.dailymail.co.uk/sciencetech/article-2108160/Quantum- computers-IBM-verge-creating-machine-faster-supercomputer.html?ITO=1490 No speed limit: IBM scientists on verge of creating 'quantum computers' faster than any supercomputer on Earth Breakthroughs move technology on 'up to 1000 times' Scientists believe working quantum computer will happen within their lifetimes Described as 'Holy Grail' of computing Quantum computer could crack any encryption Read more: http://www.dailymail.co.uk/sciencetech/article-2108160/ Quantum-computers-IBM-verge-creating-machine-faster- supercomputer.html#ixzz1oPHJJgsF -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
On Feb 19, 2012, at 5:27 PM, Joel C. Ewing wrote: The described record arrival rate averages at just under 58 records per second. Somehow I don't think XBM was designed with that high of transaction arrival rate in mind, processing each record as a separate transaction. I would think that a high-speed transaction processing environment (CICS, IMS) would do better than XBM, although those would probably still involve more overhead than a specialized transaction-processing STC optimized just for your own peculiar transactions (but I agree a separate specialized STC would be more of a maintenance headache). There is also an intermediate approach where you collect records by some means and then periodically fire off a process or transaction to process records collected since the last time the process was run. Another consideration: If the current batch processing is done at a time of lower system system load and involves significant work per record, moving this processing into peak processing times could have significant impact on your peak MSU requirement and a significant impact on your costs. I suspect your record arrival rate is not a constant throughout the day but also has its peaks. If those peak record arrival rates actually correspond to current periods of peak system load, then the impact on the peak system MSU requirements of moving this load would be even greater than one would expect from the average record rate alone. In other words, if there is a perceived business need to process the records in a more timely manner, be sure those footing the bill are aware it may not be a free lunch. JC Ewing Joel: I think a LOT depends on how much processing is needed for each transaction. If it is just syntax checking and minimal editing then maybe XBM is a possibility. Although your scenario is valid as well. It is hard to give out much information without a lot more detail. We did XBM jobs and the number varied all over the place. Typically each job took about 5 minutes of CPU time (168 slow I know) it was both cpu and IO intensive (essentially Assembler H compiles and with Major macros). I did not want to suggest that XBM is a final answer in any case. It was used by us in a highly unusual manner. I hope the original questioner comes back with a little bit more information. CICS or IMS is (like you suggested) viable alternative but it is complicated (bother suggestions) and hard to say this way or the otherway. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
Perhaps, But have you ever heard of a 1 petabyte (or more) volume? Ed On Feb 18, 2012, at 5:36 PM, Scott Ford wrote: Ed, Or maybe they use the famous four letter word, plan and have a harddrive big enough to handle the file Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 18, 2012, at 5:43 PM, Ed Gould edgould1...@comcast.net wrote: We are all pretty much knowledgeable about how the MF works in the multi-volume area, right? The secondary question I am asking is how does the PC create/ handle multivolume files? I can guess but that is pretty much all it is. Can anyone explain it for the PC ? Ed - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
Magen: Not sure if this is what you are looking for but There is a facility called execution batch monitoring (at least in JES2) You feed it input and it creates output (to your specifications). It was originally designed for batch compiles but it could be adapted to something like you want (?). Ed On Feb 19, 2012, at 3:25 PM, Magen Margalit wrote: Hi list. We have a daily betch job that is processing as input records which has been collected all day. volume of records is about 5 millions for 24 hours. In order to make systems more online we are looking for a way to run the process for each record all day long instead of a daily run, and doing so with minimum as possible application changes. One idea that came up is to convert the process to a self developed STC which will be triggered by a record on an MQ queue and will run as STC all the batch process programs To me it seems like a bad idea because having a self developed STC in production create a maintenance gap (and where there is one STC a second one will soon to follow...)... Are there other advantages / dis-advantages regarding a self developed STC ? Are there any self developed STC's at your shop? Any other ideas on how to approach this issue? Thanks in advanced. Magen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
We are all pretty much knowledgeable about how the MF works in the multi-volume area, right? The secondary question I am asking is how does the PC create/handle multivolume files? I can guess but that is pretty much all it is. Can anyone explain it for the PC ? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
The analyst has to have the numbers for it is he(she) that is designing the system. He is supposed to be the giver of the grail. The real issue is which analyst. There are several different types business, system and a few others. The delineation is supposed to be the job description. The real problem is who's pervue does it come under if it is no one. Ed On Feb 17, 2012, at 7:03 PM, Frank Swarbrick wrote: But who has the responsibility? This seems something that a system programmer, with some good analysis tools, should do. Or the system itself should be such that it can do it's own analysis. After all, is that not what computers are for? Frank From: John Gilmore johnwgilmore0...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Friday, February 17, 2012 5:21 PM Subject: Re: Archaic allocation in JCL (Was: Physical record size query) Frank Swabrick wrote: begin snippet | No, I'm not expecting a real answer to that question. | Just trying to point out why it's hard, to say the least, | to know how to size files of this type. /end snippet The question itself has not been very well formulated. No one, I hope and suppose, sizes files directly in cylinders, tracks or megabytes. These are derived quantities. One begins with record types, their individual sizes, and their expected volumes/counts. Initially one has only estimates, often poor ones, of transaction/processing volumes, but these estimates can be improved incrementally by collecting statistics of the volumes actually experienced during processing and then analyzing these data.. That this is not much done does not been that it cannot or should not be done. Adequate capacity planning and even many design decisions are impossible without the systematic collection and analysis of such information. John Gilmore, Ashland, MA 01721 - USA - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Career Watch: The most in-demand skills of 2012 - Good news the training budgets seem to be increasing
http://www.computerworld.com/s/article/9224116/ Career_Watch_The_most_in_demand_skills_of_2012 Year-over-year changes in training spending, 2006-2011: • 2006: 7% • 2007: 6% • 2008: -11% • 2009: -11 • 2010: 2% • 2011: 9% Source: The Corporate Learning Factbook 2012, Bersin Associates -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: REXX IEBCOPY Continuation?
Dave: I rhink the word select must start in column 2 Ed On Feb 15, 2012, at 2:33 PM, Hansen, Dave L - Eagan, MN wrote: Still no luck: FCO105I COPY1 COPY INDD=INDD1,OUTDD=OUTDD1 FCO105I SELECT MEMBER=DBOK62 FCO411A UNIDENTIFIED COMMAND OR KEYWORD NEWSTACK V1 = COPY1 COPY INDD=INDD1,OUTDD=OUTDD1 V2 = SELECT MEMBER=DBOK62 V3 = SELECT MEMBER=DP13 V4 = SELECT MEMBER=LAND1CPY V5 = SELECT MEMBER=SSTDN V6 = SELECT MEMBER=TRAY2LND QUEUE V1 QUEUE V2 QUEUE V3 QUEUE V4 QUEUE V5 QUEUE V6 EXECIO queued() DISKW SYSIN (FINIS DELSTACK TSOEXEC IEBCOPY Also got: FCO105I COPY1 COPY INDD=INDD1,OUTDD=OUTDD1 FCO105I S M=DBOK62 FCO411A UNIDENTIFIED COMMAND OR KEYWORD Dave Hansen Eagan Software Systems Branch 651-406-1208 dave.l.han...@usps.gov -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Wednesday, February 15, 2012 2:18 PM To: IBM-MAIN@bama.ua.edu Subject: SV: REXX IEBCOPY Continuation? I guess that what You want is: NEWSTACK V1 = COPY1 COPY INDD=INDD1,OUTDD=OUTDD1 V2 = S M=DBOK62 V3 = S M=DP13 V4 = S M=LAND1CPY V5 = S M=SSTDN V6 = S M=TRAY2LN Queue V1 Queue V2 Queue V3 Queue V4 Queue V5 Queue V6 EXECIO queued() DISKW SYSIN (FINIS DELSTACK TSOEXEC IEBCOPY Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Hansen, Dave L - Eagan, MN Skickat: den 15 februari 2012 21:08 Till: IBM-MAIN@bama.ua.edu Ämne: REXX IEBCOPY Continuation? Group, I have a REXX EXEC: NEWSTACK V1 = COPY1 COPY INDD=INDD1,OUTDD=OUTDD1 V2 = S M=(DBOK62,DP13,LAND1CPY,SSTDN,TRAY2LND) queue V1 '+' V2 EXECIO queued() DISKW SYSIN (FINIS DELSTACK TSOEXEC IEBCOPY It gets an error: FCO105I COPY1 COPY INDD=INDD1,OUTDD=OUTDD1 + S M=(DBOK62,DP13,LAND1CPY,SSTDN,TR AY2LND) FCO411A INVALID CONTINUATION I tried to stack both records Queue V1 Queue v2 It gets an error when the second record is read - Undefined command or keyword. Q). These are PDSE datasets. Can IEBCOPY be continued in REXX? Q). Is ISPF Library Managemnet my other solution to copy select members? Thanks in advance, Dave Dave Hansen Eagan Software Systems Branch 651-406-1208 dave.l.han...@usps.gov - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Simple iinventory control products?
Greg: I should have been more specific but I was taking about people who had to support and work with their products. I remember specifically at SHARE several conversations, McKinney came up and the best they got was yea somebody bought it and didnt go through the software selection commee and they got grandfathered in otherwise we wouldn't even consider them. Ed On Feb 13, 2012, at 11:21 AM, Greg Shirey wrote: Really? Never heard anything positive? Ever read any of the messages that come from this list? I've searched the archives and found only messages regarding MacKinney that are either positive or neutral. The only negative comments I can find are from you. I won't argue whether the circumstances you describe actually happened or not, but if the experiences of others who post to this list have any value to you (I'm sure mine don't but others might), you could consider that it was an anomaly. ((If anyone from MacKinney is following this thread and your company actually has a fund for paid lackies please contact me off-list!)) Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Gould Sent: Friday, February 10, 2012 10:55 PM Greg: I am surprised a little bit by your attitude and am disappointed in your suggestion. I wasn't going to mention it but since you seemed to infer I wasn't professional I will add: Another person in the group I was in had a similar issue with them. The person was happy he didn't have to call as he had gotten a blank wall from McKinney as well. I don't recall the product and I am not about to insult you with suggestion about being a paid lacky for Mckinney. I have never heard anything positive about them. In the last say 20 years I guess the negatives outweigh anything. I never thought highly of the company as their postage card return to order their product was a little bit less than professional in my opinion. Yes they are a cheap software company and I will repeat you get what you pay for. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Simple iinventory control products?
Greg: I am surprised a little bit by your attitude and am disappointed in your suggestion. I wasn't going to mention it but since you seemed to infer I wasn't professional I will add: Another person in the group I was in had a similar issue with them. The person was happy he didn't have to call as he had gotten a blank wall from McKinney as well. I don't recall the product and I am not about to insult you with suggestion about being a paid lacky for Mckinney. I have never heard anything positive about them. In the last say 20 years I guess the negatives outweigh anything. I never thought highly of the company as their postage card return to order their product was a little bit less than professional in my opinion. Yes they are a cheap software company and I will repeat you get what you pay for. Ed On Feb 9, 2012, at 10:27 AM, Greg Shirey wrote: After a few minutes of what on the phone? Calling them morons? Questioning their ancestry? MacKinney support gets you speaking to a developer far faster most other vendors I've contacted. Those developers may come across as somewhat defensive of their products (most everyone tends to believe they have debugged their code thoroughly) but I've had many occasions to call for support and have never been advised to debug it yourself. I think we have 5 MacKinney products in house, including LISTCAT PLUS - which has never abended 0C4 here... FWIW. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Gould Sent: Thursday, February 09, 2012 8:35 AM One day I got a call from the production people about an OC4 (in LISTCAT) . I looked at it a little and since it was a vendor program I called up their support line. AFter a few minutes on the phone I got a not to nice of a response: DEBUG it yourself -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Simple iinventory control products?
Peter: I have had the opportunity in the past to support at least one of the McKinney products (LISTCAT ??). Essentially all it did was to take the outout (sysprint) from IDCAMS and produce a much smaller report. It was a COBOL program. One day I got a call from the production people about an OC4 (in LISTCAT) . I looked at it a little and since it was a vendor program I called up their support line. AFter a few minutes on the phone I got a not to nice of a response: DEBUG it yourself Now I know the product cost very little but I expected a little more than that. I was not going to spend a half hour trying to debug their code. I decided to write a REXX exec to do the same thing. It took me all of 20 minutes to write it and 30 minutes to test it. Since it was a who cares output and to make the production people happy I ran it and gave them the output and I ran it passed the programmer. He they were happy and we put it in production and its been working for over 20 years (no bugs). I asked why we bought it and could never trace it back to the orderer. The next OS release I deleted it and made sure that we never paid them a penny for the product). I went out of my way to steer the company away from any Mckinney products after that. I think over the 20 years it was mentioned once. Yes they are cheap but then you get what you pay for source and thats it. I have gotten better support out of the CBTTAPE . Sorry I would suggest you think long and hard about any of their stuff (I refuse to call them programs as one has to have support to be called a product in my opinion). Ed On Feb 9, 2012, at 8:01 AM, Farley, Peter x23353 wrote: Thanks Jim, that one was pointed out to me in an offline email. It's in the mix for analysis. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jim McAlpine Sent: Thursday, February 09, 2012 5:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Simple iinventory control products? Mackinney have something called OSXREFS. *OSXREFS consists of 4 utility programs* *OSXDSN*, *OSXLINKS*, *OSXSCAN* and *OSXPROC* provide the following functions: - Cross-reference datasets and PROCEDURES in a specified JCLLIB/ PROCLIB - Cross-reference Programs and PROCEDURES that execute them - Cross-references strings found in PDS members - Cross-reference JCL Procedures and executed Programs I haven't used it myself, but I expect that as with all Mackinney products, the price will be right and support will be good. Jim McAlpine On Mon, Feb 6, 2012 at 5:23 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: Hi All, I am being asked if there are relatively simple source-and-JCL inventory control products available for z/OS. I found one myself (XREF product at dcmsi.com), but management wants to know if any other software vendors provide such a product. We're not interested at the moment in full life cycle management products like Endeavor or ChangeMan. We just need a simple inventory control product that could answer interactive queries (E.G., What JCL uses this file? Where is this program used?) by programmers and technical support staff. TIA for any product or company names or links you can provide. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
OT The Big Blues: How the Giants and IBM got their nicknames - what's your opinion?
http://www.poughkeepsiejournal.com/article/20120204/ NEWS01/302030064/1006 Both the New York Giants, preparing for Sunday's Super Bowl against the New England Patriots, and one of the state's most famous corporations and major local employers, IBM, share the nickname Big Blue. So what? Nothing, really. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM Research z196 Papers
I do not know if its changed but... At one time I asked IBM to get me subscribed to the system journal. They were sort of reticent but did so for one year I got it. The next year they said no. From then on they got no IBM recommendations from me. I also made it plain that if and when they changed their mind I would again start recommending IBM software (they lost DFSORT for this and other reasons). Frankly after reading it for a couple of years there were very few interesting articles (to me) although there to be honest there was one article out of twenty (or so) that were interesting. I came to the conclusion that (at least the during the time that I was reading it) it was more about hardware and very little about software. I think they really tightened the audience for some reason but cannot say for sure. Ed On Jan 31, 2012, at 7:46 AM, Meral Temel (Garanti Teknoloji) wrote: Students can get them via university membership, mainframe customers can communicate with IBM representatives in order to get them. Best Regards Meral -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Comstock Sent: Tuesday, January 31, 2012 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] IBM Research z196 Papers On 1/31/2012 6:06 AM, Meral Temel wrote: To colleagues and students who are interested in, IBM Research published z196 papers in their current issue which is entitled `IBM zEnterprise Systems And Technology'. http://www.research.ibm.com/journal/ Best Regards, Meral. Looks interesting. But individual articles are $30 for non-IEEE members and $20 for IEEE members. Am I reading that right? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This message and attachments are confidential and intended solely for the individual(s) stated in this message. If you received this message although you are not the addressee, you are responsible to keep the message confidential. The sender has no responsibility for the accuracy or correctness of the information in the message and its attachments. Our company shall have no liability for any changes or late receiving, loss of integrity and confidentiality, viruses and any damages caused in anyway to your computer system. Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi herhangi bir zarardan sorumlu tutulamaz. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why can't the track format be changed? (was: Physical record size query)
Allan: All good stuff. But I think IBM indicated that the use of SDB would be king. Indeed it makes sense. To tie themselves forever to 3390 is foolish (IMO) not that its bad mind you but it defeats the whole idea of system managed storage. SMS is a stated direction. The map is in place now to handle all changes reasonably painless (as long as SDB is used). Ed On Feb 7, 2012, at 2:23 PM, Staller, Allan wrote: Think of all of the code within z/OS that actually depends upon device geometry. The C and H in CCHHR, etc. A hallmark of z/OS has been backward compatibility. If this code were to be changed, all of that backward compatibility would go poof! For what benefit. Customers have revolted against making massive changes to support arbitrary hardware design changes. Another reason is that back in the SLED days, every new device type had a different geometry, and caused massive JCL changes to accommodate that new geometry efficiently in terms of space utilization, and indirectly $$$. 1/2 track block size (27998) on a 3390 (track length 56664) will waste about 40% of the available space if used on a 3380 (track length 47476). That is the reason a few vendor products are still distributing source/load modules with a approx. 6k block size, as opposed to 1/2 track blocking. A 6k block size is fairly efficient (although sub-optimal) on both 3380 and 3390. A secondary effect of the geometry issue is the reason for 3390-9, 27, 54, To get around some of the other limitations imposed by volume limits arising from the basic 3390-3 configuration. These other volume sizes are compatible with the CCHHR format of a 3390-3. IBM has stated that future devices will be compatible with 3390 geometry to prevent the need for mass JCL changes. snip That leads to a question that I've been thinking about for some time. Since the 3390 geometry is emulated by modern storage control units, why then are the inefficiencies of small blocks emulated also? There are not SLEDs actually storing the data, why are IBG's, sectors, and all the other CKD nastiness emulated that makes 80 byte blocks such a bad idea? IOW, why can't the control unit simply store 708 * 80 byte blocks on a 56,664 byte 3390 track? Does zos's calculations take these inefficiencies into account and only write 78 of these blocks per track? The C in CKD stands for count and this is some information about the amount of data following in the next data block (the amount may vary from block to block). Likewise K in CKD stands for key and some access methods are using key data that is stored before the actual data. So, both are bits of information that are used and thus cannot be dropped. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
MainframeZone.com - IT Management: Mainframe Linux: How to Save a Million Dollars!
http://www.mainframezone.com/it-management-spotlight/mainframe-linux- how-to-save-a-million-dollars1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
Yes indeed this question has popped up on often. You have the easiest answer and probably the best. In a JES2 exit it is reasonably easy but then it depends on why you are changing it. I went at it at a two pronged attack. I did the exit and then I figured out that that it was easy to get around. In my case we had a jobclass's set up for tape or notape and I figured if the submitters weren't going to be honest I would look at every mount and then look at the jobclass and if they were in the wrong jobclass I issued a cancel with an appropriate message. Ed On Jan 24, 2012, at 7:37 AM, Walt Farrell wrote: On Tue, 24 Jan 2012 07:21:23 -0500, Tim Brown tbr...@cenhud.com wrote: Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R That question seems a bit odd to me. Have you considered that almost all jobs are submitted via intrdr? The exceptions would be jobs coming from a physical card reader (if any) or via RJE or NJE. Or STCs that are really started jobs rather than started tasks because they have a JOB statement in them. But anything else that's running basically came in via an intrdr, even if it's a production job scheduled by your production job scheduling system. Did you really mean something else? In any case, as others have indicated, you'd use JES or system exits to accomplish that, but what you'd need to do in them may differ depending on what you really meant. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: I thought it would be easy (IEBDG)
David: Speaking of Sort... 20+ years ago I created a data tape for testing sort out. It was essentially an 80 byte record with 20 4 byte sort keys. I created a million records using IEBDG and it really put any sort I threw at it to a heavy duty test. All fields were binary and random. Once I got through the control cards the process was painless. My memory is cloudy here but I think I ran into issues like yours understanding what IEBDG was really asking for. Ed On Jan 18, 2012, at 4:58 PM, Donald Russell wrote: Thanks very much for this working example. What threw me was the format of the PICTURE= clause... I didn't realize the length was the number of digits to parse in the B'...' part you'd THINK that would be unnecessary as it would just count them itself. :-) I did try specifying the length of the field, which I also thought was redundant as I already coded LENGTH= for the field. I know, IEBDG was probably written in the 1960's :-) I also learned about SORT... I never think of using sort for copying data or this sort of translation. Thanks again for all the replies. Cheers On Tue, Jan 17, 2012 at 17:42, Gainsford, Allen allen.gainsf...@hp.comwrote: Let's take a simplified example. I want to create a file with a 2 byte record with x'a1b2' as the contents. I use FD to define two fields, each one byte long: FD NAME=BYTE1,LENGTH=1,STARTLOC=1,PICTURE=161 FD NAME=BYTE2,LENGTH=1,STARTLOC=2,PICTURE=178 IEBDG definitely isn't an easy way to do it, but if you really want to use it, then the following works: FD NAME=BYTE1,LENGTH=1,STARTLOC=1,PICTURE=3,B'161' FD NAME=BYTE2,LENGTH=1,STARTLOC=2,PICTURE=3,B'178' CREATE QUANTITY=1,NAME=(BYTE1,BYTE2) Regards, Allen - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How can I know the owner of a PDS?
Paul: Originally there was one TCB per user (or job) (IIRC). PCP-MVT Vs2R2 - ASCB one per address space and (may) have multiple TCB's (you have to manually create multiple TCB's (normally with attach). There are (or were) other type address spaces (non executable code IIRC - ie data spaces that had a ASCB not sure about TCB) Ed On Jan 16, 2012, at 12:20 PM, Paul Gilmartin wrote: On Mon, 16 Jan 2012 16:36:54 +, Eric Bielefeld wrote: This may not be multi-user, but I know the when I was a computer operator back in 1969, DOS on a 360 mod 40 could be run with 3 partitions - BG, F1, and F2. We didn't run any online systems, but you could run up to 3 jobs at a time. Indeed. I regard that as multiprocessing, but not multi-user, even as on z/OS UNIX I can do for I in 15 10 5; do sleep $I done ... four processes but only one user. I suppose the earliest accommodation of multiple users by OS/360 was the accounting fields on the JOB statement (was this aboriginal?), needed for chargeback accounting. There was a similar perceived need for DASD space accounting which would have most reasonably been satisfied by copying the JOB accounting info by default into the DSCB. Never happened. Programmers are still being advised to scour the SMF data to retrieve the information. I recall one site in the late 1970s which performed DASD accounting by requiring users to submit a paper form to create a data set, supplying DSN and SPACE. Undocumented data sets were periodically scratched. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: RES: ACCOUNT Product
Sergio: As others have said that are quire a few products out that that do something similar, at either CHEAP or $$. Usually the more $$ gets you a lot more customizability as to reports. If you don't want to spend money there are FREE programs on the CBT Tape (www.cbttape.org) There are also semi free reports that you have to tell RMF what you want. Sometimes it can be interesting as it doesn't always do quite what you want. You may have to write (control cards like with RMF) simple items. Or you can go to essentially writing full programs with SAS. Barry Merrill with MXG (his product MXG) does indeed produce a LOT of reports and for the most part they are canned and you have to do very little. The sort of down side is SAS which can be $$ is needed. I like his product but the down side is it may be relatively cheap but the program needed is SAS $$$. Yes you can write COBOL programs to do what you want but again this needs programmer time. No matter what direction you go it will cost you money and the only question you need to know is how much. The CBT TAPE is probably the cheapest but remember it will probably require you to customize the program(s) it may be a little or a lot. It really depends on the customization. Ed On Jan 11, 2012, at 10:19 AM, Sérgio Lima Costa wrote: Hello Lizette. How are you ? I spoke with a person here, from Computer Associates. They have a CA JARS product, that may be what our boss want. I got to CBTTAPE and download some samples there, very good, like FILE019. With this, I can get this report for example : 0 JOB START START ELAPSEDCPU CPU REGION REGION NAMEDATETIMETIME TIME % BELOW ABOVE ADELMOA 2012.001 15:44 001:11:450:01 0 .6M 17.4M ADELMOA 2012.001 17:09 000:00:500:01 2 .6M 17.6M ADELMOA 2012.001 17:11 002:01:280:09 0 .6M 18.2M ADELMOA 2012.001 19:13 000:07:360:01 0 .6M 19.4M ADELMOA 2012.001 19:22 002:14:380:02 0 .6M 17.6M ADELMOA 2012.001 21:47 000:01:130:08 11 .6M 19.4M ADELMOA 2012.002 17:18 000:02:250:01 1 .6M 20.2M ADELMOA 2012.002 20:34 000:49:350:02 0 .6M 18.4M ADRIANA 2012.003 14:42 000:34:310:02 02.7M 41.7M ADRIANA 2012.003 15:55 001:43:200:22 02.7M 41.9M ADRIANA 2012.003 18:09 000:31:590:03 02.7M 41.7M ADRIANA 2012.004 11:12 001:12:590:02 02.3M 22.9M But this is not enough for what they want here. I must say thanks very much again to you, that all time, try help us. Best Regards. Sergio -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de Lizette Koehler Enviada em: quarta-feira, 11 de janeiro de 2012 12:18 Para: IBM-MAIN@bama.ua.edu Assunto: Re: ACCOUNT Product : ACCOUNT Product Hello List, Someone know, if have a product to produce account reports from ZOS ? Our system, is ZOS 1.12. Thanks very much. Sergio, Could you provide details on what an ACCOUNT report would produce? Are they TSU/STC/JOB accounting information (CPU Time, Start Time, End Time, and so on) Or is there something else you are looking for? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/ privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect CETIP's point of view, which is only divulged by authorized personnel. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO
Re: Error apply ZAP
Gerhard: I honestly don't remember ever having the issue with IBM module(s). I memory goes back to early MVS 2.0 and if we did have an issue it was because TMS or some other vendor code hit the same module (open). In the case of TMS it wasn't their fault so much as IBM didn't give exits at the right points . I am not defending TMS but they just happened to need the hooks in a popular spot. Although I do not like how CA (ie TMS) and other products now put zaps in on the fly (so to speak). I have been burned once or twice with on the fly zaps as IBM quickly found the finger prints and tossed me off the boat and I had to got to CA support begging because IBM washed their hands of the issue once or twice. CA (this does go back a few years) wanted to toss me back to IBM. I had to supply a bunch of trace and dumps before CA would listen to me again but even then I felt CA was trying to avoid the problem rather than working with IBM the customer to resolve the problem. The problem did get resolved but it took days (or was it a week?) to get the problem resolved. The biggest PITA was ACF2 (never a fan) and the way they handled problems with TSO Allocation. Of course the ACF2 person on our side was well lets say less than average. I had to get involved before the issue was resolved and I had to pound some manager at ACF2 to get them to listen. We got rid of ACF2 and never had an issue with security after that. Ed On Jan 7, 2012, at 4:15 PM, Gerhard Postpischil wrote: On 1/7/2012 2:31 PM, Ed Gould wrote: constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. I've had the issue with IBM modules a long, long time ago. Assuming ZAPs are sequential, I prefer putting an identifier, APAR or whatever, into the eyeball text at the beginning of the module. That way I can see in a dump how it's been updated, rather than having to run a report. Module replacements take more effort and disk space, so ZAPs are closer to being green g Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
Seymour: I didn't say anything about the IDR space (and indeed I relinked a few modules) to get the zap on. It was difficult with quantity of the zaps. I hated to get the mail opened daily as the number of envelopes with zaps was scary at times. One ugly day I had 5 envelopes with 5 separate zaps in each envelope. I had enough work without having to deal with the paperwork that went along with each. One nice thing I will admit very rarely did zaps go against multiple modules. Ed On Jan 7, 2012, at 7:17 PM, Robert A. Rosenberg wrote: At 13:31 -0600 on 01/07/2012, Ed Gould wrote about Re: Error apply ZAP: Robert: I used to have a vendor that would send out zaps almost weekly and IDR space was at a premium on the vendors modules. We dropped the vendor so I don't know how they did resolve the constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. As I noted, and someone here confirmed, doing a relink adds extra IDR room (if the current IDR Record is full). IOW: The AMA120I message by suggesting the relink would add another IDR record with room for another 19 IDENTIFY commands. The IDR record is on a per- loadmodule basis and thus is shared by all the CSECTs in the Load Module. In the case of your vendor, so long as the ZAPs came with IDENTIFY commands and you did not supply the PARM override, every 19 ZAPs (~5 months) a relink would be needed to add another IDR record to be used. Ed On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote: At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
Robert: I used to have a vendor that would send out zaps almost weekly and IDR space was at a premium on the vendors modules. We dropped the vendor so I don't know how they did resolve the constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. Ed On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote: At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: EZTrieve
Lizette: That is indeed the best way to go. One caveat is that it will not catch TSO (users). Short of running GTF (forever) you will have a hard time catching every use. I think the only way is to talk to all the users and see if they know of any tso users out there that might be using it. If the reason is discontinuance and how dispersed you user community is allow probably 6 months (each installation is different). If the reason is something else and depending how politicized your environment is you may have to write email(s) and wait and see. Ed On Jan 6, 2012, at 9:10 PM, Lizette Koehler wrote: Does anyone know of a way to locate all JCLs/Proc members that are using EZTrieve? Any help would be greatly appreciated. Thanks If you have SAS and MXG or MICS then you can use that to begin the analysis. Or you can download the CBTTAPE.ORG file containing DAF. If you have JCLPLUS from SEA Software, then you might also have the JCLPUS XREF process Or if you have Endeavor or Changeman, you might be able to see what is in their processes. But as it has been pointed out, it will most but possibly not all. Let me know if you need more details. What you may not be able to see are end users of Easytrieve. Production use of Easytrieve might be easier. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: cpu / machine identification
Sam: From some experience. We were constantly adding/changing cpu's over just a two year period I remember going through at least 15 changes and it could have been more. From past experience PLEASE allow some amount of time (execution wise) if the serial number(s) do not agree. We would get the serial numbers invariably on Friday and have to make 30-40 (it was spread out over several people) phone calls. INVARIABLY a number was either misread or mis-keyed or whatever and we had to make emergency phone calls in the middle of the night to the software company asking for a temporary number until the morning. Also please do not keep the keys in storage (or if you do allow a simple way to update them). We had one vendor who will remain nameless who didn't have 24 hour support and it was a critical piece of software and we had to back out the upgrade what a disaster. Needless to say the vendor got kicked out of the shop as soon as we found a replacement. Ed On Dec 26, 2011, at 3:19 PM, Sam Siegel wrote: zMan - Thanks for the reply. It is a new product - No customers yet. I would like enough licensing to keep honest people honest and an operationally oriented reminder for the annual renewal. Sam On Mon, Dec 26, 2011 at 1:11 PM, zMan zedgarhoo...@gmail.com wrote: Gahh, IF BibBox, Inc. On Mon, Dec 26, 2011 at 4:11 PM, zMan zedgarhoo...@gmail.com wrote: On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel s...@pscsi.net wrote: Hello List - I'm attempting to create a licensing mechanism for a bit of software. I would like to be able to use a unique and non-modifiable identifier as part of the mechanism. The CSRSI callable service and STSI instruction provide a variety of hardware related identifiers. CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode. These appear directly related to PCCACPID (PCCA control block) and Sequence Code (STSI basic machine configuration).. Is there any preference to using one field over the other? What are the advantages and disadvantages of using each field? Are there other fields (in same or other control blocks) that should be used? Please feel free to treat this as an open ended question related to licensing mechanism and provided any related advice and tips based on experience. OK, I gotta ask -- what's the problem you're trying to solve? You don't trust your customers? In over a quarter century in the mainframe software business, I've come across ONE customer running software on an unlicensed box, and it was an oversight -- and a nice full-price bluebird for the sales rep. I don't believe CPUIDs are worth the hassle. Having said that, I would expect that any CPUID processing would work off, well, the CPUID. That's what customers understand. SAS Institute used to have a nice CPUID system for their C compiler that would issue a warning and print out what company the sucker was licensed to, but would continue to operate if the CPUID was wrong. This allowed emergency operation, while clearly keeping any real company from running it on the wrong box (though I suppose of BigBox, Inc. licensed it on one and ran it on two, it would be harder to notice; the case I'm thinking of was when we were running the Merrill-Lynch copy on another company's machine, WITH permission from SAS; every time we invoked the compiler, it would whine and say Licensed to Merrill-Lynch). Now, with systems management stuff that doesn't have a real UI that gets invoked all the time, it's harder. The best I've seen allowed: - multiple key entries in the CPUID file, so you didn't have to worry about swapping files at expiration: you just added new entries and eventually deleted the old ones. And you could keep all your CPUIDs in a common file, shared (or replicated) across systems. - Warned starting 30 days before expiration, on the operator's console: XYZ will expire in 30 days (29, 28...). - If it had a valid license (i.e., one with time on it but on the wrong machine) would run in emergency mode, whining on the operator's console every 10 minutes or so, but still running (this allowed for DR). - Supported universal temporary keys, that could be read/emailed/FAXed by support at 3AM if you really screwed up and were dead in the water despite the above. Now, this also meant that there were folks carrying beepers and temp keys, so they could do that after-hours support. Are you prepared to deal with all this? Is it worth it? As you can tell, I'm not a fan of such mechanisms. But it's not my decision (doh), so I'm trying to help :-) -- zMan -- I've got a mainframe and I'm not afraid to use it -- zMan -- I've got a mainframe and I'm not afraid to use it - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: cpu / machine identification
On Dec 26, 2011, at 3:11 PM, zMan wrote: OK, I gotta ask -- what's the problem you're trying to solve? You don't trust your customers? In over a quarter century in the mainframe software business, I've come across ONE customer running software on an unlicensed box, and it was an oversight -- and a nice full-price bluebird for the sales rep. I don't believe CPUIDs are worth the hassle. OK, I have run into two companies and one was just cheapness and the other was well dishonest. Both knew better but until a hammer is applied at the head nothing was accomplished. I pointed out the issue and was told to shut up. The other company claimed stupidity and I was told to shut up. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM Manuals
Scott: Last year I got an brand new IPAD. The installation instructions were on a 3 X 5 in a 4 page booklet. The font size was 4 and I could not read it to save my life. I had to get a friend to come over to read them so I could do the install. Bah humbug so much APPLE being user friendly. Ed On Dec 27, 2011, at 12:56 PM, Scott Ford wrote: lol, love it I have a19 inch one here at home where I work ...Maybe they are telling us old dinosaurs we are getting old, man Scott J Ford Software Engineer http://www.identityforge.com From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, December 27, 2011 1:37 PM Subject: Re: IBM Manuals Maybe they think everyone should be using 32 inch 1080P TVs as monitors? On Tue, Dec 27, 2011 at 12:13 PM, Scott Ford scott_j_f...@yahoo.com wrote: Lizette: Thanks, I thought it was these 61 yr old eyes...lol. I zoomed IE9 up to like 200+ % ..to read the TOC of the manual on the right panel of the page... Scott J Ford Software Engineer http://www.identityforge.com -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SPF timeline?
Benyamin: It was later explained to me that SPF was written at a woman's undergarment (Bra?) place in Chicago by I think an IBM person (or group). My mind is complete blank as to its name. Whoever came up with structured program facility was short sighted IMO. The immediate use might have been that but it was just plain misleading and a lot of people looked elsewhere quickly when they heard the name. At the time we were using TCAM and the fullscreen was at best clumsy IMO. VTAM fixed that of course but until ISPF came along (it, Fullscreen) was well supported, IIRC. Ed On Dec 24, 2011, at 12:58 PM, Binyamin Dissen wrote: On Thu, 22 Dec 2011 18:00:22 -0600 Ed Gould edgould1...@comcast.net wrote: :I think you are about right on the time line. I do remember the two :separate products. We had look at ISPF (we had gone FSE instead). :Our IBMers at the time went AWOL and I could never get a good :explanation between the two products. :We decided to keep FSE as it was a lot less $$$ . We also did not :like the proliferation of ISPF datasets (at the time DASD was :expensive). I remember when SPF was being tested at Western Electric and I much preferred Session Manager + FSE. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
Timothy: Semi off topic but germane to your entry. LONG LONG ago (and in New Jersey) the company I worked for had opened a data center building and was going to bring in new IBM mainframe. The company had hired a bunch of experts from a company that was relocating. The people came out and measured the way from the loading dock to the final resting place and assured everyone that the new CPU would fit without issue. IBM suggested otherwise. The system showed up and surprise the experts did not measure correctly. A emergency crane had to be procured and it had to be lifted (after having to break down a few walls) to the place where the crane was supposed to leave it. It was finally installed three days later and $50K later (not sure on the cost of the walls). These so called experts were at best big talkers and no real knowledge of installing a MF. There is a longer version but the end is do not trust the big talkers. Ed On Dec 21, 2011, at 11:42 PM, Timothy Sipples wrote: Now that I think about it, if the door to your data center isn't tall enough, IBM has a solution. Your new mainframe can be shipped topless, although that's not the exact term for it. Topless mainframe shipment is not recommended unless you really do have an unavoidably short entry door since IBM has to put the top back on your mainframe at your location. That takes some extra time. Best wishes everyone for a safe, happy, and healthy New Year. -- -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SPF timeline?
Skip: I think you are about right on the time line. I do remember the two separate products. We had look at ISPF (we had gone FSE instead). Our IBMers at the time went AWOL and I could never get a good explanation between the two products. We decided to keep FSE as it was a lot less $$$ . We also did not like the proliferation of ISPF datasets (at the time DASD was expensive). *MAYBE* if IBM hadn't gone AWOL we would have been persuaded to go. My memory is sketch but my memory seems to recall we were paying $95 a month for FSE and if memory serves me IBM's ISPF was like $395 a month. The programmers seemed happy with FSE and we (systems programmers) were happy as I can recall only one bug in the several years we had the product (it was a minor bug at that). Flash forward 4 or so years and at another shop we bit the bullet and went ISPF. Luckily the programmers were unsophisticated but we got a few complaints about bugs. Flash forward 10 years and IBM really put out a reasonably good product maybe 1 bug report in a year and I think I found the bug myself. To this day IBM (as long as you don't do too exotic things with it ISPF is a good solid product, IMO. Ed On Dec 21, 2011, at 7:24 PM, Skip Robinson wrote: SPF (Structured Programming Facility) when I entered this biz in the late 70s was a single product that essentially provided only what came later to be called PDF: Browse, Edit, Data Set, etc. It was not intended for installation applications, but if you were clever you could jury rig one of the 'foreground' functions like Compile to perform your own pet tricks. In my shop we created a few such RYO adaptations that were pretty crude and limited in feature. But like the dog who can walk on two legs, it amazed us for being even possible. Around 1980 the product morphed into ISPF (Interactive System Productivity Facility)--one of the great feats of acronym acrobatics in IT history. This transformation more or less coincided with the advent of MVS/SP. Initially there were two products: ISPF and PDF. You could buy and run PDF without ISPF. (I'd be curious to know how many shops ever did that.) The magic advance in ISPF was the notion of a 'dialog', a fully documented and extremely powerful mechanism for creating your own interactive applications that could even--miracle of miracles--be driven by COBOL. ISPF and PDF eventually melded back into a single product--probably an indication of how few shops wanted one component without the other. . . 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: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@bama.ua.edu Date: 12/21/2011 03:23 PM Subject:Re: SPF timeline? Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu In 2543323993444028.wa.elardus.engelbrechtsita.co...@bama.ua.edu, on 12/21/2011 at 07:22 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za said: http://www.planetmvs.com/spfeditor/ispfhist.txt Thanks. Now if I could just get the dates for 5740-XT8 and 5787-XT2. Some background of TSO and ISPF (missing good citations... :-( ) : I've probably edited one or both of those. Apparently TSO is not an 'option' in MVS, if I understand these links correctly, so ISPF came with MVS in 1974. No, ISPF was not part of either MVS or the later TSO/E. BTW, I would encourage anybody with copies of the relevant manuals oe announcement letters to edit the wiki articles and to add references where appropriate. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on scheduling security for TWS ad-hoc jobs
Dave: We had similar issues but we ran UCC7. I stayed away from the product (except when it was broken). Our UCC7 people managed to get your issue resolved, sorry I can't help with TIVOLI. One issue I think you also need to address is responsibility of how you handle when the user schedules the job and it bombs this is a sticky wicket in most shops. Ed On Dec 22, 2011, at 12:16 PM, Hal Merritt wrote: One possibility is to have the scheduler trigger upon the creation of a dataset. The dataset could be real (as in the input data), or an empty dataset just for triggering. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, December 21, 2011 1:30 PM To: IBM-MAIN@bama.ua.edu Subject: Question on scheduling security for TWS ad-hoc jobs I am posting a question for a co-worker. We are looking for some real world feedback on how you may have solved the problem we are trying to solve. We use Tivoli workload scheduler on z/OS for about 80% of our standard/supported production batch workload. Operated in typical fashion by production control staff that monitor the schedule, problem resolution, etc. However, we have this remaining 20% of production batch that is currently NOT under TWS control that needs to be. It is under a homegrown process that usually involves end-users keying data, and then submitting the actual production job.We have a project to eliminate this process, and are looking for idea's. What we need to be able to do is to continue to do whatever manual process(data input, etc), and then most likely post some user requirement on the TWS job that would then allow that job to run on demand, but from TWS. The catch is that we need to be able to secure who has the authority to post a specific job. As far as we can tell, we don't see any granularity to secure specific TWS functions down to the job(application) level for a specific person. Thanks in advance for any suggestions. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 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...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS MPFLSTxx vs Control-O for console message suppression.
Annetjie Van Heerden wrote: Hi, can anybody give me advise please? ---SNIP--- May I suggest that if you suppress *ANY* message from the SYSLOG that you get a write off (permission) from the auditors in advance. I would also make sure to get it in writing and keep it in a safe place for at least 5 years (maybe more). I trust the auditors but when they get a bee in their bonnet you can bet they will come after you. Another option is to massage syslog after its written put it to a dataset and then delete the messages and then archive both copies. I once had to chase a bug and it took me quite a bit of time as the messages never made it to the syslog, it was though the message did not exist. I would rather spend the extra time looking at a real copy than an altered copy thinking the message had to be there only to find out its been zapped. I got a few gray hairs for that experience that I will never grow back. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY in z/OS 1.13
Seymour: I was remembering MVS. I was using numbers in my original reply from SMF and IEFACTRT accounting in sysout. I don't recall if a conditional getmain would show up as used. I do not think so as I specifically remember seeing sizes less than 320K (I want to say 256K) on the job SMF data. If you want to go back to MFT IEBCOPY *WOULD* run (I used to do it everyday) in a 64K partition. IEHMOVE likewise ran in that size. Its a long story and probably not for here. On Dec 16, 2011, at 9:52 AM, Shmuel Metz (Seymour J.) wrote: In 45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc, on 12/16/2011 at 07:27 AM, Staller, Allan allan.stal...@kbmg.com said: Also (at the time) IEBCOPY would run in a region much smaller than 1 meg. ISTR 64K, but am not positive. That would not have been in the same timeframe as a 1 MiB conditional GETMAIN. As I recall, the OS/360 SysGen process generated different Linkage Editor control statements for IEBCOPY depending on whether it was for PCP, MFT or MVT. Given the design points for OS/360, your 64KiB recollection is certainly likely to within a factor of 2 either way. That is, I'm sure that the required partition/region it wasn't less than 32KiB or greater than 128 KiB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY in z/OS 1.13
Mary Anne: Way back when and continuing forward I always put on parm=size=1000K on all IEBCOPY (especially in SMPE) and got great throughput usually 50 percent (or more) faster runtimes. I think I started doing this in the 1970's. I know we had to use it when copying the CDS's (when they were pds's). Ed On Dec 14, 2011, at 1:26 PM, Mary Anne Matyaz wrote: John, I ran a few tests today and I'm seeing pretty good results, similar to what are in the presentation. Here's some data on one job that copies five large and one small PDS: T 12.02.3312.05.48 3 min 15 seconds J12.11.13 12.15.46 4 min 35 seconds MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEBCOPY in z/OS 1.13
I honestly don't think there was a default as the region it ran in I think was 256K. Giving it plenty of memory on the parm really did help out. I know my SMPE runs ran faster than any elses in the group. I also set up a larger size (4096K,1024K) on the link/binder runs and SMPE just ran terrifically (reasonably) fast. Yes and I always ran with a 6M on the job card (nothing on the exec). I vaguely remember bumping up the second size on the link did not help at all. I think I read an APAR on the link editor that explained this, but again this was ages ago and since it worked I was not about to complain. I remember also that if you gave IEBCOPY enough memory it didn't need sysut3 and 4 Ed On Dec 14, 2011, at 6:00 PM, Paul Gilmartin wrote: On Wed, 14 Dec 2011 17:35:26 -0600, Ed Gould wrote: Way back when and continuing forward I always put on parm=size=1000K on all IEBCOPY (especially in SMPE) and got great throughput usually 50 percent (or more) faster runtimes. I think I started doing this in the 1970's. I know we had to use it when copying the CDS's (when they were pds's). Would that have been bigger or smaller than the default? (He asks, having 4,000,000K rattling around in his jeans pocket.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HUMOR- OLD letter written to Datamation
Real Programmers Don't Use Pascal [ A letter to the editor of Datamation, volume 29 number 7, July 1983. I've long ago lost my dog-eared photocopy, but I believe this was written (and is copyright) by Ed Post, Tektronix, Wilsonville OR USA. The story of Mel is a related article. ] Back in the good old days-- the Golden Era of computers-- it was easy to separate the men from the boys (sometimes called Real Men and Quiche Eaters in the literature). During this period, the Real Men were the ones who understood computer programming, and the Quiche Eaters were the ones who didn't. A real computer programmer said things like DO 10 I=1,10 and ABEND (they actually talked in capital letters, you understand), and the rest of the world said things like computers are too complicated for me and I can't relate to computers-- they're so impersonal. (A previous work [1] points out that Real Men don't relate to anything, and aren't afraid of being impersonal.) But, as usual, times change. We are faced today with a world in which little old ladies can get computers in their microwave ovens, 12 year old kids can blow Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy and even understand their very own personal Computer. The Real Programmer is in danger of becoming extinct, of being replaced by high school students with TRASH-80s. There is a clear need to point out the differences between the typical high school junior Pac-Man player and a Real Programmer. If this difference is made clear, it will give these kids something to aspire to-- a role model, a Father Figure. It will also help explain to the employers of Real Programmers why it would be a mistake to replace the Real Programmers on their staff with 12 year old Pac-Man players (at a considerable salary savings). The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use Fortran. Quiche Eaters use Pascal. Nicklaus Wirth, the designer of Pascal, gave a talk once at which he was asked, How do you pronounce your name?. He replied, You can either call me by name, pronouncing it 'Veert', or call me by value, 'Worth'. One can tell immediately by this comment that Nicklaus Wirth is a Quiche Eater. The only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as implemented in the IBM/370 Fortran G and H compilers. Real Programmers don't need all these abstract concepts to get their jobs done-- they are perfectly happy with a keypunch, a Fortran IV compiler, and a beer. * Real Programmers do List Processing in Fortran. * Real Programmers do String Manipulation in Fortran. * Real Programmers do Accounting (if they do it at all) in Fortran. * Real Programmers do Artificial Intelligence programs in Fortran. If you can't do it in Fortran, do it in assembly language. If you can't do it in assembly language, it isn't worth doing. The academics in computer science have gotten into the structured programming rut over the past several years. They claim that programs are more easily understood if the programmer uses some special language constructs and techniques. They don't all agree on exactly which constructs, of course, and the example they use to show their particular point of view invariably fit on a single page of some obscure journal or another-- clearly not enough of an example to convince anyone. When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000 line programs that WORKED (Really!). Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000 line Fortran program, then speed it up by a factor of two. Any Real Programmer will tell you that all the Structured Coding in the world won't help you solve a problem like that-- it takes actual talent. Some quick observations on Real Programmers and Structured Programming: * Real Programmers aren't afraid to use GOTOs. * Real Programmers can write five page long DO loops without getting confused. * Real Programmers like Arithmetic IF statements-- they make the code more interesting. * Real Programmers write self-modifying code, especially if they can save 20 nanoseconds in the middle of a tight loop. * Real Programmers don't need comments-- the code is obvious. * Since Fortran doesn't have a structured IF, REPEAT ... UNTIL, or CASE statement, Real Programmers don't have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTOs. Data structures have also gotten a lot of press lately. Abstract Data Types, Structures, Pointers, Lists, and Strings have become popular in certain circles. Wirth (the above mentioned Quiche Eater) actually wrote an entire book [2] contending that you
Re: Fwd: case from DR in France.
Has anyone noticed that we never hear from any of the contributors from the CBT ? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Fwd: case from DR in France.
Mark, I was referring to pushing their code. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: case from DR in France.
Don: I have decided to change my email account so I can delete his entries and a few others. The others that contribute to the list do not make a point of pushing their code. With him its a monthly push of his propaganda. If you guys want to put up with his noise I will just delete his stuff. Ed On Dec 13, 2011, at 7:18 PM, Don Imbriale wrote: Give it up Ed. Your keyboard does have a delete key, doesn't it? - Don Imbriale On Tue, Dec 13, 2011 at 1:32 PM, Ed Gould ps2...@yahoo.com wrote: Mark, I was referring to pushing their code. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Kees, I think I would disagree with the flexibililty issue as all it takes some imagination with JCL and symbolic for the DSN in this case. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there an IBM program that will tell me what job created a DASD DSN?
Liz, The list you provided is OK, but in reality you really only need DAF and its free. While the others an do the job well I might add. The simple answer is usually the best. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there an IBM program that will tell me what job created a DASD DSN?
Dave, Technically IBM also supplies HLASM as well but the question was phrased to let the reader to think that a canned solution. The DFSORT option (actually semi valid) requires a bit of logic and some amount of programming type logic ie packed, binary etc and of course record layouts and what the fields mean. DAF relieves the user of some or most of these items. SAS has it#39;s own set of issues and unless you have macro definitions and then you need to understand SAS processing I have never become proficient in it as I keep thinking how it should work rather than how it really works DAF takes most if not all of the processing out of the hands of the user. The basics needed to know are at best minimal DSN in this case is all besides the file name of the dataset where SMF resides is basic. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there an IBM program that will tell me what job created a DASD DSN?
Liz, I know what you mean, however most shops turn a blind eye to systems people running their own acquired code on their own ID. I understand and fully agree that programs like DAF and others on the CBT or other such places should not be given to applications programs . I have been burned by such programs from outside sources. One consultant brought in his own goody bag and somehow it got into production and of course it was then thrown in my direction and all of a sudden I was supposed to support it. I threw it back and told personally to the head of programming and he really hit the ceiling. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Shmuel, Someone (John?) suggested that a language (Pearl?) could do it in very few statements and if I recall correctly his short example seem to say (at least to me) stack everything up in a pile. I was suggesting a pile was not a way to program no matter what language. Since we were talking about columns I suggested what I did. By the way I don#39;t beat my wife just like you try and keep kosher. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Peter, There is a 100 character limit that can be passed. This has been talked about. In the past. IBM has so many hard coded programs that to change it would be almost impossible. To fix and user programs might be affected as well. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Joel, Of course you are right. I am somewhat hesitant to agree with your saying cc 17 or greater is oppressive for continuation. With ISPF you can essentially make it easy. If you can remember the drums in the 026 or 029 that you could program to skip to any column. My memory is iffy here but I think there are products that can format JCL to put 1 parameter on each card for readability and debugging. The is formatting costs DASD space but it is a small cost for what it buys, in my opinion. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
S. Thanks, I was not aware of the SUBSYS parameter issue. I have never coded it. I will admit to making more than couple of try#39;s of parms of longer than would fit on 1 card and having to hit the fine manual to figure out how to do it. Outside of the new printer parameters that s the only time I have had to hit the JCL manual in 20 years maybe more. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: JCL sheesh! for today
Gil, It sounds like production is not fully implemented in the company. JCL, maybe but not where execution source resides. I have wired in places like that and it can be a nightmare. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. Although there is some debate whether JCL is a language (or not) any language that I am familiar with does have column restrictions of some type. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Gil, Here we go again. DSN does not need to be the first. For readability a lot of installations choose to have one item per line. I happen to agree. After several years of midnight perusal of attempting to read JCL and seeing some really badly written JCL think you will find. That 1 item per line, ie DSN, disp, space etc it#39;s the only way to go. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Shmuel, I was referencing mind you indirectly about continuation(s) with quotes, parenthesis . Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
John, I am not familiar with PERL, However the main point I am suggesting is that readability and debugging is EVERYTHING. What good does it do to string out an entire program into one continuous line? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Joel, My reading of your reply is frankly confused. Any DD card that needs to be continued must end with a comma and start (in the continuation card with a // and a blank) in CC 4 or at least up to CC 16 (no continuation in CC 72 is needed). A parm on the exec card in order to be continued had different rules and IIRC must start in CC 16 *AND* cannot be any longer than 100 characters (thats a double restriction) *AND* must have a continuation in 72 (thats three) which IIRC there is no other DD parameter has any restrictions (that I can remember of). Ed - Original Message - From: Joel C. Ewing jcew...@acm.org To: IBM-MAIN@bama.ua.edu Cc: Sent: Friday, December 9, 2011 10:19 PM Subject: Re: JCL sheesh! for today On 12/09/2011 11:57 AM, Ed Gould wrote: JC, My memory indicates that the parm on the exec card is really the only real column sensitive Nasty left in JCL. Although there is some debate whether JCL is a language (or not) any language that I am familiar with does have column restrictions of some type. Ed All JCL statement continuation records are column peculiar, not just those involving PARM values or quoted strings. A continuation which splits a quoted string is column sensitive on where the first record ends (column 71) and on where you must resume the string on the continuation (column 16). But, all other statement continuation records are also column sensitive in that continued parameters must resume in columns 4 - 16. This complicates manual verification of JCL, because visually it is difficult to distinguish between any parameter continuation that resumes in column 16 versus one that resumes in column 17, but of course the latter fails. It is true that there are languages (e.g., COBOL, FORTRAN, Assembler) with column restrictions that are an integral part of the language syntax; but a number of other languages (e.g.,PL/I, C, REXX) are essentially free-form with a syntax that is column insensitive. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: vdawkin
I have once again changed my password. Someone is very determi e to crack my password. My apologies. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
John, I had a so called manager, he used to read gas meters. He had that level of mentality. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: vdawkin
No, it was 6 character alpha and a 1 character numeric. They really did work at. It. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL sheesh! for today
Zman, Indeed I think you are correct. Someone can come up with the year but IBM did rewrite a huge chunck of code several years ago (they apparently did it well) as there was no fall out that I heard. I think this is similar to the TSO code that IBM refuses to update. I imagine there are other code pieces that IBM doesn#39;t want to touch because of bad or missing documentation. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: vdawkin
They don#39;t make(key scanners) for macintosh. My latest password is so far away from anything I have tree so far that. It will take them a few months. If it happens again I will change the email. A dress to an unhackable one. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: vdawkin
Try IPAD. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Charles, I believe, a long time ago mind you, that there was a conversation at GUIDE about where the proper place was for the layouts. The agreement was in the SMF manual. It seemed to work as lot of products records showed up there. Then they started to leave, slowly mind you. The question is of course why. I don#39;t think it#39;s any great crime, just curious as to why the reversal on the part of IBM. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Seymore, The SMF record layouts ar in a GC manual. This also has DFSORT and a few other PP record layouts. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Robert, Of course I forgot about those, thanks. But you have to have z/os to have the smf dsects. Z/os is not free. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Frank, Interesting. This seems to have changed from last time I looked as I think at one time there was a note in the DFSORT manual as it used to tell the people to look at the SMF manual. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Sorry about the spelling. From memory 0,4,5,6,13,14,17,30, paging, look at the manual for a complete list. Although Frank has informed us that the DFSORT was taken out (it was there at one time) the CICS maybe as well. I am not sure if IBM did it because of issues of real or imagined issues. You will have to ask them. OH yes RMF records. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Version Query for Installed Product
Jakes, This is one of the many reasons that all programs no matter how trivial should be installed with SMPE. Not only that the products should also be smpe maintainable. That should be a prereq for any program. I have heard many an excuse from various vendors over the years but when you have hundreds of often obscure programs there is just no easy way to determine what, where and who. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Scott, Well IBM does this in their freely available SMF records layout manual. The very idea that a record layout should not be public information is in my mind close minded. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Not to put to fine of a point on it but MXG and IIRC. Barry Merrill#39;s product amongst others have the layout of the records and you do not need to be a licensed user of ACF2 (and other products mind you) to have the layouts. Although unless you are a licensed user you wouldn#39;t need them. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Charles: I worded that poorly and agree with you. ALthough outside of report writers I can' think of any other reasons for needing them. But again why not have them freely available for all? There are no secrets to be gained from the records as each installation (at least in the case of ACF2) write rules for dataset usage so indeed the information seems limited to the installation to understand and interpret them. The only possible information to be gained is possibly sort SMF records and that if you are attempting to write your own sort. With DFSORT and SYNCSORT are the only two sorts available there used to be another one but have not heard anything out of them in probably 20+ years (maybe more). Ed - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@bama.ua.edu Cc: Sent: Monday, December 5, 2011 9:54 PM Subject: Re: What SMF record types and formats does ACF2 write? Although unless you are a licensed user you wouldn't need them Au contraire! You might be a software product developer hoping to write code to read (and make sense of!) the records. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Monday, December 05, 2011 7:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: What SMF record types and formats does ACF2 write? Not to put to fine of a point on it but MXG and IIRC. Barry Merrill's product amongst others have the layout of the records and you do not need to be a licensed user of ACF2 (and other products mind you) to have the layouts. Although unless you are a licensed user you wouldn't need them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Last use date of a PDS member
Barry, Even if you had a proc name with dynamic proclibs it wouldn#39;t mean much as there would no easy way to determine where the proc originated from or it could also be an in stream proc. Somewhere in my slim memory though there was a proc name some place in SMF. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
