Re: Rexx and member statistics question
Ze'ev Atlas wrote: >I have to take it back >In one of the libraries, I consistently have an empty line as the first line >and I did do some of my tests on that library. This is WAD. You read something empty, then REXX processes stops. >Mystery resolved! Good! One riddle solved in 2015! ;-) Anyways, I don't believe member stats have any influence in reading and writing of members in PDS. In fact, I have several REXX programs in Batch Jobs reading/writing members as generated by IEBGENER for example (which caused no member stats to be written at all, since AFAIK, IEBGENER does not update member stats) AFAIK, Member stats are ONLY used by ISPF and other products (if they are designed to do that stats). PS: I don't have any access to my z/OS toy for now... so above is based on my faulty decaying memory... 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
Re: IXGLOGR on RSM usage
I'm not aware, but that doesn't mean there isn't! I seem to remember the page fixing (RSM use) for logstream mode SMF being specific to SMF's use of dataspaces and not necessarily System Logger's real storage use itself. There may have been something in the SMF Logstream Redbook that made me think that. Andrew -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nathan Astle Sent: 30 December 2015 18:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IXGLOGR on RSM usage Hi Andrew Thank you for the pointer which helped me in tuning up the SMF logstream. So when it comes to other logstream structures for DB2,CICS. Is there a way to limit their RSM usage as well ? Nathan On Wednesday 23 December 2015, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Andrew Metcalfe wrote: > > >Do you have SMF in Logstream mode? > > The OP said he has SMF in Logstream in thread 'Re: S00C Slip trap for > any Stc'. > > He wrote: "Our SMF logstream has been defined in IXGLOGR with dasdonly. " > > > >If so how many logstreams are defined? Each logstream has its own > dataspace/buffers. There are some parameters which govern > Logstream/SMF real storage requirements that you may need to tune. > > Good questions. Thanks for asking. > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx and member statistics question
On Thu, 31 Dec 2015 09:05:20 +0200, Itschak Mugzach wrote: >You might have blanks lines in input. Stem . It stops the writing of the stem >to dataset. Try changing null lines to blanks. > No! If the programmer's intent is to copy a file unchanged, the programmer shouldn't change the content of any line. On Thu, 31 Dec 2015 03:20:32 -0600, Elardus Engelbrecht wrote: > >This is WAD. You read something empty, then REXX processes stops. > It does not; it faithfully creates a corresponding empty item in the input STEM. >Anyways, I don't believe member stats have any influence in reading and >writing of members in PDS. In fact, I have several REXX programs in Batch Jobs >reading/writing members as generated by IEBGENER for example (which caused no >member stats to be written at all, since AFAIK, IEBGENER does not update >member stats) > For example, NFS, and perhaps FTP, update member stats. Why do people have such cognitive dissonance with the concept of empty records? Ever since the advent of Arabic numerals, zero has been recognized as a valid number. Or should be. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
So Long, and Thanks For All The Fish
Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So Long, and Thanks For All The Fish
An this as well - http://www.theregister.co.uk/2015/12/30/ian_murdock_debian_founder/ Message d'origine De : Shane Ginnane À : IBM-MAIN@LISTSERV.UA.EDU Objet : So Long, and Thanks For All The Fish Date : 31/12/2015 15:47:04 CET Shane ... -- 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: So Long, and Thanks For All The Fish
That is a devastating loss. And sounds like bizarre circumstances-yet to get all the details. > On Dec 31, 2015, at 09:00, Andre Massena wrote: > > An this as well - > http://www.theregister.co.uk/2015/12/30/ian_murdock_debian_founder/ > > > > > Message d'origine > De : Shane Ginnane > À : IBM-MAIN@LISTSERV.UA.EDU > Objet : So Long, and Thanks For All The Fish > Date : 31/12/2015 15:47:04 CET > > Shane ... > > -- > 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: So Long, and Thanks For All The Fish
Best of luck Shane - enjoy your time, and don't think twice about us lot still slaving over z/OS ;-) -Original Message- From: Shane Ginnane To: IBM-MAIN Sent: Thu, 31 Dec 2015 9:47 Subject: So Long, and Thanks For All The Fish Shane ... -- 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: So Long, and Thanks For All The Fish
Best of luck Shane, and enjoy life. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Thursday, December 31, 2015 9:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: So Long, and Thanks For All The Fish Shane ... -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Sample Programs for WebSphere MQ for z/OS V8.0.0?
Hello, I am looking for a sample program for MQ. I can find a lot of CICS COBOL samples for programs that prompt and get back text. For MQ I found the examples in the Application Programming Guide, but it looks like they are batch jobs. One will connect, but a different one disconnects. Q). Is there a sample program for MQ that is a CICS online program instead of MQ batch? I'd take Assembler if there is a good example (they don't even load the sample libraries for Assembler here). Thanks to everybody for all there help through the year, Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So Long, and Thanks For All The Fish
Best wishes Shane. Your wit and your knowledge will be missed. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So Long, and Thanks For All The Fish
Apologies to Shane I hadn't read beyond the first reply. Best sir. > On Dec 31, 2015, at 09:58, Bigendian Smalls > wrote: > > That is a devastating loss. And sounds like bizarre circumstances-yet to get > all the details. > >> On Dec 31, 2015, at 09:00, Andre Massena wrote: >> >> An this as well - >> http://www.theregister.co.uk/2015/12/30/ian_murdock_debian_founder/ >> >> >> >> >> Message d'origine >> De : Shane Ginnane >> À : IBM-MAIN@LISTSERV.UA.EDU >> Objet : So Long, and Thanks For All The Fish >> Date : 31/12/2015 15:47:04 CET >> >> Shane ... >> >> -- >> 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: So Long, and Thanks For All The Fish
https://www.youtube.com/watch?v=N_dUmDBfp6k Shane, Good luck in all your endeavors! I leave you with the following response: https://www.youtube.com/watch?v=SJUhlRoBL8M Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Thursday, December 31, 2015 9:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: So Long, and Thanks For All The Fish Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So Long, and Thanks For All The Fish
Good Luck to you Shane Bob Longabaugh CA Technologies Storage Management -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Thursday, December 31, 2015 3:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: So Long, and Thanks For All The Fish https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DN-5FdUmDBfp6k&d=CwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=o2gVjNZ9TdK6lLWT_C1wblxP02_yu_2JweU5e56_KLo&s=ldI_LXEDIHmJJS1V-vNMiGV9tPTxaHL7aHIORSCXuvI&e= Shane, Good luck in all your endeavors! I leave you with the following response: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DSJUhlRoBL8M&d=CwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=o2gVjNZ9TdK6lLWT_C1wblxP02_yu_2JweU5e56_KLo&s=MlaQgklrm1EvKcYockXbax4dC9Edh9WpUzqaYbl7F-Q&e= Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Thursday, December 31, 2015 9:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: So Long, and Thanks For All The Fish Shane ... -- 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: So Long, and Thanks For All The Fish
On 12/31/2015 9:47 AM, Shane Ginnane wrote: Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Happy New Yeah, ya bugga! All the best in your new endeavours. Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Acessing storage in a other address space
Hi I am trying to access storage in a other address space I am logged on to TSOA and am running the following code under TESTAUTH L R5,0(,R5) USING ASCB,R5 L R6,ASCBASSB USING ASSB,R6 MVC STOKENC,ASSBSTKN Get the job's STOKEN MODESET KEY=ZERO,MODE=SUP XR R1,R1 ALESERV ADD, X STOKEN=STOKENC, X CHKEAX=NO, X ACCESS=PUBLIC, X ALET=ALET, X LA R0,111 STORAGE OBTAIN, X LENGTH=(R0),X ADDR=(R9), X SP=0, X BNDRY=DBLWD,X ALET=ALET LATER ON I go to into access register mode SAC 512 And Move data to the storage area after doing so I versify the move under TESTAUTH Via L 9R? AR(9) L(111) XC However in the target address space using TASID Storage View Option the data I see at the address is not there, I am still under TESTAUTH at this point (meaningthe task hasn't ended) in the first address space both ALESERV and Storage have return code zeros Thanks in Advance -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So Long, and Thanks For All The Fish
Enjoy and don't be a stranger! Scott -- Chief Architect - z Systems CA Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Code Gened for MOVE COMP-3 S9(9) to S9(8)
On Sun, 13 Dec 2015 14:53:27 -0600, David Speake wrote: >A coworker posed the following question. > >Given a COBOL statement that moves a field defined as S9(9) comp-3 >to a field defined S9(8) comp-3, the generated assembler code looks like this: > > 01A598 D204 5E58 17B3 MVC 3672(5,5),1971(1) > 01A59E 940F 5E58 NI3672(5),X'0F' > 01A5A2 F844 5E58 5E58 ZAP 3672(5,5),3672(5,5) > >I know the following: >1. The program was compiled with the TRUNC option >2. The source and target field are the same length (5 bytes) >3. the first line does the actual move >4. the second line is generated because the TRUNC compile option > >So why is IBM generating the ZAP instruction? >The only use to this is to abend with S0C7 if the data is garbage. >Right? > >I too can see no good reason for ZAP. >Not a pressing issue, just both puzzled. I had meant to reply to this earlier, but unfortunately, work and the holidays intervened! :-)> The TRUNC option only applies to Binary (COMP) fields, not Packed (COMP-3) fields. The generated code is the result of compiling the program with the NOOPTimize option. If OPTimize(STD) or OPTimize(FULL) is used, then the generated code will only contain an MVC instruction. We have our default set to OPT(STD) as this generates better code but still allows Debug and Fault Analyzer to work. The ZAP instruction will also appear in instructions that add/subtract to/from Packed fields. The reason is because COBOL II (and beyond) will sometimes use CLC to compare two Packed fields instead of a Compare Packed (CP) instruction. This introduces a potential problem if the result of the computations is negative zero! For example, two S9(3) COMP-3 fields, (FLD1 = -999 and FLD2 = -1), are added together, the result is negative zero with the overflow flag set. The ZAP will change -0 to +0, but leave other values unchanged. Thus zero fields would always compare equal with CLC. If ON SIZE ERROR is used on the ADD or SUBTRACT, then the ZAP instruction is not generated. The performance gain of using CLC instead of CP is somewhat offset by having the extra ZAP instruction added. IMNSHO, Packed fields should always be defined with an odd number of digits in COBOL programs. Packed fields always contain an odd number of digits so why would you create extra work for the compiler and the programmer by defining a Packed field with an even number of digits? If you want an even number of digits on report, then define the edited output field with even number of digits. In COBOL V5.2 they have added a new RULES compiler option and one of the new rules that can be used is NOEVENPACK. NOEVENPACK will issue Warning messages for Packed fields with an even number of digits! -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So Long, and Thanks For All The Fish
Always enjoyed reading your posts, enjoy life away from us. Regards, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Friday, 1 January 2016 1:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: So Long, and Thanks For All The Fish Shane ... -- 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