Re: VLF caching
Peter, Yes, some confusion was caused by terminology: I regard VLF as the manager of the cache and the exploiters as doing 'caching', meaning giving an object to VLF to put it in its cache. Finally, the first and basic question of this thread was: -can I use VLF trimming statistics as a good measure to determine if my CSVLLA cache is large enough? -If not, what measure does tell me this, besides the LLAFETCH/PGMFETCH measures I get from CSVLLIX1/2? Besides all the information you do not wish to publish, this in my opinion is useful information worth publishing. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 30 November, 2014 16:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VLF caching Now, please put your wisdom in IBM books. I think that most of my post was discussing internal details that are not suitable for documentation (where by documenting them, customers and programmers are allowed to rely on them, which in turn may hamstring future desire to change). If there are particular pieces that would really help customers if we document them, I'll listen to requests for them (which should include at least a hint of how it will help). If LLA finds that a module that it had successfully gotten cached no longer is deemed worthwhile, it does not tell VLF. No? Why? Not having been involved in the initial implementation, I'm not sure. Perhaps it was felt that doing so would be overkill, that trimming would do a good enough job such that the overhead of doing the delminor was not worth the cycles. It also makes it less flexible -- if there are subsequent fetches, LLA might be able simply to mark its data as active and not have to re-cache the module. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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 Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copying sequential files - BSAM and QSAM
You should up your buffers (and NCP). Two will be spending a lot of time waiting. Just remember that after a CHECK shows EOF, you should not expect a valid status from the pending reads. On Fri, 28 Nov 2014 12:20:08 -0500 Sam Golob sbgo...@cbttape.org wrote: :Hi Folks, : : I was just involved in an exercise to improve an old file copying :program from CBT Tape File 316. It is called FFYCOPY, and it was :written in the mid-1970's by Frank Yates (courtesy of Jim Marshall). :This program's copy engine uses BSAM with double buffers, and for its :time, it was very fast, since BSAM (using the READ and WRITE macros) :deals with copying blocks of data instead of records. Of course, QSAM :(using the GET and PUT macros) is geared to copying records. : : Most sequential file copying programs use QSAM, because the :granularity is at the record level and not at the block level. But :if speed is a priority, BSAM, copying equal sized blocks to equal sized :blocks, can be an advantage. : : I'm not telling anybody here to give up the copying programs they :have been using (there are many of them out there), but this is for the :purpose of discussion, and I hope it helps somebody in the process :(maybe even me). : : FFYCOPY, being a very simply written program (except for the skill :in writing the engine), needs to have the output dataset having :identical RECFM, LRECL, and BLKSIZE to those of the input dataset. To :guarantee that, it simply overlays those attibutes in the output dataset :before OPENing it. This may get into problems if you're copying a :sequential dataset to a member of a pds. The copy does not reblock the :dataset (as it uses BSAM very simply), and the output pds can be messed :up. To avoid such problems, I put safeguards into FFYCOPY (see FFYCOPY :in File 316 on the Updates page of www.cbttape.org), so that if RECFM, :LRECL, or BLKSIZE don't match, the copy is not done. I also added a :SYSPRINT dataset to report status of what happened. And to force the :overlay of the attributes in the output dataset (as in the old version), :you can code PARM=O in the EXEC statement. : : I'd be interested in hearing if there are any issues nowadays in :copying BIG files FAST. Of course the world has progressed a lot in 40 :years (snicker), but I'd still like to hear some thoughts on the subject. : : Thanks much. All the best of everything to all of you. : :Sincerely,Sam : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zNALC Reporting Requirements
We've been approved for zOS zNALC licensing on some of our lpars, and I was asked to research the reporting requirements. Are there any requirements other than identifying these lpars as zNALC, and continue to report usage on the SCRT report? -- Mark Jacobs Time Customer Service Tampa, FL The standard you walk past is the standard you accept. Lt. Gen. David Morrison, Australian Army Chief -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zNALC Reporting Requirements
Mark, I would send an email to Al Sherkow and ask him. a...@sherkow.com Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Monday, December 01, 2014 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: zNALC Reporting Requirements We've been approved for zOS zNALC licensing on some of our lpars, and I was asked to research the reporting requirements. Are there any requirements other than identifying these lpars as zNALC, and continue to report usage on the SCRT report? -- Mark Jacobs Time Customer Service Tampa, FL The standard you walk past is the standard you accept. Lt. Gen. David Morrison, Australian Army Chief -- 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: Death of spinning disk?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples Sent: Friday, November 28, 2014 2:14 AM [ snip ] - smoke/vapor-based recording; I use the word recording here quite consciously. These recording systems could not be played back when they were invented and used. They were simply used for studying the general behavior and characteristics of sound waves. Now, thanks to digital processing -- high resolution digital scans of the smoke imprints combined with computer-based reconstruction of the audio that produced the imprints -- the information they contain can be recovered. That's how the world's oldest sound recordings are now being retrieved. Unfortunately Abraham Lincoln probably didn't speak into such a mechanism, or at least his recording was lost, so it's extremely unlikely a recording of his voice will ever be recoverable and playable. Might have been fun to hear Chopin and Liszt play Dueling Pianos :-) [ snip ] -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Death of spinning disk?
Chase, John wrote: Might have been fun to hear Chopin and Liszt play Dueling Pianos :-) Could be serious 'fun', hmmm! ;-) Serious music were played by musicians on toy pianos, see last paragraphs in this URL: http://en.wikipedia.org/wiki/Toy_piano Though originally made as a child's toy, the toy piano has been used in serious classical and contemporary musical contexts. ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Hillgang reminder
The next meeting is this Wednesday. The agenda and sign up instructions may be found at: http://www.vm.ibm.com/events/HILL1214.PDF We have a good number signed up already but still have space for more. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RES: SYSNAME command in SDSF and IOF
Mr. Kaptein, SDSF uses RMF to obtain information and display it in DA panel. As far as I remember, there is a way to obtain this info from your IOF Lpars, by loading in LPA some SDSF modules. There is an explanation in IBM-MAIN archives, I think from Mr. Mark Zelden, that I've tested and it worked. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4250 / DPCD Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 3684-2177 R: 42177 3-1402 Fax: +55 11 3684-4427 Banco Bradesco. Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016. -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de Fred Kaptein Enviada em: sexta-feira, 28 de novembro de 2014 19:54 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: SYSNAME command in SDSF and IOF We have nine systems running in a sysplex. All of them are z/OS V1.13 and all of them are JES2. The systems are called SYS1, SYS2, SYS3, SYS4, SYS5, SYS6, SYS7, SYS8 and SYS9 SYS1, SYS2, SYS3, SYS4, SYS5, SYS6 use IBM's SDSF to monitor jobs and the spool. SYS7, SYS8, SYS9 use a product called IOF from Fischer International to do the same thing. When entering the command SYSNAME * on SYS1, SYS2, SYS3, SYS4, SYS5, SYS6 we do not see any tasks running on SYS7, SYS8, SYS9. Does anyone know why we can not see tasks from SYS7, SYS8, SYS9 from any of the other systems? Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN AVISO LEGAL br...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. LEGAL ADVICEbr...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ptfs for a specific FMID
I installed a feature pack for CICS. It came as a separate FMID. We are having trouble making it work, so I wanted to make sure that we had the latest maintenance for it. That tells me why you want to install (APPLY) PTFs for a single FMID. It does not answer my question of why you feel it necessary to order and receive PTFs only for that FMID. At the risk of beating a dead horse, I'll say you are missing the point I and others are trying to make. You can order and RECEIVE all PTFs, but then you can install (APPLY) only the PTFs for the FMID you desire, using FORFMID on the APPLY. There is no harm in having PTFs in your global zone that you don't intend to install, yet. After all, you will have a maintenance cycle eventually, and you will need to APPLY those PTFs eventually, right? Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
In 8902901628988927.wa.paulgboulderaim@listserv.ua.edu, on 11/30/2014 at 11:51 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: Can this information be supplied from HLASM Yes. (but this would be harder for us to automate.) Why can't you pass the necessary variables through SYSPARM? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
In CAE1XxDHQB8Mn99LQZcydqGc5QHGPR5HJC-bNPmv0H==um7c...@mail.gmail.com, on 11/30/2014 at 01:19 PM, John Gilmore jwgli...@gmail.com said: AINSERT is then used to 'save' them, and AREAD is used to put them into the output. That's not even wrong! He needs a PUNCH or REPRO to get them into the output. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ptfs for a specific FMID
I was working on a specific product and *ONLY* wanted maintenance for that. Time and again I had to figure out all the pertaining PTF's and do a select(,,,,eee, etc etc) I did NOT want maintenance for other products to be recieved and applied. (I know I'm going to kick my self for responding, but...) Why didn't you want PTFs for other FMIDs received? What's the harm? You'll need them eventually, right? Because you will eventually update all the other FMIDs with service during a maintenance cycle, right? Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to clear console backlog.
Thank's BabyEklavaya.. On Sun, Nov 30, 2014 at 1:40 PM, baby eklavya baby.ekla...@gmail.com wrote: Issue K Q,L=consolename to clear the backlog To see the backlog information , issue D C,B and look out for NBUF value in the output On Sat, Nov 29, 2014 at 7:54 PM, Lizette Koehler stars...@mindspring.com wrote: I am not sure what you mean by backlog Is the console buffering? What do you see when you do a D C command? Can you show the D C command for that console? Have you looked at the K E command in the MVS Commands manual? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rajesh Kumar Sent: Saturday, November 29, 2014 7:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to clear console backlog. Hi all, May i know what is the command to clear the console backlog of particular system(lpar),we have 6 lpar but i wanted to deleted backlog of sysname=syd1 Please guide me. Regards, Rajesh -- 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: zNALC Reporting Requirements
If you have any mobile device transactions, you can work with your IBM account representative to get a discount for these transactions. On Mon, Dec 1, 2014 at 7:00 AM, Mark Jacobs mark.jac...@custserv.com wrote: We've been approved for zOS zNALC licensing on some of our lpars, and I was asked to research the reporting requirements. Are there any requirements other than identifying these lpars as zNALC, and continue to report usage on the SCRT report? -- Mark Jacobs Time Customer Service Tampa, FL The standard you walk past is the standard you accept. Lt. Gen. David Morrison, Australian Army Chief -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
Shmuel was, of course, entirely correct in saying that a PUNCH or REPRO statement is necessary to get them into the output; but this surpassingly obvious observation is not very interesting. The AINSERTs and AREADs are needed to sequence IDENTIFY binder control statements properly: They must follow the section---CSECT, RSECT, or labeled-common block---to which they refer; and great care is required in those situations in which sections are assembled in non-contrigtuous pieces, when, e.g., such constructions as |ALFACSECT | . . . |BETA CSECT | . . . |ALFACSECT | . . . are used, as I learned to to my sorrow on another occasion. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why is the System Data Sets book no longer deemed useful?
First, I can't resist saying that as it seems to have taken a full decade for members of this group to perceive a significant lack, it seems the decision to drop the book was a good one! That aside, the vast majority of customers install z/OS using ServerPac. ServerPac, in turn, provides far more information about data set allocation and data set requirements than System Data Set Definition ever did, and does so for other products' data sets that were never described by that book in the first place. It even does it in a way that allows you to generate and save lists of interesting data sets, including those required or eligible for LPA, link list, and APF. Samples to allocate them all can be extracted from the ALLOCDS job you saved in the SCPPBENU data set (you did do that, right?) or can re-generate if needed, and they are kept 100% current with product content and tested every time a new product is added to the ServerPac ordering checklist. For z/OS itself, the z/OS Program Directory includes detailed information about data set attributes and sizes required for installation. The other data sets needed to run the system are, for the most part*, documented in various books, as should be true for other products you might have (such as DB2, CICS, and IMS). That the allocation information for the STGINDEX data set happens not to be documented was an unfortunate oversight. I've already asked someone to fix that. * I'd have said all, once, but since we know we missed one, I won't. -- John Eells (back from a week off) z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
On Sun, 30 Nov 2014 19:32:45 -0500, Shmuel Metz (Seymour J.) wrote: at 11:51 AM, Paul Gilmartin said: Can this information be supplied from HLASM Yes. Can it be more straightforward than JWG's suggestion? (but this would be harder for us to automate.) Why can't you pass the necessary variables through SYSPARM? That might require editing every source file (of hundreds) to parse and elaborate SYSPARM. (In fact, it might be necessary only to edit a common header macro.) OTOH, we're already digesting SYSLIN to generate CSECT parameters for SMP/E ++MOD MCS. It would be quite natural to append Binder IDENTIFY commands at that point. But I believe SMP/E doesn't recognize Binder commands appearing in SYSLIN. -- 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?
Or possibly when the precursor to the binder was developed that long ago, whoever wrote this section figured with a 44 character DSN being the longest available, they padded it with 20 bytes to make sure it was plenty long. Then when Unix-style path names came along later, whoever added the path capability decided to not increase the length in order to not take a chance at breaking anything? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, November 22, 2014 6:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Binder SYSPRINT wrap? Gil mentioned the DATA SET SUMMARY section. I presume his use involved the file system. For a data set, the lines in that section would not come close to reaching column 84. For example, DDNAMECONCAT FILE IDENTIFICATION LPALIB 01 SYS1.LPALIB SYSOBJS 02 TESTUSER.OBJS I would guess that many who read the append did not realize that the original post related to presentation of a long path name. I know that I did not. Regardless, for whatever reason, when the binder was developed going on 25 years ago someone implemented put 64 columns of path name info per line. Maybe they thought that was a reasonable amount, maybe they wanted a power of two; I have no idea. This has apparently not been an issue to anyone. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why is the System Data Sets book no longer deemed useful?
Hi John, I have seen and used the ServerPac resources you mentioned and found them very helpful and useful. What about the majority who do not have access to ServerPac? With role based security these days, many, perhaps most, do not have access. Thanks, Linda Sent from my iPhone On Dec 1, 2014, at 8:22 AM, John Eells ee...@us.ibm.com wrote: First, I can't resist saying that as it seems to have taken a full decade for members of this group to perceive a significant lack, it seems the decision to drop the book was a good one! That aside, the vast majority of customers install z/OS using ServerPac. ServerPac, in turn, provides far more information about data set allocation and data set requirements than System Data Set Definition ever did, and does so for other products' data sets that were never described by that book in the first place. It even does it in a way that allows you to generate and save lists of interesting data sets, including those required or eligible for LPA, link list, and APF. Samples to allocate them all can be extracted from the ALLOCDS job you saved in the SCPPBENU data set (you did do that, right?) or can re-generate if needed, and they are kept 100% current with product content and tested every time a new product is added to the ServerPac ordering checklist. For z/OS itself, the z/OS Program Directory includes detailed information about data set attributes and sizes required for installation. The other data sets needed to run the system are, for the most part*, documented in various books, as should be true for other products you might have (such as DB2, CICS, and IMS). That the allocation information for the STGINDEX data set happens not to be documented was an unfortunate oversight. I've already asked someone to fix that. * I'd have said all, once, but since we know we missed one, I won't. -- John Eells (back from a week off) z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- 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: zNALC Reporting Requirements
Thanks Bob. Mark: You need to mark the LPAR, which most sites now do with IEASYSXX, LICENSE=zNALC. SCRT will take care of the rest. You still need to audit SCRT and the resultant invoices you receive from IBM. You also need to apply for zNALC annually, which entails updating your original zNALC paperwork and recertifying that the LPARs still qualify for zNALC. Regards, Al -- Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on IBM Workload License Charges (WLC), Seminars on IBM Mainframe Software Pricing +1 414 332-3062 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ptfs for a specific FMID
On Dec 1, 2014, at 8:41 AM, Kurt Quackenbush wrote: Kurt: We wanted to bring RACF to the latest level without the other acruttumonts(sp?) so w just wanted to receive maintenance for RACF. We had an issue and level 2 want ptf X on and x was in the the group of PTFS that we wanted to order from IBM but did not want to apply the who mess . Ed That tells me why you want to install (APPLY) PTFs for a single FMID. It does not answer my question of why you feel it necessary to order and receive PTFs only for that FMID. At the risk of beating a dead horse, I'll say you are missing the point I and others are trying to make. You can order and RECEIVE all PTFs, but then you can install (APPLY) only the PTFs for the FMID you desire, using FORFMID on the APPLY. There is no harm in having PTFs in your global zone that you don't intend to install, yet. After all, you will have a maintenance cycle eventually, and you will need to APPLY those PTFs eventually, right? Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ptfs for a specific FMID
Kurt: We didn't have the DASD space at the time (we needed a few extra volumes for maintenance and they were being used by another application). We were in a DASD constrained environment. Ed On Dec 1, 2014, at 8:49 AM, Kurt Quackenbush wrote: I was working on a specific product and *ONLY* wanted maintenance for that. Time and again I had to figure out all the pertaining PTF's and do a select(,,,,eee, etc etc) I did NOT want maintenance for other products to be recieved and applied. (I know I'm going to kick my self for responding, but...) Why didn't you want PTFs for other FMIDs received? What's the harm? You'll need them eventually, right? Because you will eventually update all the other FMIDs with service during a maintenance cycle, right? Kurt Quackenbush -- IBM, SMP/E Development -- 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: Why is the System Data Sets book no longer deemed useful?
Once the data sets have all been allocated for the first time, for most things you can model after one that exists and tweak as needed. But for formal documentation, people without READ access to the ServerPac data sets *should* be able to find allocation information for individual data sets in other places. It's just not all together in one place. If a particular data set's information is missing--as is currently the case for STGINDEX--please submit an RCF! (As a side note, I'd hope--perhaps in vain--that people in sysprog roles who share responsibility for products installed with ServerPac share at least READ access to the associated ServerPac data sets even in a role-based security model environment. They surely have a need to know what they contain to fulfill their roles. But when I was a sysprog my batting average vs. security auditors was probably less than .500, so what do I know?) However, let's take a step back. Looking at the TOC for the SDSD book (http://publibfp.dhe.ibm.com/epubs/pdf/iea2g500.pdf), I find that, if I counted correctly, it then described 62 data sets. Four are likely obsolete. There are well over 1,000 target libraries and operational data sets associated with a z/OS system. If the book existed now in its older form, it would represent less than 10% of the total (and perhaps less than 5%). linda.lst...@comcast.net (Linda) wrote: Hi John, I have seen and used the ServerPac resources you mentioned and found them very helpful and useful. What about the majority who do not have access to ServerPac? With role based security these days, many, perhaps most, do not have access. snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Death of spinning disk?
Miles Davis biographer and producer said while they were outlining Man with a Horn(album) Miles had his kids piano and was banging out ideas, but only about half the keys worked. He could hear them in his vision, but for mere mortals it was difficult to comprehend. In a message dated 12/1/2014 7:38:11 A.M. Central Standard Time, elardus.engelbre...@sita.co.za writes: Though originally made as a child's toy, the toy piano has been used in serious classical and contemporary musical contexts. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List mail being marked as spam
On 30 November 2014 at 20:33, Graham Harris harris...@gmail.com wrote: I setup a filter in gmail to send all IBM-MAIN stuff to its own folder (or label?), and my experience is that nothing (IBM-MAIN-wise) then gets sent to spam - the filter overrides it. Unfortunately it doesn't override the many legitimate IBM-MAIN postings that Gmail marks as Phishing. And it's clear that, despite the claim, Gmail does not learn from the hundreds of such posts -- often from the same small group of people -- that I've lovingly marked as Not Phishing. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List mail being marked as spam
Gmail could, in the sense that it is within Google's technical capacity, deal with this problem. It has instead elected to discover that characteristic, long-standing LISTSERV behavior is a species of 'phishing'. This position has no technical merit. It is, I suppose, convenient; but it opens Google to suspicions of low-level venality that may well be totally absent. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XMIT-Manager is now installable on 64-bit Windows
Hi Folks, For those of you who wish to install XMIT-Manager (originally from Neal Johnston-Ward) on 64-bit Windows systems, there is a version of it which was modified by Robert A.H. Prins to install there. I had placed this version on File 916 of the CBT Tape, but it needs a mainframe to load it up to, and then to FTP down to a PC. (At least I archived the thing so it wouldn't disappear. Robert had originally put it on the files of H390-MVS on yahoogroups, but things don't stay there forever as more files are loaded up) Anyway, I made an attempt to make this package available on the www.cbttape.org website, maybe not in the best manner, but I myself was able to install it from there on a 64-bit Windows system. How do you get it? Go to www.cbttape.org, and click on XMIT-Manager at the upper left side of the screen. Look at the resulting screen. Notice that I replaced the defunct UK download site for XMIT-Manager-V3, with a link to this program that says XmitMgr-64bit. Just click on that link to download it, unzip, point to Xmit Manager.exe and run it. Maybe I will polish this up later, or Sam K will, but at least it's out there now for people to access and use. All the best of everything to all of you... Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why is the System Data Sets book no longer deemed useful?
Hi John, It is management that approves access - or not! And if IBM packs documentation that appears to be only for the installer, that is who it is for, paraphrasing here. sigh. Just the way it is. Linda Sent from my iPhone On Dec 1, 2014, at 12:03 PM, John Eells ee...@us.ibm.com wrote: Once the data sets have all been allocated for the first time, for most things you can model after one that exists and tweak as needed. But for formal documentation, people without READ access to the ServerPac data sets *should* be able to find allocation information for individual data sets in other places. It's just not all together in one place. If a particular data set's information is missing--as is currently the case for STGINDEX--please submit an RCF! (As a side note, I'd hope--perhaps in vain--that people in sysprog roles who share responsibility for products installed with ServerPac share at least READ access to the associated ServerPac data sets even in a role-based security model environment. They surely have a need to know what they contain to fulfill their roles. But when I was a sysprog my batting average vs. security auditors was probably less than .500, so what do I know?) However, let's take a step back. Looking at the TOC for the SDSD book (http://publibfp.dhe.ibm.com/epubs/pdf/iea2g500.pdf), I find that, if I counted correctly, it then described 62 data sets. Four are likely obsolete. There are well over 1,000 target libraries and operational data sets associated with a z/OS system. If the book existed now in its older form, it would represent less than 10% of the total (and perhaps less than 5%). linda.lst...@comcast.net (Linda) wrote: Hi John, I have seen and used the ServerPac resources you mentioned and found them very helpful and useful. What about the majority who do not have access to ServerPac? With role based security these days, many, perhaps most, do not have access. snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ptfs for a specific FMID
On Mon, 1 Dec 2014 13:49:37 -0600, Ed Gould wrote: We didn't have the DASD space at the time (we needed a few extra volumes for maintenance and they were being used by another application). We were in a DASD constrained environment. Is there a further performance concern in that if the user wants to APPLY a single PTF (plus what GROUPEXTEND brings along), the user will spend network bandwidth to download everything; CPU cycles to un-pax everything; space in SMPNTS and SMPWKDIR; and more CPU cycles to pass a needlessly large SMPPTFIN? (All assuming the customer is in a hurry for an urgent PTF and is willing to defer the other stuff until later.) Beyond those performance concerns, APPLY SELECT() GROUPEXTEND should suffice. Some years ago, a contributor to this list used the notion of The Great SMPPTS in the Sky, his vision being that APPLY should access that cloud and transfer and unpack only the PTFs needed according to SELECT() GROUPEXTEND. The RECEIVE command, a relic of tape processing, would simply vanish. It remains an unfulfilled wish. On Dec 1, 2014, at 8:49 AM, Kurt Quackenbush wrote: (I know I'm going to kick my self for responding, but...) Why didn't you want PTFs for other FMIDs received? What's the harm? You'll need them eventually, right? Because you will eventually update all the other FMIDs with service during a maintenance cycle, right? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XMIT-Manager is now installable on 64-bit Windows
Thanks Sam. It works fine on my 64-bit Windows 8 laptop. Sam Golob wrote: Hi Folks, For those of you who wish to install XMIT-Manager (originally from Neal Johnston-Ward) on 64-bit Windows systems, there is a version of it which was modified by Robert A.H. Prins to install there. I had placed this version on File 916 of the CBT Tape, but it needs a mainframe to load it up to, and then to FTP down to a PC. (At least I archived the thing so it wouldn't disappear. Robert had originally put it on the files of H390-MVS on yahoogroups, but things don't stay there forever as more files are loaded up) Anyway, I made an attempt to make this package available on the www.cbttape.org website, maybe not in the best manner, but I myself was able to install it from there on a 64-bit Windows system. How do you get it? Go to www.cbttape.org, and click on XMIT-Manager at the upper left side of the screen. Look at the resulting screen. Notice that I replaced the defunct UK download site for XMIT-Manager-V3, with a link to this program that says XmitMgr-64bit. Just click on that link to download it, unzip, point to Xmit Manager.exe and run it. Maybe I will polish this up later, or Sam K will, but at least it's out there now for people to access and use. All the best of everything to all of you... Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
In CAE1XxDG4NRGnr2hk-=cdsgdxqs1nuv7ucbru4ntyy_ebkmx...@mail.gmail.com, on 12/01/2014 at 11:18 AM, John Gilmore jwgli...@gmail.com said: surpassingly obvious It should have been obvious *before* you incorrrecvtly described the roles in AINSERT and AREAD. The AINSERTs and AREADs are needed to sequence IDENTIFY binder control statements properly: No, although it is certainly possible that you wrote something with convoluted logic that works that way. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ptfs for a specific FMID
The problem I had with it was that there doesn't seem to be any way to order maintenance for an FMID (or product) until *after* it has been applied. I would have much preferred to have applied all maintenance along with the FMID, particularly since there were ++IFREQs against the FMID that wanted to prevent us from applying the FMID without the PTFs that we couldn't get until after the FMID had been applied, but couldn't be with out the PTFs that couldn't be obtained until after the apply, which couldn't be done until... etc. Tim Henness Newport News Shipbuilding On 12/1/2014 9:41 AM, Kurt Quackenbush wrote: That tells me why you want to install (APPLY) PTFs for a single FMID. It does not answer my question of why you feel it necessary to order and receive PTFs only for that FMID. At the risk of beating a dead horse, I'll say you are missing the point I and others are trying to make. You can order and RECEIVE all PTFs, but then you can install (APPLY) only the PTFs for the FMID you desire, using FORFMID on the APPLY. There is no harm in having PTFs in your global zone that you don't intend to install, yet. After all, you will have a maintenance cycle eventually, and you will need to APPLY those PTFs eventually, right? Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ptfs for a specific FMID
On Tue, 2 Dec 2014 00:04:50 -0500, Tim Henness wrote: The problem I had with it was that there doesn't seem to be any way to order maintenance for an FMID (or product) until *after* it has been applied. I would have much preferred to have applied all maintenance along with the FMID, particularly since there were ++IFREQs against the FMID that wanted to prevent us from applying the FMID without the PTFs that we couldn't get until after the FMID had been applied, but couldn't be with out the PTFs that couldn't be obtained until after the apply, which couldn't be done until... etc. RECEIVE and APPLY are two separate operations with different rules. So: RECEIVE the FUNCTION(s) RECEIVE the PTFs and HOLDDATA APPLY SELECT(FMID(s)) GROUPEXTEND. (or, does shopZ actually preclude that, as you seem to be saying. That would be a defect, perhaps not APARable, but at least subject to RFE or Requirement. For a properly designed shopZ, it should suffice to have the FMID in the GLOBAL zone; no requirement for its presence in the TZONE.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyzMAIL/z new features
That's my point, SyzSPOOL/z already does just that, and to add the capability to SyzMPF/z would place it in competition with our own product. Besides, getting the STEP and MAX condition codes with the runtime details is useful, but to send the entire job just because we can seems to be overkill. Especially in an Abend situation, who really wants 100,000+ lines of SYSABEND information when all they really want is to know that it abended and what the codes were. I can see sending the message log, or JCL log, but the entire job (which would be much easier than trying to separate the individual SYSOUTs) would really just tie up the email pipeline. Do you agree? Thanks for the info though, it is indeed far easier to send the whole job than to pick out individual sysouts. Brian On Mon, 1 Dec 2014 01:39:24 -0600, Mike Schwab mike.a.sch...@gmail.com wrote: I would say if they want more than the three system files you just send them the whole job. On Mon, Dec 1, 2014 at 1:25 AM, Brian Westerman brian_wester...@syzygyinc.com wrote: Hi, We had several user requests (at least 200) for the automatic StepCC/MaxCC eMail/SMS text product to allow the JES system datasets to be attached to the email, so that besides the stepCC's and MaxCC, the user can receive any or all of the JESJCL, JESMSGLG, and JESYSLG as attachments. I added that code and also added the ability to send JESJCLIN (the input JCL) even though I can't see a reason why anyone would normally want/need it. As a result of that extra little bit of coding, we had a meeting here and I was asked to (also) add the ability to send regular SYSOUT and even non-related files (sequential, PDS, VSAM, etc.) in the next release. I fought it as being absurd and beyond the scope of the product. Sending the JES system datasets was fairly simple because they have (sort of) static names, but the actual SYSOUT requires a bit more programming to derive and send, not to mention the effort required on the client's part to tell us (definitively) what they want sent in the way of other data. They (our client support) sent a query out to our client base and got back several hundred replies of Sure, and sounds good, but no one really had a good reason to get the SYSOUT or other datasets automatically that would make sense with respect to the programming effort. We already Send any datasets they want via email from our SyzSPOOL/z product (the spool manager) and it makes sense to do it there because we have much more control over what we are looking at on a job by job basis, and we can send it in usable formats (like PDF, Word, wtc.) but for the End-of-task MaxCC stuff, we really don't know (or care) about what SYSOUT might actually be there, and we sure can't be formatting SYSOUT on the fly. I'm okay with sending the JES system data, because the console messages and JCL resolution, etc. makes sense with respect to keeping track of what happened and maybe why a task got the condition codes it did, especially with an ABEND, but turning the product into a spool delivery product when we already have one seems to be counter-productive. I'm ready to stand firm on this, but over the holiday I have been thinking that I could be just being stubborn (or lazy) for no good reason, and as I respect what you guys think I wondered how you might look at this request? Brian Westerman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
At 11:18 -0500 on 12/01/2014, John Gilmore wrote about Re: SMP/E and IDR (was: Binder SETSSI ...?): Shmuel was, of course, entirely correct in saying that a PUNCH or REPRO statement is necessary to get them into the output; but this surpassingly obvious observation is not very interesting. The AINSERTs and AREADs are needed to sequence IDENTIFY binder control statements properly: They must follow the section---CSECT, RSECT, or labeled-common block---to which they refer; and great care is required in those situations in which sections are assembled in non-contrigtuous pieces, when, e.g., such constructions as |ALFACSECT | . . . |BETA CSECT | . . . |ALFACSECT | . . . are used, as I learned to to my sorrow on another occasion. Everyone is forgetting/ignoring the need for these commands to occur AFTER the end of the object deck. IOW: If I am in in JCL I would reference the Object Deck and then do a DD * to insert the commands. While you can use a PUNCH to generate the command during assembly there is no way (to my knowledge) to do DEFERRED PUNCH (ie: For the PUNCH output to be queued and then flushed once the END statement has been processed). The closest method I can think of is to make the assembly a BATCH assembly where the first input is the actual code and the 2nd is the set of PUNCH Statements. IOW: CSECT . . . END PUNCH . . PUNCH John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
