Reviewing hardware configuration
Hi, I was asked to review our hardware configuration: How many CP’s, logical and physical, are assigned to each partition Capping and capacity settings. Where would be the best place to read about these settings and how to determine the best ones for our configuration. Thanks Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TPUT under TEST
On Tue, 19 Nov 2013 22:03:47 -0500 Micheal Butz michealb...@optonline.net wrote: :Hi : :I am running a command processor :Using TPUT processing 3270 data :Full screen mode : :Under TSO TEST is there anyway to :Get output from TPUT displayed When doing full screen you have to be sensitive to the RESHOW key (typically) PA2 and if you see it know that you have to reissue the previous TPUT. The SYSTEM automatically provides the reshow key when there is the *** at the bottom of the screen (due to out of line messages). So if you have a breakpoint of the TPUT and before the TGET you will go out of line and when you do the GO the TGET will get the reshow. Which will get you in a loop until you remove the breakpoint. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Callable Assembler Services
L R1,16 CVT POINTER L R1,0(R1) TCB TABLE L R1,4(R1) OWN TCB FWIW, the above sequence hasn't been necessary for probably 25+ years (it does still work). Instead L R1,X'21C'(0,0)PSATOLD, address of this TCB Similarly, PSAAOLD for the ASCB. By the way, using the form that loads the CVT pointer (or TCB pointer, etc) with (0,0) or (,0) will avoid a warning from the assembler's flag(page0). We have found that option to be very useful. 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
New and improved V2R1 manuals (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Hello List, I have been scanning the manuals associated with z/OS V2R1 and have noticed the following in those I've seen: 1) Summary of changes at the beginning of the manual has been deleted and replaced by a reference to other manuals 2) The vertical bars in the left margin that denote changes no longer appear (e.g. JCL Reference: description of EXPORT statement and SYMBOLS keyword on DD statement). If this is a permanent improvement, I shall miss them. Alan Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New and improved V2R1 manuals (UNCLASSIFIED)
Perhaps because it is a new version all that stuff starts over. Just a guess. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Storr, Lon A CTR USARMY HRC (US) lon.a.storr@mail.mil To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/20/2013 09:10 Subject:New and improved V2R1 manuals (UNCLASSIFIED) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Classification: UNCLASSIFIED Caveats: NONE Hello List, I have been scanning the manuals associated with z/OS V2R1 and have noticed the following in those I've seen: 1) Summary of changes at the beginning of the manual has been deleted and replaced by a reference to other manuals 2) The vertical bars in the left margin that denote changes no longer appear (e.g. JCL Reference: description of EXPORT statement and SYMBOLS keyword on DD statement). If this is a permanent improvement, I shall miss them. Alan Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Callable Assembler Services
I have found out that the documentation is poor. This sequence of Instructions is correct. L 15,16 CVT - common vector table L 15,544(15) CSRTABLE L 15,24(15) CSR slot L 15,offset(15) Address of the service BALR 14,15 Branch and link The issue with the Reason Code has to do with the setting of the MSG_TYPE. The documentation does not expalin it well enough that the MSG_ID returned from BXP1QGT needs to be stored in the MSG_TYPE field prior to the MSG_TEXT before issuing BPX1QSND. I can noe WRITE and RED from the queue. Thanks To All Who responded. Paul D'Angelo -- Original Message -- From: Tony Harminc t...@harminc.net To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: USS Callable Assembler Services Date: Mon, 18 Nov 2013 15:17:59 -0500 On 18 November 2013 14:36, esst...@juno.com esst...@juno.com wrote: Tom Marchant and others pointed out I don't have an answer to your questions, but I think you mean LA 15,16 And I agree, However From z/OS UNIX System Services Programming: Assembler Callable Services Reference SA23-2281-00 The following is an example of code that specifies the offset. The example assumes that register 1 is set up with the address of the parameter list. Replace offset with the appropriate value from the following offset table. L 15,16 CVT - common vector table L 15,544(15) CSRTABLE L 15,24(15) CSR slot L 15,offset(15) Address of the service BALR 14,15 Branch and link I suspect the documentation is wrong It's not wrong, and changing L to LA would break what you have. You could indeed use the IHAPSA and CVT macros and avoid use of hard-coded constants, but the problem with this is that the CSRTABLE and what it points to are OCO, so there are no IBM-supplied mappings or names. I wrote a little macro that contains roughly what you show above. It takes the service name as an argument and generates the call with the offset and arguments. There are other services reached through the CSRTABLE with offsets other than 24; some of them are documented to various extents, and others not at all. Tony H. -- 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: New and improved V2R1 manuals (UNCLASSIFIED)
Agreed. The new summary of changes is darned near useless. The old version was a huge asset. Sigh. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Storr, Lon A CTR USARMY HRC (US) Sent: Wednesday, November 20, 2013 6:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: New and improved V2R1 manuals (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Hello List, I have been scanning the manuals associated with z/OS V2R1 and have noticed the following in those I've seen: 1) Summary of changes at the beginning of the manual has been deleted and replaced by a reference to other manuals 2) The vertical bars in the left margin that denote changes no longer appear (e.g. JCL Reference: description of EXPORT statement and SYMBOLS keyword on DD statement). If this is a permanent improvement, I shall miss them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Callable Assembler Services
Copying MSG_TYPE from the get to the send message is not necessarily correct. It is an arbitrary positive number that MSGSND sends to the receiver. The receiver may use this information any way it desires. It is simply a standard. E.g. Think about MVS SMF record types. Everyone agree's on the values and how they will be used. MSG_TYPE is similar but each queue may have it's own meaning for the values that it represents.. When using the MVS interfaces to UNIX functionality, you should also look at the UNIX documentation for the UNIX version of the interface. That documentation is heavily used and more complete because of usage. In this case, you would immediately see a structure that contains the TYPE and message where as MVS gives you an IMPORTANT note that says the TYPE is the first word preceding the message. The MVS versions simply don't get enough use and users often already know the functionality from using the UNIX version. Jon Perryman. From: esst...@juno.com esst...@juno.com The issue with the Reason Code has to do with the setting of the MSG_TYPE. The documentation does not expalin it well enough that the MSG_ID returned from BXP1QGT needs to be stored in the MSG_TYPE field prior to the MSG_TEXT before issuing BPX1QSND. I can noe WRITE and RED from the queue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
In 4562813219550940.wa.mathwstittbellsouth@listserv.ua.edu, on 11/19/2013 at 04:52 PM, Matthew Stitt mathwst...@bellsouth.net said: DB2 does not release PTFs on a Level Set basis. Who said anything about level sets? What should be a standard operating procedure is to order and receive PTFs on a daily basis. Why? You can download them when you want to do an APPLY, and automatically get the most recent hold data. When an Apply is done, any PTFs which are marked as being in error will not be Applied. So? That doesn't help if the error is not discovered until after you do the APPLY. -- 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: TPUT under TEST
Thanks Sent from my iPhone On Nov 20, 2013, at 7:09 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: On Tue, 19 Nov 2013 22:03:47 -0500 Micheal Butz michealb...@optonline.net wrote: :Hi : :I am running a command processor :Using TPUT processing 3270 data :Full screen mode : :Under TSO TEST is there anyway to :Get output from TPUT displayed When doing full screen you have to be sensitive to the RESHOW key (typically) PA2 and if you see it know that you have to reissue the previous TPUT. The SYSTEM automatically provides the reshow key when there is the *** at the bottom of the screen (due to out of line messages). So if you have a breakpoint of the TPUT and before the TGET you will go out of line and when you do the GO the TGET will get the reshow. Which will get you in a loop until you remove the breakpoint. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
At 00:28 -0500 on 11/20/2013, Shmuel Metz (Seymour J.) wrote about Re: When should we ACCEPT DB2 PTFs?: When an Apply is done, any PTFs which are marked as being in error will not be Applied. So? That doesn't help if the error is not discovered until after you do the APPLY. I agree. It bites you when it is time to do the ACCEPT. One way to handle the already APPLY'ed and now PE PTF issue is to periodically pull the HOLD Data and do an ACCEPT CHECK. That would flag/indicate a PTFs in this state. You can then pull the designated fix PTFs (or APARs) if they exist and APPLY them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
