Re: Binder SYSPRINT wrap?
On 2014-11-20, at 13:25, Charles Mills wrote: Just to annoy you. I hadn't known they cared. I suppose I should be flattered. Original message From: Paul Gilmartin Date:11/20/2014 9:57 AM (GMT-08:00) Browsing a Binder SYSPRINT, I notice that lines in *** DATA SET SUMMARY *** are wrapped after 84 columns (including carriage control), then padded with blanks to 121 characters. Why? What's the rationale for this behavior? Other sections of the same SYSPRINT use all 121 characters. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Page Data Set Sizes and Volume Types
My old ROT was 2-3x the real memory on the LPAR. Now that we can have 16, 32, 64GB partitions, we're talking some real DASD here. Multiply by 10. Two of our larger LPARs have 640GB each. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch Msgid Profile
IKJEFF10? snip Is there a Default table or exit that is/can be set for all batch submits, so it would work without entering the 'PROF MSGID WTPMSG'? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What are STC, JOB and TSU?
In CAFO-8toTThE4dNeA1xxZFRDByzWZts=m4sqst+6arue07gu...@mail.gmail.com, on 11/20/2014 at 01:49 PM, zMan zedgarhoo...@gmail.com said: Any guesses We don't need no stinking guesses. what STC *means*? Started Task Control. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Forbes article: Mainframe: Engine of Digital Transformation
http://www.forbes.com/sites/jasonbloomberg/2014/11/21/mainframe-engine-of-digital-transformation/ Thanks, Mark Regan, USNR-Ret, 1969-1991 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder SYSPRINT wrap?
That would be too easy. Many things seems to annoy the OP. Maybe there's a platform out there with fewer nits to pick. On Thu, Nov 20, 2014 at 3:25 PM, Charles Mills charl...@mcn.org wrote: Just to annoy you. Charles Sent from a mobile; please excuse the brevity Original message From: Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu Date:11/20/2014 9:57 AM (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Binder SYSPRINT wrap? Browsing a Binder SYSPRINT, I notice that lines in *** DATA SET SUMMARY *** are wrapped after 84 columns (including carriage control), then padded with blanks to 121 characters. Why? What's the rationale for this behavior? Other sections of the same SYSPRINT use all 121 characters. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder SYSPRINT wrap?
On Fri, Nov 21, 2014 at 1:52 PM, Don Imbriale don.imbri...@gmail.com wrote: That would be too easy. Many things seems to annoy the OP. Maybe there's a platform out there with fewer nits to pick. I think gil has more of a UNIX background. When you are used to truly long lines, the z/OS use of 121 or 132 byte print lines can be a real PITA. UNIX people are used to longer lines so that a logical entity is normally on just one line. This type of output is much easier to parse with normal UNIX utilities. I guess it's what you're used to. I, personally, have not actually printed _anything_ on paper for _years_. I keep my output in either sequential data sets or UNIX files. I prefer UNIX files, but I put stuff in data sets to be kind to others who view UNIX as something arcane and impossible to learn. -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Does z/OS V1R13 CSF support TLS v1.2?
I call gsk_attribute_set_enum(env_handle, GSK_PROTOCOL_TLSV1_2, GSK_PROTOCOL_TLSV1_2_ON) and get RC 701 Attribute identifier is not valid. The same code works on V2R1 so either the answer to my question is Yes, or else something is hosed up on my V1R13 system. I'd like to know which it is. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does z/OS V1R13 CSF support TLS v1.2?
For z/OS 1.13 there's a PTF. Sorry off hand I do not know it. On 11/21/2014 3:43 PM, Charles Mills wrote: I call gsk_attribute_set_enum(env_handle, GSK_PROTOCOL_TLSV1_2, GSK_PROTOCOL_TLSV1_2_ON) and get RC 701 Attribute identifier is not valid. The same code works on V2R1 so either the answer to my question is Yes, or else something is hosed up on my V1R13 system. I'd like to know which it is. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu To make an apple pie from scratch, you must first invent the universe. Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder SYSPRINT wrap?
On Fri, 21 Nov 2014 14:37:40 -0600, John McKown wrote: On Fri, Nov 21, 2014 at 1:52 PM, Don Imbriale wrote: That would be too easy. Many things seems to annoy the OP. Maybe there's a platform out there with fewer nits to pick. I think gil has more of a UNIX background. When you are used to truly long lines, the z/OS use of 121 or 132 byte print lines can be a real PITA. I understand that, but given that they've settled on 121, and use all 121 productively elsewhere in the SYSPRINT, wrapping at 84 in one section is plain stupidity. mit der Dummheit kämpfen Götter selbst vergebens -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder SYSPRINT wrap?
For the record let me say I was not dinging the OP for being a nitpicker. No such implication was intended. It just seemed that the question itself was unanswerable. I have a friend who used to be the systems programming manager for a large retailer. When his people would come to him with questions like why does the Binder wrap certain lines at 84 columns? he would say Let's split that question into two parts to make it simpler. Why? That's a question that philosophers have struggled with for years and have never come up with an answer. And does the Binder wrap certain lines at 84 columns? The answer to that question is Yes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Imbriale Sent: Friday, November 21, 2014 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Binder SYSPRINT wrap? That would be too easy. Many things seems to annoy the OP. Maybe there's a platform out there with fewer nits to pick. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder SYSPRINT wrap?
On Fri, 21 Nov 2014 13:51:14 -0800, Charles Mills wrote: For the record let me say I was not dinging the OP for being a nitpicker. No such implication was intended. It just seemed that the question itself was unanswerable. I have a friend who used to be the systems programming manager for a large retailer. When his people would come to him with questions like why does the Binder wrap certain lines at 84 columns? he would say Let's split that question into two parts to make it simpler. Why? That's a question that philosophers have struggled with for years and have never come up with an answer. And does the Binder wrap certain lines at 84 columns? The answer to that question is Yes. I think he was imitating Prof. Irwin Corey, the World's Foremost Authority. https://www.youtube.com/watch?v=RHlLmYVCzKY Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Page Data Set Sizes and Volume Types
On 21 Nov 2014 07:35:43 -0800, in bit.listserv.ibm-main you wrote: My old ROT was 2-3x the real memory on the LPAR. Now that we can have 16, 32, 64GB partitions, we're talking some real DASD here. Multiply by 10. Two of our larger LPARs have 640GB each. I didn't know that an individual instance could be that large. Without revealing any company secrets could you tell what combination of systems can use that much memory above the bar? Clark Morris Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: Page Data Set Sizes and Volume Types
Multiply by 10. Two of our larger LPARs have 640GB each. I didn't know that an individual instance could be that large. Without revealing any company secrets could you tell what combination of systems can use that much memory above the bar? Sure, there are not country secrets here. It's *real* storage we're talking about here. There are exceptions, but generally speaking, application code knows only about *virtual* storage. This is where you talk about addressing like below and above the line or the bar. Hardware maps virtual addresses to real addresses. How much *real* storage you can install and use is mainly dependent on hardware limitations and then on the operating system portion that is responsible for hardware storage, i.e the real storage manager (RSM). The fact that hardware and RSM can handle 640GB of *real*, doesn't imply there is a lot of above the bar *virtual* storage usage. Simplified example: Say you have 640 instances of a 31bit application active in parallel, each of which is aktively using 1GB of *below* the bar (virtual) storage. That's 640GB of virtual storage which needs to be backed by real storage to hold the data. If your system has got 64GB of *real* storage, then 90% of your applications data has to be paged out at any point in time. Your system will do a lot of paging. If your system has got 640GB of *real* storage, all of the application's data can be kept in real storage at the same time. The system won't page anymore. Aside from that, DF Sort and DB2 are two applications that I know are heavily using above the bar (virtual) storage instead of data space or hiperspace storage. DB2 permits itself to use 4TB of above the bar virtual (by overriding any MEMLIMIT, as I only recently learned). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Why is the System Data Sets book no longer deemed useful?
As the System Data Set Definition book hasn't been published in rather a long time ... Why is this? Isn't this a valuable book for those new to z/OS (and for us old guys with shrinking memories as well)? IBM makes us believe how serious they take it to get new people aboard on z/OS. Good, extensive documentation has aways be one strength of z/OS (and it predecesors). IBM should stop (silently) droping documentation. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
