Re: Problem with SMP/E RECEIVE ORDER
Hi, thanks to all, who answered to my note. The CSI I'm talking about is a z/OS CSI. You suggested to reduce the size of the package, for example to use CONTENT(CRITICAL). I have already done so, but as soon, as I'm using RECOMMENDED I get the error message. AFAIK using parameters like FORFMID or EXCLUDE etc. will not help, because I think they are recognized after the package is transfered on the client side, what is too late here. So again my question is, is it possible to identify the very large PTFs somewhere to order them seperately? Am 14.06.2012 02:10, schrieb Linda Mooney: The work around is to reduce the size of the package, by ordering parts of it at a a time -- Freundliche Gruesse / Kind regards *Dipl. Math. Juergen Kehr * IT Schulung Beratung / IT Education + Consulting Elfbuchenstrasse 10 34317 Habichtswald Germany Tel. +49-5606-5337408 Fax +49-3222-9341387 Mobil +49-172-5129389 mailto:kehrjuer...@t-online.de mailto:kehrjuer...@googlemail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Problem with SMP/E RECEIVE ORDER
On Thu, 14 Jun 2012 10:02:42 +0200, Jürgen Kehr wrote: So again my question is, is it possible to identify the very large PTFs somewhere to order them seperately? No. But The Usual Suspects are Java, Java Java (HJV(A/B)500, HJV(A/B)60(0/1) HJV(A/B)700. TOP 29 from my SMPPTS: PTF FMID# blks Bytes (cmprsd) --- --- -- - UK74827 HJVB6005488 179561920 UK76972 HJVB6005469 178920720 UK69389 HJVB6005462 178704640 UK74408 HJVB6005462 178699280 UK74817 HJVA6005172 169202400 UK76933 HJVA6005159 168800960 UK69345 HJVA6005145 168336320 UK74407 HJVA6005145 168330240 UK68991 HJVA6014097 134032480 UK69000 HJVB6014097 134032480 UK78535 HJVA6013757 122898400 UK78537 HJVB6013757 122898400 UK78842 HJVA7003757 122897600 UK78844 HJVB7003757 122897600 UK72318 HJVA6013757 122897040 UK74829 HJVB6013757 122897040 UK69795 HJVA5003734 122158960 UK73733 HJVA5003733 122130880 UK77350 HJVA5003733 122125280 UK73742 HJVB5003515 114991840 UK69796 HJVB5003514 114974480 UK77394 HJVB5003514 114965600 UK69001 HJVB6013103 101509360 UK78538 HJVB601294896445680 UK78845 HJVB700284493048560 UK74870 HJVB601275189994880 UK78536 HJVA601233076230080 UK72319 HJVA601218671502960 UK78843 HJVA700213369791680 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Problem with SMP/E RECEIVE ORDER
Hi, today I get a problem with SMPE RECEIVE ORDER. With several tries I always get the following message: GIM69212S ** RECEIVE PROCESSING HAS FAILED FOR ORDER ORD2. A PACKAGE FOR ORDER ORD2 WITH ORDERID H73315968 CANNOT BE CREATED BECAUSE THE PACKAGE SIZE (10282199040 BYTES) WOULD EXCEED THE THRESHOLD FOR INTERNET DELIVERY (80 BYTES). Two questions regarding this message: 1. Is there any chance to identify which very large PTFs lead to such a large package size? Can I RECEIVE then the PTFs one by one by using CONTENT(PTFS(xxx)) instead of CONTENT(ALL) or CONTENT(RECOMMENDED)? 2. If some PTFs are logically connected via REQ (one requires the other, both or all are not already received), in this case is it possible to RECEIVE these PTFs one by one, or will I always get the whole package? Thanks in advance for any help. -- Freundliche Gruesse / Kind regards *Dipl. Math. Juergen Kehr * IT Schulung Beratung / IT Education + Consulting Elfbuchenstrasse 10 34317 Habichtswald Germany Tel. +49-5606-5337408 Fax +49-3222-9341387 Mobil +49-172-5129389 mailto:kehrjuer...@t-online.de mailto:kehrjuer...@googlemail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Problem with SMP/E RECEIVE ORDER
Hi, today I get a problem with SMPE RECEIVE ORDER. With several tries I always get the following message: GIM69212S ** RECEIVE PROCESSING HAS FAILED FOR ORDER ORD2. A PACKAGE FOR ORDER ORD2 WITH ORDERID H73315968 CANNOT BE CREATED BECAUSE THE PACKAGE SIZE (10282199040 BYTES) WOULD EXCEED THE THRESHOLD FOR INTERNET DELIVERY (80 BYTES). Two questions regarding this message: 1. Is there any chance to identify which very large PTFs lead to such a large package size? Can I RECEIVE then the PTFs one by one by using CONTENT(PTFS(xxx)) instead of CONTENT(ALL) or CONTENT(RECOMMENDED)? 2. If some PTFs are logically connected via REQ (one requires the other, both or all are not already received), in this case is it possible to RECEIVE these PTFs one by one, or will I always get the whole package? Thanks in advance for any help. It would help to know what you were ordering? Was it an RSU? Was it all PTFs for 2012? If you could tell us what you were ordering, we might be able to help. Were you going after MQ, CICS, DB2, etc PTFs? It is possible you have to do multiplie Receives. Possibly doing CONTENT(CRITICAL) or other. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Problem with SMP/E RECEIVE ORDER
When we first started doing Internet Orders we had to gradually prime the systems by doing as Lizette suggested. Initially order just small subsets (Critical, HIPER, RSUXXX) until you have the system current. Then you can go to CONTENT(ALL). (I'm making an assumption that you are just starting out as I see ORD2 as your identifier.) Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, June 13, 2012 4:26 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Problem with SMP/E RECEIVE ORDER Hi, today I get a problem with SMPE RECEIVE ORDER. With several tries I always get the following message: GIM69212S ** RECEIVE PROCESSING HAS FAILED FOR ORDER ORD2. A PACKAGE FOR ORDER ORD2 WITH ORDERID H73315968 CANNOT BE CREATED BECAUSE THE PACKAGE SIZE (10282199040 BYTES) WOULD EXCEED THE THRESHOLD FOR INTERNET DELIVERY (80 BYTES). Two questions regarding this message: 1. Is there any chance to identify which very large PTFs lead to such a large package size? Can I RECEIVE then the PTFs one by one by using CONTENT(PTFS(xxx)) instead of CONTENT(ALL) or CONTENT(RECOMMENDED)? 2. If some PTFs are logically connected via REQ (one requires the other, both or all are not already received), in this case is it possible to RECEIVE these PTFs one by one, or will I always get the whole package? Thanks in advance for any help. It would help to know what you were ordering? Was it an RSU? Was it all PTFs for 2012? If you could tell us what you were ordering, we might be able to help. Were you going after MQ, CICS, DB2, etc PTFs? It is possible you have to do multiplie Receives. Possibly doing CONTENT(CRITICAL) or other. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Problem with SMP/E RECEIVE ORDER
Hi Jürgen, I had a similar issue with a service package that was larger that 8GB, about a year ago. IBM opened an APAR - it was JAVA that couldn't handle the package size . I didn't have time to wait so I ordered my service on tape. I don't have the APAR info handy at the moment, but will try to find it for you tomorrow, if you still need it. I recommend that you open a issue. The APAR may be reselved by now, in which case you could put the PTF for that, and try again or - The work around is to reduce the size of the package, by ordering parts of it at a a time, or order tape. HTH, Linda - Original Message - From: Jürgen Kehr kehrjuer...@t-online.de To: IBM-MAIN@bama.ua.edu Sent: Wednesday, June 13, 2012 3:48:41 PM Subject: Problem with SMP/E RECEIVE ORDER Hi, today I get a problem with SMPE RECEIVE ORDER. With several tries I always get the following message: GIM69212S ** RECEIVE PROCESSING HAS FAILED FOR ORDER ORD2. A PACKAGE FOR ORDER ORD2 WITH ORDERID H73315968 CANNOT BE CREATED BECAUSE THE PACKAGE SIZE (10282199040 BYTES) WOULD EXCEED THE THRESHOLD FOR INTERNET DELIVERY (80 BYTES). Two questions regarding this message: 1. Is there any chance to identify which very large PTFs lead to such a large package size? Can I RECEIVE then the PTFs one by one by using CONTENT(PTFS(xxx)) instead of CONTENT(ALL) or CONTENT(RECOMMENDED)? 2. If some PTFs are logically connected via REQ (one requires the other, both or all are not already received), in this case is it possible to RECEIVE these PTFs one by one, or will I always get the whole package? Thanks in advance for any help. -- Freundliche Gruesse / Kind regards *Dipl. Math. Juergen Kehr * IT Schulung Beratung / IT Education + Consulting Elfbuchenstrasse 10 34317 Habichtswald Germany Tel. +49-5606-5337408 Fax +49-3222-9341387 Mobil +49-172-5129389 mailto:kehrjuer...@t-online.de mailto:kehrjuer...@googlemail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMP/E and UNIX (JAVA?)
The following scenario: single PTF APPLY. APPLY CHECK ends with RC=0 APPLY end with RC=8 reason: jar command not found. (see details below) I edited /etc/profile, so PATH variable do containg entry for jar. I tested it using shell (jar -? command) and BPXBATCH PARM='SH jar-?' However SMPE APPLY does not see the PATH. Q: is there any customization required/available to tell SMPE where to find jar program? BPXBATCH output from the SMPE job quotation: jar: /usr/lpp/IHSA... 73: FSUM7351 not found -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and UNIX (JAVA?) (solved)
W dniu 2012-05-29 22:39, R.S. pisze: The following scenario: single PTF APPLY. APPLY CHECK ends with RC=0 APPLY end with RC=8 reason: jar command not found. (see details below) I edited /etc/profile, so PATH variable do containg entry for jar. I tested it using shell (jar -? command) and BPXBATCH PARM='SH jar-?' However SMPE APPLY does not see the PATH. Q: is there any customization required/available to tell SMPE where to find jar program? BPXBATCH output from the SMPE job quotation: jar: /usr/lpp/IHSA... 73: FSUM7351 not found Solution: add SMPJHOME DD to SMPE job. I'm curious why IBM did not add a DDDEF for that... -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and UNIX (JAVA?) (solved)
On Tue, 29 May 2012 22:50:05 +0200, R.S. wrote: Solution: add SMPJHOME DD to SMPE job. I'm curious why IBM did not add a DDDEF for that... http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimrfr42/4.20 4.20 SMPJHOME ... No default location is assumed by SMP/E for SMPJHOME. ... Notes: 1. SMPJHOME can be specified using a DD statement or a DDDEF entry. Do you mean that sample UCLIN for the product should include a customizable sample/default SMPJHOME DDDEF? A reasonable UNIX distribution (in contrast to z/OS USS) would provide a (customizable) symlink to the current Java libraries in (e.g.) /usr/lpp/java/... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and UNIX (JAVA?) (solved)
W dniu 2012-05-30 16:06, Paul Gilmartin pisze: On Tue, 29 May 2012 22:50:05 +0200, R.S. wrote: Solution: add SMPJHOME DD to SMPE job. I'm curious why IBM did not add a DDDEF for that... http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimrfr42/4.20 4.20 SMPJHOME ... No default location is assumed by SMP/E for SMPJHOME. ... Notes: 1. SMPJHOME can be specified using a DD statement or a DDDEF entry. Do you mean that sample UCLIN for the product should include a customizable sample/default SMPJHOME DDDEF? A reasonable UNIX distribution (in contrast to z/OS USS) would provide a (customizable) symlink to the current Java libraries in (e.g.) /usr/lpp/java/... Well, I found 'jar' program in 9 different locations, including WebSphere - the product I applied the PTF to. I compared size of the files - it looks I have 9 identical jar's. Why ServerPac is not customized to use any of them? Why there is not HOLD ACTION in the PTF to take care about SMPJHOME? Why APPLY CHECK does not check presence/lack of ot? Why SMP/E does not use PATH variable? -- Radoslaw Skorupka Lodz, Poland P.S. Something tell me that I will have to solve the same problem few years later. And obviously I'll forget the solution. And IBM won't fix it. -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and UNIX (JAVA?) (solved)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, May 30, 2012 9:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMP/E and UNIX (JAVA?) (solved) snip Well, I found 'jar' program in 9 different locations, including WebSphere - the product I applied the PTF to. I compared size of the files - it looks I have 9 identical jar's. Why ServerPac is not customized to use any of them? Good question! Why there is not HOLD ACTION in the PTF to take care about SMPJHOME? Another good question. Why APPLY CHECK does not check presence/lack of ot? Why SMP/E does not use PATH variable? Perhaps because SMP/E does not run in a UNIX shell environment. It starts out as a normal z/OS batch program (not a UNIX process). When it needs to run the jar command, it is dubbed as a UNIX process. This process does not set up any UNIX environment variables. PATH is a UNIX environment variable. Normally it is set in by the login shell (/bin/sh) via the /etc/profile shell script. And perhaps futher modified by the ~/.profile script and/or the shell script in the specified in the ENV environment variable, if any. -- Radoslaw Skorupka Lodz, Poland P.S. Something tell me that I will have to solve the same problem few years later. And obviously I'll forget the solution. And IBM won't fix it. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and UNIX (JAVA?) (solved)
On 5/30/2012 8:43 AM, R.S. wrote: W dniu 2012-05-30 16:06, Paul Gilmartin pisze: On Tue, 29 May 2012 22:50:05 +0200, R.S. wrote: Solution: add SMPJHOME DD to SMPE job. I'm curious why IBM did not add a DDDEF for that... http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimrfr42/4.20 4.20 SMPJHOME ... No default location is assumed by SMP/E for SMPJHOME. ... Notes: 1. SMPJHOME can be specified using a DD statement or a DDDEF entry. Do you mean that sample UCLIN for the product should include a customizable sample/default SMPJHOME DDDEF? A reasonable UNIX distribution (in contrast to z/OS USS) would provide a (customizable) symlink to the current Java libraries in (e.g.) /usr/lpp/java/... Well, I found 'jar' program in 9 different locations, including WebSphere - the product I applied the PTF to. I compared size of the files - it looks I have 9 identical jar's. I have this objection to RDz or whatever it's called, and Eclipse, the base for that: I found many copies of the same Java support files in one installation of the product; I find that senseless bloat of resources very offensive. Probably in today's world the response is get over it, but for a guy who prefers Assembler, that's a big attitude change; at the very least there should be only a single set of Java modules used by all the classes in an application (or better, in a single system). -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMP/E Order Servers Problems (Was: SMP/E Order Server Pair)
On 2/29/2012 8:08 AM, Mary Anne Matyaz wrote: The PMR was updated stating that the issue has been resolved. My receive pointing to Boulder completed successfully. Now we have new problems. No matter if we use the boulder server address or the rochester server address, the package gets created on the IBM side, but all download attempts fail with: Connecting to: dispby-103.boulder.ibm.com 170.225.15.103 port: 21. Connection to server interrupted or timed out. Waiting for reply Server not responding, closing connection. Std Return Code = 1, Error Code = 8 SMP/E retries once per minute for ten minutes, then gives up. :-( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/28/2012 11:46 PM, Andrew Rowley wrote: I get the impression that once Thunderbird has the messages in its local database, it is difficult or impossible to change the way they are threaded. I think (based on my experiences) that these options apply only to new messages. That makes sense. I'll watch future threading behavior. I much preferred Thunderbirds threading behaviour prior to version 3. Threading based on subject is a much more intuitive system - even with its occasional failings. It's guesswork. The In-ReplyTo: tag gives perfect results, but only if used by everyone. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
W dniu 2012-02-29 09:09, Edward Jaffe pisze: On 2/28/2012 11:46 PM, Andrew Rowley wrote: I get the impression that once Thunderbird has the messages in its local database, it is difficult or impossible to change the way they are threaded. I think (based on my experiences) that these options apply only to new messages. That makes sense. I'll watch future threading behavior. I have two instances of TB. I did the change in one of them and see a difference in new messages. = It does work! :-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/28/2012 9:11 PM, Edward Jaffe wrote: On 2/28/2012 4:09 PM, Paul Gilmartin wrote: On Tue, 28 Feb 2012 14:51:31 -0800, Edward Jaffe wrote: On 2/28/2012 8:51 AM, McKown, John wrote: IOW, damned if I do and damned if I don't (insert hard line breaks, that is). My advice is not to ever insert any hard breaks. That just makes things worse. When one relies on software that properly handles format=flowed everything should work beautifully. Thunderbird seems to support this very well. I assume Outlook does as well. I'll take the contrary position. This ain't a word processor. I learned long ago to insert line breaks where I want them -- it's the big key to the right of the home row. Allow me to restate. What I actually meant to say was not to insert any GRATUITOUS hard breaks. Obviously, hard breaks between paragraphs is a good idea. But, hard breaks in the middle of a paragraph become unreadable when quoted. I don't think so. As I mentioned earlier, I insert lots of hard breaks. The key is to keep lines short and roughly the same width. I think the result is easier to read and easier to reply to. But, of course, YMMV. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Order Server Pair
The PMR was updated stating that the issue has been resolved. My receive pointing to Boulder completed successfully. The status page: http://www14.software.ibm.com/webapp/set2/sas/f/gdbm/home.html Still says Current issues or problems: The eccgw01.boulder server used in SMP/E's Internet Service Retrieval process is experiencing a problem. The user's job may end due to a long wait and/or SMP/E message GIM44336S may be received. We have also seen message EDC8130I Host cannot be reached. Customers are advised to submit a new order using the alternate (Rochester) server, for example, https://eccgw02.rochester.ibm.com/services/projects/ecc/ws Updates will be posted when available. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In 4f4d5a73.9030...@phoenixsoftware.com, on 02/28/2012 at 02:51 PM, Edward Jaffe edja...@phoenixsoftware.com said: My advice is not to ever insert any hard breaks. That just makes things worse. When one relies on software that properly handles format=flowed John isn't generating format=flowed, alas. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In 2142326002012139.wa.paulgboulderaim@bama.ua.edu, on 02/28/2012 at 06:09 PM, Paul Gilmartin paulgboul...@aim.com said: I learned long ago to insert line breaks where I want them -- it's the big key to the right of the home row. Which makes things harder for thos using a narrower window to read them. F=F is an abominable compromise. But better than alternating long and short lines. Q-P is no better. Much as I hate QP, it has a useful role. Both are attempts at stealth markup No; QP is a way to sneak non-ASCII data into an ASCII protocol without breaking things. structured text that appears plain FSVO structured text. The games they play are never quite transparent. No protocol is transparent to software that doesn't support it. Half a decade is long enough for the authors of e-mail software to start supporting MIME. They corrupt plain text that I paste in. Then you're running broken software. MS Exchange is broken. I believe F=F uses SPACENEWLINE as a continuation indicator. Woe betide anyone who allows a space to occur before a hard line break. That can only happen with broken software. From RFC 3676 A generating agent SHOULD: ... o Trim spaces before user-inserted hard line breaks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
W dniu 2012-02-27 17:59, Tony Harminc pisze: While we're on the topic of posting problems, am I the only reader to have trouble with Radoslaw Skorupka's posts? I find that his original posts are fine, but his replies to anyone else's are always shown without line breaks. I almost missed this mail. Thank you for paying attention. I didn't know about the problems. BTW: I think I haven't changed my settings for years, only upgraded mail program (Thunderbird and predecessors). As far as I understand the problem occurs when both conditions are met: 1. It is reply, not start of thread. 2. Another user is using GMAIL. I would like to fix it, but I need some clue or maybe I should send some test messages with different settings (and make some noise on the list!). -- Radoslaw Skorupka Lodz, Poland P.S. It's nice to know that anybody read my posts ;-) -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In caarmm9tjvqnv6xrfg9gzwykubfjju91nf0s9hf-dxftbubc...@mail.gmail.com, on 02/27/2012 at 11:59 AM, Tony Harminc t...@harminc.net said: While we're on the topic of posting problems, am I the only reader to have trouble with Radoslaw Skorupka's posts? I find that his original posts are fine, but his replies to anyone else's are always shown without line breaks. I have no problem with the format of his messages. I read the list with Gmail. There's your problem. I notice that both his original and reply posts have the dreaded Dreaded? format=flowed on the Content-Type line, but it seems to cause trouble only for replies. C=F means that a line ending in SP CR LF should be wrapped with the following line while a line without the trailing space ends a paragraph. I'm quite certain that you're seeing incorrect wrapping in all of his messages, even if you don't realize it. He seems to have a habbit of adding hard returns at the end of a sentence, and if GMAIL does not handle C=F then it will wrap those. Usually Gmail is very good at interpreting and displaying strangely formatted mail, But not so good at handling standards. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In 4f4c8937.4000...@bremultibank.com.pl, on 02/28/2012 at 08:58 AM, R.S. r.skoru...@bremultibank.com.pl said: I would like to fix it, This time it's not your error. The only thing wrong with the format of your messages is that you are putting a hard return at the end of every sentences instead of allowing rewrap of multiple sentences in a paragraph. I didn't know about the problems. They're problems in GMAIL, not in your software. You could ask TB to not use F=F, but that would cause other problems. The fix is for Tony to send a bug report to google citing failure to handle RFC 2646 and RFC 3676. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In 1322374244611894.wa.markmzelden@bama.ua.edu, on 02/27/2012 at 10:35 AM, Mark Zelden m...@mzelden.com said: Do you see the problem with my posts? Yes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
Perhaps this will help: http://kb.mozillazine.org/Mail_content_types#Disabling_paragraph_flow or this http://www.techques.com/question/3-202613/Thunderbird-is-removing-line-breaks-on-forwarded-messages---what-gives - Don Imbriale On Tue, Feb 28, 2012 at 2:58 AM, R.S. r.skoru...@bremultibank.com.plwrote: W dniu 2012-02-27 17:59, Tony Harminc pisze: While we're on the topic of posting problems, am I the only reader to have trouble with Radoslaw Skorupka's posts? I find that his original posts are fine, but his replies to anyone else's are always shown without line breaks. I almost missed this mail. Thank you for paying attention. I didn't know about the problems. BTW: I think I haven't changed my settings for years, only upgraded mail program (Thunderbird and predecessors). As far as I understand the problem occurs when both conditions are met: 1. It is reply, not start of thread. 2. Another user is using GMAIL. I would like to fix it, but I need some clue or maybe I should send some test messages with different settings (and make some noise on the list!). Radoslaw Skorupka Lodz, Poland P.S. It's nice to know that anybody read my posts ;-) tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s bowego adresata. Odbiorc e by jedynie jej adresat z wy czeniem dost pu os b trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy c odpowied oraz trwale usun wiadomo czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pld Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorc w KRS 025237, NIP: 526-021-50-88. ug stanu na dzie 01.01.2012 r. kapita zak adowy BRE Banku SA (w ca ci wp acony) wynosi 168.410.984 z otych. --** --**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.eduwith the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Order Server Pair
On Sat, 25 Feb 2012 07:55:11 -0800, Edward Jaffe edja...@phoenixsoftware.com wrote: Last night's automatic SMP/E RECEIVE ORDER job failed with: GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - java.net.NoRouteToHostException: EDC8130I Host cannot be reached. GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. After being resubmitted this morning, it failed with the same issues. snip This thread switched subjects - back to the original problem: It still is broken today - that is 4 days! Has anyone opened a PMR or does anyone know the current status? Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Order Server Pair
It still is broken today - that is 4 days! Has anyone opened a PMR or does anyone know the current status? Mark, I have a PMR open. The latest update says: We are aware that there is currently an issue with one of the servers used in IBM's Internet Service Retrieval process. We have notified our folks in Boulder and they are working to determine what the error is and resolve it as soon as possible. We will keep you updated. In the meantime, we have found that the alternate order server is still available. You may want to try specifying the following in your ORDERSERVER statement: url=https://eccgw02.rochester.ibm.com/services/projects/ecc/ws/; or url=https://207.25.252.197/services/projects/ecc/ws; End IBM update -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 02/27/2012 at 12:52 PM, McKown, John john.mck...@healthmarkets.com said: I guess I'm just used to the email client inserting a line break where appropriate. The e-mail client has no way of knowing where a line break is appropriate, because it does not know the screen width that the reader will use. I tend to do email like I do word processing. I only use the newline key when I want to force a line break, or and the end of a paragraph. Quite properly, although it would be better if your software supported RFC 2646[1], including Format=Flowed. I didn't realize that some email clients don't conform to normal standards. I'll get in a habit of using the new line key more often. That causes problems for e-mail clients that do conform to normal standards. [1] With a date of 1999-08, it's hardly bleeding edge. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In 4f4bd29c.8060...@trainersfriend.com, on 02/27/2012 at 11:59 AM, Steve Comstock st...@trainersfriend.com said: Thanks. I have gotten in the habit of making sure my lines are all relatively short and roughly the same length (without obsessing about it). I find that makes it easier to read _and_ easier to reply to. If the reader has a window that is narrower than yours, it leads to alternating long and short lines, which are harder to read. RFC 2646 is more than a decade old; it's past time for google to notice it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In caarmm9rg9avh95ocdgbfzr0p9rpt6pfmp83jvut9sh0cnav...@mail.gmail.com, on 02/27/2012 at 03:25 PM, Tony Harminc t...@harminc.net said: However it seems strange to me that Gmail, which typically handles just about any strange mail format quite nicely, fails to lay out Radoslaw's posts in a readable way. Google is notorious for ignoring standards. RFC 2646 is more than a decade old. Have you tried reporting it to google as a bug[1]? May I also say that I usually just keep on typing in my posts, except to hit enter for a new paragraph. That's appropriate with FORMAT=FLOWED. Without it, there are problems whether you add hard CR's or you don't. [1] If GMAIL can generate FORMAT=FLOWED, shouldn't it be able to read it? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
IOW, damned if I do and damned if I don't (insert hard line breaks, that is). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, February 28, 2012 10:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Unwanted New Threads (Was: SMP/E Order Server Pair) In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 02/27/2012 at 12:52 PM, McKown, John john.mck...@healthmarkets.com said: I guess I'm just used to the email client inserting a line break where appropriate. The e-mail client has no way of knowing where a line break is appropriate, because it does not know the screen width that the reader will use. I tend to do email like I do word processing. I only use the newline key when I want to force a line break, or and the end of a paragraph. Quite properly, although it would be better if your software supported RFC 2646[1], including Format=Flowed. I didn't realize that some email clients don't conform to normal standards. I'll get in a habit of using the new line key more often. That causes problems for e-mail clients that do conform to normal standards. [1] With a date of 1999-08, it's hardly bleeding edge. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/28/2012 8:51 AM, McKown, John wrote: IOW, damned if I do and damned if I don't (insert hard line breaks, that is). My advice is not to ever insert any hard breaks. That just makes things worse. When one relies on software that properly handles format=flowed everything should work beautifully. Thunderbird seems to support this very well. I assume Outlook does as well. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Tue, 28 Feb 2012 14:51:31 -0800, Edward Jaffe wrote: On 2/28/2012 8:51 AM, McKown, John wrote: IOW, damned if I do and damned if I don't (insert hard line breaks, that is). My advice is not to ever insert any hard breaks. That just makes things worse. When one relies on software that properly handles format=flowed everything should work beautifully. Thunderbird seems to support this very well. I assume Outlook does as well. I'll take the contrary position. This ain't a word processor. I learned long ago to insert line breaks where I want them -- it's the big key to the right of the home row. Using this and presuming a monospaced font (terminals used to be that way; 3270s still are) I can enter tabular information using the space bar (the long key near my belly button), and even compose rudimentary graphics. for anything fancier, people should use a markup language (but which one? HTML? RTF? Other (specify)?) F=F is an abominable compromise. Q-P is no better. Both are attempts at stealth markup -- structured text that appears plain The games they play are never quite transparent. They corrupt plain text that I paste in. MS Exchange used to take JCL snippets that supplied and interpret such as BLKSIZE=6144 as Q-P entities. (It was breaking the rules; Q-P was not declared in the MIME headers, but MS was governed by a principle of fewest phone calls, and more people would complain about seeing =3D in their emails because the sender omitted them, or they had configured LISTSERV to strip MIME headers, than about seeing BLKSIZE=6144 become BLKSIZEa44) When I paste in a snippet of a Rexx trace which flags its lines with on the left, my MUA, or perhaps yours, tries to interpret them as quotation flags. And F=F's attempt to reposition to fit the screen width makes things even worse. I believe F=F uses SPACENEWLINE as a continuation indicator. Woe betide anyone who allows a space to occur before a hard line break. Perhaps this is the source of R.S.'s problem. Leave my text alone, dammit! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Order Server Pair
Like other shops, we've been having more failures than successes recently trying to pull Shopz maintenance from Boulder. We get this: GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - java.io.IOException: Unable to tunnel through proxy. Proxy returns HTTP/1.1 503 Service Unavailable GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. So I tackled it like an errant application whose only reliable behavior is a bad return code in case of failure. In this case 12. So I coded a job with two steps: first one goes to Boulder, second one to Rochester. I put a conditional execution on the second step: COND=(12,GT) . It's not a very elegant solution, but when the first stop choked as above, the second step ran fine. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mary Anne Matyaz maryanne4...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 02/28/2012 08:24 AM Subject:Re: SMP/E Order Server Pair Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu It still is broken today - that is 4 days! Has anyone opened a PMR or does anyone know the current status? Mark, I have a PMR open. The latest update says: We are aware that there is currently an issue with one of the servers used in IBM's Internet Service Retrieval process. We have notified our folks in Boulder and they are working to determine what the error is and resolve it as soon as possible. We will keep you updated. In the meantime, we have found that the alternate order server is still available. You may want to try specifying the following in your ORDERSERVER statement: url=https://eccgw02.rochester.ibm.com/services/projects/ecc/ws/; or url=https://207.25.252.197/services/projects/ecc/ws; End IBM update -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 02/28/2012 at 10:51 AM, McKown, John john.mck...@healthmarkets.com said: IOW, damned if I do and damned if I don't (insert hard line breaks, that is). Unless you use format=flowed. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/28/2012 4:09 PM, Paul Gilmartin wrote: On Tue, 28 Feb 2012 14:51:31 -0800, Edward Jaffe wrote: On 2/28/2012 8:51 AM, McKown, John wrote: IOW, damned if I do and damned if I don't (insert hard line breaks, that is). My advice is not to ever insert any hard breaks. That just makes things worse. When one relies on software that properly handles format=flowed everything should work beautifully. Thunderbird seems to support this very well. I assume Outlook does as well. I'll take the contrary position. This ain't a word processor. I learned long ago to insert line breaks where I want them -- it's the big key to the right of the home row. Allow me to restate. What I actually meant to say was not to insert any GRATUITOUS hard breaks. Obviously, hard breaks between paragraphs is a good idea. But, hard breaks in the middle of a paragraph become unreadable when quoted. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/26/2012 3:23 PM, Andrew Rowley wrote: Thunderbird can be configured to also use the subject for threading: https://wiki.mozilla.org/MailNews:Message_Threading This sounded promising. But, no matter how I set the threading options I still have multiple threads with the same subject. :-( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 29/02/2012 5:37 PM, Edward Jaffe wrote: On 2/26/2012 3:23 PM, Andrew Rowley wrote: Thunderbird can be configured to also use the subject for threading: https://wiki.mozilla.org/MailNews:Message_Threading This sounded promising. But, no matter how I set the threading options I still have multiple threads with the same subject. :-( I think mail.strict_threading=false is the most important option. mail.thread_without_re=true is potentially useful, but has the likely side effect of adding new messages to ancient threads of the same name (if you don't clean out old messages). I get the impression that once Thunderbird has the messages in its local database, it is difficult or impossible to change the way they are threaded. I think (based on my experiences) that these options apply only to new messages. I much preferred Thunderbirds threading behaviour prior to version 3. Threading based on subject is a much more intuitive system - even with its occasional failings. -- Andrew Rowley and...@blackhillsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I also use the web client, do my responses show the same way? MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/27/2012 3:57 AM, Mary Anne Matyaz wrote: I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I also use the web client, do my responses show the same way? That now you mention it, yes they do. :-( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Sun, 26 Feb 2012 15:32:50 -0800, Edward Jaffe edja...@phoenixsoftware.com wrote: The missing In-Reply-To: tag seems to be a failure of the web interface, perhaps due misconfiguration or running a back-level release -- OR perhaps this tag is simply not supported AT ALL by the L-Soft web interface and an enhancement is needed. I tried to Google this, but there are a lot of hits that use those words and I don't have the time to research it. (I only use the web interface to conduct searches.) I have used the web interface for posting / replying to posts exclusively for over 10 years. My former employer started blocking all NNTP at some point so I couldn't use the news servers from my ISP and reply via normal email. I've used a combination of Firefox (Netscape prior to that) and IE. Do you see the problem with my posts? Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
While we're on the topic of posting problems, am I the only reader to have trouble with Radoslaw Skorupka's posts? I find that his original posts are fine, but his replies to anyone else's are always shown without line breaks. I read the list with Gmail. I notice that both his original and reply posts have the dreaded format=flowed on the Content-Type line, but it seems to cause trouble only for replies. Usually Gmail is very good at interpreting and displaying strangely formatted mail, but consistently not in this case. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
Tony, I have this same exact problem with his posts. I too use Gmail. Some time in the recent past I believe he switched to a new email client and this first showed up; I had contacted him off-list about this, but we were unable to come up with an answer. His are the only posts that exhibit such behavior. - Don Imbriale On Mon, Feb 27, 2012 at 11:59 AM, Tony Harminc t...@harminc.net wrote: While we're on the topic of posting problems, am I the only reader to have trouble with Radoslaw Skorupka's posts? I find that his original posts are fine, but his replies to anyone else's are always shown without line breaks. I read the list with Gmail. I notice that both his original and reply posts have the dreaded format=flowed on the Content-Type line, but it seems to cause trouble only for replies. Usually Gmail is very good at interpreting and displaying strangely formatted mail, but consistently not in this case. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
Also having the same problem wth have trouble with Radoslaw Skorupka's posts . No line breaks at all. Jan On Mon, Feb 27, 2012 at 5:59 PM, Tony Harminc t...@harminc.net wrote: While we're on the topic of posting problems, am I the only reader to have trouble with Radoslaw Skorupka's posts? I find that his original posts are fine, but his replies to anyone else's are always shown without line breaks. I read the list with Gmail. I notice that both his original and reply posts have the dreaded format=flowed on the Content-Type line, but it seems to cause trouble only for replies. Usually Gmail is very good at interpreting and displaying strangely formatted mail, but consistently not in this case. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/27/2012 8:35 AM, Mark Zelden wrote: I have used the web interface for posting / replying to posts exclusively for over 10 years. My former employer started blocking all NNTP at some point so I couldn't use the news servers from my ISP and reply via normal email. I've used a combination of Firefox (Netscape prior to that) and IE. Do you see the problem with my posts? Yes. Same issue. No In-Reply-To: tag in the header causes a new thread to be started. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Mon, 27 Feb 2012 18:13:06 +0100, Jan Vanbrabant wrote: Also having the same problem wth have trouble with Radoslaw Skorupka's posts . No line breaks at all. Style. John M. habitually posts without line breaks. I deal with it. Perhaps because I too often agree with his substance to complain about style. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
I guess I'm just used to the email client inserting a line break where appropriate. I tend to do email like I do word processing. I only use the newline key when I want to force a line break, or and the end of a paragraph. I didn't realize that some email clients don't conform to normal standards. I'll get in a habit of using the new line key more often. Like in did in this email. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 11:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Unwanted New Threads (Was: SMP/E Order Server Pair) On Mon, 27 Feb 2012 18:13:06 +0100, Jan Vanbrabant wrote: Also having the same problem wth have trouble with Radoslaw Skorupka's posts . No line breaks at all. Style. John M. habitually posts without line breaks. I deal with it. Perhaps because I too often agree with his substance to complain about style. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/27/2012 11:52 AM, McKown, John wrote: I guess I'm just used to the email client inserting a line break where appropriate. I tend to do email like I do word processing. I only use the newline key when I want to force a line break, or and the end of a paragraph. I didn't realize that some email clients don't conform to normal standards. I'll get in a habit of using the new line key more often. Like in did in this email. Thanks. I have gotten in the habit of making sure my lines are all relatively short and roughly the same length (without obsessing about it). I find that makes it easier to read _and_ easier to reply to. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 11:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Unwanted New Threads (Was: SMP/E Order Server Pair) On Mon, 27 Feb 2012 18:13:06 +0100, Jan Vanbrabant wrote: Also having the same problem wth have trouble with Radoslaw Skorupka's posts . No line breaks at all. Style. John M. habitually posts without line breaks. I deal with it. Perhaps because I too often agree with his substance to complain about style. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In 20120226232947.e728924...@panix5.panix.com, on 02/26/2012 at 06:29 PM, Rich Greenberg ric...@panix.com said: I don't think so, Your message certainly reads as though you interpreted Paul's I usually read and post to IBM-MAIN using the web interface. as a reference to gargle groups. If not, why did you discuss Usenet? If a followup is made directly to usenet, its presence depends on the newsreader used and I think the default is NO. The In-Reply-To header field is intended for e-mail; the usenet equivalent is References. However, why do you believe that Paul is using a news client? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In 9121530388364333.wa.maryanne4psugmail@bama.ua.edu, on 02/27/2012 at 05:57 AM, Mary Anne Matyaz maryanne4...@gmail.com said: I also use the web client, do my responses show the same way? Your response does not have an In-Reply-To header field. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 27 February 2012 12:21, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 27 Feb 2012 18:13:06 +0100, Jan Vanbrabant wrote: Also having the same problem wth have trouble with Radoslaw Skorupka's posts . No line breaks at all. Style. John M. habitually posts without line breaks. I deal with it. Perhaps because I too often agree with his substance to complain about style. I have no complaint about the content of the posts of either of these gentlemen. However it seems strange to me that Gmail, which typically handles just about any strange mail format quite nicely, fails to lay out Radoslaw's posts in a readable way. If I can't disentangle one of his by eye, I click Gmail's message text garbled? box, which though it is mostly concerned with code page issues that I believe are not relevant here, generally produces readable text at the cost of another step and another tab or window. I never see a problem with John M's posts. May I also say that I usually just keep on typing in my posts, except to hit enter for a new paragraph. I have had no complaints ever on this style, so presumably between Gmail's posting and everyone else's reading, either it works, or no one reads my posts in any case. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
Yes, using gmail, and not seeing it on others. On Mon, Feb 27, 2012 at 10:59 AM, Tony Harminc t...@harminc.net wrote: While we're on the topic of posting problems, am I the only reader to have trouble with Radoslaw Skorupka's posts? I find that his original posts are fine, but his replies to anyone else's are always shown without line breaks. I read the list with Gmail. I notice that both his original and reply posts have the dreaded format=flowed on the Content-Type line, but it seems to cause trouble only for replies. Usually Gmail is very good at interpreting and displaying strangely formatted mail, but consistently not in this case. Tony H. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Order Server Pair
In 3785790301733305.wa.paulgboulderaim@bama.ua.edu, on 02/25/2012 at 10:34 AM, Paul Gilmartin paulgboul...@aim.com said: I don't know how the client is expected to choose among the responses, That depends on how it's coded. nor what GetHostByName returns. An alias array and an address array. More precisely, it returns a pointer to a hostent structure containing 5 data, of which h_length and h_addr give you the addresses. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Order Server Pair
On Sat, 25 Feb 2012 20:52:13 -0500, Shmuel Metz (Seymour J.) wrote: I don't know how the client is expected to choose among the responses, That depends on how it's coded. nor what GetHostByName returns. An alias array and an address array. More precisely, it returns a pointer to a hostent structure containing 5 data, of which h_length and h_addr give you the addresses. So, if IBM were to assign both server IP addresses to a single domain name (IBM has control over this), and if the FTP client were to try the multiple addresses in succession (IBM TCP/IP development, but not SMP/E development has control over this), the OP's availability requirement would be somewhat addressed. But in many cases, such as ours, there's anFTP proxy involved over which IBM has no control. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Unwanted New Threads (Was: SMP/E Order Server Pair)
Paul Gilmartin, I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I finally decided to compare headers from your non-threaded posts to other peoples' threaded posts. What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix that? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Sun, 26 Feb 2012 10:01:36 -0800, Edward Jaffe wrote: I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I finally decided to compare headers from your non-threaded posts to other peoples' threaded posts. What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix that? I usually read and post to IBM-MAIN using the web interface. So this seems to be a LISTSERV problem. Is Darren IBM-MAIN's interface to L-Soft? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In article 5978244080952028.wa.paulgboulderaim@bama.ua.edu you write: On Sun, 26 Feb 2012 10:01:36 -0800, Edward Jaffe wrote: I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I finally decided to compare headers from your non-threaded posts to other peoples' threaded posts. What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix that? I usually read and post to IBM-MAIN using the web interface. So this seems to be a LISTSERV problem. Is Darren IBM-MAIN's interface to L-Soft? No, its not a problem, its just an artifact of how this list works. You may not realize it but there are TWO entities called IBM-MAIN. One is a mailing list hosted at the listserver at bama.ua.edu. The second is the usenet group named bit.listserv.ibm-main. The mailing list has a gateway to the usenet group but there is no reverse gateway. There used to be but it was taken down due to abuse. So if someone originates a post by sending it to the mailing list, it will appear there and ALSO on the usenet group. But if someone originates a post on usenet, it will not be sent to the mailing list. Google Groups is fed from usenet so it is complete. The mailing list archives are ONLY fed by the listserv so they will miss anything that was only posted on usenet. For folks who normally read usenet or Google Groups (which IS usenet although Goggle would like you to believe otherwise) here is what I do and what I suggest all usenet readers do also: 1) Subscribe to the mailing list. 2) Set yourself to NOMAIL on the listserv. 3) When responding to a usenet post, DON'T use Followup. Instead use Reply and make sure that the email address gets set to: To: IBM-MAIN@bama.ua.edu. That way your response will be seen on both the mailing list and on usenet, and will be in the IBM-MAIN archives at bama. -- Rich Greenberg Sarasota, FL, USA richgr atsign panix.com + 1 941 378 2097 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines: Val,Red,Shasta,Zero,Casey Cinnar (At the bridge) Owner:Chinook-L Canines: Red Max (Siberians) Retired at the beach Asst Owner:Sibernet-L -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Sun, 26 Feb 2012 17:51:33 -0500, Rich Greenberg wrote: In article you write: On Sun, 26 Feb 2012 10:01:36 -0800, Edward Jaffe wrote: I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I finally decided to compare headers from your non-threaded posts to other peoples' threaded posts. What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix that? I usually read and post to IBM-MAIN using the web interface. So this seems to be a LISTSERV problem. Is Darren IBM-MAIN's interface to L-Soft? No, its not a problem, its just an artifact of how this list works. Subjectively, it's a problem. You may not realize it but there are TWO entities called IBM-MAIN. One is a mailing list hosted at the listserver at bama.ua.edu. The second is the usenet group named bit.listserv.ibm-main. I'm well aware of this. The mailing list has a gateway to the usenet group but there is no reverse gateway. There used to be but it was taken down due to abuse. This has often been discussed here. So if someone originates a post by sending it to the mailing list, it will appear there and ALSO on the usenet group. But if someone originates a post on usenet, it will not be sent to the mailing list. Google Groups is fed from usenet so it is complete. The mailing list archives are ONLY fed by the listserv so they will miss anything that was only posted on usenet. Also well known. For folks who normally read usenet or Google Groups (which IS usenet although Goggle would like you to believe otherwise) here is what I do and what I suggest all usenet readers do also: I don't normally use Google groups, and I have no other access to Usenet. 1) Subscribe to the mailing list. I do. 2) Set yourself to NOMAIL on the listserv. I did that long ago. 3) When responding to a usenet post, DON'T use Followup. Instead use Reply and make sure that the email address gets set to: To: IBM-MAIN@bama.ua.edu. I don't use Usenet. That way your response will be seen on both the mailing list and on usenet, and will be in the IBM-MAIN archives at bama. Are you perhaps addressing a different problem from the problem (or non-problem, in your perception) that Ed reported? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 27/02/2012 5:01 AM, Edward Jaffe wrote: Paul Gilmartin, I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I finally decided to compare headers from your non-threaded posts to other peoples' threaded posts. What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix that? Thunderbird can be configured to also use the subject for threading: https://wiki.mozilla.org/MailNews:Message_Threading I have the opposite problem - many people start new threads by replying to an existing message and changing the subject - which means the In-Reply-To: header is inserted and the new thread is buried in an old one. I wish I could figure out how to make Thunderbird ignore the In-Reply-To: header, and just use the subject. Then changing the subject line woud start a new thread, which is usually what is intended. -- Andrew Rowley and...@blackhillsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In article 5564582964532228.wa.paulgboulderaim@bama.ua.edu you write: On Sun, 26 Feb 2012 17:51:33 -0500, Rich Greenberg wrote: In article you write: On Sun, 26 Feb 2012 10:01:36 -0800, Edward Jaffe wrote: What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix that? [snip] Are you perhaps addressing a different problem from the problem (or non-problem, in your perception) that Ed reported? Gil et al, I don't think so, but upon re-reading Ed's query, I see that I could have been more specific in my reply. /confession: I used a canned post that has been posted to the list several times over the years when this topic has come up. Inserting a Reply-To: header by the Listserv is an option that must be turned on. I think it is turned on, but have no way to verify this. Its also an option to respect or ignore an existing Reply-To: header. If a followup is made directly to usenet, its presence depends on the newsreader used and I think the default is NO. -- Rich Greenberg Sarasota, FL, USA richgr atsign panix.com + 1 941 378 2097 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines: Val,Red,Shasta,Zero,Casey Cinnar (At the bridge) Owner:Chinook-L Canines: Red Max (Siberians) Retired at the beach Asst Owner:Sibernet-L -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/26/2012 3:01 PM, Paul Gilmartin wrote: On Sun, 26 Feb 2012 17:51:33 -0500, Rich Greenberg wrote: No, its not a problem, its just an artifact of how this list works. Are you perhaps addressing a different problem from the problem (or non-problem, in your perception) that Ed reported? That's what I'm thinking -- Rich is discussing an entirely different issue... The missing In-Reply-To: tag seems to be a failure of the web interface, perhaps due misconfiguration or running a back-level release -- OR perhaps this tag is simply not supported AT ALL by the L-Soft web interface and an enhancement is needed. I tried to Google this, but there are a lot of hits that use those words and I don't have the time to research it. (I only use the web interface to conduct searches.) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/26/2012 3:29 PM, Rich Greenberg wrote: Inserting a Reply-To: header by the Listserv is an option that must be turned on. Rich, you're discussing a different problem. It's not the Reply-To: tag that is missing; it's the In-Reply-To: tag that is missing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Sun, 26 Feb 2012 18:29:47 -0500, Rich Greenberg wrote: In article you write: On Sun, 26 Feb 2012 17:51:33 -0500, Rich Greenberg wrote: In article you write: On Sun, 26 Feb 2012 10:01:36 -0800, Edward Jaffe wrote: What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix that? [snip] Are you perhaps addressing a different problem from the problem (or non-problem, in your perception) that Ed reported? Gil et al, I don't think so, but upon re-reading Ed's query, I see that I could have been more specific in my reply. Ed and I think so. /confession: I used a canned post that has been posted to the list several times over the years when this topic has come up. When has the topic that Ed raised been discussed here previously? (Cite.) A single canned reply does not suffice for all potential problems or subscriber misunderstandings. Inserting a Reply-To: header by the Listserv is an option that must be turned on. I think it is turned on, but have no way to verify this. Its also an option to respect or ignore an existing Reply-To: header. If a followup is made directly to usenet, its presence depends on the newsreader used and I think the default is NO. This has little or nothing to do with the In-Reply-To: header that Ed misses. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Sun, 26 Feb 2012 15:35:55 -0800, Edward Jaffe wrote: On 2/26/2012 3:29 PM, Rich Greenberg wrote: Inserting a Reply-To: header by the Listserv is an option that must be turned on. Rich, you're discussing a different problem. It's not the Reply-To: tag that is missing; it's the In-Reply-To: tag that is missing. Yes. Perhaps Rich has (or emulates) a 'bot that scans for the SUBstring Reply-To: and submits his canned message. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
In article 2832182203947394.wa.paulgboulderaim@bama.ua.edu you write: On Sun, 26 Feb 2012 15:35:55 -0800, Edward Jaffe wrote: On 2/26/2012 3:29 PM, Rich Greenberg wrote: Inserting a Reply-To: header by the Listserv is an option that must be turned on. Rich, you're discussing a different problem. Aparantly I am. I missed the In. Sorry about that. It's not the Reply-To: tag that is missing; it's the In-Reply-To: tag that is missing. I am unaware of the rules that control that tag. -- Rich Greenberg Sarasota, FL, USA richgr atsign panix.com + 1 941 378 2097 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines: Val,Red,Shasta,Zero,Casey Cinnar (At the bridge) Owner:Chinook-L Canines: Red Max (Siberians) Retired at the beach Asst Owner:Sibernet-L -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMP/E Order Server Pair
Last night's automatic SMP/E RECEIVE ORDER job failed with: GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - java.net.NoRouteToHostException: EDC8130I Host cannot be reached. GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. After being resubmitted this morning, it failed with the same issues. TSO TRACERTE to ECCGW01.BOULDER.IBM.COM shows: CS V1R13: Traceroute to ECCGW01.BOULDER.IBM.COM (207.25.252.197): 1 gateway10.phx (192.168.10.1) 6 ms 2 ms 3 ms 2 209.203.78.177 (209.203.78.177) 3 ms 4 ms 3 ms 3 lax2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.253.170) 3 ms 3 ms 3 ms 4 vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62) 8 ms vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254) 5 ms vlan80.csw3.LosAngeles1.Level3.net (4.69.144.190) 2 ms 5 ae-82-82.ebr2.LosAngeles1.Level3.net (4.69.137.25) 6 ms ae-62-62.ebr2.LosAngeles1.Level3.net (4.69.137.17) 2 ms 2 ms 6 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 13 ms 23 ms 19 ms 7 ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 22 ms 13 ms 14 ms 8 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 14 ms 13 ms 14 ms 9 ae-3-3.ebr1.Denver1.Level3.net (4.69.132.58) 49 ms 42 ms 50 ms 10 ae-1-51.edge5.Denver1.Level3.net (4.69.147.73) 39 ms 38 ms 39 ms 11 ATT-CORPORA.edge5.Denver1.Level3.net (4.53.6.66) 39 ms 40 ms 39 ms 12 170.225.30.182 (170.225.30.182) 40 ms 40 ms 40 ms 13 * * * .. 29 * * * 30 * * * hop limit reached: *** We manually switched to ECCGW02.ROCHESTER.IBM.COM, restarted the job and now it seems to be working. Unfortunately, this happens quite often. If one server is down, switch over to the other one. Wouldn't it be nice if you could specify a pair of server addresses to SMP/E such that if one failed it would automatically try the other? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Order Server Pair
On Sat, 25 Feb 2012 07:55:11 -0800, Edward Jaffe wrote: Wouldn't it be nice if you could specify a pair of server addresses to SMP/E such that if one failed it would automatically try the other? Can't something like this be done by the DNS, where one domain name can resolve to multiple IP addresses: 504 $ nslookup ECCGW01.BOULDER.IBM.COM Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: Name: ECCGW01.BOULDER.IBM.COM Address: 207.25.252.197 but: 505 $ nslookup www.google.com Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: www.google.com canonical name = www.l.google.com. Name: www.l.google.com Address: 74.125.45.106 Name: www.l.google.com Address: 74.125.45.147 Name: www.l.google.com Address: 74.125.45.99 Name: www.l.google.com Address: 74.125.45.103 Name: www.l.google.com Address: 74.125.45.104 Name: www.l.google.com Address: 74.125.45.105 I don't know how the client is expected to choose among the responses, nor what GetHostByName returns. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E: ++MOD DELETE CSECT( ??? )
Suppose I have: ++PTF (P1) . ++MOD (wombat) CSECT( foo ) . ++PTF (P2) SUP( P1 ) . ++MOD (wombat) CSECT( foo bar ) . ++PTF (P3) SUP( P1 P2 ) . ++MOD (wombat) DELETE CSECT( ??? ) . In this case the CSECT operand of P3 is ignored by APPLY. SMP/E will tell the binder to delete CSECTs based on whatever values had been specified on the prior ++MOD. So, if P1 only were applied, then only foo would be deleted from load modules. If both P1 and P2 were applied, then foo and bar would be deleted from load modules. If the original FMID, P1, and P2 all had neglected to specify any CSECTs, then the CSECT operand of P3 is used for the delete. Otherwise P3's CSECTs are ignored. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E: ++MOD DELETE CSECT( ??? )
On Tue, 31 Jan 2012 10:29:02 -0500, Kurt Quackenbush wrote: If the original FMID, P1, and P2 all had neglected to specify any CSECTs, then the CSECT operand of P3 is used for the delete. Otherwise P3's CSECTs are ignored. Thank you. RCF submitted -- I couldn't find this information in either SMP/E Reference or SMP/E Commands. Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMP/E: ++MOD DELETE CSECT( ??? )
The SMP/E Ref. states: CSECT lists all the CSECTs contained in the module. This operand is required if the module contains more than one CSECT or if the CSECT name is different from the module name on the ++MOD MCS. Suppose I have: ++PTF (P1) . ++MOD (wombat) CSECT( foo ) . ++PTF (P2) SUP( P1 ) . ++MOD (wombat) CSECT( foo bar ) . ++PTF (P3) SUP( P1 P2 ) . ++MOD (wombat) DELETE CSECT( ??? ) . Should the CSECT operand of P3 mention: o Only foo, if the customer has APPLYed only P1 previously (But this is invalid if the customer has APPLYed P2) o Both foo and bar in case the customer has APPLYed P2? Is this harmful if the customer has APPLYed only P1? Should P3 instead say, SUP( P1 ) PRE( P2 )? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. Multi-CSECT MOD Elements?
On 12/2/2011 12:05 PM, Paul Gilmartin scratched his head and wrote: If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this is done (in a warning, as if it were an extraordinary occurrence). Yes, the APPLY will generate REPLACE statements so the binder can delete the omitted CSECTs. If I RESTORE to the earlier version, does SMP/E put such CSECTs back? Where does it get them? The DLIB? SMP/E includes the MOD from the DLIB, so if the accepted level of the MOD has those CSECTs, then they will be added to the LMOD. If I APPLY a MOD that has more CSECTs than the earlier version, there should be no problem. When I RESTORE, does it REPLACE the additional CSECTS? (I seem to see this happening when I RESTORE a PTF that introduced an new MOD element; that's where I went wrong by not supplying a CSECT option -- not all CSECTS were REPLACEd, and the stragglers caused Binder errors.) Similar to APPLY, yes RESTORE should generate the appropriate REPLACE statements so the binder can delete the proper CSECTs. In the extreme, what happens if two or more MOD elements contain an identical CSECT? Without a more specific description of the scenario its hard to say, but as you surmise, this could get interesting. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
On 12/2/2011 12:05 PM, Kurt Quackenbush wrote: quote If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this is done (in a warning, as if it were an extraordinary occurrence). Yes, the APPLY will generate REPLACE statements so the binder can delete the omitted CSECTs. /quote How will APPLY know to replace (i.e. delete) the unreferenced CSECT's? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
On Mon, 5 Dec 2011 10:02:00 -0600, Staller, Allan wrote: How will APPLY know to replace (i.e. delete) the unreferenced CSECT's? When a SYSMOD includes a ++MOD that specifies the CSECTS that are included in that MOD, and another SYSMOD provides a replacement ++MOD that has a different list of CSECTS specified, SMP/E knows that there is a difference. This is not the same as providing a ++MOD that contains multiple CSECTS and not telling SMP/E about them. In that case, SMP/E would not know. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this is done (in a warning, as if it were an extraordinary occurrence). Yes, the APPLY will generate REPLACE statements so the binder can delete the omitted CSECTs. How will APPLY know to replace (i.e. delete) the unreferenced CSECT's? Consider the following: ++PTF(P1). ++VER ... ++MOD(A) CSECT(FOO,BAR). ++PTF(P2). ++VER ... PRE(P1). ++MOD(A) CSECT(FOO). SMP/E compares the CSECT lists for module A between the two PTFs and knows to delete BAR. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E vs. Multi-CSECT MOD Elements?
I am struggling with an ISV compiler that delights in producing multi-CSECT MOD elements. I've never needed to put a CSECT list in ++MOD MCS previously, but now I see that I need to. So, I wonder: If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this done (in a warning, as if it were an extraordinary occurrence). If I RESTORE to the earlier version, does SMP/E put such CSECTs back? Where does it get them? The DLIB? If I APPLY a MOD that has more CSECTs than the earlier version, there should be no problem. When I RESTORE, does it REPLACE the additional CSECTS? (I seem to see this happening when I RESTORE a PTF that introduced an new MOD element; that's where I went wrong by not supplying a CSECT option -- not all CSECTS were REPLACEd, and the stragglers caused Binder errors.) In the extreme, what happens if two or more MOD elements contain an identical CSECT? I can envision this happening without being a coding error if multiple assemblies need to COPY a SYSLIB definition of a data CSECT in order to know offsets -- when the load module is bound it doesn't matter which one is INCLUDEd -- all subsequent duplicates will be eliminated. (Yah, I know; it might be better to assemble it as a DSECT and deliver it as a separate MOD element. But isn't the rogue behavior endemic in C++ compiler output?) WHINE I wish SMP/E itself would scan the MOD elements to enumerate CSECTs, rather than placing the burden on the product developer, even as SMP/E scans inline assembler source for macro dependencies. Yah, I know; this would be easier for inline MOD elements than for RELFILE mod elements. /WHINE Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
Comments indented. HTH, I am struggling with an ISV compiler that delights in producing multi-CSECT MOD elements. I've never needed to put a CSECT list in ++MOD MCS previously, but now I see that I need to. So, I wonder: If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this done (in a warning, as if it were an extraordinary occurrence). No. The omitted CSECTS are still present. SMP works by including new CSECTS ahead of the existing LMOD. The L-Editor/Binder does the rest. IIRC, first occurrence of X wins. You will need to add replace statements for the omitted CSECTS and specify NCAL for the binder via a JCLIN to eliminate the deleted CSECTS.. The JCLIN will need to contain all of the explicit statements to build the new LMOD. You could probably accomplish the same thing w/UCLIN, (DEL MOD(x) LMOD(y). ??) but it seems like it would be harder get this right than to justreplace the necessary instructions to SMP/E. If I RESTORE to the earlier version, does SMP/E put such CSECTs back? Where does it get them? The DLIB? Yes. I believe it also gets the appropriate JCLIN from the DLIB version.. I am sure someone will correct me if this is not the case. If I APPLY a MOD that has more CSECTs than the earlier version, there should be no problem. Correct When I RESTORE, does it REPLACE the additional CSECTS? (I seem to see this happening when I RESTORE a PTF that introduced an new MOD element; that's where I went wrong by not supplying a CSECT option -- not all CSECTS were REPLACEd, and the stragglers caused Binder errors.) I do not believe so. See above. IIRC, the RESTORed LMOD will be built from the appropriate DLIB elements and JCLIN). In the extreme, what happens if two or more MOD elements contain an identical CSECT? I can envision this happening without being a coding error if multiple assemblies need to COPY a SYSLIB definition of a data CSECT in order to know offsets -- when the load module is bound it doesn't matter which one is INCLUDEd -- all subsequent duplicates will be eliminated. (Yah, I know; it might be better to assemble it as a DSECT and deliver it as a separate MOD element. But isn't the rogue behavior endemic in C++ compiler output?) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E DELETE/REDO/RESTORE Loophole?
I'm testing; this isn't production code on a production system. I created a PTF with ++ DELETE MCS. I APPLYed it, then tried to RESTORE it. SMP/E prohibited the operation, just as it's supposed to. I edited out the ++ DELETE; did REJECT; RECEIVE; APPLY REDO; RESTORE. All worked. Should this operation have been allowed? What's the state of my target library, now? (It's not my job to start up the application and test it.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
Thanks for your opinion. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, September 13, 2011 2:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge In 08ef7d7816b3b642a380513303a2d77b225c4...@alvmbxw02.prod.quest.corp, on 09/13/2011 at 07:17 PM, David Booher david.boo...@quest.com said: I posted this to DB2-L, but no takers :) Perhaps because it was a bad idea. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. Why? Foot, gun; gun, foot. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
You could point SDSNEXIT to a library you don't use for anything. SMP would still assemble and link DSNZPARM, but you wouldn't use the output module. In our case, I always delete the SMP step from DSNTIJUZ. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Booher Sent: Tuesday, September 13, 2011 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: Question for SMP/E gurus with DB2 knowledge I posted this to DB2-L, but no takers :) I was wondering if anyone was able to successfully 'unhook' the automatic assemblies of DSNZPARM, DSNDECP that result when maintenance hits the DSN6SPRM, DSN6ARVP, etc... macros? During job DSNTINUZ, step DSNTIMQ places entries into the target zone that generate automatic assembly and link of these members. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. I was wondering if anyone who has run DSNTIMQ has been able to successfully unhook its entries after the fact. Basically I've narrowed it down to the following entries in the target zone: MAC (DSN6ENV, DSN6SPRM, DSN6ARVP, DSN6LOGP, DSNHDECM, DSNHMCIM); ASSEM(DSNTILMM, DSNHDECA, DSNHMCIA); MOD(DSNTILMM, DSNHDECA, DSNHMCIA); LMOD(DSNHZAPRM, DSNDECP, DSNHMCID). Thanks, Dave Booher -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
Yes, on my new DB2 installs, I simply omit the step from DSNTIJUZ, but once it's run, the damage is done. You pin-pointed my problem on older systems, the APPLY CHECK works fine, but when you actually run the APPLY, it can fail because of a reference to an obsolete SDSNEXIT library. Your suggestion is worth a try. Unfortunately, once the damage is done to SMP, it's hard to reverse it. Thanks, Dave -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Clark, Stan [GCG-PFS] Sent: Wednesday, September 14, 2011 9:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge You could point SDSNEXIT to a library you don't use for anything. SMP would still assemble and link DSNZPARM, but you wouldn't use the output module. In our case, I always delete the SMP step from DSNTIJUZ. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Booher Sent: Tuesday, September 13, 2011 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: Question for SMP/E gurus with DB2 knowledge I posted this to DB2-L, but no takers :) I was wondering if anyone was able to successfully 'unhook' the automatic assemblies of DSNZPARM, DSNDECP that result when maintenance hits the DSN6SPRM, DSN6ARVP, etc... macros? During job DSNTINUZ, step DSNTIMQ places entries into the target zone that generate automatic assembly and link of these members. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. I was wondering if anyone who has run DSNTIMQ has been able to successfully unhook its entries after the fact. Basically I've narrowed it down to the following entries in the target zone: MAC (DSN6ENV, DSN6SPRM, DSN6ARVP, DSN6LOGP, DSNHDECM, DSNHMCIM); ASSEM(DSNTILMM, DSNHDECA, DSNHMCIA); MOD(DSNTILMM, DSNHDECA, DSNHMCIA); LMOD(DSNHZAPRM, DSNDECP, DSNHMCID). Thanks, Dave Booher -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
Caveat: Moved on to other products, so it's been a few years since I was a db2 sysprog so I may just being dense. It isn't clear what damage you're trying to reverse, or perhaps I don't understand what obsolete means in this context. Why would the SMP/E defined SDNSEXIT dsn be classified on an APPLLY as missing or obsolete in your current CSI? If you ran step DSNTIMQ and it found a DSN to put the member in, why is it obsolete? tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Booher Sent: Wednesday, September 14, 2011 10:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge Yes, on my new DB2 installs, I simply omit the step from DSNTIJUZ, but once it's run, the damage is done. You pin-pointed my problem on older systems, the APPLY CHECK works fine, but when you actually run the APPLY, it can fail because of a reference to an obsolete SDSNEXIT library. Your suggestion is worth a try. Unfortunately, once the damage is done to SMP, it's hard to reverse it. Thanks, Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Question for SMP/E gurus with DB2 knowledge
I posted this to DB2-L, but no takers :) I was wondering if anyone was able to successfully 'unhook' the automatic assemblies of DSNZPARM, DSNDECP that result when maintenance hits the DSN6SPRM, DSN6ARVP, etc... macros? During job DSNTINUZ, step DSNTIMQ places entries into the target zone that generate automatic assembly and link of these members. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. I was wondering if anyone who has run DSNTIMQ has been able to successfully unhook its entries after the fact. Basically I've narrowed it down to the following entries in the target zone: MAC (DSN6ENV, DSN6SPRM, DSN6ARVP, DSN6LOGP, DSNHDECM, DSNHMCIM); ASSEM(DSNTILMM, DSNHDECA, DSNHMCIA); MOD(DSNTILMM, DSNHDECA, DSNHMCIA); LMOD(DSNHZAPRM, DSNDECP, DSNHMCID). Thanks, Dave Booher -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question for SMP/E gurus with DB2 knowledge
In 08ef7d7816b3b642a380513303a2d77b225c4...@alvmbxw02.prod.quest.corp, on 09/13/2011 at 07:17 PM, David Booher david.boo...@quest.com said: I posted this to DB2-L, but no takers :) Perhaps because it was a bad idea. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. Why? Foot, gun; gun, foot. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E REPORT SYSMODS mistery
Hello list, I've just ran a simple comparison between two target zones : REPORT SYSMODS INZONE(ZOSENT) COMPAREDTO(ZOSPROD). to my surprise, SMP/E found no SYSMODs to report. Then I tried REPORT SYSMODS INZONE(ZOSPROD) COMPAREDTO(ZOSENT). reverting the order of my target zones, and SMP/E found (as expected) the discrepancies between the zones. Shouldn't be both commands above identical ?I've never seen anything like this before. Any hints ? Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E REPORT SYSMODS mistery
Walter, the manual says: The SYSMOD comparison report provides you with a summary of the SYSMODs found in the input zone, but not found in the comparison zone. It seems like it's built for running on the 'main' or 'base' zone, and comparing to your 'deploy' zone. We use it to send out holddata to different teams when we're getting ready to put maintenance on. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E REPORT SYSMODS mistery
On Thu, 18 Aug 2011 06:07:02 -0700, Walter Marguccio walter_marguc...@yahoo.com wrote: Hello list, I've just ran a simple comparison between two target zones : REPORT SYSMODS INZONE(ZOSENT) COMPAREDTO(ZOSPROD). to my surprise, SMP/E found no SYSMODs to report. Then I tried REPORT SYSMODS INZONE(ZOSPROD) COMPAREDTO(ZOSENT). reverting the order of my target zones, and SMP/E found (as expected) the discrepancies between the zones. Shouldn't be both commands above identical ?I've never seen anything like this before. Any hints ? = This isn't like ISPF compare where it shows all differences regardless of the 2 targets of the compare.Read the description of the command carefully.The report shows SYSMODS where ARE IN the input zone (INZONE) but NOT IN the COMPAREDTO zone. So order does matter. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E REPORT SYSMODS mistery
Mary Anne, my bad, I didn't RTFM as I should have. Thank you very much. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E REPORT SYSMODS mistery
So order does matter. Got it, Mark, sorry ... Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E RECEIVE ORDER failures
FYI - The RECEIVE ORDER service is failing for me this morning when using eccgw01.boulder.ibm.com but seems to be OK on eccgw02.rochester.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E RECEIVE ORDER failures
David, Thanks for this heads-up. I submitted an order twice to Boulder and cancelled each job, which appeared to get in some kind of loop. Submitted to Rochester; worked fine the first time. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: David Magee david.ma...@dillards.com To: IBM-MAIN@bama.ua.edu Date: 08/01/2011 08:41 AM Subject:SMP/E RECEIVE ORDER failures Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu FYI - The RECEIVE ORDER service is failing for me this morning when using eccgw01.boulder.ibm.com but seems to be OK on eccgw02.rochester.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E SAF Enhancement (was Re: CEEXOPT macro ...)
... I have experimentally built and tested simple GIMZIP-style archives outside SMP/E, using conventional utilities not SAF-controlled, such as IEBCOPY, IEBGENER, SHA-1, ... By doing this and eschewing GIMZIP do I gain security by eliminating the possibility that I might inadvertently activate the ineffable security threat? Or, since I am performing functions equivalent to GIMZIP's, do I incur an equivalent risk? Are you driving those utilities from a program that is APF authorized? If so, then you might be similarly exposed. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E SAF Enhancement (was Re: CEEXOPT macro ...)
On Thu, 14 Jul 2011 14:37:29 -0400, Mark Jacobs mark.jac...@custserv.com wrote: I asked IBM specifically whether the then new SAF profiles were used while using the query functions in the SMP/E ISPF interface and their answer was no. (I hate mixing top posting and bottom posting, so I snipped the prior context ... sorry. Also changed the subject). If that is true, it sounds inconsistent with what the enhancement is doing (unless things like LIST and REPORT aren't protected). So you protect the LIST command, but don't specifically protect the ISPF libraries because the HLQs are SYS1 and everyone has read access to SYS1. Then someone can just execute the ISPF interface and do the equivalent of LIST. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E SAF Enhancement (was Re: CEEXOPT macro ...)
On Thu, 14 Jul 2011 14:22:46 -0500, Mark Zelden m...@mzelden.com wrote: On Thu, 14 Jul 2011 14:37:29 -0400, Mark Jacobs mark.jac...@custserv.com wrote: I asked IBM specifically whether the then new SAF profiles were used while using the query functions in the SMP/E ISPF interface and their answer was no. (I hate mixing top posting and bottom posting, so I snipped the prior context ... sorry. Also changed the subject). If that is true, it sounds inconsistent with what the enhancement is doing (unless things like LIST and REPORT aren't protected). So you protect the LIST command, but don't specifically protect the ISPF libraries because the HLQs are SYS1 and everyone has read access to SYS1. Then someone can just execute the ISPF interface and do the equivalent of LIST. It is true. Remember that the SMP/E enhancement was made to close a system integrity exposure, which existed because SMP/E runs authorized. The query function via the ISPF panels does not run authorized, and does not participate in the integrity exposure, and so did not need that enhancement. And in any case, because the query function does not run authorized, if we had put a security check in it to allow control of the query function it would not be fully effective; a somewhat clever user would be able to bypass it. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E SAF Enhancement (was Re: CEEXOPT macro ...)
On Thu, 14 Jul 2011 14:22:46 -0500, Mark Zelden wrote: On Thu, 14 Jul 2011 14:37:29 -0400, Mark Jacobs mark.jac...@custserv.com wrote: I asked IBM specifically whether the then new SAF profiles were used while using the query functions in the SMP/E ISPF interface and their answer was no. (I hate mixing top posting and bottom posting, so I snipped the prior context ... sorry. Also changed the subject). I whitewash with the (implied) phrase, comments inline. Thanks for changing the subject. If that is true, it sounds inconsistent with what the enhancement is doing (unless things like LIST and REPORT aren't protected). So you protect the LIST command, but don't specifically protect the ISPF libraries because the HLQs are SYS1 and everyone has read access to SYS1. Then someone can just execute the ISPF interface and do the equivalent of LIST. You're both right. In: SMP/E for z/OS User's Guide Document Number SA22-7773-15 I read: 3.1 Authorizing use of SMP/E commands and services The System Authorization Facility (SAF) restricts the use of certain SMP/E functions to users who have appropriate access to the SAF resources that protect those functions. The functions being controlled are all the SMP/E commands processed by program GIMSMP (for example, SET, RECEIVE, APPLY, ACCEPT, UCLIN, LIST, REPORT, and so on), the GIMZIP and GIMUNZIP service routines, and the GIMIAP copy utility invocation program. ... However, of all the functions described above, several need to be controlled very carefully. Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. Therefore, they should be as trusted, for example, as users who have authority to update APF authorized libraries. These functions, and the corresponding SAF FACILITY class resources that SMP/E checks, are as follows: Table 2. Function and resource name that SMP/E checks Function Resource name RECEIVE command GIM.CMD.RECEIVE APPLY command GIM.CMD.APPLY ACCEPT commandGIM.CMD.ACCEPT RESTORE command GIM.CMD.RESTORE REJECT commandGIM.CMD.REJECT LINK command GIM.CMD.LINK CLEANUP command GIM.CMD.CLEANUP Program GIMZIPGIM.PGM.GIMZIP Program GIMUNZIP GIM.PGM.GIMUNZIP Program GIMIAPGIM.PGM.GIMIAP So, apparently, while LIST and REPORT are not in the list of functions having the potential to undermine system security regardless ..., there are nonetheless SAF resources restricting access to them (smokescreen). Which brings to mind another question: I have experimentally built and tested simple GIMZIP-style archives outside SMP/E, using conventional utilities not SAF-controlled, such as IEBCOPY, IEBGENER, SHA-1, ... By doing this and eschewing GIMZIP do I gain security by eliminating the possibility that I might inadvertently activate the ineffable security threat? Or, since I am performing functions equivalent to GIMZIP's, do I incur an equivalent risk? With great curiosity, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E SAF Enhancement (was Re: CEEXOPT macro ...)
On Thu, 14 Jul 2011 15:15:58 -0500, Walt Farrell wfarr...@us.ibm.com wrote: On Thu, 14 Jul 2011 14:22:46 -0500, Mark Zelden m...@mzelden.com wrote: On Thu, 14 Jul 2011 14:37:29 -0400, Mark Jacobs mark.jac...@custserv.com wrote: I asked IBM specifically whether the then new SAF profiles were used while using the query functions in the SMP/E ISPF interface and their answer was no. (I hate mixing top posting and bottom posting, so I snipped the prior context ... sorry. Also changed the subject). If that is true, it sounds inconsistent with what the enhancement is doing (unless things like LIST and REPORT aren't protected). So you protect the LIST command, but don't specifically protect the ISPF libraries because the HLQs are SYS1 and everyone has read access to SYS1. Then someone can just execute the ISPF interface and do the equivalent of LIST. It is true. Remember that the SMP/E enhancement was made to close a system integrity exposure, which existed because SMP/E runs authorized. The query function via the ISPF panels does not run authorized, and does not participate in the integrity exposure, and so did not need that enhancement. And in any case, because the query function does not run authorized, if we had put a security check in it to allow control of the query function it would not be fully effective; a somewhat clever user would be able to bypass it. Ah yes. Thanks for the reminder of what the intended purpose was and clarification on why it isn't needed nor implemented for ISPF query. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E MCS Syntax
In: Title: SMP/E V3R5.0 for z/OS V1R12.0 Reference Document Number: SA22-7772-14 Build Date: 06/03/10 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/gimrfr42/1.2 I read: 1.2 Syntax rules for MCS and SMPPARM members For MCSs, do the following: o Code the ++ for the MCS in columns 1 and 2. o Code the MCS name on the same line as the ++. The chapter heading calls this a rule, not a suggestion. However, one of our developers coded ++ HOLD ..., indented five positions, not starting in columns 1 and 2. Some of my administrative tools rejected it. However, the developer stated he had tested it, and SMP/E accepted it. (Can anyone else confirm or refute this?) This is chaotic; I'm inclined to PMR SMP/E's failure to report the syntax error. (Particularly irritating in that the developer reacted by shifting the entire file left 5 positions. Now SMP/E is complaining about sequence numbers starting in col. 67.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E DLIB DDDEFs in MVST100
In 2d14e7856646224aacdda13ab1d355570ecd84d...@wdcv7exvs2.opm.gov, on 04/20/2011 at 08:00 AM, Richards, Robert B. robert.richa...@opm.gov said: I just found DLIB DDDEFs in my MVST100 target zone in my z/OS 1.12 SMPEMVS CSI. And some of those entries in the SYSLIB DDDEF as well. Has something changed or is this now the new normal? It's normal to have DLIB datasets behind MTS in the SYSLIB that's because of macros that are DLIB only. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E DLIB DDDEFs in MVST100
I guess that cardiac bypass machine really did steal a few memory cells. For some reason, it didn't look right. Having said that, the explanations made perfect sense! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Wednesday, April 20, 2011 4:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMP/E DLIB DDDEFs in MVST100 ---snip- I just found DLIB DDDEFs in my MVST100 target zone in my z/OS 1.12 SMPEMVS CSI. And some of those entries in the SYSLIB DDDEF as well. Has something changed or is this now the new normal? --unsnip--- IIRC, it's been that was for a LOOONG time, Bob. The DLIB datasets must be known to the target zone in order to do a RESTORE of a PTF. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E DLIB DDDEFs in MVST100
I just found DLIB DDDEFs in my MVST100 target zone in my z/OS 1.12 SMPEMVS CSI. And some of those entries in the SYSLIB DDDEF as well. Has something changed or is this now the new normal? Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.govmailto:robert.richa...@opm.gov - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E DLIB DDDEFs in MVST100
W dniu 2011-04-20 14:00, Richards, Robert B. pisze: I just found DLIB DDDEFs in my MVST100 target zone in my z/OS 1.12 SMPEMVS CSI. And some of those entries in the SYSLIB DDDEF as well. Has something changed or is this now the new normal? It is normal -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E DLIB DDDEFs in MVST100
I just found DLIB DDDEFs in my MVST100 target zone in my z/OS 1.12 SMPEMVS CSI... Has something changed or is this now the new normal? Its normal, although not new. RESTORE, and sometimes APPLY, have a need to get at the distribution libraries, hence the DDDEF entries for those libraries must be defined in the target zone. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
